[2/2] 2.6.21-rc7: known regressions

[2/2] 2.6.21-rc7: known regressions

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

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 considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
             workaround: booting with "hpet=disable"
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
             Jeremy Fitzhardinge <jeremy@goop.org>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
Status     : unknown


Subject    : suspend to disk works only once
References : http://lkml.org/lkml/2007/4/13/240
Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit ed746e3b18f4df18afa3763155972c5835f284c5
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Dmitry Torokhov <dtor@insightbb.com>
             David Brownell <david-b@pacbell.net>
Status     : problem is being debugged


Subject    : resume from RAM corrupts vesafb console
References : http://lkml.org/lkml/2007/3/26/76
             http://lkml.org/lkml/2007/4/13/313
Submitter  : Marcus Better <marcus@better.se>
Handled-By : Pavel Machek <pavel@ucw.cz>
             Antonino A. Daplas <adaplas@gmail.com>
Status     : problem is being debugged

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:

 > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 >              workaround: booting with "hpet=disable"
 > References : http://lkml.org/lkml/2007/3/13/3
 > Submitter  : Dave Jones <davej@redhat.com>
 >              Jeremy Fitzhardinge <jeremy@goop.org>
 > Caused-By  : PCI merge
 >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 >              Rafael J. Wysocki <rjw@sisk.pl>
 > Status     : unknown

note that this workaround doesn't seem to work in all cases.
Mine may a slightly different model (I have the tablet version)
but disabling hpet shows the same regression.
I've been fighting Eric's USB debug cable code in the hope
of getting _something_ useful out of it other than a black screen,
but I've been getting nowhere with it.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Adrian Bunk]

On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote:
> On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:
> 
>  > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>  >              workaround: booting with "hpet=disable"
>  > References : http://lkml.org/lkml/2007/3/13/3
>  > Submitter  : Dave Jones <davej@redhat.com>
>  >              Jeremy Fitzhardinge <jeremy@goop.org>
>  > Caused-By  : PCI merge
>  >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
>  > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>  >              Rafael J. Wysocki <rjw@sisk.pl>
>  > Status     : unknown
> 
> note that this workaround doesn't seem to work in all cases.
> Mine may a slightly different model (I have the tablet version)
> but disabling hpet shows the same regression.
> I've been fighting Eric's USB debug cable code in the hope
> of getting _something_ useful out of it other than a black screen,
> but I've been getting nowhere with it.

I'm not sure why I thought you two ran into the same regression.

So "hpet=disable" worked for Jeremy but not for you, IOW: you two were 
running into different regressions?

@Jeremy:
If this is true, is your HPET related related regression still present 
in -rc7?

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Adrian Bunk wrote:
> I'm not sure why I thought you two ran into the same regression.
>
> So "hpet=disable" worked for Jeremy but not for you, IOW: you two were 
> running into different regressions?
>
> @Jeremy:
> If this is true, is your HPET related related regression still present 
> in -rc7?

I need to recheck, but when I tried -rc6, I was still having resume
problems but hpet=disabled didn't help.  So I definitely think there are
multiple bugs with the same symtoms.  I haven't tried -rc7 yet.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Rafael J. Wysocki]

On Monday, 16 April 2007 02:37, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> 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 considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
[--snip--]
> 
> 
> Subject    : suspend to disk works only once
> References : http://lkml.org/lkml/2007/4/13/240
> Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
>              commit ed746e3b18f4df18afa3763155972c5835f284c5
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Dmitry Torokhov <dtor@insightbb.com>
>              David Brownell <david-b@pacbell.net>
> Status     : problem is being debugged

Workaround is possible: do "echo shutdown > /sys/power/disk" before the
suspend or, for s2disk, add "shutdown method = shutdown" to the configuration
file.

Greetings,
Rafael

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Adrian Bunk wrote:
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>              workaround: booting with "hpet=disable"
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
>              Jeremy Fitzhardinge <jeremy@goop.org>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
> Status     : unknown
>   

OK. 2.6.21-rc7 suspend/resume works perfectly for me.  It's the first
kernel version in a long time.  I have no workarounds or special boot
options.  It's using hpet as the clocksource.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 09:57:15PM -0700, Jeremy Fitzhardinge wrote:
 > Adrian Bunk wrote:
 > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > >              workaround: booting with "hpet=disable"
 > > References : http://lkml.org/lkml/2007/3/13/3
 > > Submitter  : Dave Jones <davej@redhat.com>
 > >              Jeremy Fitzhardinge <jeremy@goop.org>
 > > Caused-By  : PCI merge
 > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > >              Rafael J. Wysocki <rjw@sisk.pl>
 > > Status     : unknown
 > >   
 > 
 > OK. 2.6.21-rc7 suspend/resume works perfectly for me.  It's the first
 > kernel version in a long time.  I have no workarounds or special boot
 > options.  It's using hpet as the clocksource.

