Distribution: Ubuntu Breezy Hardware Environment: Acer Aspire 1304LC, Savage Twister VT8636A [ProSavage KN133] Software Environment: xorg 6.8.2, any recent Savage DRI driver snapshot from http://dri.freedesktop.org/snapshots/ Problem Description: When using DRI drivers for my Savage graphics card, everything works fine until after a suspend/resume cycle (I use the suspend2 patches). After resuming, glxinfo still reports "direct rendering: Yes" but running glxgears locks the system hard directly, the glxgears window doesn't even open. According to Savage developer Felix K
Just tried 2.6.12 with the latest DRI snapshot, no change.
is this still an issue with 2.6.15 ? (And please test with the in-kernel suspend implementation. If you want to debug issues with suspend2, they have their own bugtracker at http://bugzilla.suspend2.net/ If it is still repeatable under that situation, please attach output of lspci and dmesg | grep -i agp
I got a new laptop, so I'm afraid I can't help you with this bug anymore.
I am using 2.6.15 from Ubuntu (6.06 Beta 2), and I have the exact same problem. There is some verbose drm output in my Ubuntu bug report: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/43007
I still have DRI/drm crashing after hibernation (no suspend2) in Ubuntu Edgy Beta: kernel 2.6.17-10.28 drm 1.0.1 20051102 savage 2.4.1 20050313 xserver-xorg-video-savage 1:2.1.1-0ubuntu3 If I try to run glxgears after hibernation, the machine locks up hard with this last message: Oct 10 02:42:14 viki kernel: [17192405.404000] [drm:savage_bci_wait_event_shadow] *ERROR* failed! Oct 10 02:42:14 viki kernel: [17192405.404000] [drm] status=0x00003d7e, e=0x3d88 https://launchpad.net/bugs/37218
It seems like I can avoid the crashes with Option "BusType" "PCI" alone. Using Option "DmaMode" "None" alone helps for glxgears, but crashes with other 3D screensavers.
I still get these crashes using Ubuntu 7.04 Beta with kernel 2.6.20 and Xorg 7.2. Can anyone suggest a way to debug this further?
I think we have a general problem with DRI. Bug #7417 seems to be related to this one.
It seems to be AGP in particular, from my experience. Many Savage cards needs BusType PCI instead of AGP to not crash, and the same is true for some ATI agp cards. It could be that the relevant parts the savage drivers are based on the ati drivers, but it could also be a more general problem in drm or agp modules. Examples: https://bugs.launchpad.net/bugs/33617 (savage) https://bugs.launchpad.net/bugs/114520 (ati) (The last one is a PCI card, but w/comments from AGP users) Note that in bug #7417 only Xorg crashes or goes bananas, and not the kernel, as in my case. And I don't get problems if I shut down Xorg before hibernation (it's just that it makes hibernation almost pointless). Please tell if I can help with some debugging/testing.
Out of couriosity, have you tried X without DRI?
Sure! It is only a problem with DRI enabled. That goes for all these savage/ati issues.
*** Bug 7417 has been marked as a duplicate of this bug. ***
Tormod, can you please confirm that the problem is still present in 2.6.23?
Yes, same issue with 2.6.23.1, running on top of Ubuntu 7.10. Like before, after waking up from hibernation, as soon as I start glxgears it hangs. I can move the mouse pointer for a second, leaving a trace of mouse pointers on the screen. Then everything is stuck, no sysrq, only hard power-off is possible.
Is this still an issue with 2.6.32?
Is the problem reproducible with 2.6.37-rc8?
Tested with 2.6.37 (Ubuntu 2.6.37-12-generic on top of Ubuntu 10.10) and it works fine, both with AGP and PCI. Thanks!
Created attachment 43882 [details] kernel messages That was too good to be true. I tested yesterday by using PCI mode after booting, sleep/resume - antspotlight - sleep/resume - antspotlight, then restarted X with AGP mode and repeated the testing. Which all seemed to work fine. Today I booted with AGP mode, and then antspotlight caused page allocation failure, with this seen in strace (fd 4 is /dev/dri/card0): [pid 2089] ioctl(4, 0x40246441, 0xbf9b5aac) = -1 ENOMEM (Cannot allocate memory) [pid 2089] write(2, "cmdbuf ioctl returned -12\n", 26) = 26 After sleep/resume I got a solid lock-up when starting antspotlight. Starting up with AGP mode, then restarting X with PCI mode, I can now sleep/resume again. However I think there is an issue in the DDX driver. I have been investigating https://bugs.freedesktop.org/show_bug.cgi?id=32511 where mesa has been writing into the wrong framebuffer aperture. Running drawpix after resume, I can see that the back buffer aperture becomes wrong - it is now tiled (I mean it draws into small squares on the top of the screen instead of displaying the picture in the window). The front buffer is fine. So I guess there is something missing in the DDX that should set up the apertures again at resume. If for instance the command buffer also gets mismapped after resume I guess a lock-up is not far away. So I think this kernel bug task can stay closed until we make sure the DDX does the right thing.
I think I am closing in on this 6 year old bug, and that the problem is the VIA agp bridge. Hacking the DDX to call drmAgpEnable after resume (in EnterVT) seems to fix the lock-up issue. I am a bit puzzled by this appearing on boot and resume: agpgart-via 0000:00:00.0: putting AGP V2 device into 0x mode although the drmAgpEnable is called with mode=1. Is the 0x expected? Can it be bridge_agpstat is read out from PCI_AGP_STATUS with the mode bits 0 and this falls through all the cracks in agp_collect_device_status and agp_v2_parse_one? Should there be something in the agp driver (or via-agp) that sets up the mode correctly again on resume? I believe there is something special about this VIA bridge in that the pci_restore_state is not enough.
Created attachment 54512 [details] Reenable with previously set mode on resume Would this (untested) patch make sense?
BTW, with regards to the x0 above, drmAgpGetMode always returns 0x1f000207.
I looked at other DDX's and the radeon DDX in fact calls drmAgpEnable in EnterVT after resume. So I will just go on and commit that to the savage DDX as well. It would be appreciated though if someone can comment on whether this is how it is supposed to work, or if this is a workaround.