Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

2007-03-20 Thread Bill Davidsen
Jim Gettys wrote: On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote: What you say sounds good, assuming that the cost of a sleep is less than the cost of the busy wait. But this may be hardware, the waits may be very small and frequent, and if it's hitting a small hardware window

BSOD (was: [2/6] 2.6.21-rc2: known regressions)

2007-03-19 Thread Pete Zaitcev
On Sun, 18 Mar 2007 12:40:45 -0400, Jim Gettys [EMAIL PROTECTED] wrote: Also more seriously, a somewhat hybrid approach is in order for mode setting: simple mode setting isn't much code and is required for sane behavior on crash (it is nice to get oopses onto a screen); but the full blown

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

2007-03-19 Thread Bill Davidsen
Jim Gettys wrote: On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote: * Pavel Machek [EMAIL PROTECTED] wrote: Some day we may have modesetting support in the kernel for some graphics hw, right now it's pretty damn spotty. Yep, that's the way to go. hey, i wildly supported this approach

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

2007-03-19 Thread Jim Gettys
On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote: What you say sounds good, assuming that the cost of a sleep is less than the cost of the busy wait. But this may be hardware, the waits may be very small and frequent, and if it's hitting a small hardware window like retrace, delays

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-18 Thread Ingo Molnar
* Pavel Machek [EMAIL PROTECTED] wrote: Some day we may have modesetting support in the kernel for some graphics hw, right now it's pretty damn spotty. Yep, that's the way to go. hey, i wildly supported this approach ever since 1996, when GGI came up :-/ Ingo - To unsubscribe

Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