Do you have the backlight code enabled ?
I'm guessing not.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
> Do you have the backlight code enabled ?
> I'm guessing not.
>   

Hm, think so.  backlight controls work, via both
/proc/acpi/ibm/backlight and /sys/class/backlight/*/brightness.

$ ls -l /sys/class/backlight/
total 0
drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video0
drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video1
drwxr-xr-x 2 root root 0 Apr 19 22:13 ibm


    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 10:15:48PM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > Do you have the backlight code enabled ?
 > > I'm guessing not.
 > >   
 > 
 > Hm, think so.  backlight controls work, via both
 > /proc/acpi/ibm/backlight and /sys/class/backlight/*/brightness.
 > 
 > $ ls -l /sys/class/backlight/
 > total 0
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video0
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 acpi_video1
 > drwxr-xr-x 2 root root 0 Apr 19 22:13 ibm

Hmm, given you hit the hpet problems and I didn't I think our X60's
aren't quite so similar.  Mine is the one with the swivelly touchscreen
tablet-pc mode. I understand they made a regular 'laptop' X60 too,
is that the one you have perhaps?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Dave Jones wrote:
> Hmm, given you hit the hpet problems and I didn't I think our X60's
> aren't quite so similar.  Mine is the one with the swivelly touchscreen
> tablet-pc mode. I understand they made a regular 'laptop' X60 too,
> is that the one you have perhaps?
>   

Yes, mine is a normal laptop X60.  Still, its hard to imagine how they
could be very different; same CPU, same chipset, same graphics.  The
main difference is that your's has a Wacom tablet, presumably attached
to USB.

Details attached. How does it compare to your machine?

    J

