Linux 2.6.21-rc7

Subject : kernels fail to boot with drives on ATIIXP controller
(ACPI/IRQ related)
References : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229621

Submitter : Michal Jaegermann <[email protected]>
Status : unknown

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

Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <[email protected]>
Status : unknown

Quoted 7 lines · Adrian Bunk

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

Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <[email protected]>
Status : unknown

Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of the interrupt handler:

Line 751:

        ichdev->position += step * ichdev->fragsize1;
        if (! chip->in_measurement)
                ichdev->position %= ichdev->size;

ichdev->size is 0. Interrupt happened upon request_irq().

Does chip->in_measurement need to be reset because this is a crashdump kernel?

At Mon, 16 Apr 2007 17:44:57 -0400,

Quoted 14 lines · Chuck Ebbert

Quoted 7 lines · Adrian Bunk

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

Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <[email protected]>
Status : unknown

Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of the interrupt handler:

Line 751:

Quoted 8 lines

        ichdev->position += step * ichdev->fragsize1;
        if (! chip->in_measurement)
                ichdev->position %= ichdev->size;

ichdev->size is 0. Interrupt happened upon request_irq().

Does chip->in_measurement need to be reset because this is a crashdump kernel?

No, the problem seems to be the timing of request_irq() and the initialization of hardware. The irq handler shouldn't get called there at all.

How about the patch below?

Takashi

diff -r 4b6ed4ef4820 sound/pci/intel8x0.c

sound/pci/intel8x0.c +3 -10

@@ -2493,6 +2493,7 @@ static int intel8x0_resume(struct pci_de
 		return -EIO;
 	}
 	pci_set_master(pci);
