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
-

[ message continues ]

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
-

[ message continues ]

That fails with a non-blinking cursor in the top left screen, just like

-

[ message continues ]

Since this is becoming more an IDE/ATA issue, I added
linux-ide@vger.kernel.org to CC. I hope that's the right mailinglist.


  Magic number: 0:971:888
  hash matches drivers/base/power/main.c:82
  hash matches device ptyuf
  hash matches device 0000:00:1f.1


  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 ...
[ message continues ]

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 ...
[ message continues ]

Care to post boot dmesg?  Or does harddisk detection fail because of this?

-- 
tejun
-

[ message continues ]

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: ...
[ message continues ]

[cc'ing libata people]

Hello,


Cool, it proves even my code works from time to time if the moon and

Your BIOS wants to issue DEVICE CONFIGURATION FREEZE LOCK but the device

libata EH gives ACPI one more chance but it fails again, so ACPI is

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
-

[ message continues ]

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


-

[ message continues ]

..

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

Mmmm.. I agree there, too!  I'm not big on filtering out commands
..

Number 1. would take care of this.

Cheers
-

[ message continues ]

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
[ message continues ]

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


-

[ message continues ]

Can you please give a shot at -rc4 kernel?

-- 
tejun
--

[ message continues ]

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


--

[ message continues ]

Here you go.

Cheers
Kjartan

[ message continues ]

Hmmm... Ah.. okay.  Wrongly splitted patch.  Can you please do it one
more time?

Thanks.

-- 
tejun
[ message continues ]

s
[ message continues ]

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

[ message continues ]

Hmm, not sure what happened there. Attaching the filter dmesg output
here.

Cheers
Kjartan

[ message continues ]

Cool, thanks.

-- 
tejun
--

[ message continues ]

I tried experimenting with echoing to [pci]/delete or [acpi]/undock and


attached

tom
[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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


We have yet to figure out how to do that. :-)

Greetings,
Rafael
-

[ message continues ]