[-- Attachment #2: config.txt.gz --]
[-- Type: application/x-gzip, Size: 4848 bytes --]

[-- Attachment #3: dmesg.txt.gz --]
[-- Type: application/x-gzip, Size: 12858 bytes --]

[-- Attachment #4: pci.txt.gz --]
[-- Type: application/x-gzip, Size: 1765 bytes --]

[-- Attachment #5: usb.txt.gz --]
[-- Type: application/x-gzip, Size: 1384 bytes --]

[-- Attachment #6: dmi.txt.gz --]
[-- Type: application/x-gzip, Size: 3274 bytes --]

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Thu, Apr 19, 2007 at 10:33:39PM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > Hmm, given you hit the hpet problems and I didn't I think our X60's
 > > aren't quite so similar.  Mine is the one with the swivelly touchscreen
 > > tablet-pc mode. I understand they made a regular 'laptop' X60 too,
 > > is that the one you have perhaps?
 > 
 > Yes, mine is a normal laptop X60.  Still, its hard to imagine how they
 > could be very different; same CPU, same chipset, same graphics.  The
 > main difference is that your's has a Wacom tablet, presumably attached
 > to USB.
 > 
 > Details attached. How does it compare to your machine?

-1142MB HIGHMEM available.
+118MB HIGHMEM available.

So you have more RAM than I do :)

-NX (Execute Disable) protection: active

You enabled PAE, I didn't..
(Though I have tried both, makes no difference)

 DMI present.
+Using APIC driver default

Hmm.

 ACPI: RSDP 000F67B0, 0024 (r2 LENOVO)
-ACPI: XSDT 7F6D1896, 008C (r1 LENOVO TP-7B        2060  LTP        0)
-ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B        2060 LNVO        1)
+ACPI: XSDT 3F6D12F5, 008C (r1 LENOVO TP-7J        1050  LTP        0)
+ACPI: FACP 3F6D1400, 00F4 (r3 LENOVO TP-7J        1050 LNVO        1)

BIOS differences (lots of these)

-Allocating PCI resources starting at 88000000 (gap: 80000000:70000000)
+Allocating PCI resources starting at 50000000 (gap: 40000000:b0000000)

Probably due to the RAM differences shuffling the memmap.

-Kernel command line: ro root=LABEL=/ acpi_sleep=s3_bios combined_mode=libata
+Kernel command line: ro root=/dev/VolGroup00/LogVol00 profile=1

Hmm. I tried..
acpi_sleep=s3_bios
acpi_sleep=s3_mode
acpi_sleep=s3_bios,s3_mode
all did nothing for me.

-CPU: After all inits, caps: bfe9fbff 00100000 00000000 00002940 0000c1a9 00000000 00000000
+CPU: After all inits, caps: bfe9f3ff 00100000 00000000 00002940 0000c1a9 00000000 00000000

Probably PAE

-CPU0: Intel Genuine Intel(R) CPU           T2400  @ 1.83GHz stepping 08
+CPU0: Intel(R) Core(TM) Duo CPU      L2400  @ 1.66GHz stepping 0c

slightly different CPU, but probably not enough to make any difference.

-BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
- [<c01091b5>] show_trace_log_lvl+0x1a/0x30
- [<c010980c>] show_trace+0x12/0x14
- [<c01098cb>] dump_stack+0x16/0x18
- [<c0468dbd>] init_sched_clock+0x58/0x9b
- [<c0461502>] init+0x14b/0x241
- [<c0108d97>] kernel_thread_helper+0x7/0x10
- =======================

heh, one for Ingo :)

-ACPI: ACPI Dock Station Driver 
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
-ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
-ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added

Hmm, I should try without the dock stuff built.

-PCI: Using MMCONFIG
+PCI: PCI BIOS revision 2.10 entry at 0xfd82b, last bus=24
+PCI: Using configuration type 1

Think I've tried with and without MMCONFIG

-pnp: PnP ACPI: found 11 devices
+pnp: PnP ACPI: found 13 devices

My Wacom tablet is one of them. There's also a mysterious 13th device :)

 ibm_acpi: IBM ThinkPad ACPI Extras v0.13
 ibm_acpi: http://ibm-acpi.sf.net/
-ibm_acpi: ThinkPad EC firmware 7BHT37WW-1.10
+ibm_acpi: ThinkPad EC firmware 7JHT12WW-1.03

possibly just because of the touchscreen.

So most of the differences seem to be BIOS/firmware rather than hardware. 
The PCI bus layout is identical for eg.

Looking at your .config, I notice that you don't have CONFIG_FB_BACKLIGHT set
(because you don't have any framebuffer drivers that use it enabled).
Can you enable say.. CONFIG_FB_RADEON=m and CONFIG_FB_RADEON_BACKLIGHT=y
(which should turn on CONFIG_FB_BACKLIGHT=y by dependancy), and see if
it stops working for you? (You don't even need to load radeonfb.ko, just
have it compiled).

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
> -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
> - [<c01091b5>] show_trace_log_lvl+0x1a/0x30
> - [<c010980c>] show_trace+0x12/0x14
> - [<c01098cb>] dump_stack+0x16/0x18
> - [<c0468dbd>] init_sched_clock+0x58/0x9b
> - [<c0461502>] init+0x14b/0x241
> - [<c0108d97>] kernel_thread_helper+0x7/0x10
> - =======================
>
> heh, one for Ingo :)
>   

Andi, I think.  I've got his firstfloor.org patches applied to this kernel.

> -ACPI: ACPI Dock Station Driver 
> -ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
> -ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
> -ACPI: Bay [\_SB_.PCI0.IDE0.PRIM.MSTR] Added
>
> Hmm, I should try without the dock stuff built.
>
> -PCI: Using MMCONFIG
> +PCI: PCI BIOS revision 2.10 entry at 0xfd82b, last bus=24
> +PCI: Using configuration type 1
>
> Think I've tried with and without MMCONFIG
>
> -pnp: PnP ACPI: found 11 devices
> +pnp: PnP ACPI: found 13 devices
>
> My Wacom tablet is one of them. There's also a mysterious 13th device :)
>
>  ibm_acpi: IBM ThinkPad ACPI Extras v0.13
>  ibm_acpi: http://ibm-acpi.sf.net/
> -ibm_acpi: ThinkPad EC firmware 7BHT37WW-1.10
> +ibm_acpi: ThinkPad EC firmware 7JHT12WW-1.03
>
> possibly just because of the touchscreen.
>   

I'm running a very recent BIOS in order to enable hardware
virtualization (VT/VMX).  The BIOS updates also update the EC firmware.

> So most of the differences seem to be BIOS/firmware rather than hardware. 
> The PCI bus layout is identical for eg.
>   

Do you have Intel wireless?  I realized one chance I'd made was to swap
the Atheros wireless with Intel, since it just seems to work better
overall.  I'd never had any major suspend/resume problems that I could
attribute to madwifi though (lots of minor wifi-related ones though).

> Looking at your .config, I notice that you don't have CONFIG_FB_BACKLIGHT set
> (because you don't have any framebuffer drivers that use it enabled).
> Can you enable say.. CONFIG_FB_RADEON=m and CONFIG_FB_RADEON_BACKLIGHT=y
> (which should turn on CONFIG_FB_BACKLIGHT=y by dependancy), and see if
> it stops working for you? (You don't even need to load radeonfb.ko, just
> have it compiled).

OK, I'll give it a spin.

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Fri, Apr 20, 2007 at 08:28:10AM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > > -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock()
 > > - [<c01091b5>] show_trace_log_lvl+0x1a/0x30
 > > - [<c010980c>] show_trace+0x12/0x14
 > > - [<c01098cb>] dump_stack+0x16/0x18
 > > - [<c0468dbd>] init_sched_clock+0x58/0x9b
 > > - [<c0461502>] init+0x14b/0x241
 > > - [<c0108d97>] kernel_thread_helper+0x7/0x10
 > > - =======================
 > >
 > > heh, one for Ingo :)
 > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.

Ah, I saw you patched in CFS too, and thought it may be related.

 > > So most of the differences seem to be BIOS/firmware rather than hardware. 
 > > The PCI bus layout is identical for eg.
 > 
 > Do you have Intel wireless?  I realized one chance I'd made was to swap
 > the Atheros wireless with Intel, since it just seems to work better
 > overall.  I'd never had any major suspend/resume problems that I could
 > attribute to madwifi though (lots of minor wifi-related ones though).

yeah, the intel wireless.  Same as teh one in your pci.gz attachment..
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
	Subsystem: Intel Corporation Unknown device 1010
	Flags: bus master, fast devsel, latency 0, IRQ 21

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
>  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
>
> Ah, I saw you patched in CFS too, and thought it may be related.
>   

Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.

Maybe there's something in Andi's queue which is making it work?

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Dave Jones]

On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
 > Dave Jones wrote:
 > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
 > >
 > > Ah, I saw you patched in CFS too, and thought it may be related.
 > >   
 > 
 > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
 > 
 > Maybe there's something in Andi's queue which is making it work?

Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
when people start flushing their git trees for .22
Maybe that'll yield a clue for something that can be backported to .21.x
because right now, I'm completely puzzled.

I was testing on a vanilla 2.6.21-rc7-git3.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [2/2] 2.6.21-rc7: known regressions

[Jeremy Fitzhardinge]

Dave Jones wrote:
> On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
>  > Dave Jones wrote:
>  > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
>  > >
>  > > Ah, I saw you patched in CFS too, and thought it may be related.
>  > >   
>  > 
>  > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
>  > 
>  > Maybe there's something in Andi's queue which is making it work?
>
> Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
> when people start flushing their git trees for .22
> Maybe that'll yield a clue for something that can be backported to .21.x
> because right now, I'm completely puzzled.

Well, it seemed reliable, but I just got a resume failure.  Different
from any previous symptom I've seen:

Intel machine check architecture supported
Intel machine check reporting enabled enabled on CPU#1
Back to C!
<hang>

    J

Re: [2/2] 2.6.21-rc7: known regressions

[Rafael J. Wysocki]

On Saturday, 21 April 2007 02:02, Jeremy Fitzhardinge wrote:
> Dave Jones wrote:
> > On Fri, Apr 20, 2007 at 10:16:54AM -0700, Jeremy Fitzhardinge wrote:
> >  > Dave Jones wrote:
> >  > >  > Andi, I think.  I've got his firstfloor.org patches applied to this kernel.
> >  > >
> >  > > Ah, I saw you patched in CFS too, and thought it may be related.
> >  > >   
> >  > 
> >  > Well, I have CONFIG_FB_BACKLIGHT enabled, and it still works.
> >  > 
> >  > Maybe there's something in Andi's queue which is making it work?
> >
> > Shrug, I'm out of ideas.  I'm hoping that it'll magically start working
> > when people start flushing their git trees for .22
> > Maybe that'll yield a clue for something that can be backported to .21.x
> > because right now, I'm completely puzzled.
> 
> Well, it seemed reliable, but I just got a resume failure.  Different
> from any previous symptom I've seen:
> 
> Intel machine check architecture supported
> Intel machine check reporting enabled enabled on CPU#1
> Back to C!
> <hang>

Hmm, looks like something in device_power_up() went awry.  Probably in
sysdev_resume().

Greetings,
Rafael

[3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

This email lists some known regressions in Linus' tree compared to 2.6.20.

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 considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : HPET enabled freeze my machine at boot
             workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/4/19/370
Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : acpi_pm clocksource loses time on x86-64
References : http://lkml.org/lkml/2007/4/17/143
Submitter  : Mikael Pettersson <mikpe@it.uu.se>
Handled-By : John Stultz <johnstul@us.ibm.com>
Status     : problem is being debugged


Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown


Subject    : ThinkPad X60: resume no longer works  (PCI related?)
             workaround: CONFIG_FB_BACKLIGHT=n
References : http://lkml.org/lkml/2007/3/13/3
Submitter  : Dave Jones <davej@redhat.com>
Caused-By  : PCI merge
             commit 78149df6d565c36675463352d0bfe0000b02b7a7
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
             Rafael J. Wysocki <rjw@sisk.pl>
             Antonino A. Daplas <adaplas@gmail.com>
Status     : unknown


Subject    : suspend to disk works only once
             workaround: "echo shutdown > /sys/power/disk"
References : http://lkml.org/lkml/2007/4/13/240
Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
             commit ed746e3b18f4df18afa3763155972c5835f284c5
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
             Dmitry Torokhov <dtor@insightbb.com>
Status     : problem is being debugged

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Andrew Morton]

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:

> This email lists some known regressions in Linus' tree compared to 2.6.20.
> 
> 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 considering you in any other way
> possibly involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : HPET enabled freeze my machine at boot
>              workaround: clocksource=acpi_pm
> References : http://lkml.org/lkml/2007/4/19/370
> Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> Caused-By  : Thomas Gleixner <tglx@linutronix.de>
>              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged
> 
> 
> Subject    : acpi_pm clocksource loses time on x86-64
> References : http://lkml.org/lkml/2007/4/17/143
> Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> Handled-By : John Stultz <johnstul@us.ibm.com>
> Status     : problem is being debugged
> 
> 
> Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/3/25/217
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown

That's still rather a lot of bustage from the timekeeping changes.  Is
anything really happening here or have we all given up?

> 
> Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>              workaround: CONFIG_FB_BACKLIGHT=n
> References : http://lkml.org/lkml/2007/3/13/3
> Submitter  : Dave Jones <davej@redhat.com>
> Caused-By  : PCI merge
>              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Rafael J. Wysocki <rjw@sisk.pl>
>              Antonino A. Daplas <adaplas@gmail.com>
> Status     : unknown
> 

Is this related to the problems Jeremy has been looking at?

> Subject    : suspend to disk works only once
>              workaround: "echo shutdown > /sys/power/disk"
> References : http://lkml.org/lkml/2007/4/13/240
> Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
>              commit ed746e3b18f4df18afa3763155972c5835f284c5
> Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
>              Dmitry Torokhov <dtor@insightbb.com>
> Status     : problem is being debugged

That's been happening on my Vaio-of-death for several weeks now.  I spent a
bit of time with the ACPI guys on it but we didn't get far.  I need to
find an hour or two to work out what's gone wrong.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
>...
> > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >              workaround: CONFIG_FB_BACKLIGHT=n
> > References : http://lkml.org/lkml/2007/3/13/3
> > Submitter  : Dave Jones <davej@redhat.com>
> > Caused-By  : PCI merge
> >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >              Rafael J. Wysocki <rjw@sisk.pl>
> >              Antonino A. Daplas <adaplas@gmail.com>
> > Status     : unknown
> 
> Is this related to the problems Jeremy has been looking at?
>...

Dave and Jeremy hran into similar looking but most likely different 
problems.

For Jeremy -rc7 is working fine, but for Dave it doesn't.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is 
> anything really happening here or have we all given up?

Jeff: does that suspend-to-disk hang problem also happen if you use 
hpet=disable?

	Ingo

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
 > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
 > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
 > >...
 > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > > >              workaround: CONFIG_FB_BACKLIGHT=n
 > > > References : http://lkml.org/lkml/2007/3/13/3
 > > > Submitter  : Dave Jones <davej@redhat.com>
 > > > Caused-By  : PCI merge
 > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
 > > >              Rafael J. Wysocki <rjw@sisk.pl>
 > > >              Antonino A. Daplas <adaplas@gmail.com>
 > > > Status     : unknown
 > > 
 > > Is this related to the problems Jeremy has been looking at?
 > >...
 > 
 > Dave and Jeremy hran into similar looking but most likely different 
 > problems.
 > 
 > For Jeremy -rc7 is working fine, but for Dave it doesn't.

I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Jeff Chua]