+	snd_intel8x0_chip_init(chip, 0);
 	if (request_irq(pci->irq, snd_intel8x0_interrupt,
 			IRQF_SHARED, card->shortname, chip)) {
 		printk(KERN_ERR "intel8x0: unable to grab IRQ %d, "

@@ -2502,7 +2503,6 @@ static int intel8x0_resume(struct pci_de
 	}
 	chip->irq = pci->irq;
 	synchronize_irq(chip->irq);
-	snd_intel8x0_chip_init(chip, 0);
 
 	/* re-initialize mixer stuff */
 	if (chip->device_type == DEVICE_INTEL_ICH4 && !spdif_aclink) {

@@ -2862,16 +2862,7 @@ static int __devinit snd_intel8x0_create
 		ICH_REG_ALI_INTERRUPTSR : ICH_REG_GLOB_STA;
 	chip->int_sta_mask = int_sta_masks;
 
-	/* request irq after initializaing int_sta_mask, etc */
-	if (request_irq(pci->irq, snd_intel8x0_interrupt,
-			IRQF_SHARED, card->shortname, chip)) {
-		snd_printk(KERN_ERR "unable to grab IRQ %d\n", pci->irq);
-		snd_intel8x0_free(chip);
-		return -EBUSY;
-	}
-	chip->irq = pci->irq;
 	pci_set_master(pci);
-	synchronize_irq(chip->irq);
 
 	switch(chip->device_type) {
 	case DEVICE_INTEL_ICH4:

@@ -2900,6 +2891,15 @@ static int __devinit snd_intel8x0_create
 		snd_intel8x0_free(chip);
 		return err;
 	}
+
+	/* request irq after initializaing int_sta_mask, etc */

Hi Takashi,

Takashi Iwai napisał(a):

Quoted 30 lines

At Mon, 16 Apr 2007 17:44:57 -0400,

Quoted 14 lines · Chuck Ebbert

Quoted 7 lines · Adrian Bunk

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

Subject : snd_intel8x0: divide error: 0000
References : http://lkml.org/lkml/2007/3/5/252
Submitter : Michal Piotrowski <[email protected]>
Status : unknown

Oops is in sound/pci/intel8x0.c::snd_intel8x0_update(), part of the interrupt handler:

Line 751:

Quoted 8 lines

        ichdev->position += step * ichdev->fragsize1;
        if (! chip->in_measurement)
                ichdev->position %= ichdev->size;

ichdev->size is 0. Interrupt happened upon request_irq().

Does chip->in_measurement need to be reset because this is a crashdump kernel?

No, the problem seems to be the timing of request_irq() and the initialization of hardware. The irq handler shouldn't get called there at all.

How about the patch below?

This patch solves the problem for me. Thanks!

Good to hear! I forgot the patch description and sign-off, so here it is again:

[PATCH] ALSA: intel8x0 - Fix Oops in crash kernel

When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init().

Quoted 10 lines · On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai <[email protected]> wrote:

Good to hear! I forgot the patch description and sign-off, so here it is again:

[PATCH] ALSA: intel8x0 - Fix Oops in crash kernel

When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init().

Neat, thanks.

Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it?

At Fri, 20 Apr 2007 11:18:07 -0700,

Quoted 17 lines · Andrew Morton

Quoted 10 lines · On Fri, 20 Apr 2007 12:34:18 +0200 Takashi Iwai <[email protected]> wrote:

Good to hear! I forgot the patch description and sign-off, so here it is again:

[PATCH] ALSA: intel8x0 - Fix Oops in crash kernel

When intel8x0 driver is loaded in the crash kernel, it gets Oops occasionally. This is because the irq handler gets called before the proper hardware initialization. Now defer it after snd_intel8x0_chip_init().

Neat, thanks.

Quoted 2 lines

Do we think this is safe enough and important enough for 2.6.21? And if so, do you want me to merge it?

It should be safe (as I already merged ALSA tree for 2.6.22), but I'd like to test the following before merging 2.6.21:
- suspend/resume works
- no severe problem even if request_irq() fails
I'll check this in this weekend, so let's hold on.

Subject : laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones <[email protected]>

Handled-By Jesse Brandeburg <[email protected]>

Status : problem is being debugged

Quoted 6 lines · Adrian Bunk

Subject : laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones <[email protected]>

Handled-By Jesse Brandeburg <[email protected]>

Status : problem is being debugged

this is being actively debugged, here is what we have so far:
o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used
o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash
o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,bbbbn8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock.
o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine.

one reproduction of the problem was had with scp -l 5000 <file> <remote> when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh.

Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it.

Quoted 18 lines · Jesse

Quoted 6 lines · Adrian Bunk

Subject : laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones <[email protected]>

Handled-By Jesse Brandeburg <[email protected]>

Status : problem is being debugged

this is being actively debugged, here is what we have so far:
o v2.6.20: crashes during boot, unless noacpi and nousb bootparams used
o v2.6.21-rc6: some userspace issue, crashes just after root mount without init=/bin/bash
o v2.6.2X: serial console in docking station spews goo at all speeds with console=ttyS0,bbbbn8 . work continues on this, as we don't know if there are kernel panic messages during the hard lock.
o fedora 7 test kernel 2948: boots okay, have been using this as only truly working kernel on this machine.

Quoted 7 lines

one reproduction of the problem was had with scp -l 5000 <file> <remote> when linked at 100Mb/Full. Tried probably 20 other times same test with no repro, ugh.

Otherwise, slogging through continues. We are actively working on this in case it *is* an e1000 issue. Right now the repro is so unlikely we could hardly tell if we fixed it.

FWIW, I can reproduce this pretty much ondemand, on 100M through the ethernet port on a netgear wireless AP.
A number of our Fedora7 testers are also able to easily reproduce this. To isolate e1000, for tomorrows test build I've reverted e1000 to the same code that was in 2.6.20. If that works out without causing hangs, I'll try and narrow down further which of the dozen csets is responsible.

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 <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
Status : unknown

Quoted 10 lines · Adrian Bunk

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 <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
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

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?

Quoted 13 lines · Dave Jones

Quoted 10 lines · Adrian Bunk

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 <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
Status : unknown

Quoted 6 lines

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.

Quoted 14 lines · Adrian Bunk

Quoted 13 lines · Dave Jones

Quoted 10 lines · Adrian Bunk

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 <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
Status : unknown

I'll try and narrow down exactly where it's failing in the backlight code next, but it's getting late here, so I may leave this until tomorrow for further investigation. Some other clues for anyone playing along at home:
This X60 has Intel graphics. ie, I'm not using any of the drivers that 'select FB_BACKLIGHT',

CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

Quoted 5 lines · Antonino A. Daplas

CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

That also gets me a dead display. Backlight doesn't turn back on.

Quoted 5 lines · Dave Jones

Quoted 3 lines · Antonino A. Daplas

CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?

Quoted 4 lines

Quoted 2 lines

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

That also gets me a dead display. Backlight doesn't turn back on.

Anything under /sys/class/backlight?

Quoted 9 lines · Antonino A. Daplas

Quoted 8 lines · Dave Jones

Quoted 5 lines · Antonino A. Daplas

CONFIG_ACPI_VIDEO depends on BACKLIGHT_CLASS_DEVICE, which, in turn is enabled by FB_BACKLIGHT. So we can narrow it down further, can you try?

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

Quoted 3 lines

Quoted 1 line

That also gets me a dead display. Backlight doesn't turn back on.

Anything under /sys/class/backlight?

Entries from ibm_acpi. I rmmod'd that, leaving the dir empty, and it still fails.

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

That also gets me a dead display. Backlight doesn't turn back on.

Anything under /sys/class/backlight?

Entries from ibm_acpi. I rmmod'd that, leaving the dir empty, and it still fails.

What happens if you never load ibm-acpi?

I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the intelfb driver. One thing it does do is set CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a working display on resume, was that set and was (or had) ibm-acpi been loaded?

A variety of other options such as ACPI_IBM also set CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it will do nothing hence the suspicion is on ibm-acpi, perhaps interacting with the backlight class badly.

Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change the backlight brightness as expected?

If you can ssh into the machine
after its resumed with the display problem, it would be interesting to know what the brightness was and if changing it helped too...

Quoted 11 lines · Richard Purdie

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

CONFIG_FB_BACKLIGHT=y
CONFIG_ACPI_VIDEO=n

That also gets me a dead display. Backlight doesn't turn back on.

Anything under /sys/class/backlight?

Entries from ibm_acpi. I rmmod'd that, leaving the dir empty, and it still fails.

What happens if you never load ibm-acpi?

Same thing. No backlight on resume.
I rm'd the .ko, so there's no chance it got loaded.

Quoted 6 lines

I'm a bit puzzled as CONFIG_FB_BACKLIGHT doesn't do anything with the intelfb driver. One thing it does do is set CONFIG_BACKLIGHT_CLASS_DEVICE. When you disabled FB_BACKLIGHT and got a working display on resume, was that set and was (or had) ibm-acpi been loaded?

Quoted 7 lines

A variety of other options such as ACPI_IBM also set CONFIG_BACKLIGHT_CLASS_DEVICE although without a backlight driver it will do nothing hence the suspicion is on ibm-acpi, perhaps interacting with the backlight class badly.

Does echoing numbers to /sys/class/backlight/ibm_acpi/brightness change the backlight brightness as expected?

/sys/class/backlight/ibm/brightness takes a value from 0 to 7. Starts off with a default of 0. I tried all values in there, and it made no visible difference. But as the no-backlight thing happens without this even loaded, I think this is a separate problem.

Quoted 3 lines

If you can ssh into the machine
after its resumed with the display problem, it would be interesting to know what the brightness was and if changing it helped too...

When the backlight doesn't come on, for some reason, nothing else runs. Capslock works, so it's at least partially alive, but even doing..

echo mem > /sys/power/state ; echo foo >/bar ; sync

results in no /bar being created.
Ethernet remains down when its in this state too.

Quoted 6 lines

When the backlight doesn't come on, for some reason, nothing else runs. Capslock works, so it's at least partially alive, but even doing..

echo mem > /sys/power/state ; echo foo >/bar ; sync

Quoted 2 lines

results in no /bar being created.
Ethernet remains down when its in this state too.

Have you tried these boot options?

acpi_sleep=s3_mode; or
acpi_sleep=s3_bios,s3_mode

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 works only once
References : http://lkml.org/lkml/2007/4/13/240
Submitter : Tobias Diedrich <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit ed746e3b18f4df18afa3763155972c5835f284c5

Handled-By Rafael J. Wysocki <[email protected]>

Dmitry Torokhov <[email protected]>
David Brownell <[email protected]>
Status : problem is being debugged

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 <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
Status : unknown

Quoted 11 lines · Adrian Bunk

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 <[email protected]>
Jeremy Fitzhardinge <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]>
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.

Quoted 3 lines · Dave Jones

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?

Quoted 4 lines · Dave Jones

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?

-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 :)

(quoted diff) +0 -4

-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.

(quoted diff) +2 -1

-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

(quoted diff) +1 -1

-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/

(quoted diff) +1 -1

-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).

