linux-kernel - Re: s2ram slow (radeon) / failing (usb)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1005021102340.25185-100000@netrider.rowland.org>
Date:	Sun, 2 May 2010 11:07:31 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
cc:	dri-devel@...ts.freedesktop.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/