On 4/25/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/3/25/217
> > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > Status     : unknown
> >
> > That's still rather a lot of bustage from the timekeeping changes.  Is
> > anything really happening here or have we all given up?
>
> Jeff: does that suspend-to-disk hang problem also happen if you use
> hpet=disable?

Yes, it is still broken with HPET disabled.

I've reported that if I press some keys, suspend will complete
successfully, otherwise, it'll just hang before the "percentage" comes
on.

Thanks,
Jeff.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 09:01 -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
>  > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
>  > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
>  > >...
>  > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
>  > > >              workaround: CONFIG_FB_BACKLIGHT=n
>  > > > References : http://lkml.org/lkml/2007/3/13/3
>  > > > Submitter  : Dave Jones <davej@redhat.com>
>  > > > Caused-By  : PCI merge
>  > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
>  > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>  > > >              Rafael J. Wysocki <rjw@sisk.pl>
>  > > >              Antonino A. Daplas <adaplas@gmail.com>
>  > > > Status     : unknown
>  > > 
>  > > Is this related to the problems Jeremy has been looking at?
>  > >...
>  > 
>  > Dave and Jeremy hran into similar looking but most likely different 
>  > problems.
>  > 
>  > For Jeremy -rc7 is working fine, but for Dave it doesn't.
> 
> I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.