2007-03-18 Thread Jim Gettys
On Sun, 2007-03-18 at 17:07 +0100, Ingo Molnar wrote: * Pavel Machek [EMAIL PROTECTED] wrote: Some day we may have modesetting support in the kernel for some graphics hw, right now it's pretty damn spotty. Yep, that's the way to go. hey, i wildly supported this approach ever

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-17 Thread Michael S. Tsirkin
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: [2/6] 2.6.21-rc2: known regressions Quoting Ingo Molnar [EMAIL PROTECTED]: Subject: Re: [2/6] 2.6.21-rc2: known regressions Michael, * Michael S. Tsirkin [EMAIL PROTECTED] wrote: 2. First disk access after

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-17 Thread Thomas Gleixner
On Sat, 2007-03-17 at 23:41 +0200, Michael S. Tsirkin wrote: a quick ping: on your box that doesnt resume - if you can log in over the network after resume (or somehow run shell commands), does 'date' advance properly or not? (or do you not get that far to be able to tell?)

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-12 Thread Stefan Seyfried
On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote: * Pavel Machek [EMAIL PROTECTED] wrote: Unfortunately, these tend to crash the box when you pass wrong options, and I do not see easy way to test can user see whats on display automatically. you could perhaps try what X's

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-12 Thread Michael S. Tsirkin
Quoting Ingo Molnar [EMAIL PROTECTED]: Subject: Re: [2/6] 2.6.21-rc2: known regressions Michael, * Michael S. Tsirkin [EMAIL PROTECTED] wrote: 2. First disk access after resume takes a couple of minutes (seemed instant with 2.6.20) during this time no new messages show

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-11 Thread Ingo Molnar
* Pavel Machek [EMAIL PROTECTED] wrote: Probably tweaking the webpage doesnt help because people dont get there - as the results plainly show it. Maybe some more automation would be useful too, a tool that detects failed resume and tries all those options that makes sense on that box

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-10 Thread Stefan Seyfried
On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote: * Pavel Machek [EMAIL PROTECTED] wrote: s2ram should be able to work around this, it has parts from radeontool. (suspend.sf.net). i'm wondering, do you have any idea how Windows handles the suspend/resume quirks problem

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-10 Thread Johannes Stezenbach
On Sat, Mar 10, 2007 at 12:43:01PM +0100, Stefan Seyfried wrote: On Sat, Mar 10, 2007 at 10:01:21AM +0100, Ingo Molnar wrote: i'm wondering, do you have any idea how Windows handles the suspend/resume quirks problem area? Do they curse BIOS vendors and maintain a large DB of DMI-driven

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-10 Thread Ingo Molnar
* Stefan Seyfried [EMAIL PROTECTED] wrote: btw., the s2ram database seems quite a bit spotty: $ ./s2ram -n Machine is unknown. This machine can be identified by: sys_vendor = System manufacturer sys_product = System Product Name sys_version = System Version

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-10 Thread Pavel Machek
Hi! Ok. To be honest, you are the first reporter that seems to have read the documentation above, but not understood what to do. thanks for the compliment ;-) _I_ very much know what to do (i mailed the right person after all ;), but i dont really count and on the 6 (Can we get the

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-10 Thread Ingo Molnar
* Pavel Machek [EMAIL PROTECTED] wrote: Even if one doesn't use the fb console at all, radeonfb apparently is still required on some ThinkPad models to work around BIOS bugs: http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off s2ram

s2ram (was Re: [2/6] 2.6.21-rc2: known regressions)

2007-03-10 Thread Pavel Machek
Hi! Even if one doesn't use the fb console at all, radeonfb apparently is still required on some ThinkPad models to work around BIOS bugs: http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off s2ram should be able to work around

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-09 Thread Ingo Molnar
* Linus Torvalds [EMAIL PROTECTED] wrote: disabling the following radeonfb options in the .config made resume work again: In general, don't even *try* to use radeonfb for suspend/resume. I don't think it has ever worked, except on some very rare laptops (largely PPC Macs) where

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-09 Thread Pavel Machek
Hi! disabling the following radeonfb options in the .config made resume work again: In general, don't even *try* to use radeonfb for suspend/resume. I don't think it has ever worked, except on some very rare laptops (largely PPC Macs) where people had enough information to set up the

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-09 Thread Linus Torvalds
On Fri, 9 Mar 2007, Ingo Molnar wrote: Some day we may have modesetting support in the kernel for some graphics hw, right now it's pretty damn spotty. having no video is what i'd have expected - but getting a /hang/ is not what i'd have expected. I debugged a case exactly like this

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-09 Thread Johannes Stezenbach
On Thu, Mar 08, 2007, Linus Torvalds wrote: On Fri, 9 Mar 2007, Ingo Molnar wrote: disabling the following radeonfb options in the .config made resume work again: In general, don't even *try* to use radeonfb for suspend/resume. I don't think it has ever worked, except on some very

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-09 Thread Pavel Machek
Hi! You're better off using the VGA console, and lettign X re-initialize the graphics device. That generally at least has a reasonably good chance of working. Re-initializing graphics modes really is very hard. You can try with the BIOS video hack (I forget the kernel command line

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ash Milsted
On Wed, 07 Mar 2007 06:09:06 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Adrian Bunk wrote: Subject: AT keyboard only works with pci=noacpi References : http://lkml.org/lkml/2007/3/3/68 Submitter : Ash Milsted [EMAIL PROTECTED] Status : unknown sounds like a BIOS bug, even

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Michael S. Tsirkin
Quoting Adrian Bunk [EMAIL PROTECTED]: Subject: [2/6] 2.6.21-rc2: known regressions Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL PROTECTED] Status : unknown Here's the status with -rc3

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Jeff Chua
On 3/8/07, Michael S. Tsirkin [EMAIL PROTECTED] wrote: Quoting Adrian Bunk [EMAIL PROTECTED]: Subject: [2/6] 2.6.21-rc2: known regressions Subject: ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin [EMAIL

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Linus Torvalds
[ Eric, Ingo, can you double-check the timer initialization after resume? We appear to have several reports of date not advancing, and while this could be some SATA issue, it could easily be a timer tick issue too ] On Thu, 8 Mar 2007, Michael S. Tsirkin wrote: Here's the status with

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Linus Torvalds [EMAIL PROTECTED] wrote: 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows after waiting for some 10 min, I rebooted. no new messages showed up in /var/log/messages I think this is likely just more of the disk being buggered, but

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote: Michael - does your 'date' output advance after resume? If not then i'd say it's a NO_HZ related problem. [...] in that case please do this on such a 'frozen date' system: echo q /proc/sysrq-trigger and then send us the hw-timers info.

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Linus Torvalds [EMAIL PROTECTED] wrote: 2. First disk access after resume takes a couple of minutes (seemed instant with 2.6.20) during this time no new messages show on console Yeah, there is some problem with SATA resume. It would be beautiful if the people who actually see

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Michael S. Tsirkin
Quoting Linus Torvalds [EMAIL PROTECTED]: Here's the status with -rc3: better, but still does not work as well as 2.6.20. Ok. I think we mostly solved the irq-related stuff, but you might want to check whether you have CONFIG_NOHZ on or off and whether that makes a difference.

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Michael S. Tsirkin
Quoting Ingo Molnar [EMAIL PROTECTED]: Subject: Re: [2/6] 2.6.21-rc2: known regressions * Linus Torvalds [EMAIL PROTECTED] wrote: 3. When I switch to X (CTRL-ALT-F7), X hangs after drawing a couple of windows after waiting for some 10 min, I rebooted. no new messages showed

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Michael S. Tsirkin
2. First disk access after resume takes a couple of minutes (seemed instant with 2.6.20) during this time no new messages show on console Yeah, there is some problem with SATA resume. It would be beautiful if the people who actually see this could narrow it down with bisection. It

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Michael S. Tsirkin [EMAIL PROTECTED] wrote: Michael - does your 'date' output advance after resume? If not then i'd say it's a NO_HZ related problem. If yes then i'd guess it's the SATA problem. I'll test, but I have NO_HZ off for now. there can still be effects of it (the

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote: Thomas found a new twist to this today: applying the patch below (which turns on ATA_DEBUG) made the SATA problem go away on his laptop. Michael, could you try this patch, does it change the behavior of your laptop in any way? Here's another

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote: Here's another suspend/resume artifact: one of my boxes wouldnt resume, it hangs at: [1.456633] pci :00:18.2: resuming [1.456641] pci :00:18.3: resuming [1.456648] 8139too :05:07.0: resuming [1.456667] radeonfb

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Ingo Molnar
* Ingo Molnar [EMAIL PROTECTED] wrote: Here's another suspend/resume artifact: one of my boxes wouldnt resume, it hangs at: [1.456633] pci :00:18.2: resuming [1.456641] pci :00:18.3: resuming [1.456648] 8139too :05:07.0: resuming [1.456667] radeonfb

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-08 Thread Linus Torvalds
On Fri, 9 Mar 2007, Ingo Molnar wrote: disabling the following radeonfb options in the .config made resume work again: In general, don't even *try* to use radeonfb for suspend/resume. I don't think it has ever worked, except on some very rare laptops (largely PPC Macs) where people had

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-07 Thread Jeff Garzik
Adrian Bunk wrote: Subject: AT keyboard only works with pci=noacpi References : http://lkml.org/lkml/2007/3/3/68 Submitter : Ash Milsted [EMAIL PROTECTED] Status : unknown sounds like a BIOS bug, even though it appears to be a regression? - To unsubscribe from this list: send the

Re: [2/6] 2.6.21-rc2: known regressions

2007-03-07 Thread Linus Torvalds
On Wed, 7 Mar 2007, Jeff Garzik wrote: Adrian Bunk wrote: Subject: AT keyboard only works with pci=noacpi References : http://lkml.org/lkml/2007/3/3/68 Submitter : Ash Milsted [EMAIL PROTECTED] Status : unknown sounds like a BIOS bug, even though it appears to be a

[2/6] 2.6.21-rc2: known regressions

2007-03-04 Thread Adrian Bunk
This email lists some known regressions in 2.6.21-rc2 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm