Re: [2/2] 2.6.21-rc7: known regressions
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! > Hmm, looks like something in device_power_up() went awry. Probably in sysdev_resume(). Greetings, Rafael - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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! J - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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() > > - [] show_trace_log_lvl+0x1a/0x30 > > - [] show_trace+0x12/0x14 > > - [] dump_stack+0x16/0x18 > > - [] init_sched_clock+0x58/0x9b > > - [] init+0x14b/0x241 > > - [] 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
Dave Jones wrote: > -BUG: at arch/i386/kernel/sched-clock.c:170 init_sched_clock() > - [] show_trace_log_lvl+0x1a/0x30 > - [] show_trace+0x12/0x14 > - [] dump_stack+0x16/0x18 > - [] init_sched_clock+0x58/0x9b > - [] init+0x14b/0x241 > - [] 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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-7B2060 LTP0) -ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B2060 LNVO1) +ACPI: XSDT 3F6D12F5, 008C (r1 LENOVO TP-7J1050 LTP0) +ACPI: FACP 3F6D1400, 00F4 (r3 LENOVO TP-7J1050 LNVO1) BIOS differences (lots of these) -Allocating PCI resources starting at 8800 (gap: 8000:7000) +Allocating PCI resources starting at 5000 (gap: 4000:b000) 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 0010 2940 c1a9 +CPU: After all inits, caps: bfe9f3ff 0010 2940 c1a9 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() - [] show_trace_log_lvl+0x1a/0x30 - [] show_trace+0x12/0x14 - [] dump_stack+0x16/0x18 - [] init_sched_clock+0x58/0x9b - [] init+0x14b/0x241 - [] 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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-7B2060 LTP0) -ACPI: FACP 7F6D1A00, 00F4 (r3 LENOVO TP-7B2060 LNVO1) +ACPI: XSDT 3F6D12F5, 008C (r1 LENOVO TP-7J1050 LTP0) +ACPI: FACP 3F6D1400, 00F4 (r3 LENOVO TP-7J1050 LNVO1) BIOS differences (lots of these) -Allocating PCI resources starting at 8800 (gap: 8000:7000) +Allocating PCI resources starting at 5000 (gap: 4000:b000) 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 0010 2940 c1a9 +CPU: After all inits, caps: bfe9f3ff 0010 2940 c1a9 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 config.txt.gz Description: GNU Zip compressed data dmesg.txt.gz Description: GNU Zip compressed data pci.txt.gz Description: GNU Zip compressed data usb.txt.gz Description: GNU Zip compressed data dmi.txt.gz Description: GNU Zip compressed data
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 <[EMAIL PROTECTED]> > > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > Caused-By : PCI merge > > commit 78149df6d565c36675463352d0bfeb02b7a7 > > 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. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 <[EMAIL PROTECTED]> > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Caused-By : PCI merge > commit 78149df6d565c36675463352d0bfeb02b7a7 > 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. J - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 [EMAIL PROTECTED] Jeremy Fitzhardinge [EMAIL PROTECTED] Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 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. J - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 [EMAIL PROTECTED] Jeremy Fitzhardinge [EMAIL PROTECTED] Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 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. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 config.txt.gz Description: GNU Zip compressed data dmesg.txt.gz Description: GNU Zip compressed data pci.txt.gz Description: GNU Zip compressed data usb.txt.gz Description: GNU Zip compressed data dmi.txt.gz Description: GNU Zip compressed data
Re: [2/2] 2.6.21-rc7: known regressions
On Wed, Apr 18, 2007 at 07:48:55AM +0800, Antonino A. Daplas wrote: > > 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. > > Have you tried these boot options? > > acpi_sleep=s3_mode; or > acpi_sleep=s3_bios,s3_mode Yeah, did nothing. I also tried acpi_sleep=s3_bios on its own. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 23:34 -0400, Dave Jones wrote: > On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote: > > > > > > > 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. > > > 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? > > /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. > > > 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. Have you tried these boot options? acpi_sleep=s3_mode; or acpi_sleep=s3_bios,s3_mode Tony - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 23:34 -0400, Dave Jones wrote: On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote: 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. 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? /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. 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. Have you tried these boot options? acpi_sleep=s3_mode; or acpi_sleep=s3_bios,s3_mode Tony - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Wed, Apr 18, 2007 at 07:48:55AM +0800, Antonino A. Daplas wrote: 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. Have you tried these boot options? acpi_sleep=s3_mode; or acpi_sleep=s3_bios,s3_mode Yeah, did nothing. I also tried acpi_sleep=s3_bios on its own. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote: > > > > > 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. > 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? /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. > 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. It's the reason it's taken this long to get any debug info out of it at all. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 <[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 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 03:55 -0400, Dave Jones wrote: > On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote: > > On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: > > > On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: > > > > > > > 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. > > > > 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... Regards, Richard - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote: > On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: > > On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: > > > > > 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. > > Anything under /sys/class/backlight? Entries from ibm_acpi. I rmmod'd that, leaving the dir empty, and it still fails. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: > On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: > > > 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. Anything under /sys/class/backlight? Tony - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: > 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. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 02:29 -0400, Dave Jones wrote: > On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote: > > 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 <[EMAIL PROTECTED]> > > > > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > > > Caused-By : PCI merge > > > > commit 78149df6d565c36675463352d0bfeb02b7a7 > > > > 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 Tony - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote: > 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 <[EMAIL PROTECTED]> > > > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > > Caused-By : PCI merge > > > commit 78149df6d565c36675463352d0bfeb02b7a7 > > > 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. > > I'm not sure why I thought you two ran into the same regression. I'm not sure why I never hit the same bug that Jeremy did (again, maybe subtle hardware differences between our models), but I finally got somewhere. -rc7 with the same config I've been testing exhibited exactly the same bug. Disabling the FB_BACKLIGHT option (and all the FB drivers that 'select' it), I get a working display on resume again. This makes a lot of sense. As before, when I resumed, the backlight wasn't coming back on, but I knew the machine was alive, as capslock was working. (Amusingly, I never noticed the backlight wasn't coming back on until tonight, when I started debugging this with the lights off. Late-night debugging ftw). 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', so somewhere in the common fb code is code that I'm guessing is dependant upon the framebuffer driver doing something or other if FB_BACKLIGHT is set. (Adding Richard to Cc: as he seems to be responsible for the FB backlight code from what I can tell.) Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote: 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 [EMAIL PROTECTED] Jeremy Fitzhardinge [EMAIL PROTECTED] Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 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. I'm not sure why I thought you two ran into the same regression. I'm not sure why I never hit the same bug that Jeremy did (again, maybe subtle hardware differences between our models), but I finally got somewhere. -rc7 with the same config I've been testing exhibited exactly the same bug. Disabling the FB_BACKLIGHT option (and all the FB drivers that 'select' it), I get a working display on resume again. This makes a lot of sense. As before, when I resumed, the backlight wasn't coming back on, but I knew the machine was alive, as capslock was working. (Amusingly, I never noticed the backlight wasn't coming back on until tonight, when I started debugging this with the lights off. Late-night debugging ftw). 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', so somewhere in the common fb code is code that I'm guessing is dependant upon the framebuffer driver doing something or other if FB_BACKLIGHT is set. (Adding Richard to Cc: as he seems to be responsible for the FB backlight code from what I can tell.) Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 02:29 -0400, Dave Jones wrote: On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote: 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 [EMAIL PROTECTED] Jeremy Fitzhardinge [EMAIL PROTECTED] Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 Handled-By : Eric W. Biederman [EMAIL PROTECTED] Rafael J. Wysocki [EMAIL PROTECTED] Status : unknown snip 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 Tony - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: 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. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: 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. Anything under /sys/class/backlight? Tony - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote: On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: 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. Anything under /sys/class/backlight? Entries from ibm_acpi. I rmmod'd that, leaving the dir empty, and it still fails. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, 2007-04-16 at 03:55 -0400, Dave Jones wrote: On Mon, Apr 16, 2007 at 03:32:02PM +0800, Antonino A. Daplas wrote: On Mon, 2007-04-16 at 03:23 -0400, Dave Jones wrote: On Mon, Apr 16, 2007 at 02:54:07PM +0800, Antonino A. Daplas wrote: 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. 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... Regards, Richard - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 [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 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
On Mon, Apr 16, 2007 at 10:26:43AM +0100, Richard Purdie wrote: 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. 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? /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. 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. It's the reason it's taken this long to get any debug info out of it at all. Dave -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 <[EMAIL PROTECTED]> > > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > Caused-By : PCI merge > > commit 78149df6d565c36675463352d0bfeb02b7a7 > > 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. 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 <[EMAIL PROTECTED]> > Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Caused-By : PCI merge > commit 78149df6d565c36675463352d0bfeb02b7a7 > 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 -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 [EMAIL PROTECTED] Jeremy Fitzhardinge [EMAIL PROTECTED] Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 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 -- http://www.codemonkey.org.uk - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 [EMAIL PROTECTED] Jeremy Fitzhardinge [EMAIL PROTECTED] Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 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. 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 - 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/
Re: [2/2] 2.6.21-rc7: known regressions
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 - 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/