This is really weird, as CONFIG_FB_BACKLIGHT just selects
BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
under /sys/class/backlight/*/. ACPI_IBM which is set (presumably) in
Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
framebuffer drivers in the thinkpad are vesafb and intelfb, none of
which has a backlight driver.

I'm still at a loss how this happens.  Dave, can you post your config?
And have you tried the following settings:

FB_BACKLIGHT=y
ACPI_IBM=n
ACPI_VIDEO=n

I'm also adding Richard Purdie to the CC list.

Tony 

PS: I also get a blank display on resume with a Toshiba laptop.  But
cycling through the Fn keys brings it back.  I don't know if this is a
regression, I will have to try older kernels.

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

Forgot to add Richard, sorry for the double post.

On Wed, 2007-04-25 at 21:50 +0800, Antonino A. Daplas wrote:
> On Wed, 2007-04-25 at 09:01 -0400, Dave Jones wrote:
> > On Wed, Apr 25, 2007 at 01:31:02PM +0200, Adrian Bunk wrote:
> >  > On Wed, Apr 25, 2007 at 04:06:05AM -0700, Andrew Morton wrote:
> >  > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> >  > >...
> >  > > > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >  > > >              workaround: CONFIG_FB_BACKLIGHT=n
> >  > > > References : http://lkml.org/lkml/2007/3/13/3
> >  > > > Submitter  : Dave Jones <davej@redhat.com>
> >  > > > Caused-By  : PCI merge
> >  > > >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> >  > > > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >  > > >              Rafael J. Wysocki <rjw@sisk.pl>
> >  > > >              Antonino A. Daplas <adaplas@gmail.com>
> >  > > > Status     : unknown
> >  > > 
> >  > > Is this related to the problems Jeremy has been looking at?
> >  > >...
> >  > 
> >  > Dave and Jeremy hran into similar looking but most likely different 
> >  > problems.
> >  > 
> >  > For Jeremy -rc7 is working fine, but for Dave it doesn't.
> > 
> > I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.
> 
> This is really weird, as CONFIG_FB_BACKLIGHT just selects
> BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
> under /sys/class/backlight/*/. ACPI_IBM which is set (presumably) in
> Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
> framebuffer drivers in the thinkpad are vesafb and intelfb, none of
> which has a backlight driver.
> 
> I'm still at a loss how this happens.  Dave, can you post your config?
> And have you tried the following settings:
> 
> FB_BACKLIGHT=y
> ACPI_IBM=n
> ACPI_VIDEO=n
> 
> I'm also adding Richard Purdie to the CC list.
> 
> Tony 
> 
> PS: I also get a blank display on resume with a Toshiba laptop.  But
> cycling through the Fn keys brings it back.  I don't know if this is a
> regression, I will have to try older kernels.
> 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Jeremy Fitzhardinge]

