Hi Connor, As promised in the previous bug report (Bug #91113, Comment #44), I am back at my place, so I will be filing several bugs I have observed with the r128 x.org DDX device driver since I have far more equipment for doing extensive testing at my place. I downloaded the source code for r128 from the Git repository, compiled it, and installed it on Ubuntu 10.04 LTS i386 (not Lubuntu 10.04 this time around). The mainboard I used for testing is ECS L4S5A/DX+ mainboard (SiS 645DX north bridge and SiS 962 south bridge). This mainboard supports ACPI S1 and S3 state (S3 state works, but the BIOS setup sometimes loses the S3 state option. There is a trick I use to get the S3 state option back. The BIOS I have is the last release version. Note that the S3 state resume itself works 100% of the time with other AGP graphics cards.). The graphics card I used was Rage 128 AGP 16 MB. Note that it is not Rage 128 Pro. It is the older version of Rage 128 with AGP 3.3V signalling support only (AGP 1x and 2x modes). I put the computer into ACPI S3 state, resumed it, and the computer will freeze. Screen does come back on, but there is nothing displayed on the screen, and the computer is not responsive. I will test another Rage 128 Pro with this mainboard as well soon, but already one Rage 128 Pro AGP was not able to boot X server with this mainboard due to the card itself using an internal DVI output instead of a VGA output for the monitor despite having a physical VGA output connector (more on this in a different bug report). A week ago, I also tested Rage 128 Pro AGP 32 MB with Intel D845PEBT2 mainboard, and ACPI S3 state resume did not work (i.e., freeze). Note that Intel D845PEBT2 mainboard's ACPI S3 state resume works 100% of the time with Radeon 9550SE and Lubuntu 12.04. I will not have access to this mainboard for many months, but I can easily find a comparable mainboard to this one. Let me know which log files you want, and I will get them ready. Regards, Kevin Brace
Created attachment 117153 [details] xorg.conf (Try 1) Functioning minimalist xorg.conf.
Created attachment 117154 [details] xorg.conf (Try 1) Functioning minimalist xorg.conf.
Created attachment 117155 [details] Xorg.0.log (Try 1)
Created attachment 117156 [details] pm-suspend.log (Try 1)
Created attachment 117157 [details] kern.log that was edited kern.log was edited due to its size (earlier boot added lots of junk, so I got rid of that stuff). The computer did come out of standby, but graphics subsystem went nuts.
Created attachment 117158 [details] kern.log that was edited (Try 1) kern.log was edited due to its size (earlier boot added lots of junk, so I got rid of that stuff). The computer did come out of standby, but graphics subsystem went nuts.
Created attachment 117159 [details] lspci output (Try 1)
Hi Connor, The log files I attached are subpar when it comes to analyzing what happened when the computer came out of standby. Screen does go nuts when it comes out, and keyboard and mouse will not work anymore (I am using USB keyboard and mouse here). I will try doing another log file capture so that you have a better picture of what is going on. It is not very easy to capture relevant information in Linux when it crashes, and I have been frustrated with this for years. Looking at the Xorg.0.log, it appears that r128 is executing some code after the resume, but it appears that something is crashing in your code. Again, the mainboard firmware's ACPI code is solid when it comes to executing the ACPI S3 state resume code, so the fault lies in your code at this point (i.e., resume works 100% of the time with Radeon 9700 AGP). Regards, Kevin Brace
Created attachment 117160 [details] kern.log that was edited (Try 2) kern.log was edited due to its size (earlier boot added lots of junk, so I got rid of that stuff). The computer did come out of standby, but graphics subsystem went nuts. This one contains a little more information than the first one I posted.
Suspend support was always bad on the Thinkpad I used so I've never done this with an r128 card. Have you seen this work for any version of the driver? I was going to ask if switching VTs could get rid of the graphics mess, but if you say the keyboard doesn't even work then there's no way to make a VT switch. Is it the same system except for the video card? It sounds like with the Radeon card, graphics and input both work after resuming and with the Rage card, graphics and input both break. What is the last line of the Xorg.0.log file before you go into S3 state? Is it "(II) AIGLX: Suspending AIGLX clients for VT switch"?
(In reply to Connor Behan from comment #10) Hi Connor, Thank you for the response. I will try to switch to VT mode when I put the computer into standby. Obviously, when the screen freezes, the keyboard does not work, so I cannot switch to VT. Regarding Rage 128 and ACPI S3 state resume, before you got involved in the development (the pre-2012 code base), Rage 128 Pro AGP "did" work with ACPI S3 state resume, but for some reason it did not work with Rage 128 AGP (i.e., non-pro Rage 128). I know this because I did some testing with Ubuntu 10.04 while ago. I do not know why ACPI S3 state resume does not work with Rage 128. Here is my understanding of ACPI S3 state (Also known as STR or Suspend to RAM) implementation history. Desktop mainboards supporting ACPI S3 state started to show up around year 2001 or so (i.e., around the time of Windows XP launch). I would imagine that this might had something to do with the precondition for obtaining the coveted Windows XP logo certification (Note: speculation). Anyway, I know Windows 2000's ACPI S3 state support is good (since I still have a Windows 2000 box around and use it with a mainboard that supports ACPI S3 state), and it works as long as ACPI S3 state is supported by the mainboard and ACPI S3 state was available at the time of the installation (there is a special utility called dumppo.exe that allows retroactive activation of ACPI S3 state standby). From system's perspective, what ACPI S3 state does is to put OS state information into the RAM, letting the ACPI BIOS of the mainboard put the main memory (DRAM) into self refresh mode (as far back as SDRAM supports self refresh mode), and allow the power supply to pull the power except +5VSB (+5V Standby) power rail of the mainboard power supply. The DRAM chip itself contains self refresh circuitury, so the contents of the DRAM should stay there (When the DRAM controller is active, DRAM controller actively refreshes the DRAM every once in a while. The exact refresh period is implementation dependent. In a current DDR3 SDRAM-based system, the distributed refresh period is 7.8us. 64 ms / 8192). The interesting thing is, even Intel brand mainboards had ACPI S3 state related issues, and I recall seeing several of their Intel 815 chipset mainboards' BIOS being updated for ACPI S3 state resume related issues (i.e., even Intel had issues with ACPI S3 state implementation). ACPI S3 state, in my opinion, is like stopping a human heart temporarily (i.e., pulling most power rails), so it is very difficult to implement and debug. The reason why I am using this obscure mainboard called ECS L4S5A/DX+ for testing Rage 128 and Rage 128 Pro graphics card is because around the time of mainboard manufacturers started supporting ACPI S3 state in their BIOS, Intel dropped supporting AGP 3.3V signaling graphics cards. http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?DetailID=21&MenuID=24&LanID=9 Intel supported AGP 3.3V signaling cards (i.e., graphics cards that are capable of AGP 1X and / or 2X mode) until Intel 815 / 820 / 840 chipsets, but stopped supporting them since 850 chipset (i.e., first Pentium 4 chipset with Rambus DRAM support). The first mainstream Pentium 4 chipset called Intel 845 does not support AGP 3.3V card either. Anyway, SiS 645 chipset does support AGP 3.3V signaling cards, is Pentium 4-based, supports ACPI S3 state (does have a strange settings related bug, but I can work around it), and the AGP 4X mode support was fairly reliable unlike VIA Technologies at the time (i.e., Apollo Pro133A), so I prefer using this mainboard for my old AGP graphics cards testing rather than Intel 815 chipset-based system (i.e., Intel cripped 815 chipset in terms of memory subsystem performance and maximum capacity RAM of only 512 MB) since I am currently running this board with 2.53 GHz Pentium 4 (still quite capable as a basic computer even today). Anyway, Rage 128 does not support AGP 1.5V signaling, so it can be used only with mainboards that support AGP 3.3V signaling (i.e., left side of the AGP edge connector has the "cut."). However, Rage 128 Pro does support AGP 1.5V signaling and its associated 4X mode, so it can be used with the newer mainboards (Rage 128 Pro is a universal AGP card, so it can still run with mainboards with an AGP 3.3V slot) that lack AGP 3.3V signaling support (i.e., both left and right sides of the AGP edge connector have the "cut."). Yes, Radeon, especially R300 or later Radeon (i.e., R300 = Radeon 9700 if I am correct. Radeon 9500, 9550, and 9600 used RV350-based chip) works very well with ACPI S3 state resume. In fact, at this point, I believe Radeon 9500 or later Radeon is the most stable (least buggy) AGP graphics card with Linux, probably due to AMD releasing hardware programming information many years ago, and from my observation, had several prominent Linux developers worked on it (i.e., Alex Deucher). I have tested Radeon 9700 with several different mainboards (various Intel, NVIDIA, SiS, and VIA Technologies chipset-based mainboards), and ACPI S3 state resume fine with various Ubuntu releases. Regarding this obscure ECS mainboard called ECS L4S5A/DX+ I am using for testing purpose, I have tested ACPI S3 state resume with 3dfx Banshee-based AGP graphics card (i.e., AGP 3.3V signaling card), and while it has to do what people call "VGA BIOS RePOST," (i.e., the graphics card needs to reenter the VGA BIOS to perform Power On Self Test) the graphics card does resume 100% of the time. Please note that newer graphics cards do not have to perform VGA BIOS RePOST (This option is selectable in some mainboard BIOS setup. In fact, ECS L4S5A/DX+ allows me to select this, but I usually keep it at "Auto."). I can test a few more different graphics cards as well, as far as I am concerned, there are some serious problems with the Rage 128 code standby resume code path, and it is not the fault of this mainboard's ACPI BIOS. Regarding your IBM ThinkPad with Rage 128-based graphics chip, it is possible that it might not support ACPI S3 state. As far as I know, I do not own or know an Intel 440BX chipset mainboard with supporting ACPI S3 state. https://en.wikipedia.org/wiki/Intel_440BX Even Intel did not support ACPI S3 state with their own branded mainboards. However, S1 state (Power on Suspend) is well supported by 440BX chipset. Here is some basic concepts of ACPI. https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface There was a bug in ACPI S3 state related feature support (i.e., self refresh) for 440BX, but it was fixed in later revision (Errata 12, SDRAM Suspend Refresh). http://www.intel.com/design/chipsets/specupdt/29063906.pdf You laptop probably has C-1 stepping, so it is probably not affected by it, but there is no guarantee the BIOS supports ACPI S3 state. That being said, it is a laptop, so maybe the support has to be there as a merchandise. I am not too knowledgeable about APM (Advanced Power Management), so I will not discuss it here for now. I believe dmesg displays ACPI state support, so you may want to take a look at this to see if S3 state is supported by your laptop. AIGLX message displayed is the last message recorded by Xorg.0.log. I attached that file verbatim. If you can sprinkle some debug messages to the likely code path during resume, that might help analyze the bug. However, kern.log had to be truncated due to the freeze. The message recorded there is practically the last word of the kernel before the freeze. If you look at the log, the resume is succeeding up to certain point. In other words, the BIOS code is fine, and is successfully coming back to the OS kernel. When the system freezes, the log recording stops, so that is the best I can do for now unless someone else can teach me a better way to collect log information. Regards, Kevin Brace > Suspend support was always bad on the Thinkpad I used so I've never done > this with an r128 card. Have you seen this work for any version of the > driver? > > I was going to ask if switching VTs could get rid of the graphics mess, but > if you say the keyboard doesn't even work then there's no way to make a VT > switch. Is it the same system except for the video card? It sounds like with > the Radeon card, graphics and input both work after resuming and with the > Rage card, graphics and input both break. > > What is the last line of the Xorg.0.log file before you go into S3 state? Is > it "(II) AIGLX: Suspending AIGLX clients for VT switch"?
It sounds like this has more to do with the kernel. Does suspending improve if you use X without any r128 kernel code? Remove or blacklist the r128 module so that it does not appear in your lsmod. This will break acceleration and make the session slower but if S3 resume works, we'll know the problem is there. If the problem really is in the DDX, I don't have any good suggestions. Just see if the VT switch provides a workaround and try to identify the specific commit where the Rage 128 Pro AGP stopped working.
Kevin Brace, Ubuntu 10.04 Desktop reached EOL on May 9, 2013. For more on this, please see https://wiki.ubuntu.com/Releases . If this is reproducible in a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal: ubuntu-bug xorg Also, please feel free to subscribe me to it. For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.