echo disk > /sys/power/state
successfully saves that state to the disk, but just as the laptop is
about to turn itself off, it reboots (successfully, so the
hibernation/resume process works well, even with X running! which is
awesome :) ). But I'd rather like the computer turned off after I
hibernate it. Where could the problem be?
It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
days, both suspend and hibernate worked there (with one or two crashes,
probably due to X, I've read that the intel driver got some
suspend/resume improvements recently). Now I'm running gentoo, kernel
2.6.24-rc2. I'm using newer versions of almost all software now compared
to the ubuntu system.
tom
Hi!
> echo disk > /sys/power/state
>
> successfully saves that state to the disk, but just as the laptop is
> about to turn itself off, it reboots (successfully, so the
> hibernation/resume process works well, even with X running! which is
> awesome :) ). But I'd rather like the computer turned off after I
> hibernate it. Where could the problem be?
>
> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
> days, both suspend and hibernate worked there (with one or two crashes,
> probably due to X, I've read that the intel driver got some
> suspend/resume improvements recently). Now I'm running gentoo, kernel
> 2.6.24-rc2. I'm using newer versions of almost all software now compared
> to the ubuntu system.
If it works in older ubuntu, you can probably do bisect. Does normal
shutdown work? You can try platform vs. shutdown mode...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> Hi!
>
>> echo disk > /sys/power/state
>>
>> successfully saves that state to the disk, but just as the laptop is
>> about to turn itself off, it reboots (successfully, so the
>> hibernation/resume process works well, even with X running! which is
>> awesome :) ). But I'd rather like the computer turned off after I
>> hibernate it. Where could the problem be?
>>
>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
>> days, both suspend and hibernate worked there (with one or two crashes,
>> probably due to X, I've read that the intel driver got some
>> suspend/resume improvements recently). Now I'm running gentoo, kernel
>> 2.6.24-rc2. I'm using newer versions of almost all software now compared
>> to the ubuntu system.
>
> If it works in older ubuntu, you can probably do bisect. Does normal
> shutdown work? You can try platform vs. shutdown mode...
>
I don't have ubuntu anymore, though I'll try if hibernate works with the
livecd. One interesting thing I've found out: hibernate reboots the
laptop _only_ if it is in the docking station. If I hibernate while
outside of the docking station, it properly shuts down the laptop.
The default mode seems to be 'platform', after I echoed 'shutdown' to
/sys/power/disk the notebook correctly shuts down after hibernation!
Some interesting facts. All tests were done with 2.6.24-rc2, custom
tailored kernel with just the options needed for my notebook (ThinkPad
X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded.
All tests were done without X running, from the console. If I say
something 'works' it means I tested it at least three/four times in a
row (if not even more).
(1) Both STR and STD work correctly if I keep the notebook outside of
the docking station (both in platform and shutdown mode).
(2) Both STR and STD work correctly if I keep the notebook in the
docking station (both in platform and shutdown mode - with the small
glitch in platform mode that the notebook won't power off after
hibernation).
(3) Once the notebook was in the docking station (whether I boot it
while in the dock or boot it outside and then put it into the dock) and
I take it out (press the 'undock' button on the dock, wait for the green
led, then take out the notebook) things get interesting:
(a) I initiate STR, notebook correctly goes to sleep, but it only wakes
up if I have it in the docking station. If I try to wake it up outside
of the docking station it will fail.
(b) I initiate STD, and it locks up after a few seconds, at that time
only the cursor in the top left screen is visible (not blinking). If I
put the notebook in its locked up state into the dock, it will reboot
after a few seconds.
(4) If the notebook is in the dock and I initiate STR and then press the
undock button, it resumes (I assume that is 'working as intended').
(5) If the notebook is in the dock, I press the undock button and wait
for the green led then initiate STR, I can take the notebook out but
resuming doesn't work - unless I resume it while the notebook is back in
the docking station (see point 3a)
(6) If the notebook is in the dock, I press the undock button and wait
for the green led, then initiate STD:
(a) in platform mode: I can take the notebook out but resuming doesn't
work - unless I resume it while the notebook is back in the docking
station (contrary to point 3b). It seems as the notebook 'locks' itself
into the docking station during STD, I see the green led change into red
during the hibernation process (just before heavy HD activity starts).
(b) in shutdown mode: STD fails with a completely black screen, not even
the cursor is visible.
There doesn't seem to be a difference between platform and shutdown mode
other than the reboot glitch when the laptop is in the docking station
or as described in point 6.
tom
Tomas Carnecky wrote:
> Pavel Machek wrote:
>> Hi!
>>
>>> echo disk > /sys/power/state
>>>
>>> successfully saves that state to the disk, but just as the laptop is
>>> about to turn itself off, it reboots (successfully, so the
>>> hibernation/resume process works well, even with X running! which is
>>> awesome :) ). But I'd rather like the computer turned off after I
>>> hibernate it. Where could the problem be?
>>>
>>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
>>> days, both suspend and hibernate worked there (with one or two crashes,
>>> probably due to X, I've read that the intel driver got some
>>> suspend/resume improvements recently). Now I'm running gentoo, kernel
>>> 2.6.24-rc2. I'm using newer versions of almost all software now compared
>>> to the ubuntu system.
>> If it works in older ubuntu, you can probably do bisect. Does normal
>> shutdown work? You can try platform vs. shutdown mode...
>>
>
> I don't have ubuntu anymore, though I'll try if hibernate works with the
> livecd. One interesting thing I've found out: hibernate reboots the
> laptop _only_ if it is in the docking station. If I hibernate while
> outside of the docking station, it properly shuts down the laptop.
>
> The default mode seems to be 'platform', after I echoed 'shutdown' to
> /sys/power/disk the notebook correctly shuts down after hibernation!
>
> Some interesting facts. All tests were done with 2.6.24-rc2, custom
> tailored kernel with just the options needed for my notebook (ThinkPad
> X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded.
> All tests were done without X running, from the console. If I say
> something 'works' it means I tested it at least three/four times in a
> row (if not even more).
>
> (1) Both STR and STD work correctly if I keep the notebook outside of
> the docking station (both in platform and shutdown mode).
>
> (2) Both STR and STD work correctly if I keep the notebook in the
> docking station (both in platform and shutdown mode - with the small
> glitch in platform mode that the notebook won't power off after
> hibernation).
>
> (3) Once the notebook was in the docking station (whether I boot it
> while in the dock or boot it outside and then put it into the dock) and
> I take it out (press the 'undock' button on the dock, wait for the green
> led, then take out the notebook) things get interesting:
>
> (a) I initiate STR, notebook correctly goes to sleep, but it only wakes
> up if I have it in the docking station. If I try to wake it up outside
> of the docking station it will fail.
That fails with a non-blinking cursor in the top left screen, just like
in point 3b.
>
> (b) I initiate STD, and it locks up after a few seconds, at that time
> only the cursor in the top left screen is visible (not blinking). If I
> put the notebook in its locked up state into the dock, it will reboot
> after a few seconds.
>
> (4) If the notebook is in the dock and I initiate STR and then press the
> undock button, it resumes (I assume that is 'working as intended').
>
> (5) If the notebook is in the dock, I press the undock button and wait
> for the green led then initiate STR, I can take the notebook out but
> resuming doesn't work - unless I resume it while the notebook is back in
> the docking station (see point 3a)
>
> (6) If the notebook is in the dock, I press the undock button and wait
> for the green led, then initiate STD:
>
> (a) in platform mode: I can take the notebook out but resuming doesn't
> work - unless I resume it while the notebook is back in the docking
> station (contrary to point 3b). It seems as the notebook 'locks' itself
> into the docking station during STD, I see the green led change into red
> during the hibernation process (just before heavy HD activity starts).
>
> (b) in shutdown mode: STD fails with a completely black screen, not even
> the cursor is visible.
>
> There doesn't seem to be a difference between platform and shutdown mode
> other than the reboot glitch when the laptop is in the docking station
> or as described in point 6.
>
> tom
Pavel Machek wrote:
> Hi!
>
>> echo disk > /sys/power/state
>>
>> successfully saves that state to the disk, but just as the laptop is
>> about to turn itself off, it reboots (successfully, so the
>> hibernation/resume process works well, even with X running! which is
>> awesome :) ). But I'd rather like the computer turned off after I
>> hibernate it. Where could the problem be?
>>
>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
>> days, both suspend and hibernate worked there (with one or two crashes,
>> probably due to X, I've read that the intel driver got some
>> suspend/resume improvements recently). Now I'm running gentoo, kernel
>> 2.6.24-rc2. I'm using newer versions of almost all software now compared
>> to the ubuntu system.
>
> If it works in older ubuntu, you can probably do bisect. Does normal
> shutdown work? You can try platform vs. shutdown mode...
I forgot, normal shutdown (init 0) works, the 'shutdown' command fails
somewhere in the gentoo init scripts, but that has nothing to do with
the kernel. 'init 6' also works. Both regardless of where the notebook
is (dock or outside).
tom
Since this is becoming more an IDE/ATA issue, I added
[email protected] to CC. I hope that's the right mailinglist.
Tomas Carnecky wrote:
> (3) Once the notebook was in the docking station (whether I boot it
> while in the dock or boot it outside and then put it into the dock) and
> I take it out (press the 'undock' button on the dock, wait for the green
> led, then take out the notebook) things get interesting:
>
> (a) I initiate STR, notebook correctly goes to sleep, but it only wakes
> up if I have it in the docking station. If I try to wake it up outside
> of the docking station it will fail.
Magic number: 0:971:888
hash matches drivers/base/power/main.c:82
hash matches device ptyuf
hash matches device 0000:00:1f.1
00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03)
> (5) If the notebook is in the dock, I press the undock button and wait
> for the green led then initiate STR, I can take the notebook out but
> resuming doesn't work - unless I resume it while the notebook is back in
> the docking station (see point 3a)
Magic number: 0:648:888
hash matches drivers/base/power/main.c:103
hash matches device ptyuf
hash matches device 0000:00:1f.1
00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03)
I kindof had suspected that. The docking station has an ultrabay slot
where I currently have a cdrom drive (since the notebook itself doesn't
have any cdrom drive. Once I took the cdrom drive out, I was able to
successfully perform what I wanted to do in points 3a and 5!
The 'undock' button probably doesn't tell the kernel that it should
unload the cdrom driver. Even though after pressing the undock button
the drive becomes unusable (the green led that is on the side of the
ultrabay disables and it's impossible to open the tray). Though pressing
the undock button causes the usb ports to be removed from the kernel, at
least that's what dmesg suggests (I put the notebook into the dock,
waited a bit and then pressed the undock button):
usb 1-4: new high speed USB device using ehci_hcd and address 11
usb 1-4: configuration #1 chosen from 1 choice
hub 1-4:1.0: USB hub found
hub 1-4:1.0: 4 ports detected
ACPI: \_SB_.GDCK - docking
ACPI: \_SB_.GDCK - undocking
usb 1-4: USB disconnect, address 11
The notebook+dock+STR works as long as the notebook doesn't know about
the ultrabay device. That can be because the notebook was started
outside of the docking station, or inside the docking station but with
the ultrabay removed. But once the notebook sees the ultrabay device
it's over. As little as one suspend/resume cycle inside the docking
station and with a ultrabay device plugged in is enough to make the
kernel (partially) recognize the device - the kernel doesn't recognize
the device as a cdrom drive, but only as an UDMA/33 device. After one
suspend/resume cycle I see this in dmesg:
ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
ata4: failed to recover some devices, retrying in 5 secs
Coming out of suspend...
[... snip ...]
ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5)
ata4.00: revalidation failed (errno=1)
ata4: failed to recover some devices, retrying in 5 secs
ata4.00: configured for UDMA/33
And after that I can't resume outside of the docking station. So the
description of point 3 was incomplete, sorry about that.
At least the two failures 3a and 5 can be explained...
tom
On Sunday, 18 of November 2007, Tomas Carnecky wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >> echo disk > /sys/power/state
> >>
> >> successfully saves that state to the disk, but just as the laptop is
> >> about to turn itself off, it reboots (successfully, so the
> >> hibernation/resume process works well, even with X running! which is
> >> awesome :) ). But I'd rather like the computer turned off after I
> >> hibernate it. Where could the problem be?
> >>
> >> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
> >> days, both suspend and hibernate worked there (with one or two crashes,
> >> probably due to X, I've read that the intel driver got some
> >> suspend/resume improvements recently). Now I'm running gentoo, kernel
> >> 2.6.24-rc2. I'm using newer versions of almost all software now compared
> >> to the ubuntu system.
> >
> > If it works in older ubuntu, you can probably do bisect. Does normal
> > shutdown work? You can try platform vs. shutdown mode...
>
> I forgot, normal shutdown (init 0) works, the 'shutdown' command fails
> somewhere in the gentoo init scripts, but that has nothing to do with
> the kernel. 'init 6' also works. Both regardless of where the notebook
> is (dock or outside).
Please verify if you have the ehci_hcd driver loaded when the box is in the
dock. If so, please try to unload it before hibernation and see if the box
will reboot.
Greetings,
Rafael
sø., 18.11.2007 kl. 21.16 +0100, skrev Tomas Carnecky:
> Since this is becoming more an IDE/ATA issue, I added
> [email protected] to CC. I hope that's the right mailinglist.
>
> Tomas Carnecky wrote:
> > (3) Once the notebook was in the docking station (whether I boot it
> > while in the dock or boot it outside and then put it into the dock) and
> > I take it out (press the 'undock' button on the dock, wait for the green
> > led, then take out the notebook) things get interesting:
> >
> > (a) I initiate STR, notebook correctly goes to sleep, but it only wakes
> > up if I have it in the docking station. If I try to wake it up outside
> > of the docking station it will fail.
>
[snip str problem description]
> ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
> ata4: failed to recover some devices, retrying in 5 secs
> Coming out of suspend...
> [... snip ...]
> ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
> ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5)
> ata4.00: revalidation failed (errno=1)
> ata4: failed to recover some devices, retrying in 5 secs
> ata4.00: configured for UDMA/33
>
I get this exact error message on a normal first time boot here. I'm
using the latest fedora development kernel which is 2.6.24-rc2-git6
based. And I have the latest BIOS from HP IIRC.
This is an HP nc6400 intel based laptop:
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
ata1.00: ACPI on devcfg failed the second time, disabling (errno=-5)
ata1.00: revalidation failed (errno=1)
ata1: failed to recover some devices, retrying in 5 secs
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 892C PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
insmod used greatest stack depth: 596 bytes left
lspci:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 01)
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5753M Gigabit Ethernet PCI Express (rev 21)
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
04:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
04:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
04:06.3 Generic system peripheral [0805]: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
04:06.4 Communication controller: Texas Instruments PCIxx12 GemCore based SmartCard controller
Cheers
Kjartan
Rafael J. Wysocki wrote:
> On Sunday, 18 of November 2007, Tomas Carnecky wrote:
>> Pavel Machek wrote:
>>> Hi!
>>>
>>>> echo disk > /sys/power/state
>>>>
>>>> successfully saves that state to the disk, but just as the laptop is
>>>> about to turn itself off, it reboots (successfully, so the
>>>> hibernation/resume process works well, even with X running! which is
>>>> awesome :) ). But I'd rather like the computer turned off after I
>>>> hibernate it. Where could the problem be?
>>>>
>>>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
>>>> days, both suspend and hibernate worked there (with one or two crashes,
>>>> probably due to X, I've read that the intel driver got some
>>>> suspend/resume improvements recently). Now I'm running gentoo, kernel
>>>> 2.6.24-rc2. I'm using newer versions of almost all software now compared
>>>> to the ubuntu system.
>>> If it works in older ubuntu, you can probably do bisect. Does normal
>>> shutdown work? You can try platform vs. shutdown mode...
>> I forgot, normal shutdown (init 0) works, the 'shutdown' command fails
>> somewhere in the gentoo init scripts, but that has nothing to do with
>> the kernel. 'init 6' also works. Both regardless of where the notebook
>> is (dock or outside).
>
> Please verify if you have the ehci_hcd driver loaded when the box is in the
> dock. If so, please try to unload it before hibernation and see if the box
> will reboot.
I had to recompile the kernel because I have a monolithic kernel with as
many components as possible compiled in. But after I disabled the whole
USB subsystem, the laptop doesn't reboot anymore after hibernation. Is
that a bug in the usb driver or are users supposed to unload ehci_hcd
each time before hibernation? In the former case, I'd be willing to help
debug.
tom
On Thursday, 22 of November 2007, Tomas Carnecky wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 18 of November 2007, Tomas Carnecky wrote:
> >> Pavel Machek wrote:
> >>> Hi!
> >>>
> >>>> echo disk > /sys/power/state
> >>>>
> >>>> successfully saves that state to the disk, but just as the laptop is
> >>>> about to turn itself off, it reboots (successfully, so the
> >>>> hibernation/resume process works well, even with X running! which is
> >>>> awesome :) ). But I'd rather like the computer turned off after I
> >>>> hibernate it. Where could the problem be?
> >>>>
> >>>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few
> >>>> days, both suspend and hibernate worked there (with one or two crashes,
> >>>> probably due to X, I've read that the intel driver got some
> >>>> suspend/resume improvements recently). Now I'm running gentoo, kernel
> >>>> 2.6.24-rc2. I'm using newer versions of almost all software now compared
> >>>> to the ubuntu system.
> >>> If it works in older ubuntu, you can probably do bisect. Does normal
> >>> shutdown work? You can try platform vs. shutdown mode...
> >> I forgot, normal shutdown (init 0) works, the 'shutdown' command fails
> >> somewhere in the gentoo init scripts, but that has nothing to do with
> >> the kernel. 'init 6' also works. Both regardless of where the notebook
> >> is (dock or outside).
> >
> > Please verify if you have the ehci_hcd driver loaded when the box is in the
> > dock. If so, please try to unload it before hibernation and see if the box
> > will reboot.
>
> I had to recompile the kernel because I have a monolithic kernel with as
> many components as possible compiled in. But after I disabled the whole
> USB subsystem, the laptop doesn't reboot anymore after hibernation. Is
> that a bug in the usb driver
Well, I suspect so. We've already had a similar report and there are some
problems that seem to be related to it with some boxes. Still, nobody knows
what the problem really is so far.
> or are users supposed to unload ehci_hcd each time before hibernation?
As a (hopefully temporary) workaround.
> In the former case, I'd be willing to help debug.
We have yet to figure out how to do that. :-)
Greetings,
Rafael
Kjartan Maraas wrote:
> I get this exact error message on a normal first time boot here. I'm
> using the latest fedora development kernel which is 2.6.24-rc2-git6
> based. And I have the latest BIOS from HP IIRC.
>
> This is an HP nc6400 intel based laptop:
Care to post boot dmesg? Or does harddisk detection fail because of this?
--
tejun
Tomas Carnecky wrote:
> I kindof had suspected that. The docking station has an ultrabay slot
> where I currently have a cdrom drive (since the notebook itself doesn't
> have any cdrom drive. Once I took the cdrom drive out, I was able to
> successfully perform what I wanted to do in points 3a and 5!
>
> The 'undock' button probably doesn't tell the kernel that it should
> unload the cdrom driver. Even though after pressing the undock button
> the drive becomes unusable (the green led that is on the side of the
> ultrabay disables and it's impossible to open the tray). Though pressing
> the undock button causes the usb ports to be removed from the kernel, at
> least that's what dmesg suggests (I put the notebook into the dock,
> waited a bit and then pressed the undock button):
That undock button generate an ACPI event, right? You probably need
to hook that ACPI event such that something like the following gets
executed.
echo 1 > /sys/device/pci0000:00/0000:00:1f.1/host?/target?:?:?:?/?:?:?:?/delete"
> usb 1-4: new high speed USB device using ehci_hcd and address 11
> usb 1-4: configuration #1 chosen from 1 choice
> hub 1-4:1.0: USB hub found
> hub 1-4:1.0: 4 ports detected
> ACPI: \_SB_.GDCK - docking
> ACPI: \_SB_.GDCK - undocking
> usb 1-4: USB disconnect, address 11
USB is capable of detecting hotplug event by itself. Unfortunately,
ata_piix can't and in your case accessing non existent device is
resulting machine reset. I don't know why tho. It usually just
causes a bunch of timeouts before libata EH gives up on the device.
> The notebook+dock+STR works as long as the notebook doesn't know about
> the ultrabay device. That can be because the notebook was started
> outside of the docking station, or inside the docking station but with
> the ultrabay removed. But once the notebook sees the ultrabay device
> it's over. As little as one suspend/resume cycle inside the docking
> station and with a ultrabay device plugged in is enough to make the
> kernel (partially) recognize the device - the kernel doesn't recognize
> the device as a cdrom drive, but only as an UDMA/33 device. After one
> suspend/resume cycle I see this in dmesg:
Do you have sr_mod loaded?
> ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
> ata4: failed to recover some devices, retrying in 5 secs
> Coming out of suspend...
> [... snip ...]
> ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
That's your BIOS trying to set UDMA UDMA5 on the drive and the drive
not liking it for some reason.
> ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5)
> ata4.00: revalidation failed (errno=1)
After two tries, libata thinks BIOS is no good and decides to turn off
ACPI.
> ata4: failed to recover some devices, retrying in 5 secs
> ata4.00: configured for UDMA/33
Which results in successful configuration, yay.
> And after that I can't resume outside of the docking station. So the
> description of point 3 was incomplete, sorry about that.
Can you please post...
* full boot log with the ultra bay occupied.
* the result of "hdparm -I /dev/sr0" with the ultra bay occupied.
* the result of "lspci -nnvvv" with the ultra bay occupied.
* full boot log without docking station.
* the result of "lspci -nnvvv" without docking station.
Thanks.
--
tejun
/dev/sr0:
ATAPI CD-ROM, with removable media
Model Number: DVD/CDRW UJDA775
Serial Number:
Firmware Revision: CB03
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: 50us.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(cannot be disabled)
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=180ns IORDY flow control=120ns
HW reset results:
CBLID- below Vih
Device num = 0 determined by CSEL
on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
> Kjartan Maraas wrote:
> > I get this exact error message on a normal first time boot here. I'm
> > using the latest fedora development kernel which is 2.6.24-rc2-git6
> > based. And I have the latest BIOS from HP IIRC.
> >
> > This is an HP nc6400 intel based laptop:
>
> Care to post boot dmesg? Or does harddisk detection fail because of this?
>
Here you go. It shows the error two times and then it gets it right and
continues to boot. No other problems arise from this that I can see.
libata version 3.00 loaded.
ahci 0000:00:1f.2: version 3.0
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 21 (level, low) -> IRQ 22
ahci 0000:00:1f.2: nr_ports (4) and implemented port map (0x1) don't match, using nr_ports
ahci 0000:00:1f.2: forcing PORTS_IMPL to 0xf
usb 2-1: new full speed USB device using uhci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
usb 3-1: new full speed USB device using uhci_hcd and address 2
usb 3-1: configuration #1 chosen from 1 choice
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq ilck stag pm led clo pmp pio slum part
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m1024@0xf4785000 port 0xf4785100 irq 220
ata2: SATA max UDMA/133 abar m1024@0xf4785000 port 0xf4785180 irq 220
ata3: SATA max UDMA/133 abar m1024@0xf4785000 port 0xf4785200 irq 220
ata4: SATA max UDMA/133 abar m1024@0xf4785000 port 0xf4785280 irq 220
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
ata1: failed to recover some devices, retrying in 5 secs
input: PS/2 Generic Mouse as /class/input/input3
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
ata1.00: ACPI on devcfg failed the second time, disabling (errno=-5)
ata1.00: revalidation failed (errno=1)
ata1: failed to recover some devices, retrying in 5 secs
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 0)
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 892C PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 156301488 512-byte hardware sectors (80026 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
insmod used greatest stack depth: 596 bytes left
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
Cheers
Kjartan
[cc'ing libata people]
Hello,
Kjartan Maraas wrote:
> Here you go. It shows the error two times and then it gets it right and
> continues to boot. No other problems arise from this that I can see.
Cool, it proves even my code works from time to time if the moon and
stars are perfectly aligned.
> ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
Your BIOS wants to issue DEVICE CONFIGURATION FREEZE LOCK but the device
NACKs it probably because the drive doesn't support DCO feature set.
> ata1: failed to recover some devices, retrying in 5 secs
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04)
> ata1.00: ACPI on devcfg failed the second time, disabling (errno=-5)
libata EH gives ACPI one more chance but it fails again, so ACPI is
turned off.
> ata1.00: revalidation failed (errno=1)
> ata1: failed to recover some devices, retrying in 5 secs
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/100
Device is now configured properly.
Your BIOS is probably trying to issue DCO freeze lock to all drives. I
don't have the faintest idea why it does but it does. I think there are
several choices here.
1. Ignore device errors for _GTF commands. Report the failure with
KERN_DEBUG priority and just keep processing. ISTR there was a patch to
do this. Anyone knows what happened to it.
2. Filter out certain commands from ACPI. I definitely don't like BIOS
locking up random features via _GTF commands. It makes debugging difficult.
3. Look at opcode on failure and ignore error for certain operations.
My favorite is #2 but #1 should be fine too. Any thoughts?
Thanks.
--
tejun
Tejun Heo wrote:
> 2. Filter out certain commands from ACPI. I definitely don't like BIOS
> locking up random features via _GTF commands. It makes debugging difficult.
I agree.
Take a look at what Alan has been doing for the "trusted" command stuff.
At the very least we should definitely blare a warning into the log if
the BIOS is taking away key features from the user.
Jeff
Tejun Heo wrote:
>
> Your BIOS is probably trying to issue DCO freeze lock to all drives. I
> don't have the faintest idea why it does but it does. I think there are
> several choices here.
>
> 1. Ignore device errors for _GTF commands. Report the failure with
> KERN_DEBUG priority and just keep processing. ISTR there was a patch to
> do this. Anyone knows what happened to it.
..
Since we now *know* that this is how it has to be done
(as otherwise the BIOS would never even attempt DCO here
because most drives don't support it yet),
then ignoring the return value seems to be a useful strategy.
> 2. Filter out certain commands from ACPI. I definitely don't like BIOS
> locking up random features via _GTF commands. It makes debugging difficult.
..
Mmmm.. I agree there, too! I'm not big on filtering out commands
that *we* don't happen to like, but for this specific opcode, yes.
> 3. Look at opcode on failure and ignore error for certain operations.
..
Number 1. would take care of this.
Cheers
Kjartan Maraas wrote:
> on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
>> Kjartan Maraas wrote:
>>> I get this exact error message on a normal first time boot here. I'm
>>> using the latest fedora development kernel which is 2.6.24-rc2-git6
>>> based. And I have the latest BIOS from HP IIRC.
>>>
>>> This is an HP nc6400 intel based laptop:
>> Care to post boot dmesg? Or does harddisk detection fail because of this?
>>
> Here you go. It shows the error two times and then it gets it right and
> continues to boot. No other problems arise from this that I can see.
I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3
and report kernel boot logs for both.
Thanks.
--
tejun
fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo:
> Kjartan Maraas wrote:
> > on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
> >> Kjartan Maraas wrote:
> >>> I get this exact error message on a normal first time boot here. I'm
> >>> using the latest fedora development kernel which is 2.6.24-rc2-git6
> >>> based. And I have the latest BIOS from HP IIRC.
> >>>
> >>> This is an HP nc6400 intel based laptop:
> >> Care to post boot dmesg? Or does harddisk detection fail because of this?
> >>
> > Here you go. It shows the error two times and then it gets it right and
> > continues to boot. No other problems arise from this that I can see.
>
> I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3
> and report kernel boot logs for both.
>
I tried to do that but recent kernels hang on boot here after TSC:
clocksource installed.
Filed a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=405721
but it also happens on the plain rc3 kernel...
Cheers
Kjartan
Kjartan Maraas wrote:
> fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo:
>> Kjartan Maraas wrote:
>>> on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
>>>> Kjartan Maraas wrote:
>>>>> I get this exact error message on a normal first time boot here. I'm
>>>>> using the latest fedora development kernel which is 2.6.24-rc2-git6
>>>>> based. And I have the latest BIOS from HP IIRC.
>>>>>
>>>>> This is an HP nc6400 intel based laptop:
>>>> Care to post boot dmesg? Or does harddisk detection fail because of this?
>>>>
>>> Here you go. It shows the error two times and then it gets it right and
>>> continues to boot. No other problems arise from this that I can see.
>> I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3
>> and report kernel boot logs for both.
>>
> I tried to do that but recent kernels hang on boot here after TSC:
> clocksource installed.
>
> Filed a bug here:
> https://bugzilla.redhat.com/show_bug.cgi?id=405721
>
> but it also happens on the plain rc3 kernel...
Can you please give a shot at -rc4 kernel?
--
tejun
on., 05.12.2007 kl. 16.46 +0900, skrev Tejun Heo:
> Kjartan Maraas wrote:
> > fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo:
> >> Kjartan Maraas wrote:
> >>> on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
> >>>> Kjartan Maraas wrote:
> >>>>> I get this exact error message on a normal first time boot here. I'm
> >>>>> using the latest fedora development kernel which is 2.6.24-rc2-git6
> >>>>> based. And I have the latest BIOS from HP IIRC.
> >>>>>
> >>>>> This is an HP nc6400 intel based laptop:
> >>>> Care to post boot dmesg? Or does harddisk detection fail because of this?
> >>>>
> >>> Here you go. It shows the error two times and then it gets it right and
> >>> continues to boot. No other problems arise from this that I can see.
> >> I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3
> >> and report kernel boot logs for both.
> >>
> > I tried to do that but recent kernels hang on boot here after TSC:
> > clocksource installed.
> >
> > Filed a bug here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=405721
> >
> > but it also happens on the plain rc3 kernel...
>
> Can you please give a shot at -rc4 kernel?
>
Sure. It seems the bug above was caused by the compiler and has been
fixed in rawhide now so I'll give it a try.
Cheers
Kjartan
on., 05.12.2007 kl. 16.46 +0900, skrev Tejun Heo:
> Kjartan Maraas wrote:
> > fr., 30.11.2007 kl. 19.39 +0900, skrev Tejun Heo:
> >> Kjartan Maraas wrote:
> >>> on., 28.11.2007 kl. 10.09 +0900, skrev Tejun Heo:
> >>>> Kjartan Maraas wrote:
> >>>>> I get this exact error message on a normal first time boot here. I'm
> >>>>> using the latest fedora development kernel which is 2.6.24-rc2-git6
> >>>>> based. And I have the latest BIOS from HP IIRC.
> >>>>>
> >>>>> This is an HP nc6400 intel based laptop:
> >>>> Care to post boot dmesg? Or does harddisk detection fail because of this?
> >>>>
> >>> Here you go. It shows the error two times and then it gets it right and
> >>> continues to boot. No other problems arise from this that I can see.
> >> I'm attaching two patches. Please apply each on top of clean 2.6.24-rc3
> >> and report kernel boot logs for both.
> >>
> > I tried to do that but recent kernels hang on boot here after TSC:
> > clocksource installed.
> >
> > Filed a bug here:
> > https://bugzilla.redhat.com/show_bug.cgi?id=405721
> >
> > but it also happens on the plain rc3 kernel...
>
> Can you please give a shot at -rc4 kernel?
>
Here you go.
Cheers
Kjartan
Thanks. Almost there. Can you please try the attached two patches and
report the boot log?
--
tejun
to., 06.12.2007 kl. 11.38 +0900, skrev Tejun Heo:
> Thanks. Almost there. Can you please try the attached two patches and
> report the boot log?
>
Here we go again.
Cheers
Kjartan
Kjartan Maraas wrote:
> to., 06.12.2007 kl. 11.38 +0900, skrev Tejun Heo:
>> Thanks. Almost there. Can you please try the attached two patches and
>> report the boot log?
>>
> Here we go again.
Hmmm... Ah.. okay. Wrongly splitted patch. Can you please do it one
more time?
Thanks.
--
tejun
sø., 09.12.2007 kl. 15.46 +0900, skrev Tejun Heo:
> Kjartan Maraas wrote:
> > to., 06.12.2007 kl. 11.38 +0900, skrev Tejun Heo:
> >> Thanks. Almost there. Can you please try the attached two patches and
> >> report the boot log?
> >>
> > Here we go again.
>
> Hmmm... Ah.. okay. Wrongly splitted patch. Can you please do it one
> more time?
>
> Thanks.
>
Attached.
Cheers
Kjartan
Kjartan Maraas wrote:
>> Hmmm... Ah.. okay. Wrongly splitted patch. Can you please do it one
>> more time?
>>
> Attached.
Alright, it works now but it seems both dmesgs are from no-filter patch.
I'm pretty sure it works too because one of your previous dmesgs showed
it worked. Please double check.
Thanks.
--
tejun
Kjartan Maraas wrote:
> ma., 10.12.2007 kl. 10.03 +0900, skrev Tejun Heo:
>> Kjartan Maraas wrote:
>>>> Hmmm... Ah.. okay. Wrongly splitted patch. Can you please do it one
>>>> more time?
>>>>
>>> Attached.
>> Alright, it works now but it seems both dmesgs are from no-filter patch.
>> I'm pretty sure it works too because one of your previous dmesgs showed
>> it worked. Please double check.
>>
> Hmm, not sure what happened there. Attaching the filter dmesg output
> here.
Cool, thanks.
--
tejun
ma., 10.12.2007 kl. 10.03 +0900, skrev Tejun Heo:
> Kjartan Maraas wrote:
> >> Hmmm... Ah.. okay. Wrongly splitted patch. Can you please do it one
> >> more time?
> >>
> > Attached.
>
> Alright, it works now but it seems both dmesgs are from no-filter patch.
> I'm pretty sure it works too because one of your previous dmesgs showed
> it worked. Please double check.
>
Hmm, not sure what happened there. Attaching the filter dmesg output
here.
Cheers
Kjartan