s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 "Rafael J. Wysocki" wrote: > On Sunday 02 May 2010, Bruno Pr?mont wrote: > > On Sun, 02 May 2010 Alan Stern wrote: > > > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > > > It freezes during device suspend (unless I rmmod everything USB > > > > related) - usb fails even in pm_test case 'devices'. > > > > > > > > When the system is able to suspend it takes an eternity (more than 3 > > > > minutes to wake-up, the radeon apparently being responsible for quite > > > > a big share of that slowness. > > > > > > > > > > > > During resume early it looks like every PCI access needs about a second, > > > > and there are a few cases where during lots of seconds nothing seems to > > > > happen and the first event following is related to radeon. > > > > > > > > The kernel used is todays Linus's tree at commit > > > > be1066bbcd443a65df312fdecea7e4959adedb45 > > > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > > > > > Note, I've not been able to suspend to RAM properly recently (last one > > > > that worked correctly but resumed without graphics was some-when during > > > > 2.6.2x, before KMS) > > > > Since then the system would either fail suspend or resume. > > > > > > > > Manual changes I applied in order to find out some context information: > > > > - add a few debugging printk's to ata/ahci as that was the last entry > > > > on serial console for freezing suspends (that one succeeded but > > > > following step never completed, from suspend_prepare that would have > > > > been USB => unload usb before suspend) > > > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so > > > > serial > > > > console would continue working as long as possible and output suspend > > > > progress (resume output happens only very late) > > > > > > > > Is there some additional information I could gather in order do help > > > > improving s2ram on this system? > > > > - get it to suspend with usb loaded (ohci + ehci) > > > > - get it to resume a reasonable speed > > > > > > There's no way to fix the USB problem without knowing what goes wrong. > > > Let's see how far you get before the system freezes on a kernel with > > > CONFIG_USB_DEBUG enabled. > > > > Am I missing something? > > > > I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter > > nor anything extra to toggle and I don't get more output than without it. > > > > Device suspend (pm_test = device) works well when there is no USB device > > connected, but with USB keyboard I get the freeze (though the keyboard > > is still usable, e.g. CAPS key works and I can issue SYSRQ commands). > > > > When I issue sysreq-t, I find the following suspicious entry: > > [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 > > 0x > > [ 669.112505] 88007a085e20 0046 88007a085fd8 > > 88007c536820 > > [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 > > 000129c0 > > [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 > > 88007a085fd8 > > [ 669.112505] Call Trace: > > [ 669.112505] [] refrigerator+0x95/0xf0 > > [ 669.112505] [] worker_thread+0xc6/0x1e0 > > [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 > > [ 669.112505] [] ? worker_thread+0x0/0x1e0 > > [ 669.112505] [] kthread+0x8e/0xa0 > > [ 669.112505] [] kernel_thread_helper+0x4/0x10 > > [ 669.112505] [] ? kthread+0x0/0xa0 > > [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 > > > > Except for that one there are a few async/* tasks waiting. > > It looks like the freezer fails on your system. > > How much time did you wait for the failig "pm_test = device" to recover? I've given it at least 5 minutes, but didn't check exactly. Is there a (big) timeout that could happen, if so how long is it? Thanks, Bruno Those async threads looked like: [ 669.112505] async/15 D 0 2213 2 0x [ 669.112505] 8800797dbc80 0046 8800797dbfd8 88007aff8820 [ 669.112505] 8800797dbfd8 8800797dbfd8 000129c0 000129c0 [ 669.112505] 88007aff8820 88007cdf3040 0002 0113 [ 669.112505] Call Trace: [ 669.112505] [] schedule_timeout+0x19d/0x230 [ 669.112505] [] ? acpi_pci_irq_lookup+0x42/0x1b1 [ 669.112505] [] ? acpi_pci_irq_disable+0x74/0x7d [ 669.112505] [] wait_for_common+0xe1/0x170 [ 669.112505] [] ? default_wake_function+0x0/0x10 [ 669.112505] [] ? dpm_wait_fn+0x0/0x40 [ 669.112505] [] wait_for_completion+0x18/0x20 [ 669.112505] [] dpm_wait_fn+0x2f/0x40 [ 669.112505] [] device_for_each_child+0x48/0x70 [ 669.112505] [] __device_suspend+0x38/0x1e0 [ 669.112505] [] async_suspend+0x24/0x60 [ 669.112505] [] async_thread+0x112/0x280 [ 669.112505] [] ? default_wake_function+0x0/0x10 [ 669.112505] [] ?
s2ram slow (radeon) / failing (usb)
On Sunday 02 May 2010, Bruno Pr?mont wrote: > On Sun, 02 May 2010 Alan Stern wrote: > > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > > It freezes during device suspend (unless I rmmod everything USB > > > related) - usb fails even in pm_test case 'devices'. > > > > > > When the system is able to suspend it takes an eternity (more than 3 > > > minutes to wake-up, the radeon apparently being responsible for quite > > > a big share of that slowness. > > > > > > > > > During resume early it looks like every PCI access needs about a second, > > > and there are a few cases where during lots of seconds nothing seems to > > > happen and the first event following is related to radeon. > > > > > > The kernel used is todays Linus's tree at commit > > > be1066bbcd443a65df312fdecea7e4959adedb45 > > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > > > Note, I've not been able to suspend to RAM properly recently (last one > > > that worked correctly but resumed without graphics was some-when during > > > 2.6.2x, before KMS) > > > Since then the system would either fail suspend or resume. > > > > > > Manual changes I applied in order to find out some context information: > > > - add a few debugging printk's to ata/ahci as that was the last entry > > > on serial console for freezing suspends (that one succeeded but > > > following step never completed, from suspend_prepare that would have > > > been USB => unload usb before suspend) > > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial > > > console would continue working as long as possible and output suspend > > > progress (resume output happens only very late) > > > > > > Is there some additional information I could gather in order do help > > > improving s2ram on this system? > > > - get it to suspend with usb loaded (ohci + ehci) > > > - get it to resume a reasonable speed > > > > There's no way to fix the USB problem without knowing what goes wrong. > > Let's see how far you get before the system freezes on a kernel with > > CONFIG_USB_DEBUG enabled. > > Am I missing something? > > I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter > nor anything extra to toggle and I don't get more output than without it. > > Device suspend (pm_test = device) works well when there is no USB device > connected, but with USB keyboard I get the freeze (though the keyboard > is still usable, e.g. CAPS key works and I can issue SYSRQ commands). > > When I issue sysreq-t, I find the following suspicious entry: > [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x > [ 669.112505] 88007a085e20 0046 88007a085fd8 > 88007c536820 > [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 > 000129c0 > [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 > 88007a085fd8 > [ 669.112505] Call Trace: > [ 669.112505] [] refrigerator+0x95/0xf0 > [ 669.112505] [] worker_thread+0xc6/0x1e0 > [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 > [ 669.112505] [] ? worker_thread+0x0/0x1e0 > [ 669.112505] [] kthread+0x8e/0xa0 > [ 669.112505] [] kernel_thread_helper+0x4/0x10 > [ 669.112505] [] ? kthread+0x0/0xa0 > [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 > > Except for that one there are a few async/* tasks waiting. It looks like the freezer fails on your system. How much time did you wait for the failig "pm_test = device" to recover? Rafael
s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Alan Stern wrote: > On Sun, 2 May 2010, Bruno [UTF-8] Pr?mont wrote: > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > > It freezes during device suspend (unless I rmmod everything USB > > related) - usb fails even in pm_test case 'devices'. > > > > When the system is able to suspend it takes an eternity (more than 3 > > minutes to wake-up, the radeon apparently being responsible for quite > > a big share of that slowness. > > > > > > During resume early it looks like every PCI access needs about a second, > > and there are a few cases where during lots of seconds nothing seems to > > happen and the first event following is related to radeon. > > > > The kernel used is todays Linus's tree at commit > > be1066bbcd443a65df312fdecea7e4959adedb45 > > with Dave's drm-linus and drm-radeon-testing applied on top. > > > > Note, I've not been able to suspend to RAM properly recently (last one > > that worked correctly but resumed without graphics was some-when during > > 2.6.2x, before KMS) > > Since then the system would either fail suspend or resume. > > > > Manual changes I applied in order to find out some context information: > > - add a few debugging printk's to ata/ahci as that was the last entry > > on serial console for freezing suspends (that one succeeded but > > following step never completed, from suspend_prepare that would have > > been USB => unload usb before suspend) > > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial > > console would continue working as long as possible and output suspend > > progress (resume output happens only very late) > > > > Is there some additional information I could gather in order do help > > improving s2ram on this system? > > - get it to suspend with usb loaded (ohci + ehci) > > - get it to resume a reasonable speed > > There's no way to fix the USB problem without knowing what goes wrong. > Let's see how far you get before the system freezes on a kernel with > CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Device suspend (pm_test = device) works well when there is no USB device connected, but with USB keyboard I get the freeze (though the keyboard is still usable, e.g. CAPS key works and I can issue SYSRQ commands). When I issue sysreq-t, I find the following suspicious entry: [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [] refrigerator+0x95/0xf0 [ 669.112505] [] worker_thread+0xc6/0x1e0 [ 669.112505] [] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [] ? worker_thread+0x0/0x1e0 [ 669.112505] [] kthread+0x8e/0xa0 [ 669.112505] [] kernel_thread_helper+0x4/0x10 [ 669.112505] [] ? kthread+0x0/0xa0 [ 669.112505] [] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. Thanks, Bruno
RV630 KMS PM info on tables requested
On Tue, 27 Apr 2010 14:06:41 -0400 Alex Deucher wrote: > >> > I've been testing radeon KMS PM with 2.6.34-rc* for a few days now and > >> > I wanted to send you my testcase. Even though PM is enabled, the > >> > defaults of my card are somewhat insane so no real powermanagement > >> > takes place - i.e. the card doesn't get clocked down. is there any way > >> > to force the card to use a different setting where less power is being > >> > consumed? > >> > >> The current code doesn't handle a lot of cases properly. ?Please try > >> my latest patch set against Dave's drm-next tree: > >> http://people.freedesktop.org/~agd5f/pm3/ > >> It allows you to enable dynamic pm or force a static power mode via sysfs. > >> > >> Alex > > > > Will do so at the end of the week when (hopefully) 2.6.34-rc6 is out > > and I have mor etime on my hands. > > Could you a bit more explicit on how I could set a static power mode > > via sysfs? I've never worked with sysfs before so some hints would be > > greatly appreciated. > > enable/disable dynpm: > echo 1 > /sys/class/drm/card0/device/dynpm > > force a static power state: > echo 1.0 > /sys/class/drm/card0/device/power_state > > Alex > Hi Alex, I just built drm-radeon-testing as I saw the patches have already been merged there. It built fine, I updated the firmware files as the Xor-Wiki suggests, but when I boot into the resulting kernel with dynpem on my screen goes all wonky, a portion on the right side is missing and I've got vertical lines running down the screen. Somehow I managed to look at dmesg and saw that the speed was being set correctly (it even set the lowest one available). When I tried "sudo echo 0 > /sys/class/drm/card0/device/dynpm" to see whether switching off dynpm would fix the "drunken" screen the system told me I was not permitted to access the file... I am attaching the syslog from the faulty boot in case it's of any help... Klaus -- Klaus Doblmann B.A. - http://straightrazorguy.net - FSF member #7570 PGP-Key: http://www.doblmann.de/pgp_key.asc http://twitter.com/klausdoblmann A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- next part -- A non-text attachment was scrubbed... Name: syslog Type: application/octet-stream Size: 125362 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100502/f5f16333/attachment-0001.obj>
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
On Sun, May 2, 2010 at 7:42 PM, GhePeU wrote: > Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: >> On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: >> > Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: >> >> On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: >> >> > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: >> >> >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU wrote: >> >> >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: >> >> >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 >> >> >> >> >2001 >> >> >> >> From: Alex Deucher >> >> >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 >> >> >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver >> >> >> > >> >> >> > Hi, >> >> >> > >> >> >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found >> >> >> > that with >> >> >> > KMS both the console and X were using a 800x600 resolution instead >> >> >> > of my LCD >> >> >> > display's native resolution of 1440x900 who was selected by default >> >> >> > with >> >> >> > 2.6.33 and previous kernels. >> >> >> > >> >> >> > I tracked the problem to this patch, which causes the same issues >> >> >> > also >> >> >> > when manually applied to 2.6.33: apparently the kms radeon driver >> >> >> > wrongly detects a TV connected to my card (I don't have one, only a >> >> >> > LCD >> >> >> > display connected to the DVI port) and forces the TV default >> >> >> > resolution >> >> >> > for all the outputs. >> >> >> >> >> >> You issue is not related to the patch. ?What the patch does is allow >> >> >> you to use the digital part of DVI plus TV at the same time. ?The >> >> >> analog part of the DVI port and the TV share the same DAC so they >> >> >> can't be used at the same time. ?Prior to the patch, both the TV and >> >> >> DVI were detected as attached, but the TV was always disabled since it >> >> >> was wrongly seen as conflicting with the DVI. >> >> >> >> >> >> Your issue is actually a matter of load detection for TV not always >> >> >> being reliable. ?I don't know what a proper fix would be. ?We could >> >> >> disable load detection for TV to avoid false positives, but that would >> >> >> prevent automatic detection of TV which does work in most cases. >> >> >> >> >> >> Alex >> >> >> >> >> > >> >> > With UMS however I don't have this problem, is the logic different? >> >> > >> >> > Shouldn't the driver behavior with KMS be the same, in this case? At >> >> > least there wouldn't be (apparent) regressions like the one I'm >> >> > experiencing. >> >> > >> >> >> >> UMS does not enable load detection on TV by default while KMS does, >> >> the difference being KMS provides both the console and X so you want >> >> to make sure you put something up on whatever monitors or tvs happen >> >> to be attached. ?I'm not sure what the best answer is here. >> >> >> >> Alex >> > >> > Would it be possible to add a module option to disable tv load >> > detection? As things are now I must always change back the resolution to >> > 1440x900 and disable the TV. >> >> try booting with video=TV-1:d oh try video=DIN-1:d or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. Dave.
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: >> On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: >> > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: >> >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU wrote: >> >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: >> >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 >> >> >> From: Alex Deucher >> >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 >> >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver >> >> > >> >> > Hi, >> >> > >> >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found that >> >> > with >> >> > KMS both the console and X were using a 800x600 resolution instead of >> >> > my LCD >> >> > display's native resolution of 1440x900 who was selected by default with >> >> > 2.6.33 and previous kernels. >> >> > >> >> > I tracked the problem to this patch, which causes the same issues also >> >> > when manually applied to 2.6.33: apparently the kms radeon driver >> >> > wrongly detects a TV connected to my card (I don't have one, only a LCD >> >> > display connected to the DVI port) and forces the TV default resolution >> >> > for all the outputs. >> >> >> >> You issue is not related to the patch. ?What the patch does is allow >> >> you to use the digital part of DVI plus TV at the same time. ?The >> >> analog part of the DVI port and the TV share the same DAC so they >> >> can't be used at the same time. ?Prior to the patch, both the TV and >> >> DVI were detected as attached, but the TV was always disabled since it >> >> was wrongly seen as conflicting with the DVI. >> >> >> >> Your issue is actually a matter of load detection for TV not always >> >> being reliable. ?I don't know what a proper fix would be. ?We could >> >> disable load detection for TV to avoid false positives, but that would >> >> prevent automatic detection of TV which does work in most cases. >> >> >> >> Alex >> >> >> > >> > With UMS however I don't have this problem, is the logic different? >> > >> > Shouldn't the driver behavior with KMS be the same, in this case? At >> > least there wouldn't be (apparent) regressions like the one I'm >> > experiencing. >> > >> >> UMS does not enable load detection on TV by default while KMS does, >> the difference being KMS provides both the console and X so you want >> to make sure you put something up on whatever monitors or tvs happen >> to be attached. ?I'm not sure what the best answer is here. >> >> Alex > > Would it be possible to add a module option to disable tv load > detection? As things are now I must always change back the resolution to > 1440x900 and disable the TV. try booting with video=TV-1:d Dave.
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 13.59 +0200, GhePeU ha scritto: > Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: > > On Sun, May 2, 2010 at 7:42 PM, GhePeU wrote: > > > Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: > > >> On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > > >> > > > >> > Would it be possible to add a module option to disable tv load > > >> > detection? As things are now I must always change back the resolution > > >> > to > > >> > 1440x900 and disable the TV. > > >> > > >> try booting with video=TV-1:d > > > > oh try video=DIN-1:d > > > > or S-video-1:d, have a look in /sys/class/drm when booted for the correct > > one. > > > > Dave. > > /sys/class/drm lists "card0-SVIDEO-1", dmesg has "S-video" and the > encoder is "TV1". I booted with "video=SVIDEO-1:d", "video=S-video:d", > "video=TV1:d" and finally "video=S-video-1:d" but none of them worked. > > I'll look to the source code when I'll have the time. > > Giacomo > Looking to radeon_connector.c I found that TV load detection had already been disabled for some other chipsets because it wasn't always reliable. I just added my card's family to the check (patch attached) and now my problem's gone. Disabling TV detection for the entire family is probably overkill, just blacklisting my card (a Radeon Sapphire X550 Silent, 1002:5b63) would've been enough, is there another place where this quirk could be added? Giacomo -- next part -- A non-text attachment was scrubbed... Name: RV380-disable-tv-load-detection.patch Type: text/x-patch Size: 622 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100502/fa5179c1/attachment.bin>
s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010, Bruno [UTF-8] Pr??mont wrote: > > There's no way to fix the USB problem without knowing what goes wrong. > > Let's see how far you get before the system freezes on a kernel with > > CONFIG_USB_DEBUG enabled. > > Am I missing something? > > I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter > nor anything extra to toggle and I don't get more output than without it. Depends what you mean by "output". The kernel generates more log messages, but they may not get sent to your console. You need to make sure the console's log level is set high enough to see debugging messages. For example: echo 9 >/proc/sys/kernel/printk or type Alt-SysRq-9. Alan Stern
s2ram slow (radeon) / failing (usb)
Hi, On a IEI Kino 690S1 I'm having a hard time to get s2ram running. It freezes during device suspend (unless I rmmod everything USB related) - usb fails even in pm_test case 'devices'. When the system is able to suspend it takes an eternity (more than 3 minutes to wake-up, the radeon apparently being responsible for quite a big share of that slowness. During resume early it looks like every PCI access needs about a second, and there are a few cases where during lots of seconds nothing seems to happen and the first event following is related to radeon. The kernel used is todays Linus's tree at commit be1066bbcd443a65df312fdecea7e4959adedb45 with Dave's drm-linus and drm-radeon-testing applied on top. Note, I've not been able to suspend to RAM properly recently (last one that worked correctly but resumed without graphics was some-when during 2.6.2x, before KMS) Since then the system would either fail suspend or resume. Manual changes I applied in order to find out some context information: - add a few debugging printk's to ata/ahci as that was the last entry on serial console for freezing suspends (that one succeeded but following step never completed, from suspend_prepare that would have been USB => unload usb before suspend) - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial console would continue working as long as possible and output suspend progress (resume output happens only very late) Is there some additional information I could gather in order do help improving s2ram on this system? - get it to suspend with usb loaded (ohci + ehci) - get it to resume a reasonable speed Thanks, Bruno List of modules when suspend works (slowly): Module Size Used by snd_atiixp 14095 0 snd_ac97_codec118013 1 snd_atiixp ac97_bus1274 1 snd_ac97_codec snd_pcm71003 2 snd_atiixp,snd_ac97_codec snd_timer 19369 1 snd_pcm snd51992 4 snd_atiixp,snd_ac97_codec,snd_pcm,snd_timer soundcore974 1 snd snd_page_alloc 7797 2 snd_atiixp,snd_pcm sg 18667 0 pata_atiixp 4189 0 tg3 125844 0 lspci: 00:00.0 Host bridge [0600]: ATI Technologies Inc RS690 Host Bridge [1002:7910] 00:01.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx) [1002:7912] 00:04.0 PCI bridge [0604]: ATI Technologies Inc Device [1002:7914] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1) [1002:7915] 00:06.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2) [1002:7916] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] 00:13.2 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI2) [1002:4389] 00:13.3 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI3) [1002:438a] 00:13.4 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] 00:13.5 USB Controller [0c03]: ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386] 00:14.0 SMBus [0c05]: ATI Technologies Inc SBx00 SMBus Controller [1002:4385] (rev 13) 00:14.1 IDE interface [0101]: ATI Technologies Inc SB600 IDE [1002:438c] 00:14.3 ISA bridge [0601]: ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d] 00:14.4 PCI bridge [0604]: ATI Technologies Inc SBx00 PCI to PCI Bridge [1002:4384] 00:14.5 Multimedia audio controller [0401]: ATI Technologies Inc SB600 AC97 Audio [1002:4382] 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:05.0 VGA compatible controller [0300]: ATI Technologies Inc RS690 [Radeon X1200 Series] [1002:791e] 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express [14e4:1693] (rev 02) 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express [14e4:1693] (rev 02) PM related config options: CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_PM_RUNTIME=y CONFIG_X86_PM_TIMER=y USB related config options: CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y CONFIG_USB_PWC=m CONFIG_USB_PWC_INPUT_EVDEV=y CONFIG_SND_USB=y CONFIG_USB_HID=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: > On Sun, May 2, 2010 at 7:42 PM, GhePeU wrote: > > Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: > >> On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > >> > Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: > >> >> On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: > >> >> > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: > >> >> >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU > >> >> >> wrote: > >> >> >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha > >> >> >> > scritto: > >> >> >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 > >> >> >> >> >00:00:00 2001 > >> >> >> >> From: Alex Deucher > >> >> >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 > >> >> >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > >> >> >> > > >> >> >> > Hi, > >> >> >> > > >> >> >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found > >> >> >> > that with > >> >> >> > KMS both the console and X were using a 800x600 resolution instead > >> >> >> > of my LCD > >> >> >> > display's native resolution of 1440x900 who was selected by > >> >> >> > default with > >> >> >> > 2.6.33 and previous kernels. > >> >> >> > > >> >> >> > I tracked the problem to this patch, which causes the same issues > >> >> >> > also > >> >> >> > when manually applied to 2.6.33: apparently the kms radeon driver > >> >> >> > wrongly detects a TV connected to my card (I don't have one, only > >> >> >> > a LCD > >> >> >> > display connected to the DVI port) and forces the TV default > >> >> >> > resolution > >> >> >> > for all the outputs. > >> >> >> > >> >> >> You issue is not related to the patch. What the patch does is allow > >> >> >> you to use the digital part of DVI plus TV at the same time. The > >> >> >> analog part of the DVI port and the TV share the same DAC so they > >> >> >> can't be used at the same time. Prior to the patch, both the TV and > >> >> >> DVI were detected as attached, but the TV was always disabled since > >> >> >> it > >> >> >> was wrongly seen as conflicting with the DVI. > >> >> >> > >> >> >> Your issue is actually a matter of load detection for TV not always > >> >> >> being reliable. I don't know what a proper fix would be. We could > >> >> >> disable load detection for TV to avoid false positives, but that > >> >> >> would > >> >> >> prevent automatic detection of TV which does work in most cases. > >> >> >> > >> >> >> Alex > >> >> >> > >> >> > > >> >> > With UMS however I don't have this problem, is the logic different? > >> >> > > >> >> > Shouldn't the driver behavior with KMS be the same, in this case? At > >> >> > least there wouldn't be (apparent) regressions like the one I'm > >> >> > experiencing. > >> >> > > >> >> > >> >> UMS does not enable load detection on TV by default while KMS does, > >> >> the difference being KMS provides both the console and X so you want > >> >> to make sure you put something up on whatever monitors or tvs happen > >> >> to be attached. I'm not sure what the best answer is here. > >> >> > >> >> Alex > >> > > >> > Would it be possible to add a module option to disable tv load > >> > detection? As things are now I must always change back the resolution to > >> > 1440x900 and disable the TV. > >> > >> try booting with video=TV-1:d > > oh try video=DIN-1:d > > or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. > > Dave. /sys/class/drm lists "card0-SVIDEO-1", dmesg has "S-video" and the encoder is "TV1". I booted with "video=SVIDEO-1:d", "video=S-video:d", "video=TV1:d" and finally "video=S-video-1:d" but none of them worked. I'll look to the source code when I'll have the time. Giacomo
mmotm 2010-04-28 - nouveau driver issues
l_ttm+0x0/0xb3 [1.195459] [] ? mark_held_locks+0x52/0x70 [1.195463] [] ? trace_kmalloc+0x40/0xb4 [1.195468] [] nv50_instmem_populate+0x6d/0x11a [1.195473] [] nouveau_gpuobj_new+0x252/0x34c [1.195477] [] nouveau_sgdma_init+0x5f/0x241 [1.195481] [] ? pci_find_capability+0x6d/0x7c [1.195485] [] nouveau_mem_init+0x330/0x42f [1.195489] [] nouveau_card_init+0xb09/0xe35 [1.195493] [] nouveau_load+0x4e6/0x50c [1.195497] [] drm_get_dev+0x3bf/0x4cc [1.195501] [] nouveau_pci_probe+0x10/0x12 [1.195505] [] local_pci_probe+0x12/0x16 [1.195509] [] pci_device_probe+0x60/0x8f [1.195513] [] ? driver_sysfs_add+0x47/0x6c [1.195517] [] driver_probe_device+0xde/0x178 [1.195521] [] __driver_attach+0x5c/0x80 [1.195525] [] ? __driver_attach+0x0/0x80 [1.195528] [] ? __driver_attach+0x0/0x80 [1.195532] [] bus_for_each_dev+0x54/0x89 [1.195536] [] driver_attach+0x19/0x1b [1.195540] [] bus_add_driver+0xb4/0x206 [1.195544] [] driver_register+0xb8/0x129 [1.195548] [] __pci_register_driver+0x63/0xd3 [1.195552] [] ? nouveau_init+0x0/0x52 [1.195556] [] drm_init+0x6b/0xd1 [1.195560] [] ? nouveau_init+0x0/0x52 [1.195563] [] nouveau_init+0x50/0x52 [1.195567] [] do_one_initcall+0x59/0x14e [1.195571] [] kernel_init+0x144/0x1ce [1.195575] [] kernel_thread_helper+0x4/0x10 [1.195579] [] ? restore_args+0x0/0x30 [1.195582] [] ? kernel_init+0x0/0x1ce [1.195586] [] ? kernel_thread_helper+0x0/0x10 [1.195588] ---[ end trace f31dec58d66d24a6 ]--- [1.195597] [drm] nouveau :01:00.0: error getting PRAMIN backing pages: -12 [1.195693] [drm] nouveau :01:00.0: Error creating sgdma object: -12 [1.195784] [drm] nouveau :01:00.0: Error initialising PCI(E): -12 [1.196854] nouveau :01:00.0: PCI INT A disabled [1.196863] nouveau: probe of :01:00.0 failed with error -12 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100502/b646348e/attachment-0001.pgp>
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: > On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > > Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: > >> On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: > >> > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: > >> >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU wrote: > >> >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: > >> >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 > >> >> >> >2001 > >> >> >> From: Alex Deucher > >> >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 > >> >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > >> >> > > >> >> > Hi, > >> >> > > >> >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found that > >> >> > with > >> >> > KMS both the console and X were using a 800x600 resolution instead of > >> >> > my LCD > >> >> > display's native resolution of 1440x900 who was selected by default > >> >> > with > >> >> > 2.6.33 and previous kernels. > >> >> > > >> >> > I tracked the problem to this patch, which causes the same issues also > >> >> > when manually applied to 2.6.33: apparently the kms radeon driver > >> >> > wrongly detects a TV connected to my card (I don't have one, only a > >> >> > LCD > >> >> > display connected to the DVI port) and forces the TV default > >> >> > resolution > >> >> > for all the outputs. > >> >> > >> >> You issue is not related to the patch. What the patch does is allow > >> >> you to use the digital part of DVI plus TV at the same time. The > >> >> analog part of the DVI port and the TV share the same DAC so they > >> >> can't be used at the same time. Prior to the patch, both the TV and > >> >> DVI were detected as attached, but the TV was always disabled since it > >> >> was wrongly seen as conflicting with the DVI. > >> >> > >> >> Your issue is actually a matter of load detection for TV not always > >> >> being reliable. I don't know what a proper fix would be. We could > >> >> disable load detection for TV to avoid false positives, but that would > >> >> prevent automatic detection of TV which does work in most cases. > >> >> > >> >> Alex > >> >> > >> > > >> > With UMS however I don't have this problem, is the logic different? > >> > > >> > Shouldn't the driver behavior with KMS be the same, in this case? At > >> > least there wouldn't be (apparent) regressions like the one I'm > >> > experiencing. > >> > > >> > >> UMS does not enable load detection on TV by default while KMS does, > >> the difference being KMS provides both the console and X so you want > >> to make sure you put something up on whatever monitors or tvs happen > >> to be attached. I'm not sure what the best answer is here. > >> > >> Alex > > > > Would it be possible to add a module option to disable tv load > > detection? As things are now I must always change back the resolution to > > 1440x900 and disable the TV. > > try booting with video=TV-1:d > > Dave. Didn't work, both console and X started at 800x600. Giacomo
s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010, Bruno [UTF-8] Pr??mont wrote: > Hi, > > On a IEI Kino 690S1 I'm having a hard time to get s2ram running. > It freezes during device suspend (unless I rmmod everything USB > related) - usb fails even in pm_test case 'devices'. > > When the system is able to suspend it takes an eternity (more than 3 > minutes to wake-up, the radeon apparently being responsible for quite > a big share of that slowness. > > > During resume early it looks like every PCI access needs about a second, > and there are a few cases where during lots of seconds nothing seems to > happen and the first event following is related to radeon. > > The kernel used is todays Linus's tree at commit > be1066bbcd443a65df312fdecea7e4959adedb45 > with Dave's drm-linus and drm-radeon-testing applied on top. > > Note, I've not been able to suspend to RAM properly recently (last one > that worked correctly but resumed without graphics was some-when during > 2.6.2x, before KMS) > Since then the system would either fail suspend or resume. > > Manual changes I applied in order to find out some context information: > - add a few debugging printk's to ata/ahci as that was the last entry > on serial console for freezing suspends (that one succeeded but > following step never completed, from suspend_prepare that would have > been USB => unload usb before suspend) > - strip "if EMBEDED" from CONFIG_SERIAL_8250_PNP and disabled it so serial > console would continue working as long as possible and output suspend > progress (resume output happens only very late) > > Is there some additional information I could gather in order do help > improving s2ram on this system? > - get it to suspend with usb loaded (ohci + ehci) > - get it to resume a reasonable speed There's no way to fix the USB problem without knowing what goes wrong. Let's see how far you get before the system freezes on a kernel with CONFIG_USB_DEBUG enabled. Alan Stern
[Bug 27937] SEGV in r700_assembler.c next_ins() with RV670 kms
https://bugs.freedesktop.org/show_bug.cgi?id=27937 --- Comment #3 from Andre Heider 2010-05-02 04:41:42 PDT --- the game binary is from here: http://www.playdeb.net/software/0%20A.D. ii 0ad 0.0.0+r07419~pre-alpha-1~getdeb2 A war/economy strategy game ii 0ad-data 0.0.0+r07419~pre-alpha-1~getdeb1 A war/economy strategy game (data files) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27937] SEGV in r700_assembler.c next_ins() with RV670 kms
https://bugs.freedesktop.org/show_bug.cgi?id=27937 --- Comment #2 from Andre Heider 2010-05-02 04:34:15 PDT --- Created an attachment (id=35376) --> (https://bugs.freedesktop.org/attachment.cgi?id=35376) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27937] SEGV in r700_assembler.c next_ins() with RV670 kms
https://bugs.freedesktop.org/show_bug.cgi?id=27937 --- Comment #1 from Andre Heider 2010-05-02 04:33:54 PDT --- Created an attachment (id=35375) --> (https://bugs.freedesktop.org/attachment.cgi?id=35375) dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27937] New: SEGV in r700_assembler.c next_ins() with RV670 kms
https://bugs.freedesktop.org/show_bug.cgi?id=27937
Summary: SEGV in r700_assembler.c next_ins() with RV670 kms
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/R600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: a.heider at gmail.com
the game 0ad crashes when just starting a single player game.
ubuntu lucid, mainline 2.6.34-rc6, xorg-edgers
#0 0x7fffea2926e3 in next_ins (pAsm=0x7fffe11b4690)
at r700_assembler.c:2619
No locals.
#1 0x7fffea292f4b in assemble_MOV (pAsm=0x7fffe11b4690)
at r700_assembler.c:3874
No locals.
#2 0x7fffea297b4d in AssembleInstr (uiFirstInst=1, uiIL_Shift=256,
uiNumberInsts=4, pILInst=0x7fffe11b6550, pR700AsmCode=0x7fffe11b4690)
at r700_assembler.c:5622
No locals.
#3 0x7fffea299678 in r700TranslateFragmentShader (fp=0x7fffe11b03e0,
mesa_fp=0x7fffe11b03e0, ctx=0xb615d0) at r700_fragprog.c:412
number_of_colors_exported =
z_enabled =
shadow_unit =
i = 126
inst = 0x0
shadow_ambient = {STATE_INTERNAL, STATE_SHADOW_AMBIENT, 0, 0, 0}
#4 0x7fffea2a4ac7 in r700UpdateShaders (ctx=0x7fffe11b4690)
at r700_state.c:73
No locals.
#5 0x7fffea2a6097 in r700TryDrawPrims (ctx=0xb615d0,
arrays=, prim=,
nr_prims=, ib=0x7fffdfe0,
index_bounds_valid=, min_index=0, max_index=126)
at r700_render.c:904
i =
rrb =
emit_end =
#6 r700DrawPrims (ctx=0xb615d0, arrays=,
prim=, nr_prims=,
ib=0x7fffdfe0, index_bounds_valid=, min_index=0,
max_index=126) at r700_render.c:993
No locals.
#7 0x7fffea350dec in vbo_validated_drawrangeelements (ctx=0xb615d0,
mode=4, index_bounds_valid=, start=0, end=126,
count=126, type=5123, indices=0x7fffe110b010, basevertex=0, primcount=1)
at vbo/vbo_exec_array.c:721
ib = {count = 126, type = 5123, obj = 0xb03e80, ptr = 0x7fffe110b010}
prim = {{mode = 4, indexed = 1, begin = 1, end = 1, weak = 0, pad = 0,
start = 0, count = 126, basevertex = 0, num_instances = 1}}
#8 0x7fffea35107d in vbo_exec_DrawRangeElementsBaseVertex (
mode=, start=0, end=126, count=126, type=5123,
indices=0x7fffe110b010, basevertex=0) at vbo/vbo_exec_array.c:829
warnCount = 0
ctx = 0xb615d0
__PRETTY_FUNCTION__ = "vbo_exec_DrawRangeElementsBaseVertex"
#9 0x7fffea351170 in vbo_exec_DrawRangeElements (mode=3776661136,
start=256, end=7, count=-518298288, type=256, indices=0x3)
at vbo/vbo_exec_array.c:846
No locals.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 27904] r300g segfaults on M56GL
https://bugs.freedesktop.org/show_bug.cgi?id=27904 --- Comment #5 from Marek Ol??k 2010-05-02 03:32:25 PDT --- It's called automatically. I think we shouldn't chat like that in a bug report. If you have any questions, send me an email. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27904] r300g segfaults on M56GL
https://bugs.freedesktop.org/show_bug.cgi?id=27904 --- Comment #4 from Pavel Rojtberg 2010-05-02 02:51:18 PDT --- I have makedepend installed. Is it called by the makefile automatically or have I to call it myself? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 6:24 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 5:30 PM, GhePeU ghe...@virgilio.it wrote: Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Thu, 15 Apr 2010 13:31:12 -0400 Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. You issue is not related to the patch. What the patch does is allow you to use the digital part of DVI plus TV at the same time. The analog part of the DVI port and the TV share the same DAC so they can't be used at the same time. Prior to the patch, both the TV and DVI were detected as attached, but the TV was always disabled since it was wrongly seen as conflicting with the DVI. Your issue is actually a matter of load detection for TV not always being reliable. I don't know what a proper fix would be. We could disable load detection for TV to avoid false positives, but that would prevent automatic detection of TV which does work in most cases. Alex With UMS however I don't have this problem, is the logic different? Shouldn't the driver behavior with KMS be the same, in this case? At least there wouldn't be (apparent) regressions like the one I'm experiencing. UMS does not enable load detection on TV by default while KMS does, the difference being KMS provides both the console and X so you want to make sure you put something up on whatever monitors or tvs happen to be attached. I'm not sure what the best answer is here. Alex Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 6:24 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 5:30 PM, GhePeU ghe...@virgilio.it wrote: Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Thu, 15 Apr 2010 13:31:12 -0400 Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. You issue is not related to the patch. What the patch does is allow you to use the digital part of DVI plus TV at the same time. The analog part of the DVI port and the TV share the same DAC so they can't be used at the same time. Prior to the patch, both the TV and DVI were detected as attached, but the TV was always disabled since it was wrongly seen as conflicting with the DVI. Your issue is actually a matter of load detection for TV not always being reliable. I don't know what a proper fix would be. We could disable load detection for TV to avoid false positives, but that would prevent automatic detection of TV which does work in most cases. Alex With UMS however I don't have this problem, is the logic different? Shouldn't the driver behavior with KMS be the same, in this case? At least there wouldn't be (apparent) regressions like the one I'm experiencing. UMS does not enable load detection on TV by default while KMS does, the difference being KMS provides both the console and X so you want to make sure you put something up on whatever monitors or tvs happen to be attached. I'm not sure what the best answer is here. Alex Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d Dave. Didn't work, both console and X started at 800x600. Giacomo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27904] r300g segfaults on M56GL
https://bugs.freedesktop.org/show_bug.cgi?id=27904 --- Comment #4 from Pavel Rojtberg pa...@rojtberg.net 2010-05-02 02:51:18 PDT --- I have makedepend installed. Is it called by the makefile automatically or have I to call it myself? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27937] SEGV in r700_assembler.c next_ins() with RV670 kms
https://bugs.freedesktop.org/show_bug.cgi?id=27937 --- Comment #2 from Andre Heider a.hei...@gmail.com 2010-05-02 04:34:15 PDT --- Created an attachment (id=35376) -- (https://bugs.freedesktop.org/attachment.cgi?id=35376) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: On Sun, May 2, 2010 at 7:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 6:24 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 5:30 PM, GhePeU ghe...@virgilio.it wrote: Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Thu, 15 Apr 2010 13:31:12 -0400 Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. You issue is not related to the patch. What the patch does is allow you to use the digital part of DVI plus TV at the same time. The analog part of the DVI port and the TV share the same DAC so they can't be used at the same time. Prior to the patch, both the TV and DVI were detected as attached, but the TV was always disabled since it was wrongly seen as conflicting with the DVI. Your issue is actually a matter of load detection for TV not always being reliable. I don't know what a proper fix would be. We could disable load detection for TV to avoid false positives, but that would prevent automatic detection of TV which does work in most cases. Alex With UMS however I don't have this problem, is the logic different? Shouldn't the driver behavior with KMS be the same, in this case? At least there wouldn't be (apparent) regressions like the one I'm experiencing. UMS does not enable load detection on TV by default while KMS does, the difference being KMS provides both the console and X so you want to make sure you put something up on whatever monitors or tvs happen to be attached. I'm not sure what the best answer is here. Alex Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d oh try video=DIN-1:d or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. Dave. /sys/class/drm lists card0-SVIDEO-1, dmesg has S-video and the encoder is TV1. I booted with video=SVIDEO-1:d, video=S-video:d, video=TV1:d and finally video=S-video-1:d but none of them worked. I'll look to the source code when I'll have the time. Giacomo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 13.59 +0200, GhePeU ha scritto: Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: On Sun, May 2, 2010 at 7:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d oh try video=DIN-1:d or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. Dave. /sys/class/drm lists card0-SVIDEO-1, dmesg has S-video and the encoder is TV1. I booted with video=SVIDEO-1:d, video=S-video:d, video=TV1:d and finally video=S-video-1:d but none of them worked. I'll look to the source code when I'll have the time. Giacomo Looking to radeon_connector.c I found that TV load detection had already been disabled for some other chipsets because it wasn't always reliable. I just added my card's family to the check (patch attached) and now my problem's gone. Disabling TV detection for the entire family is probably overkill, just blacklisting my card (a Radeon Sapphire X550 Silent, 1002:5b63) would've been enough, is there another place where this quirk could be added? Giacomo --- a/drivers/gpu/drm/radeon/radeon_connectors.c 2010-05-02 16:28:30.123432476 +0200 +++ b/drivers/gpu/drm/radeon/radeon_connectors.c 2010-05-02 17:46:25.026128098 +0200 @@ -1337,7 +1337,7 @@ * found a way to make load detect reliable on those * chipset, thus just disable it for TV. */ - if (rdev-family == CHIP_RS400 || rdev-family == CHIP_RS480) + if (rdev-family == CHIP_RS400 || rdev-family == CHIP_RS480 || rdev-family == CHIP_RV380) radeon_connector-dac_load_detect = false; drm_connector_attach_property(radeon_connector-base, rdev-mode_info.load_detect_property, ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Alan Stern st...@rowland.harvard.edu wrote: On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: On a IEI Kino 690S1 I'm having a hard time to get s2ram running. It freezes during device suspend (unless I rmmod everything USB related) - usb fails even in pm_test case 'devices'. When the system is able to suspend it takes an eternity (more than 3 minutes to wake-up, the radeon apparently being responsible for quite a big share of that slowness. During resume early it looks like every PCI access needs about a second, and there are a few cases where during lots of seconds nothing seems to happen and the first event following is related to radeon. The kernel used is todays Linus's tree at commit be1066bbcd443a65df312fdecea7e4959adedb45 with Dave's drm-linus and drm-radeon-testing applied on top. Note, I've not been able to suspend to RAM properly recently (last one that worked correctly but resumed without graphics was some-when during 2.6.2x, before KMS) Since then the system would either fail suspend or resume. Manual changes I applied in order to find out some context information: - add a few debugging printk's to ata/ahci as that was the last entry on serial console for freezing suspends (that one succeeded but following step never completed, from suspend_prepare that would have been USB = unload usb before suspend) - strip if EMBEDED from CONFIG_SERIAL_8250_PNP and disabled it so serial console would continue working as long as possible and output suspend progress (resume output happens only very late) Is there some additional information I could gather in order do help improving s2ram on this system? - get it to suspend with usb loaded (ohci + ehci) - get it to resume a reasonable speed There's no way to fix the USB problem without knowing what goes wrong. Let's see how far you get before the system freezes on a kernel with CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Device suspend (pm_test = device) works well when there is no USB device connected, but with USB keyboard I get the freeze (though the keyboard is still usable, e.g. CAPS key works and I can issue SYSRQ commands). When I issue sysreq-t, I find the following suspicious entry: [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [8105d765] refrigerator+0x95/0xf0 [ 669.112505] [81051a16] worker_thread+0xc6/0x1e0 [ 669.112505] [81055e90] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [81051950] ? worker_thread+0x0/0x1e0 [ 669.112505] [810559be] kthread+0x8e/0xa0 [ 669.112505] [81003a94] kernel_thread_helper+0x4/0x10 [ 669.112505] [81055930] ? kthread+0x0/0xa0 [ 669.112505] [81003a90] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. Thanks, Bruno ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 02 May 2010 Rafael J. Wysocki r...@sisk.pl wrote: On Sunday 02 May 2010, Bruno Prémont wrote: On Sun, 02 May 2010 Alan Stern st...@rowland.harvard.edu wrote: On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: On a IEI Kino 690S1 I'm having a hard time to get s2ram running. It freezes during device suspend (unless I rmmod everything USB related) - usb fails even in pm_test case 'devices'. When the system is able to suspend it takes an eternity (more than 3 minutes to wake-up, the radeon apparently being responsible for quite a big share of that slowness. During resume early it looks like every PCI access needs about a second, and there are a few cases where during lots of seconds nothing seems to happen and the first event following is related to radeon. The kernel used is todays Linus's tree at commit be1066bbcd443a65df312fdecea7e4959adedb45 with Dave's drm-linus and drm-radeon-testing applied on top. Note, I've not been able to suspend to RAM properly recently (last one that worked correctly but resumed without graphics was some-when during 2.6.2x, before KMS) Since then the system would either fail suspend or resume. Manual changes I applied in order to find out some context information: - add a few debugging printk's to ata/ahci as that was the last entry on serial console for freezing suspends (that one succeeded but following step never completed, from suspend_prepare that would have been USB = unload usb before suspend) - strip if EMBEDED from CONFIG_SERIAL_8250_PNP and disabled it so serial console would continue working as long as possible and output suspend progress (resume output happens only very late) Is there some additional information I could gather in order do help improving s2ram on this system? - get it to suspend with usb loaded (ohci + ehci) - get it to resume a reasonable speed There's no way to fix the USB problem without knowing what goes wrong. Let's see how far you get before the system freezes on a kernel with CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Device suspend (pm_test = device) works well when there is no USB device connected, but with USB keyboard I get the freeze (though the keyboard is still usable, e.g. CAPS key works and I can issue SYSRQ commands). When I issue sysreq-t, I find the following suspicious entry: [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [8105d765] refrigerator+0x95/0xf0 [ 669.112505] [81051a16] worker_thread+0xc6/0x1e0 [ 669.112505] [81055e90] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [81051950] ? worker_thread+0x0/0x1e0 [ 669.112505] [810559be] kthread+0x8e/0xa0 [ 669.112505] [81003a94] kernel_thread_helper+0x4/0x10 [ 669.112505] [81055930] ? kthread+0x0/0xa0 [ 669.112505] [81003a90] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. It looks like the freezer fails on your system. How much time did you wait for the failig pm_test = device to recover? I've given it at least 5 minutes, but didn't check exactly. Is there a (big) timeout that could happen, if so how long is it? Thanks, Bruno Those async threads looked like: [ 669.112505] async/15 D 0 2213 2 0x [ 669.112505] 8800797dbc80 0046 8800797dbfd8 88007aff8820 [ 669.112505] 8800797dbfd8 8800797dbfd8 000129c0 000129c0 [ 669.112505] 88007aff8820 88007cdf3040 0002 0113 [ 669.112505] Call Trace: [ 669.112505] [8146838d] schedule_timeout+0x19d/0x230 [ 669.112505] [811f661c] ? acpi_pci_irq_lookup+0x42/0x1b1 [ 669.112505] [811f67ff] ? acpi_pci_irq_disable+0x74/0x7d [ 669.112505] [81467961] wait_for_common+0xe1/0x170 [ 669.112505] [81037620] ? default_wake_function+0x0/0x10 [ 669.112505] [813092f0] ? dpm_wait_fn+0x0/0x40 [ 669.112505] [81467a88] wait_for_completion+0x18/0x20 [ 669.112505] [8130931f] dpm_wait_fn+0x2f/0x40 [ 669.112505] [81302188] device_for_each_child+0x48/0x70 [ 669.112505] [81309e68] __device_suspend+0x38/0x1e0 [ 669.112505] [8130a504] async_suspend+0x24/0x60 [ 669.112505]
mmotm 2010-04-28 - nouveau driver issues
On Wed, 28 Apr 2010 16:53:32 PDT, a...@linux-foundation.org said: The mm-of-the-moment snapshot 2010-04-28-16-53 has been uploaded to http://userweb.kernel.org/~akpm/mmotm/ The nouveau driver had issues during boot, caused plymouth to have indigestion and fall back to 24x80 character mode. This happened sometime between -mmotm0422 and -mmotm0428. Looks like something in linux-next, cc'ing anybody who apparently touched nouveau code. Will bisect if nobody has a good idea what happened. The X server was able to init the card and get gdm started just fine. lspci says: 01:00.0 VGA compatible controller: nVidia Corporation G98M [Quadro NVS 160M] (rev a1) [1.038152] [drm] nouveau :01:00.0: Detected 256MiB VRAM [1.194505] [TTM] Zone kernel: Available graphics memory: 2013496 kiB. [1.194508] [ttm] Initializing pool allocator. [1.194896] [ cut here ] [1.194903] WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x238/0x3f4() [1.194906] Hardware name: Latitude E6500 [1.194908] Modules linked in: [1.194912] Pid: 1, comm: swapper Not tainted 2.6.34-rc5-mmotm0428 #1 [1.194915] Call Trace: [1.194921] [81038936] warn_slowpath_common+0x80/0x98 [1.194925] [81038963] warn_slowpath_null+0x15/0x17 [1.194929] [8102064a] __ioremap_caller+0x238/0x3f4 [1.194934] [812b27ba] ? ttm_mem_reg_ioremap+0x54/0x7b [1.194939] [810d6aff] ? kmem_cache_alloc_notrace+0x68/0xc0 [1.194942] [8102088f] ioremap_nocache+0x12/0x14 [1.194946] [812b27ba] ttm_mem_reg_ioremap+0x54/0x7b [1.194950] [812b2b5c] ttm_bo_move_memcpy+0x5e/0x3e0 [1.194954] [812a4d7d] ? drm_mm_split_at_start+0x79/0x95 [1.194959] [8120ec2d] ? do_raw_spin_unlock+0xd0/0xfa [1.194964] [812c21cf] nouveau_bo_move+0x19e/0x222 [1.194968] [812afe79] ttm_bo_handle_move_mem+0x1b4/0x2c0 [1.194972] [812b1d9e] ttm_bo_move_buffer+0xf4/0x14d [1.194976] [81210b2d] ? __list_add+0xb7/0xd2 [1.194980] [812b1ee3] ttm_bo_validate+0xec/0x13e [1.194983] [8120e900] ? do_raw_write_unlock+0x7e/0xc8 [1.194987] [812b2315] ttm_bo_init+0x3e0/0x419 [1.194990] [812c2957] nouveau_bo_new+0x394/0x405 [1.194994] [812c2510] ? nouveau_bo_del_ttm+0x0/0xb3 [1.194997] [812a4cca] ? drm_mm_init+0x63/0x6b [1.195015] [812ba319] nouveau_mem_init+0x262/0x42f [1.195019] [812b7e02] nouveau_card_init+0xb09/0xe35 [1.195023] [812b86de] nouveau_load+0x4e6/0x50c [1.195028] [812a0fee] drm_get_dev+0x3bf/0x4cc [1.195034] [8158c3be] nouveau_pci_probe+0x10/0x12 [1.195039] [8121d71b] local_pci_probe+0x12/0x16 [1.195043] [8121db88] pci_device_probe+0x60/0x8f [1.195048] [813082e3] ? driver_sysfs_add+0x47/0x6c [1.195052] [81308462] driver_probe_device+0xde/0x178 [1.195056] [81308558] __driver_attach+0x5c/0x80 [1.195060] [813084fc] ? __driver_attach+0x0/0x80 [1.195063] [813084fc] ? __driver_attach+0x0/0x80 [1.195067] [81307a47] bus_for_each_dev+0x54/0x89 [1.195071] [8130829a] driver_attach+0x19/0x1b [1.195075] [81307ee2] bus_add_driver+0xb4/0x206 [1.195079] [81308857] driver_register+0xb8/0x129 [1.195083] [8121ddbe] __pci_register_driver+0x63/0xd3 [1.195088] [81b4f4c4] ? nouveau_init+0x0/0x52 [1.195092] [8129ba89] drm_init+0x6b/0xd1 [1.195096] [81b4f4c4] ? nouveau_init+0x0/0x52 [1.195100] [81b4f514] nouveau_init+0x50/0x52 [1.195104] [810001ef] do_one_initcall+0x59/0x14e [1.195109] [81b2e68a] kernel_init+0x144/0x1ce [1.195113] [81003414] kernel_thread_helper+0x4/0x10 [1.195117] [81598a40] ? restore_args+0x0/0x30 [1.195121] [81b2e546] ? kernel_init+0x0/0x1ce [1.195125] [81003410] ? kernel_thread_helper+0x0/0x10 [1.195192] ---[ end trace f31dec58d66d24a5 ]--- [1.195323] [drm] nouveau :01:00.0: failed to reserve VGA memory [1.195360] resource map sanity check conflict: 0x0 0xf 0xa 0xb PCI Bus :00 [1.195363] [ cut here ] [1.195366] WARNING: at arch/x86/mm/ioremap.c:98 __ioremap_caller+0x13b/0x3f4() [1.195369] Hardware name: Latitude E6500 [1.195371] Info: mapping multiple BARs. Your kernel is fine. [1.195373] Modules linked in: [1.195376] Pid: 1, comm: swapper Tainted: GW 2.6.34-rc5-mmotm0428 #1 [1.195378] Call Trace: [1.195382] [81038936] warn_slowpath_common+0x80/0x98 [1.195386] [810389e2] warn_slowpath_fmt+0x41/0x43 [1.195390] [8102054d] __ioremap_caller+0x13b/0x3f4 [1.195394]
Re: s2ram slow (radeon) / failing (usb)
On Sunday 02 May 2010, Bruno Prémont wrote: On Sun, 02 May 2010 Alan Stern st...@rowland.harvard.edu wrote: On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: On a IEI Kino 690S1 I'm having a hard time to get s2ram running. It freezes during device suspend (unless I rmmod everything USB related) - usb fails even in pm_test case 'devices'. When the system is able to suspend it takes an eternity (more than 3 minutes to wake-up, the radeon apparently being responsible for quite a big share of that slowness. During resume early it looks like every PCI access needs about a second, and there are a few cases where during lots of seconds nothing seems to happen and the first event following is related to radeon. The kernel used is todays Linus's tree at commit be1066bbcd443a65df312fdecea7e4959adedb45 with Dave's drm-linus and drm-radeon-testing applied on top. Note, I've not been able to suspend to RAM properly recently (last one that worked correctly but resumed without graphics was some-when during 2.6.2x, before KMS) Since then the system would either fail suspend or resume. Manual changes I applied in order to find out some context information: - add a few debugging printk's to ata/ahci as that was the last entry on serial console for freezing suspends (that one succeeded but following step never completed, from suspend_prepare that would have been USB = unload usb before suspend) - strip if EMBEDED from CONFIG_SERIAL_8250_PNP and disabled it so serial console would continue working as long as possible and output suspend progress (resume output happens only very late) Is there some additional information I could gather in order do help improving s2ram on this system? - get it to suspend with usb loaded (ohci + ehci) - get it to resume a reasonable speed There's no way to fix the USB problem without knowing what goes wrong. Let's see how far you get before the system freezes on a kernel with CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Device suspend (pm_test = device) works well when there is no USB device connected, but with USB keyboard I get the freeze (though the keyboard is still usable, e.g. CAPS key works and I can issue SYSRQ commands). When I issue sysreq-t, I find the following suspicious entry: [ 669.112505] usbhid_resume D 88007a085fd8 0 1145 2 0x [ 669.112505] 88007a085e20 0046 88007a085fd8 88007c536820 [ 669.112505] 88007a085fd8 88007a085fd8 000129c0 000129c0 [ 669.112505] 88007c536820 88007cf3f040 88007a085fd8 88007a085fd8 [ 669.112505] Call Trace: [ 669.112505] [8105d765] refrigerator+0x95/0xf0 [ 669.112505] [81051a16] worker_thread+0xc6/0x1e0 [ 669.112505] [81055e90] ? autoremove_wake_function+0x0/0x40 [ 669.112505] [81051950] ? worker_thread+0x0/0x1e0 [ 669.112505] [810559be] kthread+0x8e/0xa0 [ 669.112505] [81003a94] kernel_thread_helper+0x4/0x10 [ 669.112505] [81055930] ? kthread+0x0/0xa0 [ 669.112505] [81003a90] ? kernel_thread_helper+0x0/0x10 Except for that one there are a few async/* tasks waiting. It looks like the freezer fails on your system. How much time did you wait for the failig pm_test = device to recover? Rafael ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: s2ram slow (radeon) / failing (usb)
On Sun, 2 May 2010, Bruno [UTF-8] Prémont wrote: There's no way to fix the USB problem without knowing what goes wrong. Let's see how far you get before the system freezes on a kernel with CONFIG_USB_DEBUG enabled. Am I missing something? I've enabled CONFIG_USB_DEBUG but don't see any additional module parameter nor anything extra to toggle and I don't get more output than without it. Depends what you mean by output. The kernel generates more log messages, but they may not get sent to your console. You need to make sure the console's log level is set high enough to see debugging messages. For example: echo 9 /proc/sys/kernel/printk or type Alt-SysRq-9. Alan Stern ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