Dave Jones wrote:
> I think this was due to Jeremy not having CONFIG_FB_BACKLIGHT=y in his config.
>   

No, I enabled it and it still works.

    J

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
 > > This is really weird, as CONFIG_FB_BACKLIGHT just selects
 > > BACKLIGHT_CLASS and LCD_CLASS, and adds an entry (bl_curve)
 > > under /sys/class/backlight/*/.

Yeah, it's puzzling to me too.

 > > ACPI_IBM which is set (presumably) in
 > > Dave's kconfig, also selects the BACKLIGHT_CLASS. And the only possible
 > > framebuffer drivers in the thinkpad are vesafb and intelfb, none of
 > > which has a backlight driver.
 > > 
 > > I'm still at a loss how this happens.  Dave, can you post your config?

http://people.redhat.com/davej/config-x60

 > > And have you tried the following settings:
 > > FB_BACKLIGHT=y
 > > ACPI_IBM=n
 > > ACPI_VIDEO=n

I think I've tried that yes.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Antonino A. Daplas]

On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
>  > > And have you tried the following settings:
>  > > FB_BACKLIGHT=y
>  > > ACPI_IBM=n
>  > > ACPI_VIDEO=n
> 

BTW, there was one report where resume from RAM resulted in a screen
full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
did not work for him anymore.  But it worked with s2ram and other
options. So if you have s2ram, try:

s2ram -f -s -a3
s2ram -f -m -a3
s2ram -f -p -m
s2ram -f -p -s

Tony 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Dave Jones]

On Wed, Apr 25, 2007 at 11:24:42PM +0800, Antonino A. Daplas wrote:
 > On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
 > > On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
 > >  > > And have you tried the following settings:
 > >  > > FB_BACKLIGHT=y
 > >  > > ACPI_IBM=n
 > >  > > ACPI_VIDEO=n
 > > 
 > 
 > BTW, there was one report where resume from RAM resulted in a screen
 > full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
 > did not work for him anymore.  But it worked with s2ram and other
 > options. So if you have s2ram, try:
 > 
 > s2ram -f -s -a3
 > s2ram -f -m -a3
 > s2ram -f -p -m
 > s2ram -f -p -s

I just did a pull of linus' tree, and it now works for me fine.
Adrian, I think we can remove this from the list.

I can't explain what fixed it (or even what caused it in the first place),
but it seems to be behaving itself.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[john stultz]

On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > 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 considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : HPET enabled freeze my machine at boot
> >              workaround: clocksource=acpi_pm
> > References : http://lkml.org/lkml/2007/4/19/370
> > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : acpi_pm clocksource loses time on x86-64
> > References : http://lkml.org/lkml/2007/4/17/143
> > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is
> anything really happening here or have we all given up?


The ACPI PM one is *really* odd as its the same clocksource driver on
both arches. I had Mikael cut out the clocksource frequency adjustments,
and confirmed both i386 and x86_64 are using the same base freq
(confirmed via printks).

It almost seems like when booting x86_64 the ACPI PM counter is running
slowly! 

Len: Have you ever heard of such a thing? It seems quite unlikely...


WRT the HPET freeze issue, I'm still digging there. In that case it
appears the HPET isn't counting, so timekeeping just stops. I was
thinking it might be HRT messing w/ the wrong HPET registers, but so far
that hasn't shaken out.

I'll spend some more time on these today and see if we get any further.

thanks
-john

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Rafael J. Wysocki]

On Wednesday, 25 April 2007 13:06, Andrew Morton wrote:
> On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> 
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > 
> > 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 considering you in any other way
> > possibly involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : HPET enabled freeze my machine at boot
> >              workaround: clocksource=acpi_pm
> > References : http://lkml.org/lkml/2007/4/19/370
> > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : acpi_pm clocksource loses time on x86-64
> > References : http://lkml.org/lkml/2007/4/17/143
> > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > Handled-By : John Stultz <johnstul@us.ibm.com>
> > Status     : problem is being debugged
> > 
> > 
> > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/3/25/217
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown
> 
> That's still rather a lot of bustage from the timekeeping changes.  Is
> anything really happening here or have we all given up?
> 
> > 
> > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
> >              workaround: CONFIG_FB_BACKLIGHT=n
> > References : http://lkml.org/lkml/2007/3/13/3
> > Submitter  : Dave Jones <davej@redhat.com>
> > Caused-By  : PCI merge
> >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
> > Handled-By : Eric W. Biederman <ebiederm@xmission.com>
> >              Rafael J. Wysocki <rjw@sisk.pl>
> >              Antonino A. Daplas <adaplas@gmail.com>
> > Status     : unknown
> > 
> 
> Is this related to the problems Jeremy has been looking at?
> 
> > Subject    : suspend to disk works only once
> >              workaround: "echo shutdown > /sys/power/disk"
> > References : http://lkml.org/lkml/2007/4/13/240
> > Submitter  : Tobias Diedrich <ranma+kernel@tdiedrich.de>
> > Caused-By  : Rafael J. Wysocki <rjw@sisk.pl>
> >              commit ed746e3b18f4df18afa3763155972c5835f284c5
> > Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
> >              Dmitry Torokhov <dtor@insightbb.com>
> > Status     : problem is being debugged
> 
> That's been happening on my Vaio-of-death for several weeks now.  I spent a
> bit of time with the ACPI guys on it but we didn't get far.  I need to
> find an hour or two to work out what's gone wrong.

I can't reproduce it on any of my machines ...

Does the appended patch help, BTW?


---
 kernel/power/disk.c |    4 ++--
 kernel/power/user.c |    8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6.21-rc7/kernel/power/disk.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/disk.c
+++ linux-2.6.21-rc7/kernel/power/disk.c
@@ -170,9 +170,9 @@ int pm_suspend_disk(void)
 
 	if (in_suspend) {
 		enable_nonboot_cpus();
-		platform_finish();
 		device_resume();
 		resume_console();
+		platform_finish();
 		pr_debug("PM: writing image.\n");
 		error = swsusp_write();
 		if (!error)
@@ -189,9 +189,9 @@ int pm_suspend_disk(void)
  Enable_cpus:
 	enable_nonboot_cpus();
  Resume_devices:
-	platform_finish();
 	device_resume();
 	resume_console();
+	platform_finish();
  Thaw:
 	unprepare_processes();
  Finish:
Index: linux-2.6.21-rc7/kernel/power/user.c
===================================================================
--- linux-2.6.21-rc7.orig/kernel/power/user.c
+++ linux-2.6.21-rc7/kernel/power/user.c
@@ -170,11 +170,11 @@ static inline int snapshot_suspend(int p
 	}
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	mutex_unlock(&pm_mutex);
 	return error;
@@ -202,11 +202,11 @@ static inline int snapshot_restore(int p
 
 	enable_nonboot_cpus();
  Resume_devices:
+	device_resume();
+	resume_console();
 	if (platform_suspend)
 		platform_finish();
 
-	device_resume();
-	resume_console();
  Finish:
 	pm_restore_console();
 	mutex_unlock(&pm_mutex);

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Adrian Bunk]

On Wed, Apr 25, 2007 at 12:31:45PM -0400, Dave Jones wrote:
> On Wed, Apr 25, 2007 at 11:24:42PM +0800, Antonino A. Daplas wrote:
>  > On Wed, 2007-04-25 at 10:33 -0400, Dave Jones wrote:
>  > > On Wed, Apr 25, 2007 at 09:52:16PM +0800, Antonino A. Daplas wrote:
>  > >  > > And have you tried the following settings:
>  > >  > > FB_BACKLIGHT=y
>  > >  > > ACPI_IBM=n
>  > >  > > ACPI_VIDEO=n
>  > > 
>  > 
>  > BTW, there was one report where resume from RAM resulted in a screen
>  > full of garbage.  It seems that the option acpi_sleep= (or s2ram -a3)
>  > did not work for him anymore.  But it worked with s2ram and other
>  > options. So if you have s2ram, try:
>  > 
>  > s2ram -f -s -a3
>  > s2ram -f -m -a3
>  > s2ram -f -p -m
>  > s2ram -f -p -s
> 
> I just did a pull of linus' tree, and it now works for me fine.
> Adrian, I think we can remove this from the list.
>...

Thanks, removed as "seems fixed in -rc8".

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Len Brown]

On Wednesday 25 April 2007 14:08, john stultz wrote:
> On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > This email lists some known regressions in Linus' tree compared to 2.6.20.
> > > 
> > > 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 considering you in any other way
> > > possibly involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : HPET enabled freeze my machine at boot
> > >              workaround: clocksource=acpi_pm
> > > References : http://lkml.org/lkml/2007/4/19/370
> > > Submitter  : Guilherme Schroeder <guilherme@centralinf.com.br>
> > > Caused-By  : Thomas Gleixner <tglx@linutronix.de>
> > >              commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684
> > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > Status     : problem is being debugged
> > > 
> > > 
> > > Subject    : acpi_pm clocksource loses time on x86-64
> > > References : http://lkml.org/lkml/2007/4/17/143
> > > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > Status     : problem is being debugged
> > > 
> > > 
> > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/3/25/217
> > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > Status     : unknown
> > 
> > That's still rather a lot of bustage from the timekeeping changes.  Is
> > anything really happening here or have we all given up?
> 
> 
> The ACPI PM one is *really* odd as its the same clocksource driver on
> both arches. I had Mikael cut out the clocksource frequency adjustments,
> and confirmed both i386 and x86_64 are using the same base freq
> (confirmed via printks).

If this chipset's PM-timer loses "several minutes per hour" on x86_64,
I would expect it to do the same on i386.  I can't imagine what the
difference could be.  Any possibility it is the 24-bit version
and we do something funky on wraparound?

-Len


> It almost seems like when booting x86_64 the ACPI PM counter is running
> slowly! 
> 
> Len: Have you ever heard of such a thing? It seems quite unlikely...
> 
> 
> WRT the HPET freeze issue, I'm still digging there. In that case it
> appears the HPET isn't counting, so timekeeping just stops. I was
> thinking it might be HRT messing w/ the wrong HPET registers, but so far
> that hasn't shaken out.
> 
> I'll spend some more time on these today and see if we get any further.
> 
> thanks
> -john
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[john stultz]

On Wed, 2007-04-25 at 20:33 -0400, Len Brown wrote:
> On Wednesday 25 April 2007 14:08, john stultz wrote:
> > On Wed, 2007-04-25 at 04:06 -0700, Andrew Morton wrote:
> > > On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <bunk@stusta.de> wrote:
> > > > Subject    : acpi_pm clocksource loses time on x86-64
> > > > References : http://lkml.org/lkml/2007/4/17/143
> > > > Submitter  : Mikael Pettersson <mikpe@it.uu.se>
> > > > Handled-By : John Stultz <johnstul@us.ibm.com>
> > > > Status     : problem is being debugged
> > 
> > 
> > The ACPI PM one is *really* odd as its the same clocksource driver on
> > both arches. I had Mikael cut out the clocksource frequency adjustments,
> > and confirmed both i386 and x86_64 are using the same base freq
> > (confirmed via printks).
> 
> If this chipset's PM-timer loses "several minutes per hour" on x86_64,
> I would expect it to do the same on i386.  I can't imagine what the
> difference could be.  Any possibility it is the 24-bit version
> and we do something funky on wraparound?

No, we assume the PM timer wraps at 24 bits and mask it as such on all
systems.

-john

Re: [3/3] 2.6.21-rc7: known regressions (v2)

[Thomas Gleixner]

Jeff,

On Wed, 2007-04-25 at 21:45 +0800, Jeff Chua wrote:
> On 4/25/07, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > > Subject    : suspend to disk hangs  (CONFIG_NO_HZ)
> > > > References : http://lkml.org/lkml/2007/3/25/217
> > > > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > > > Status     : unknown
> > >
> > > That's still rather a lot of bustage from the timekeeping changes.  Is
> > > anything really happening here or have we all given up?
> >
> > Jeff: does that suspend-to-disk hang problem also happen if you use
> > hpet=disable?
> 
> Yes, it is still broken with HPET disabled.
> 
> I've reported that if I press some keys, suspend will complete
> successfully, otherwise, it'll just hang before the "percentage" comes
> on.

Can you please grab the collection of fixups, which I just put into
bugzilla: 

http://bugzilla.kernel.org/attachment.cgi?id=11379&action=view

and apply it on top of 2.6.21 ?

Thanks,

	tglx