Quoted 9 lines · Dave Jones

-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
- =======================

Quoted 1 line

heh, one for Ingo :)

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

Quoted 2 lines

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).

Quoted 1 line

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.

Quoted 4 lines · Dave Jones

Quoted 1 line

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?

Quoted 6 lines · Jeremy Fitzhardinge

Quoted 4 lines · Dave Jones

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 7 lines · Dave Jones

Quoted 6 lines · Jeremy Fitzhardinge

Quoted 4 lines · Dave Jones

Quoted 1 line

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.

Quoted 8 lines

Quoted 3 lines

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>

Since we're still waiting for resolution for some regressions that people weren't able to work on last week, there's a new -rc kernel out there. Hopefully we'll get them all and I can do 2.6.21-final next weekend or so..

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 : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

Quoted 10 lines · 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.

Quoted 4 lines

Subject : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

I've asked for more information about this, and so far am not sure it's a real problem.

Quoted 16 lines · Greg KH

Quoted 14 lines · 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 : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

Quoted 2 lines

I've asked for more information about this, and so far am not sure it's a real problem.

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour. No sync between my Nokia mobile and Linux with the latest kernel :(

Quoted 17 lines · Wolfgang Erig

Quoted 16 lines · Greg KH

Quoted 14 lines · 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 : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

Quoted 6 lines

Quoted 2 lines

I've asked for more information about this, and so far am not sure it's a real problem.

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour. No sync between my Nokia mobile and Linux with the latest kernel :(

Sorry, I didn't see your response, have followed up on lkml now.

thanks,

greg k-h

Quoted 21 lines · Greg KH

Quoted 20 lines · Wolfgang Erig

Quoted 18 lines · Greg KH

Quoted 7 lines · 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.

Quoted 7 lines

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

Subject : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

I've asked for more information about this, and so far am not sure it's a real problem.

Quoted 5 lines

Quoted 3 lines

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour. No sync between my Nokia mobile and Linux with the latest kernel :(

Sorry, I didn't see your response, have followed up on lkml now.

It turned out this was actually a bug in Gammu that will be fixed in the next release of Gammu.

Quoted 26 lines · Adrian Bunk

Quoted 25 lines · Greg KH

Quoted 23 lines · Wolfgang Erig

Quoted 11 lines · Greg KH

Quoted 10 lines · 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.

Quoted 7 lines

Quoted 4 lines

Subject : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

I've asked for more information about this, and so far am not sure it's a real problem.

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour. No sync between my Nokia mobile and Linux with the latest kernel :(

Quoted 4 lines

Quoted 1 line

Sorry, I didn't see your response, have followed up on lkml now.

It turned out this was actually a bug in Gammu that will be fixed in the next release of Gammu.

Ah, ok, thanks for letting me know.

But how was the kernel version change triggering it?

greg k-h

Quoted 6 lines · Greg KH

Quoted 5 lines · Adrian Bunk

Quoted 4 lines · Greg KH

Quoted 3 lines · Wolfgang Erig

Quoted 2 lines · Greg KH

Quoted 1 line · Adrian Bunk

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

2.6.20.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

If you find your name in the Cc header, you are either submitter of

one

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

of the bugs, maintainer of an affectected subsystem or driver, a

patch

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 6 lines

Subject : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

I've asked for more information about this, and so far am not sure

it's

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

a real problem.

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour. No sync between my Nokia mobile and Linux with the latest kernel :(

Sorry, I didn't see your response, have followed up on lkml now.

Quoted 6 lines

Quoted 2 lines

It turned out this was actually a bug in Gammu that will be fixed in the next release of Gammu.

Ah, ok, thanks for letting me know.

But how was the kernel version change triggering it?

I don't know, perhaps a side effect of Eric's work in kernel/signal.c?

Quoted 34 lines · Greg KH

Quoted 22 lines · Adrian Bunk

Quoted 21 lines · Greg KH

Quoted 20 lines · Wolfgang Erig

Quoted 18 lines · Greg KH

Quoted 7 lines · 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.

Quoted 7 lines

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

Subject : gammu no longer works
References : http://lkml.org/lkml/2007/4/20/84
Submitter : Wolfgang Erig <[email protected]>
Status : unknown

I've asked for more information about this, and so far am not sure it's a real problem.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

It is a real problem for me.
I tried this on 2 different boxes with the same behaviour. No sync between my Nokia mobile and Linux with the latest kernel :(

Sorry, I didn't see your response, have followed up on lkml now.

It turned out this was actually a bug in Gammu that will be fixed in the next release of Gammu.

Ah, ok, thanks for letting me know.

Quoted 1 line

But how was the kernel version change triggering it?

I don't know, perhaps a side effect of Eric's work in kernel/signal.c?

The bug in Gammu was:
- Gammu wrongly set FASYNC in a fcntl() call.
- The unhandled SIGIO terminated Gammu in 2.6.21-rc.

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 <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684

Handled-By John Stultz <[email protected]>

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 <[email protected]>

Handled-By John Stultz <[email protected]>

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 <[email protected]>
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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
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 <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit ed746e3b18f4df18afa3763155972c5835f284c5

Handled-By Rafael J. Wysocki <[email protected]>

Dmitry Torokhov <[email protected]>
Status : problem is being debugged

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:
...

Quoted 10 lines

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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 13 lines · Andrew Morton

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:
...

Quoted 10 lines

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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

Quoted 2 lines

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.

Quoted 17 lines · Adrian Bunk

Quoted 15 lines · Andrew Morton

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:
...

Quoted 10 lines

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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 4 lines

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.

Quoted 17 lines · Adrian Bunk

Quoted 15 lines · Andrew Morton

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:
...

Quoted 10 lines

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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 4 lines

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.

Quoted 18 lines · Dave Jones

Quoted 17 lines · Adrian Bunk

Quoted 15 lines · Andrew Morton

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:
...

Quoted 10 lines

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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 6 lines

Quoted 4 lines

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.

Quoted 18 lines · Dave Jones

Quoted 17 lines · Adrian Bunk

Quoted 15 lines · Andrew Morton

On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:
...

Quoted 10 lines

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 <[email protected]>
Caused-By : PCI merge

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 6 lines

Quoted 4 lines

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.

Quoted 3 lines

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/*/.

Quoted 6 lines

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?

Quoted 4 lines

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

Quoted 4 lines · Antonino A. Daplas

Quoted 4 lines

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

Quoted 4 lines · Antonino A. Daplas

Quoted 4 lines

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

Quoted 6 lines · Dave Jones

Quoted 4 lines · Antonino A. Daplas

Quoted 4 lines

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

Quoted 13 lines · Antonino A. Daplas

Quoted 6 lines · Dave Jones

Quoted 4 lines · Antonino A. Daplas

Quoted 4 lines

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:

Quoted 4 lines

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.
...

Dave

Quoted 13 lines · Antonino A. Daplas

Quoted 6 lines · Dave Jones

Quoted 4 lines · Antonino A. Daplas

Quoted 4 lines

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:

Quoted 4 lines

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.
...

Dave

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

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

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
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?

Quoted 5 lines · Andrew Morton

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
Status : unknown

Quoted 2 lines

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?

Quoted 5 lines · Andrew Morton

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
Status : unknown

Quoted 2 lines

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?

Quoted 11 lines · Ingo Molnar

Quoted 7 lines · Andrew Morton

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
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?

Quoted 2 lines

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.

Quoted 11 lines · Ingo Molnar

Quoted 7 lines · Andrew Morton

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
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?

Quoted 2 lines

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.

Quoted 27 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> 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 <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684

Handled-By John Stultz <[email protected]>

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 <[email protected]>

Handled-By John Stultz <[email protected]>

Status : problem is being debugged

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
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?

Quoted 27 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> 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 <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684

Handled-By John Stultz <[email protected]>

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 <[email protected]>

Handled-By John Stultz <[email protected]>

Status : problem is being debugged

Quoted 4 lines

Subject : suspend to disk hangs (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/3/25/217
Submitter : Jeff Chua <[email protected]>
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?

Quoted 34 lines · Andrew Morton

Quoted 31 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> 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 <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684

Handled-By John Stultz <[email protected]>

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 <[email protected]>

Handled-By John Stultz <[email protected]>

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 <[email protected]>
Status : unknown

Quoted 2 lines

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

(quoted diff) +0 -2

-john
 
 
-

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

Quoted 9 lines · john stultz

Quoted 6 lines · Andrew Morton

Quoted 5 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:

Subject : acpi_pm clocksource loses time on x86-64
References : http://lkml.org/lkml/2007/4/17/143
Submitter : Mikael Pettersson <[email protected]>

Handled-By John Stultz <[email protected]>

Status : problem is being debugged

Quoted 4 lines

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?

Quoted 9 lines · john stultz

Quoted 6 lines · Andrew Morton

Quoted 5 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> wrote:

Subject : acpi_pm clocksource loses time on x86-64
References : http://lkml.org/lkml/2007/4/17/143
Submitter : Mikael Pettersson <[email protected]>

Handled-By John Stultz <[email protected]>

Status : problem is being debugged

Quoted 4 lines

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?

Quoted 23 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> 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 <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684

Handled-By John Stultz <[email protected]>

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 <[email protected]>

Quoted 8 lines

Handled-By John Stultz <[email protected]>

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 <[email protected]>
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?

Quoted 6 lines

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 <[email protected]>
Caused-By : PCI merge

Quoted 6 lines

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 9 lines

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 <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit ed746e3b18f4df18afa3763155972c5835f284c5

Handled-By Rafael J. Wysocki <[email protected]>

Dmitry Torokhov <[email protected]>
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.

Quoted 23 lines · On Mon, 23 Apr 2007 23:49:09 +0200 Adrian Bunk <[email protected]> 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 <[email protected]>

Caused-By Thomas Gleixner <[email protected]>

             commit 5d8b34fdcb384161552d01ee8f34af5ff11f9684

Handled-By John Stultz <[email protected]>

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 <[email protected]>

Quoted 8 lines

Handled-By John Stultz <[email protected]>

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 <[email protected]>
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?

Quoted 6 lines

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 <[email protected]>
Caused-By : PCI merge

Quoted 6 lines

             commit 78149df6d565c36675463352d0bfe0000b02b7a7

Handled-By Eric W. Biederman <[email protected]>

Rafael J. Wysocki <[email protected]> Antonino A. Daplas <[email protected]>
Status : unknown

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

Quoted 9 lines

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 <[email protected]>

Caused-By Rafael J. Wysocki <[email protected]>

             commit ed746e3b18f4df18afa3763155972c5835f284c5

Handled-By Rafael J. Wysocki <[email protected]>

Dmitry Torokhov <[email protected]>
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.