Greetings
I'm experiencing double disk spin down issue on my HP nx6310 laptop
during shut down and suspend to disk. The drive is power down on "Will
now halt message" then turned back on and off again with the laptop
itself. I'm using the newest bios available F.0D, 2.6.23-rc1-mm kernel
along with Debian Unstable plus fixes from Sidux repository so I have
the updated shut down script. I have also verified on two other
systems [AMD/Nforce based] that the spin down issue has been resolved
by the Sidux update and I'm certain that this is a hp bios bug or a
piix kernel module problem.
Michael
Cc'ing Henrique. Any ideas?
Michał sed wrote:
> Greetings
>
> I'm experiencing double disk spin down issue on my HP nx6310 laptop
> during shut down and suspend to disk. The drive is power down on "Will
> now halt message" then turned back on and off again with the laptop
> itself. I'm using the newest bios available F.0D, 2.6.23-rc1-mm kernel
> along with Debian Unstable plus fixes from Sidux repository so I have
> the updated shut down script. I have also verified on two other systems
> [AMD/Nforce based] that the spin down issue has been resolved by the
> Sidux update and I'm certain that this is a hp bios bug or a piix kernel
> module problem.
>
> Michael
--
tejun
Some additional info:
As I stated before I'm using a patched sysvinit package with patch from
Debian bug 426224 with provide a patched hddown.c.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
Michael
On Mon, 06 Aug 2007, Tejun Heo wrote:
> Cc'ing Henrique. Any ideas?
Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is,
remove that -h flag. Usually, there is a hddown variable that holds it, you
just need to get rid of it.
I don't know anything about a Sidux, though.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh
napisał(a):
> On Mon, 06 Aug 2007, Tejun Heo wrote:
> > Cc'ing Henrique. Any ideas?
>
> Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is,
> remove that -h flag. Usually, there is a hddown variable that holds it, you
> just need to get rid of it.
>
> I don't know anything about a Sidux, though.
Well there is an -h variable:
# Don't shut down drives if we're using RAID.
hddown="-h"
if grep -qs '^md.*active' /proc/mdstat
then
hddown=""
fi
....
log_action_msg "Will now halt"
halt -d -f $netdown $poweroff $hddown
However removing it has no effect, the drive still spins down two times.
Sidux is a Debian Unstable based distro with it's own set of patches
including the shut down patch provided here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
Michael
On Mon, 06 Aug 2007, Michael Sedkowski wrote:
> Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh
> napisa??(a):
> > On Mon, 06 Aug 2007, Tejun Heo wrote:
> > > Cc'ing Henrique. Any ideas?
> >
> > Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is,
> > remove that -h flag. Usually, there is a hddown variable that holds it, you
> > just need to get rid of it.
> >
> > I don't know anything about a Sidux, though.
>
> Well there is an -h variable:
> # Don't shut down drives if we're using RAID.
> hddown="-h"
> if grep -qs '^md.*active' /proc/mdstat
> then
> hddown=""
> fi
> ....
> log_action_msg "Will now halt"
> halt -d -f $netdown $poweroff $hddown
> However removing it has no effect, the drive still spins down two times.
Nothing in Debian userspace will spin down the drive if you kill that -h, at
least as far as I know.
> Sidux is a Debian Unstable based distro with it's own set of patches
> including the shut down patch provided here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
You'll probably have to ask Sidux what changes they made that could cause
the double spin down, even if halt(8) is never passed the -h flag.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Monday, 6 August 2007 17:01, Henrique de Moraes Holschuh wrote:
> On Mon, 06 Aug 2007, Michael Sedkowski wrote:
> > Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh
> > napisa??(a):
> > > On Mon, 06 Aug 2007, Tejun Heo wrote:
> > > > Cc'ing Henrique. Any ideas?
> > >
> > > Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is,
> > > remove that -h flag. Usually, there is a hddown variable that holds it, you
> > > just need to get rid of it.
> > >
> > > I don't know anything about a Sidux, though.
> >
> > Well there is an -h variable:
> > # Don't shut down drives if we're using RAID.
> > hddown="-h"
> > if grep -qs '^md.*active' /proc/mdstat
> > then
> > hddown=""
> > fi
> > ....
> > log_action_msg "Will now halt"
> > halt -d -f $netdown $poweroff $hddown
> > However removing it has no effect, the drive still spins down two times.
>
> Nothing in Debian userspace will spin down the drive if you kill that -h, at
> least as far as I know.
>
> > Sidux is a Debian Unstable based distro with it's own set of patches
> > including the shut down patch provided here:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
>
> You'll probably have to ask Sidux what changes they made that could cause
> the double spin down, even if halt(8) is never passed the -h flag.
Well, I've been observing the same behavior on nx6325 for some time and I
use openSUSE 10.2. I think this is kernel-related.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
Dnia 06-08-2007, Pn o godzinie 12:01 -0300, Henrique de Moraes Holschuh
napisał(a):
> On Mon, 06 Aug 2007, Michael Sedkowski wrote:
> > Dnia 06-08-2007, Pn o godzinie 11:23 -0300, Henrique de Moraes Holschuh
> > napisa??(a):
> > > On Mon, 06 Aug 2007, Tejun Heo wrote:
> > > > Cc'ing Henrique. Any ideas?
> > >
> > > Check if /etc/init.d/halt is calling halt(8) with the -h flag. If it is,
> > > remove that -h flag. Usually, there is a hddown variable that holds it, you
> > > just need to get rid of it.
> > >
> > > I don't know anything about a Sidux, though.
> >
> > Well there is an -h variable:
> > # Don't shut down drives if we're using RAID.
> > hddown="-h"
> > if grep -qs '^md.*active' /proc/mdstat
> > then
> > hddown=""
> > fi
> > ....
> > log_action_msg "Will now halt"
> > halt -d -f $netdown $poweroff $hddown
> > However removing it has no effect, the drive still spins down two times.
>
> Nothing in Debian userspace will spin down the drive if you kill that -h, at
> least as far as I know.
>
> > Sidux is a Debian Unstable based distro with it's own set of patches
> > including the shut down patch provided here:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
>
> You'll probably have to ask Sidux what changes they made that could cause
> the double spin down, even if halt(8) is never passed the -h flag.
>
The double spin down problem occurs not only on Sidux, but on all
distros that I isued like Fedora 7, Mandriva, Debian or Ubuntu with
kernels ranging from 2.6.18 to 2.6.22. I only use the Sidux because they
released the shut down patch required to shut down properly on the
2.6.22 kernel line and on two other systems the drives are turned off
nicely [standard Debian still runs on the old shut down scripts. On that
basis I believe that this is a HP (Intel?) issue not related to any
particular distro.
Rafael J. Wysocki wrote:
>>> Sidux is a Debian Unstable based distro with it's own set of patches
>>> including the shut down patch provided here:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
>> You'll probably have to ask Sidux what changes they made that could cause
>> the double spin down, even if halt(8) is never passed the -h flag.
>
> Well, I've been observing the same behavior on nx6325 for some time and I
> use openSUSE 10.2. I think this is kernel-related.
Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down and up.
Thanks.
--
tejun
Dnia 07-08-2007, Wt o godzinie 02:03 +0900, Tejun Heo napisał(a):
> Rafael J. Wysocki wrote:
> >>> Sidux is a Debian Unstable based distro with it's own set of patches
> >>> including the shut down patch provided here:
> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
> >> You'll probably have to ask Sidux what changes they made that could cause
> >> the double spin down, even if halt(8) is never passed the -h flag.
> >
> > Well, I've been observing the same behavior on nx6325 for some time and I
> > use openSUSE 10.2. I think this is kernel-related.
>
> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> pulling unnecessary stunt. Please apply the attached patch and report
> when the disk spins down and up.
>
> Thanks.
>
Disk spins down on "Pre-shutdown prepare" and then goes up and down on
"Power down".
Michael Sedkowski wrote:
>> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
>> pulling unnecessary stunt. Please apply the attached patch and report
>> when the disk spins down and up.
>
> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> "Power down".
Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
it spins down the disk correctly. Does emergency unload count increase
after each power down? Also, please post the result of 'dmidecode'.
Thanks.
--
tejun
On Monday, 6 August 2007 20:21, Michael Sedkowski wrote:
> Dnia 07-08-2007, Wt o godzinie 02:03 +0900, Tejun Heo napisał(a):
> > Rafael J. Wysocki wrote:
> > >>> Sidux is a Debian Unstable based distro with it's own set of patches
> > >>> including the shut down patch provided here:
> > >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224
> > >> You'll probably have to ask Sidux what changes they made that could cause
> > >> the double spin down, even if halt(8) is never passed the -h flag.
> > >
> > > Well, I've been observing the same behavior on nx6325 for some time and I
> > > use openSUSE 10.2. I think this is kernel-related.
> >
> > Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> > pulling unnecessary stunt. Please apply the attached patch and report
> > when the disk spins down and up.
> >
> > Thanks.
> >
>
> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> "Power down".
Same thing on my box.
In kernel_shutdown_prepare(SYSTEM_POWER_OFF) we call device_shutdown(), so it
looks like the drive is powered off by one driver's .shutdown() routine.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
On Monday, 6 August 2007 20:43, Tejun Heo wrote:
> Michael Sedkowski wrote:
> >> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> >> pulling unnecessary stunt. Please apply the attached patch and report
> >> when the disk spins down and up.
> >
> > Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> > "Power down".
>
> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> it spins down the disk correctly. Does emergency unload count increase
> after each power down?
How to check that?
> Also, please post the result of 'dmidecode'.
Here's mine, from nx6325 (Michael's is a different model):
# dmidecode 2.8
SMBIOS 2.4 present.
23 structures occupying 1029 bytes.
Table at 0x000F3FA3.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Hewlett-Packard
Version: 68TT2 Ver. F.02
Release Date: 07/06/2006
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 KB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 15.2
Firmware Revision: 64.21
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name: HP Compaq nx6325 (EY351EA#AKD)
Version: F.02
Serial Number: CNU63201YR
UUID: CDF6EA3B-A5D7-DD11-0188-6D990C3F6129
Wake-up Type: Power Switch
SKU Number: EY351EA#AKD
Family: 103C_5336AN
Handle 0x0040, DMI type 126, 33 bytes
Inactive
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Hewlett-Packard
Product Name: 30B0
Version: KBC Version 40.15
Serial Number: Not Specified
Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
Manufacturer: Hewlett-Packard
Type: Notebook
Lock: Not Present
Version: Not Specified
Serial Number: CNU63201YR
Asset Tag: CNU63201YR
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: External Interface Enabled
Handle 0x0041, DMI type 126, 32 bytes
Inactive
Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: U10
Type: Central Processor
Family: Athlon 64
Manufacturer: AMD(R)
ID: 82 0F 04 00 FF FB 8B 17
Signature: Extended Family 0, Model 8, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Hyper-threading technology)
Version: AMD Turion(tm) 64 X2 Mobile TL-60
Voltage: 1.1 V
External Clock: 200 MHz
Max Speed: 2000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 128 KB
Maximum Size: 128 KB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: 4-way Set-associative
Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: External
Installed Size: 512 KB
Maximum Size: 512 KB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: None
System Type: Unified
Associativity: 4-way Set-associative
Handle 0x0007, DMI type 9, 13 bytes
System Slot Information
Designation: PC CARD-Slot 0
Type: 32-bit PC Card (PCMCIA)
Current Usage: Available
Length: Short
ID: Adapter 0, Socket 0
Characteristics:
5.0 V is provided
3.3 V is provided
PC Card-16 is supported
Cardbus is supported
PME signal is supported
Handle 0x0008, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: 128
Handle 0x0009, DMI type 11, 5 bytes
OEM Strings
String 1: http://www.hp.com
String 2: ABS 70/71 79 7A 7B 7C
Handle 0x000A, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: No Error
Number Of Devices: 2
Handle 0x000B, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: SODIMM
Set: None
Locator: DIMM #1
Bank Locator: Not Specified
Type: DDR2
Type Detail: Synchronous
Speed: 667 MHz (1.5 ns)
Manufacturer: 7F7F7F7F7F510000
Serial Number: 0213A826
Asset Tag: Not Specified
Part Number: 64T128021HDL3SB
Handle 0x000C, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: SODIMM
Set: None
Locator: DIMM #2
Bank Locator: Not Specified
Type: DDR2
Type Detail: Synchronous
Speed: 667 MHz (1.5 ns)
Manufacturer: 7F98000000000000
Serial Number: 670FA506
Asset Tag: Not Specified
Part Number:
Handle 0x000D, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0007FFFFFFF
Range Size: 2 GB
Physical Array Handle: 0x000A
Partition Width: 0
Handle 0x000E, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Device Handle: 0x000B
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: 1
Handle 0x000F, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00040000000
Ending Address: 0x0007FFFFFFF
Range Size: 1 GB
Physical Device Handle: 0x000C
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: 2
Handle 0x0010, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0085, DMI type 133, 34 bytes
OEM-specific Type
Header and Data:
85 22 85 00 01 50 14 B9 08 9F 08 02 00 32 00 1C
00 F5 2D 43 FB 30 2A 02 E0 40 00 00 49 0F 58 0F
55 0F
Strings:
00185 0D/24/2006
HP
Handle 0x0086, DMI type 126, 34 bytes
Inactive
Handle 0x0011, DMI type 144, 26 bytes
OEM-specific Type
Header and Data:
90 1A 11 00 FD 00 65 00 11 00 80 02 06 02 31 00
00 00 00 00 01 00 EB 07 00 00
Handle 0x0012, DMI type 127, 4 bytes
End Of Table
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> it spins down the disk correctly. Does emergency unload count increase
> after each power down? Also, please post the result of 'dmidecode'.
>
> Thanks.
>
I do not know how to check this emergency unload count, so please
explain what do I need to do.
dmidecode:
dmidecode 2.9
SMBIOS 2.4 present.
23 structures occupying 1029 bytes.
Table at 0x000F38EB.
Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: Hewlett-Packard
Version: 68YDU Ver. F.0D
Release Date: 04/17/2007
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 1024 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 KB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
LS-120 boot is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 15.13
Firmware Revision: 88.18
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Hewlett-Packard
Product Name:
Version: F.0D
Serial Number:
UUID: Not Settable
Wake-up Type: Power Switch
SKU Number:
Family: 103C_5336AN
Handle 0x0040, DMI type 126, 4 bytes
Inactive
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: Hewlett-Packard
Product Name: 30AA
Version: KBC Version 58.12
Serial Number: Not Specified
Handle 0x0003, DMI type 3, 13 bytes
Chassis Information
Manufacturer: Hewlett-Packard
Type: Notebook
Lock: Not Present
Version: Not Specified
Serial Number:
Asset Tag: CNU63515Y3
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: External Interface Enabled
Handle 0x0041, DMI type 126, 10 bytes
Inactive
Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: U10
Type: Central Processor
Family: Pentium M
Manufacturer: Intel(R)
ID: E8 06 00 00 FF FB E9 BF
Signature: Type 0, Family 6, Model 14, Stepping 8
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Hyper-threading technology)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Genuine Intel(R) CPU T2050 @ 1.60GHz
Voltage: 1.1 V
External Clock: 133 MHz
Max Speed: 1600 MHz
Current Speed: 1600 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 KB
Maximum Size: 64 KB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: 4-way Set-associative
Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: Internal L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: External
Installed Size: 2048 KB
Maximum Size: 2048 KB
Supported SRAM Types:
Burst
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: None
System Type: Unified
Associativity: 4-way Set-associative
Handle 0x0007, DMI type 9, 13 bytes
System Slot Information
Designation: PC CARD-Slot 0
Type: 32-bit PC Card (PCMCIA)
Current Usage: Available
Length: Short
ID: Adapter 0, Socket 0
Characteristics:
5.0 V is provided
3.3 V is provided
PC Card-16 is supported
Cardbus is supported
PME signal is supported
Handle 0x0008, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: 8
Handle 0x0009, DMI type 11, 5 bytes
OEM Strings
String 1: http://www.hp.com
String 2: ABS 70/71 79 7A 7B 7C
Handle 0x000A, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 4 GB
Error Information Handle: No Error
Number Of Devices: 2
Handle 0x000B, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 512 MB
Form Factor: SODIMM
Set: None
Locator: DIMM #1
Bank Locator: Not Specified
Type: DDR2
Type Detail: Synchronous
Speed: 667 MHz (1.5 ns)
Manufacturer: 7F7F7F7F7F510000
Serial Number: 03016A14
Asset Tag: Not Specified
Part Number: 64T64020HDL3SB
Handle 0x000C, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000A
Error Information Handle: No Error
Total Width: 64 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: SODIMM
Set: None
Locator: DIMM #2
Bank Locator: Not Specified
Type: DDR2
Type Detail: Synchronous
Speed: 667 MHz (1.5 ns)
Manufacturer: 7F7F7F2500000000
Serial Number: 00000000
Asset Tag: Not Specified
Part Number: KSCD48F-A8KB5
Handle 0x000D, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0005FFFFFFF
Range Size: 1536 MB
Physical Array Handle: 0x000A
Partition Width: 0
Handle 0x000E, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0001FFFFFFF
Range Size: 512 MB
Physical Device Handle: 0x000B
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: 1
Handle 0x000F, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00020000000
Ending Address: 0x0005FFFFFFF
Range Size: 1 GB
Physical Device Handle: 0x000C
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: 2
Handle 0x0010, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0085, DMI type 133, 34 bytes
OEM-specific Type
Header and Data:
85 22 85 00 01 A0 0F 2B 0F 56 0E 05 00 25 00 1D
00 71 30 00 00 30 2A 02 E0 40 00 00 22 10 25 10
2B 10
Strings:
11952 08/03/2006
HP
Handle 0x0086, DMI type 126, 34 bytes
Inactive
Handle 0x0011, DMI type 144, 26 bytes
OEM-specific Type
Header and Data:
90 1A 11 00 5B 00 65 00 DE 00 5D 00 0C 00 13 00
00 00 0C 00 19 00 43 01 00 00
Handle 0x0012, DMI type 127, 4 bytes
End Of Table
Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
> Does emergency unload count increase
> after each power down?
I think I got it.
Using smartctl I've done a test and shut down, then repeted the test.
The only values that where diffrent are temperatures and
Hardware_ECC_Recovered which rised by 6 points.
However I have no idea which of those is the "emergency count"...
Full results in attachment.
Regards,
Michael
Tejun Heo wrote:
> Michael Sedkowski wrote:
>>> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
>>> pulling unnecessary stunt. Please apply the attached patch and report
>>> when the disk spins down and up.
>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
>> "Power down".
>
> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> it spins down the disk correctly. Does emergency unload count increase
> after each power down? Also, please post the result of 'dmidecode'.
I know that my Compaq X1000-series laptop does do some kind of ACPI
games with the disk on ACPI power off (I assume it is putting the disk
in standby before power-off at least). It also does this if you boot
into DOS, GRUB, etc. and then hit the power button. Could be if the disk
is dumb enough to spin up for sync cache and standby when there is
nothing to flush, and the kernel does its own standby, this could cause
an extra spinup/down..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Tue, 07 Aug 2007, Tejun Heo wrote:
> Michael Sedkowski wrote:
> >> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> >> pulling unnecessary stunt. Please apply the attached patch and report
> >> when the disk spins down and up.
> >
> > Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> > "Power down".
>
> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> it spins down the disk correctly. Does emergency unload count increase
> after each power down? Also, please post the result of 'dmidecode'.
You know, this actually make a lot of sense, and one can't even complain
about firmware that pulls that off. Any chances of changing things
so that we inspect/snoop all tasks sent to the device, and filter them
out, or react to them accordingly?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Robert Hancock wrote:
> Tejun Heo wrote:
>> Michael Sedkowski wrote:
>>>> Hmmm... If the problem only shows up on nx6325, it might be that
>>>> ACPI is
>>>> pulling unnecessary stunt. Please apply the attached patch and report
>>>> when the disk spins down and up.
>>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
>>> "Power down".
>>
>> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
>> it spins down the disk correctly. Does emergency unload count increase
>> after each power down? Also, please post the result of 'dmidecode'.
>
> I know that my Compaq X1000-series laptop does do some kind of ACPI
> games with the disk on ACPI power off (I assume it is putting the disk
> in standby before power-off at least). It also does this if you boot
> into DOS, GRUB, etc. and then hit the power button. Could be if the disk
> is dumb enough to spin up for sync cache and standby when there is
> nothing to flush, and the kernel does its own standby, this could cause
> an extra spinup/down..
Yeah, that seems to be what's going on. I don't think we have any other
choice than blacklisting those notebooks. This is a mess. How does the
other OS cope with this?
I'm thinking about using DMI vendor/product match to detect the affected
systems but I think it would be better to match the ACPI implementation
directly. Is there a way to match specific ACPI implementation?
Thanks.
--
tejun
Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
>> Michael Sedkowski wrote:
>>>> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
>>>> pulling unnecessary stunt. Please apply the attached patch and report
>>>> when the disk spins down and up.
>>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
>>> "Power down".
>> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
>> it spins down the disk correctly. Does emergency unload count increase
>> after each power down? Also, please post the result of 'dmidecode'.
>
> You know, this actually make a lot of sense, and one can't even complain
> about firmware that pulls that off.
Well, I'm complaining. I think the problem here is that it isn't clear
which one is who's responsibility. There's a Korean saying which
approximately translates into "if you have too many boatmen on a ship,
it goes to mountain". We also have a bunch of Toshiba laptops which
want the ATA controller to be in enabled state when ACPI suspend is
invoked because the suspend method apparently wants to execute some
commands before going to sleep.
I wish ACPI spec carries a big fat sign saying "stay f*** away from
anything which isn't essential to the requested operation".
> Any chances of changing things
> so that we inspect/snoop all tasks sent to the device, and filter them
> out, or react to them accordingly?
No, we can't unless we snoop ACPI method execution and detect accesses
to IO ports or iomem regions. It's not going through any driver. This
is a gross mess.
--
tejun
Michael Sedkowski wrote:
> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
>> Does emergency unload count increase
>> after each power down?
>
> I think I got it.
> Using smartctl I've done a test and shut down, then repeted the test.
> The only values that where diffrent are temperatures and
> Hardware_ECC_Recovered which rised by 6 points.
> However I have no idea which of those is the "emergency count"...
> Full results in attachment.
>
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 388
I think this is the one. You can test it by forcefully powering off the
machine (press power button for several secs or disconnect AC and
battery) and see whether the count increases.
--
tejun
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
> Always - 388
>
> I think this is the one. You can test it by forcefully powering off
> the
> machine (press power button for several secs or disconnect AC and
> battery) and see whether the count increases.
>
When I forcefully power off using the power button the raw value [last
one] rise by 1 point from 389 to 390. When I power off normally with
linux it remains constant.
Now could some one please explain to me what does that mean and am I in
danger of data loss?
Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
> You can test it by forcefully powering off the
> machine (press power button for several secs or disconnect AC and
> battery) and see whether the count increases.
Forgot to mention that double spin down does not happen when the laptop
is powered down forcefully and as my friend described who has te same
model it "sounds right"...
Michael Sedkowski wrote:
> Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
>> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
>> Always - 388
>>
>> I think this is the one. You can test it by forcefully powering off
>> the
>> machine (press power button for several secs or disconnect AC and
>> battery) and see whether the count increases.
>>
> When I forcefully power off using the power button the raw value [last
> one] rise by 1 point from 389 to 390. When I power off normally with
> linux it remains constant.
> Now could some one please explain to me what does that mean and am I in
> danger of data loss?
So, the ACPI routine puts the disk into the standby mode before powering
off. That's good.
On power off, the r/w heads in a disk should be unloaded (parked). This
is usually achieved by either putting the disk into standby/sleep mode
during shutdown. However, all modern disks can automatically unload
their heads when the power is removed abruptly. This is called
emergency unload. Emergency unload does shorten the lifespan of the
disk but you don't have to worry too much about it. Disks are designed
to withstand certain number of emergency unloads.
--
tejun
Tejun Heo wrote:
> Michael Sedkowski wrote:
> > Dnia 07-08-2007, Wt o godzinie 15:56 +0900, Tejun Heo napisał(a):
> >> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
> >> Always - 388
[snip]
> On power off, the r/w heads in a disk should be unloaded (parked). This
> is usually achieved by either putting the disk into standby/sleep mode
> during shutdown. However, all modern disks can automatically unload
> their heads when the power is removed abruptly. This is called
> emergency unload. Emergency unload does shorten the lifespan of the
> disk but you don't have to worry too much about it. Disks are designed
> to withstand certain number of emergency unloads.
Out of interest, does Power-Off_Retract_Count attribute only record emergency unloads
rather than normal power off by Linux shutdown command?
Thanks in advance,
Sam
On Tue, 07 Aug 2007, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Michael Sedkowski wrote:
> >>>> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> >>>> pulling unnecessary stunt. Please apply the attached patch and report
> >>>> when the disk spins down and up.
> >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> >>> "Power down".
> >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> >> it spins down the disk correctly. Does emergency unload count increase
> >> after each power down? Also, please post the result of 'dmidecode'.
> >
> > You know, this actually make a lot of sense, and one can't even complain
> > about firmware that pulls that off.
>
> Well, I'm complaining. I think the problem here is that it isn't clear
> which one is who's responsibility. There's a Korean saying which
The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
about it. Doing it through ACPI ATA objects is at least non-broken as far
as these things go, as one knows when to do it directly ("non-ACPI mode"),
and one doesn't talk to the disk directly.
> approximately translates into "if you have too many boatmen on a ship,
> it goes to mountain". We also have a bunch of Toshiba laptops which
Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
is asking us to deliver to the disks, which IMO is an extremely good idea
anyway.
> want the ATA controller to be in enabled state when ACPI suspend is
> invoked because the suspend method apparently wants to execute some
> commands before going to sleep.
That's just broken, since it is not even using a OS-backed SATA/ATA ACPI
method to do it.
> I wish ACPI spec carries a big fat sign saying "stay f*** away from
> anything which isn't essential to the requested operation".
Shutting down disks *is* essential to the power off operation. ACPI would
have to mandate who is to do it, instead (ACPI table or OSI by itself).
> > Any chances of changing things
> > so that we inspect/snoop all tasks sent to the device, and filter them
> > out, or react to them accordingly?
>
> No, we can't unless we snoop ACPI method execution and detect accesses
> to IO ports or iomem regions. It's not going through any driver. This
> is a gross mess.
I don't mean fixing the stuff clowns like Toshiba did. The correct fix for
that is to blacklist the hell out of that crap and patch their DSDT into
something remotely sane.
I do mean snooping the ACPI methods that *return* a taskset to send to the
driver, and we send that taskset ourselves in libata and libpata(?).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Tue, 07 Aug 2007, Tejun Heo wrote:
> emergency unload. Emergency unload does shorten the lifespan of the
> disk but you don't have to worry too much about it. Disks are designed
> to withstand certain number of emergency unloads.
You *do* have to worry about it in any box you turn off daily. Desktop HDs
will croak fast in that scenario, laptop HDs less so, but still too fast.
A very good laptop HD can last about 20k emergency unloads (this is a unit
that can do about 600k normal unloads in its lifetime). Desktop and server
HDs don't even come close to those numbers, last time I checked.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
> > Henrique de Moraes Holschuh wrote:
> > > On Tue, 07 Aug 2007, Tejun Heo wrote:
> > >> Michael Sedkowski wrote:
---snip---
> > > Any chances of changing things
> > > so that we inspect/snoop all tasks sent to the device, and filter them
> > > out, or react to them accordingly?
> >
> > No, we can't unless we snoop ACPI method execution and detect accesses
> > to IO ports or iomem regions. It's not going through any driver. This
> > is a gross mess.
>
> I don't mean fixing the stuff clowns like Toshiba did. The correct fix for
> that is to blacklist the hell out of that crap and patch their DSDT into
> something remotely sane.
>
> I do mean snooping the ACPI methods that *return* a taskset to send to the
> driver, and we send that taskset ourselves in libata and libpata(?).
I haven't read the whole thread in every detail, but this sounds like a
very intrusive, overdosed workaround.
Are the DSDT/SSDTs already lying around somewhere (collecting them in a
bug assigned to ACPI component should be a good idea)?
Could someone give me a pointer where this happens (best in code and
DSDT).
Thanks,
Thomas
Hello, Henrique.
Henrique de Moraes Holschuh wrote:
>> approximately translates into "if you have too many boatmen on a ship,
>> it goes to mountain". We also have a bunch of Toshiba laptops which
>
> Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> is asking us to deliver to the disks, which IMO is an extremely good idea
> anyway.
If it were done that way (by asking OS driver to deliver commands TFs),
I wouldn't have any problem at all. The spin down command is issued
from deep down in the acpi power off method - entering S5 directly
issues ATA commands bypassing the whole OS except for the ACPI
interpreter. It's just like the toshiba suspend crap and there's no
standard way to tell whether the acpi power off method is gonna do it or
not. We'll just have to blacklist it.
Thanks.
--
tejun
On Tue, 07 Aug 2007, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> >> approximately translates into "if you have too many boatmen on a ship,
> >> it goes to mountain". We also have a bunch of Toshiba laptops which
> >
> > Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> > is asking us to deliver to the disks, which IMO is an extremely good idea
> > anyway.
>
> If it were done that way (by asking OS driver to deliver commands TFs),
> I wouldn't have any problem at all. The spin down command is issued
> from deep down in the acpi power off method - entering S5 directly
> issues ATA commands bypassing the whole OS except for the ACPI
> interpreter. It's just like the toshiba suspend crap and there's no
> standard way to tell whether the acpi power off method is gonna do it or
> not. We'll just have to blacklist it.
Urk. I see.
I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
doing this. Who should we prod to add that check?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
>> Henrique de Moraes Holschuh wrote:
>>>> approximately translates into "if you have too many boatmen on a ship,
>>>> it goes to mountain". We also have a bunch of Toshiba laptops which
>>> Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
>>> is asking us to deliver to the disks, which IMO is an extremely good idea
>>> anyway.
>> If it were done that way (by asking OS driver to deliver commands TFs),
>> I wouldn't have any problem at all. The spin down command is issued
>> from deep down in the acpi power off method - entering S5 directly
>> issues ATA commands bypassing the whole OS except for the ACPI
>> interpreter. It's just like the toshiba suspend crap and there's no
>> standard way to tell whether the acpi power off method is gonna do it or
>> not. We'll just have to blacklist it.
>
> Urk. I see.
>
> I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
> doing this. Who should we prod to add that check?
Dunno how the firmware toolkit works but this one can be pretty
difficult to test (if it were easy, we could test it in libata) as it
involves entering S5. If it's possible, I'm all for it. Also, it would
be nice if we can test the same thing for S3 and S4.
Thomas, who should we ask things about the Linux firmware toolkit? Thanks.
--
tejun
Thomas Renninger wrote:
>>>> Any chances of changing things
>>>> so that we inspect/snoop all tasks sent to the device, and filter them
>>>> out, or react to them accordingly?
>>> No, we can't unless we snoop ACPI method execution and detect accesses
>>> to IO ports or iomem regions. It's not going through any driver. This
>>> is a gross mess.
>> I don't mean fixing the stuff clowns like Toshiba did. The correct fix for
>> that is to blacklist the hell out of that crap and patch their DSDT into
>> something remotely sane.
>>
>> I do mean snooping the ACPI methods that *return* a taskset to send to the
>> driver, and we send that taskset ourselves in libata and libpata(?).
>
> I haven't read the whole thread in every detail, but this sounds like a
> very intrusive, overdosed workaround.
>
> Are the DSDT/SSDTs already lying around somewhere (collecting them in a
> bug assigned to ACPI component should be a good idea)?
> Could someone give me a pointer where this happens (best in code and
> DSDT).
The toshiba problem is already taken care of. It's the issue that we
talked over beer. Let me look up the bug number... It's 7780.
http://bugzilla.kernel.org/show_bug.cgi?id=7780
This was worked around by blacklisting the systems using dmi.
Thanks.
--
tejun
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Henrique de Moraes Holschuh wrote:
> >>>> approximately translates into "if you have too many boatmen on a ship,
> >>>> it goes to mountain". We also have a bunch of Toshiba laptops which
> >>> Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> >>> is asking us to deliver to the disks, which IMO is an extremely good idea
> >>> anyway.
> >> If it were done that way (by asking OS driver to deliver commands TFs),
> >> I wouldn't have any problem at all. The spin down command is issued
> >> from deep down in the acpi power off method - entering S5 directly
> >> issues ATA commands bypassing the whole OS except for the ACPI
> >> interpreter. It's just like the toshiba suspend crap and there's no
> >> standard way to tell whether the acpi power off method is gonna do it or
> >> not. We'll just have to blacklist it.
> >
> > Urk. I see.
> >
> > I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
> > doing this. Who should we prod to add that check?
>
> Dunno how the firmware toolkit works but this one can be pretty
> difficult to test (if it were easy, we could test it in libata) as it
> involves entering S5. If it's possible, I'm all for it. Also, it would
> be nice if we can test the same thing for S3 and S4.
>
> Thomas, who should we ask things about the Linux firmware toolkit? Thanks.
firmwarekit-discuss <[email protected]> (added to CC list)
see: http://linuxfirmwarekit.org/
But if I understand this problem right, this won't be easy.
The ACPI tables are just parsed with system ("iasl ...") and syntactical
errors/warnings are printed out.
I also thought about a test, interpreting the DSDT and read out values
of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
not designed for that atm. You need to compile in most parts of the
acpica code and parse and interpret DSDT/SSDT code yourself in the
firmwarekit core or inside a plugin, then do a walk_namespace call or
whatever to find the functions/parts you like to examine. This is a lot
work and needs a proper design (providing an interface to plugins to let
them easily check specific AML/ASL code).
Thomas
Thomas Renninger wrote:
>>> I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
>>> doing this. Who should we prod to add that check?
>> Dunno how the firmware toolkit works but this one can be pretty
>> difficult to test (if it were easy, we could test it in libata) as it
>> involves entering S5. If it's possible, I'm all for it. Also, it would
>> be nice if we can test the same thing for S3 and S4.
>>
>> Thomas, who should we ask things about the Linux firmware toolkit? Thanks.
>
> firmwarekit-discuss <[email protected]> (added to CC list)
> see: http://linuxfirmwarekit.org/
>
> But if I understand this problem right, this won't be easy.
> The ACPI tables are just parsed with system ("iasl ...") and syntactical
> errors/warnings are printed out.
> I also thought about a test, interpreting the DSDT and read out values
> of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> not designed for that atm. You need to compile in most parts of the
> acpica code and parse and interpret DSDT/SSDT code yourself in the
> firmwarekit core or inside a plugin, then do a walk_namespace call or
> whatever to find the functions/parts you like to examine. This is a lot
> work and needs a proper design (providing an interface to plugins to let
> them easily check specific AML/ASL code).
Furthermore, we don't really know what we're looking for. How can you
tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
trying to power the machine off? Adding to the fun, many modern ATA
controller have more than one way to issue a command. Maybe we can
match accesses inside regions specified by PCI BARs.... :-(
--
tejun
Tejun Heo wrote:
> Robert Hancock wrote:
>> Tejun Heo wrote:
>>> Michael Sedkowski wrote:
>>>>> Hmmm... If the problem only shows up on nx6325, it might be that
>>>>> ACPI is
>>>>> pulling unnecessary stunt. Please apply the attached patch and report
>>>>> when the disk spins down and up.
>>>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
>>>> "Power down".
>>> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
>>> it spins down the disk correctly. Does emergency unload count increase
>>> after each power down? Also, please post the result of 'dmidecode'.
>> I know that my Compaq X1000-series laptop does do some kind of ACPI
>> games with the disk on ACPI power off (I assume it is putting the disk
>> in standby before power-off at least). It also does this if you boot
>> into DOS, GRUB, etc. and then hit the power button. Could be if the disk
>> is dumb enough to spin up for sync cache and standby when there is
>> nothing to flush, and the kernel does its own standby, this could cause
>> an extra spinup/down..
>
> Yeah, that seems to be what's going on. I don't think we have any other
> choice than blacklisting those notebooks. This is a mess. How does the
> other OS cope with this?
Quite possible that it gets a double spindown with these laptop/drive
combinations as well. I don't think it's particularly harmful as long as
there's no emergency unload..
> I'm thinking about using DMI vendor/product match to detect the affected
> systems but I think it would be better to match the ACPI implementation
> directly. Is there a way to match specific ACPI implementation?
Don't think it would be very easy, it's presumably being done off some
SMI code triggered from the ACPI power off register or something, so I'm
assuming it's nothing the kernel sees in its ACPI tables..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Tejun Heo wrote:
>> Yeah, that seems to be what's going on. I don't think we have any other
>> choice than blacklisting those notebooks. This is a mess. How does the
>> other OS cope with this?
>
> Quite possible that it gets a double spindown with these laptop/drive
> combinations as well. I don't think it's particularly harmful as long as
> there's no emergency unload..
I heard that spinning a harddrive back up while the platter is still
spinning from the previous spindown can have pretty bad affect on the
harddisk. This is from a Samsung HDD service guy and I'm not sure how
credible it is at all.
Thanks.
--
tejun
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote:
> Robert Hancock wrote:
> > Tejun Heo wrote:
> >> Michael Sedkowski wrote:
> >>>> Hmmm... If the problem only shows up on nx6325, it might be that
> >>>> ACPI is
> >>>> pulling unnecessary stunt. Please apply the attached patch and report
> >>>> when the disk spins down and up.
> >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> >>> "Power down".
> >>
> >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> >> it spins down the disk correctly. Does emergency unload count increase
> >> after each power down? Also, please post the result of 'dmidecode'.
> >
> > I know that my Compaq X1000-series laptop does do some kind of ACPI
> > games with the disk on ACPI power off (I assume it is putting the disk
> > in standby before power-off at least). It also does this if you boot
> > into DOS, GRUB, etc. and then hit the power button. Could be if the disk
> > is dumb enough to spin up for sync cache and standby when there is
> > nothing to flush, and the kernel does its own standby, this could cause
> > an extra spinup/down..
>
> Yeah, that seems to be what's going on. I don't think we have any other
> choice than blacklisting those notebooks. This is a mess. How does the
> other OS cope with this?
>
> I'm thinking about using DMI vendor/product match to detect the affected
> systems but I think it would be better to match the ACPI implementation
> directly. Is there a way to match specific ACPI implementation?
I opened a new bug to collect dmi and acpidump outputs:
http://bugzilla.kernel.org/show_bug.cgi?id=8855
Thought this is the easiest way to get this all a bit together.
Would be great if you tell all affected people and let them attach
dmidecode and acpidump output there...
Thanks,
Thomas
I did some additional checking today...
On kernels prior to 2.6.22 line, the bug exists and manifests itself
exactly the same way. However, when I removed the "-h" flag
from /etc/init.d/halt, the drive spins down only once on "Power down"
message and there is no sign of the bug and the emergency unload count
remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
2.6.18-4-686-Etch.
The obvious conclusion is that something must have changed it the 2.6.22
kernels, so that removing the "-h" has no effect.
I dunno if my observations are of any value, but I thought You should
know...
Regards,
Michael
2007/8/7, Michael Sedkowski <[email protected]>:
> I did some additional checking today...
> On kernels prior to 2.6.22 line, the bug exists and manifests itself
> exactly the same way. However, when I removed the "-h" flag
> from /etc/init.d/halt, the drive spins down only once on "Power down"
> message and there is no sign of the bug and the emergency unload count
> remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
> 2.6.18-4-686-Etch.
> The obvious conclusion is that something must have changed it the 2.6.22
> kernels, so that removing the "-h" has no effect.
> I dunno if my observations are of any value, but I thought You should
> know...
I confirm this. First 2.6.21-rcx works OK (if I remember). In
2.6.22(.1) remove -h option doesn't help - only warning message
dissapear, and double spin down also exists in suspend to disk.
The same laptop, bios, Debian etc.
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote:
> 2007/8/7, Michael Sedkowski <[email protected]>:
> > I did some additional checking today...
> > On kernels prior to 2.6.22 line, the bug exists and manifests itself
> > exactly the same way. However, when I removed the "-h" flag
> > from /etc/init.d/halt, the drive spins down only once on "Power down"
> > message and there is no sign of the bug and the emergency unload count
> > remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
> > 2.6.18-4-686-Etch.
> > The obvious conclusion is that something must have changed it the 2.6.22
> > kernels, so that removing the "-h" has no effect.
> > I dunno if my observations are of any value, but I thought You should
> > know...
>
> I confirm this. First 2.6.21-rcx works OK (if I remember). In
> 2.6.22(.1) remove -h option doesn't help - only warning message
> dissapear, and double spin down also exists in suspend to disk.
Well, on my box (nx6325) with the appended (experimental) patch applied
on top of 2.6.23-rc1 with the patchset from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
double spin down doesn't occur during hibernation and the system is shut down
notceably faster.
Greetings,
Rafael
---
kernel/power/disk.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc2/kernel/power/disk.c
===================================================================
--- linux-2.6.23-rc2.orig/kernel/power/disk.c 2007-08-06 14:04:07.000000000 +0200
+++ linux-2.6.23-rc2/kernel/power/disk.c 2007-08-07 21:10:59.000000000 +0200
@@ -223,15 +223,23 @@ int hibernation_platform_enter(void)
int error;
if (hibernation_ops) {
- kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
/*
* We have cancelled the power transition by running
* hibernation_ops->finish() before saving the image, so we
* should let the firmware know that we're going to enter the
* sleep state after all
*/
- error = hibernation_ops->prepare();
- sysdev_shutdown();
+ error = hibernation_ops->start();
+ if (!error) {
+ suspend_console();
+ error = device_suspend(PMSG_SUSPEND);
+ }
+ if (!error)
+ error = hibernation_ops->prepare();
+ if (!error)
+ error = disable_nonboot_cpus();
+ if (!error)
+ error = device_power_down(PMSG_SUSPEND);
if (!error)
error = hibernation_ops->enter();
} else {
On Tuesday, 7 August 2007 22:33, Rafael J. Wysocki wrote:
> On Tuesday, 7 August 2007 22:09, Maciej Rutecki wrote:
> > 2007/8/7, Michael Sedkowski <[email protected]>:
> > > I did some additional checking today...
> > > On kernels prior to 2.6.22 line, the bug exists and manifests itself
> > > exactly the same way. However, when I removed the "-h" flag
> > > from /etc/init.d/halt, the drive spins down only once on "Power down"
> > > message and there is no sign of the bug and the emergency unload count
> > > remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
> > > 2.6.18-4-686-Etch.
> > > The obvious conclusion is that something must have changed it the 2.6.22
> > > kernels, so that removing the "-h" has no effect.
> > > I dunno if my observations are of any value, but I thought You should
> > > know...
> >
> > I confirm this. First 2.6.21-rcx works OK (if I remember). In
> > 2.6.22(.1) remove -h option doesn't help - only warning message
> > dissapear, and double spin down also exists in suspend to disk.
>
> Well, on my box (nx6325) with the appended (experimental) patch applied
> on top of 2.6.23-rc1 with the patchset from
s/2.6.23-rc1/2.6.23-rc2/
> > Well, on my box (nx6325) with the appended (experimental) patch applied
> > on top of 2.6.23-rc1 with the patchset from
>
> s/2.6.23-rc1/2.6.23-rc2/
>
HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches:
1. Before:
rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep
Power-Off_Retract_Count
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 61
2. Try suspend to disk, double spin down doesn't exist
3. Normal shutdown, double spin down exists, BUT NOTE: I have still
old shutdown utility from Debian package.
4. After:
rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep
Power-Off_Retract_Count
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
Always - 61
(it doesn't change=61).
I wait for Michael, He has new shutdown from Sidux, and the same notebook.
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Tuesday, 7 August 2007 23:28, Maciej Rutecki wrote:
> > > Well, on my box (nx6325) with the appended (experimental) patch applied
> > > on top of 2.6.23-rc1 with the patchset from
> >
> > s/2.6.23-rc1/2.6.23-rc2/
> >
>
> HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches:
>
> 1. Before:
> rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep
> Power-Off_Retract_Count
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
> Always - 61
>
> 2. Try suspend to disk, double spin down doesn't exist
>
> 3. Normal shutdown, double spin down exists, BUT NOTE: I have still
> old shutdown utility from Debian package.
I should have said explicitly that my patch only affects hibernation (it
doesn't touch the normal shutdown code path).
Greetings,
Rafael
Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
>> emergency unload. Emergency unload does shorten the lifespan of the
>> disk but you don't have to worry too much about it. Disks are designed
>> to withstand certain number of emergency unloads.
>
> You *do* have to worry about it in any box you turn off daily. Desktop HDs
> will croak fast in that scenario, laptop HDs less so, but still too fast.
>
> A very good laptop HD can last about 20k emergency unloads (this is a unit
> that can do about 600k normal unloads in its lifetime). Desktop and server
> HDs don't even come close to those numbers, last time I checked.
It only matters on hard drives which actually use load-unload heads.
Lots of desktop/server drives (perhaps some laptop ones as well) still
use contact start/stop, which doesn't remove the heads from the platters
on shutdown but just parks the heads over the landing zone. I don't
think arbitrary power-offs make too much difference on those drives.
(However, these generally aren't rated to handle as many start/stop
cycles, which is why laptop drives generally use load/unload instead.)
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Tejun Heo wrote:
>> Henrique de Moraes Holschuh wrote:
>>> On Tue, 07 Aug 2007, Tejun Heo wrote:
>>>> Michael Sedkowski wrote:
>>>>>> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
>>>>>> pulling unnecessary stunt. Please apply the attached patch and report
>>>>>> when the disk spins down and up.
>>>>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
>>>>> "Power down".
>>>> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
>>>> it spins down the disk correctly. Does emergency unload count increase
>>>> after each power down? Also, please post the result of 'dmidecode'.
>>> You know, this actually make a lot of sense, and one can't even complain
>>> about firmware that pulls that off.
>> Well, I'm complaining. I think the problem here is that it isn't clear
>> which one is who's responsibility. There's a Korean saying which
>
> The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
> about it. Doing it through ACPI ATA objects is at least non-broken as far
> as these things go, as one knows when to do it directly ("non-ACPI mode"),
> and one doesn't talk to the disk directly.
>
>> approximately translates into "if you have too many boatmen on a ship,
>> it goes to mountain". We also have a bunch of Toshiba laptops which
>
> Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> is asking us to deliver to the disks, which IMO is an extremely good idea
> anyway.
Problem is I don't think we can do this. As far as I can tell, on my
Compaq at least, it's not being done through ACPI AML in the DSDT, like
in the _PTS function (which the kernel executes and can snoop), but when
we actually do the power-off we write a value to a magic ACPI register.
That likely triggers the BIOS to take control in SMM mode and access the
controller directly before triggering the power off, which we have no
control or knowledge of.
>
>> want the ATA controller to be in enabled state when ACPI suspend is
>> invoked because the suspend method apparently wants to execute some
>> commands before going to sleep.
>
> That's just broken, since it is not even using a OS-backed SATA/ATA ACPI
> method to do it.
>
>> I wish ACPI spec carries a big fat sign saying "stay f*** away from
>> anything which isn't essential to the requested operation".
>
> Shutting down disks *is* essential to the power off operation. ACPI would
> have to mandate who is to do it, instead (ACPI table or OSI by itself).
>
>>> Any chances of changing things
>>> so that we inspect/snoop all tasks sent to the device, and filter them
>>> out, or react to them accordingly?
>> No, we can't unless we snoop ACPI method execution and detect accesses
>> to IO ports or iomem regions. It's not going through any driver. This
>> is a gross mess.
>
> I don't mean fixing the stuff clowns like Toshiba did. The correct fix for
> that is to blacklist the hell out of that crap and patch their DSDT into
> something remotely sane.
>
> I do mean snooping the ACPI methods that *return* a taskset to send to the
> driver, and we send that taskset ourselves in libata and libpata(?).
>
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Michael Sedkowski wrote:
> I did some additional checking today...
> On kernels prior to 2.6.22 line, the bug exists and manifests itself
> exactly the same way. However, when I removed the "-h" flag
> from /etc/init.d/halt, the drive spins down only once on "Power down"
> message and there is no sign of the bug and the emergency unload count
> remains constant. I've verified this on kernels 2.6.21.6; 2.6.20.4;
> 2.6.18-4-686-Etch.
> The obvious conclusion is that something must have changed it the 2.6.22
> kernels, so that removing the "-h" has no effect.
> I dunno if my observations are of any value, but I thought You should
> know...
Yeah, till 2.6.22, libata didn't spindown disks on suspend or power off
which incremented emergency unload count on all normal systems, so only
the ACPI S5 routine is spinning down the disk on you system. The
problem here is that now that libata is fixed there are two entities
trying to spin down the disk and the disk is dumb enough to spin back up
when FLUSH CACHE or STANDBYNOW is received while spun down. :-(
Thanks.
--
tejun
Rafael J. Wysocki wrote:
> Well, on my box (nx6325) with the appended (experimental) patch applied
> on top of 2.6.23-rc1 with the patchset from
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
> double spin down doesn't occur during hibernation and the system is shut down
> notceably faster.
Can you please explain what the patch does? So, I take it that entering
S4 also spins down the disk. Does the patch remove the ACPI spin down
or libata one?
--
tejun
On Tue, 07 Aug 2007, Robert Hancock wrote:
>> You *do* have to worry about it in any box you turn off daily. Desktop
>> HDs will croak fast in that scenario, laptop HDs less so, but still too
>> fast. A very good laptop HD can last about 20k emergency unloads (this
>> is a unit that can do about 600k normal unloads in its lifetime).
>> Desktop and server HDs don't even come close to those numbers, last time
>> I checked.
>
> It only matters on hard drives which actually use load-unload heads. Lots
> of desktop/server drives (perhaps some laptop ones as well) still use
> contact start/stop, which doesn't remove the heads from the platters on
I am not so sure about that.
Please correct me if I am wrong, but contact stop in an emergency retract
shakes the head assembly badly as well. It subjects the head assembly to
higher acceleration than a normal seek, and a nasty impulse at impact with
the stopper. And I very much doubt it is nice to the heads to slide into
the parking zone at high speed and hit the bumper while over it.
Unless I missed something, I don't why an emergency retract would not be as
big a problem as an emergency unload.
Maybe we should hunt down some proper datasheets for drives lacking head
load/unload technology, and check what they say about emergency unloads...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Tue, 07 Aug 2007, Robert Hancock wrote:
>>> You *do* have to worry about it in any box you turn off daily. Desktop
>>> HDs will croak fast in that scenario, laptop HDs less so, but still too
>>> fast. A very good laptop HD can last about 20k emergency unloads (this
>>> is a unit that can do about 600k normal unloads in its lifetime).
>>> Desktop and server HDs don't even come close to those numbers, last time
>>> I checked.
>> It only matters on hard drives which actually use load-unload heads. Lots
>> of desktop/server drives (perhaps some laptop ones as well) still use
>> contact start/stop, which doesn't remove the heads from the platters on
>
> I am not so sure about that.
>
> Please correct me if I am wrong, but contact stop in an emergency retract
> shakes the head assembly badly as well. It subjects the head assembly to
> higher acceleration than a normal seek, and a nasty impulse at impact with
> the stopper. And I very much doubt it is nice to the heads to slide into
> the parking zone at high speed and hit the bumper while over it.
>
> Unless I missed something, I don't why an emergency retract would not be as
> big a problem as an emergency unload.
>
> Maybe we should hunt down some proper datasheets for drives lacking head
> load/unload technology, and check what they say about emergency unloads...
I did a bit of a look and didn't find any mention of the subject for
drives using contact start/stop. I did find mention that the unload
torque needed is quite a bit higher on load/unload systems, so I would
imagine that having to extract or store that energy for emergency
unloads would be more of a demanding task and might be a rougher process.
Just judging from the sound, though, hard power-offs on a desktop
Seagate Barracuda 7200.10, for example, which is contact start/stop,
don't really sound any different from a commanded standby. On the laptop
drives I've seen you can really tell the difference.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Dnia 07-08-2007, Wt o godzinie 23:28 +0200, Maciej Rutecki napisał(a):
> > > Well, on my box (nx6325) with the appended (experimental) patch applied
> > > on top of 2.6.23-rc1 with the patchset from
> >
> > s/2.6.23-rc1/2.6.23-rc2/
> >
>
> HP nx 6310, _old_ shutdown 2.6.23-rc2+above patches:
>
> 1. Before:
> rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep
> Power-Off_Retract_Count
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
> Always - 61
>
> 2. Try suspend to disk, double spin down doesn't exist
>
> 3. Normal shutdown, double spin down exists, BUT NOTE: I have still
> old shutdown utility from Debian package.
>
> 4. After:
> rutek:/home/maciek# /usr/sbin/smartctl --all -d ata /dev/sda | grep
> Power-Off_Retract_Count
> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
> Always - 61
>
> (it doesn't change=61).
>
> I wait for Michael, He has new shutdown from Sidux, and the same notebook.
>
Same here. On suspend to disk the problem disappeared, on shut down
remained unchanged, although it is a bit faster. The emergency unload
count remain unchanged. I have the updated shut down...
On Wednesday, 8 August 2007 04:56, Tejun Heo wrote:
> Rafael J. Wysocki wrote:
> > Well, on my box (nx6325) with the appended (experimental) patch applied
> > on top of 2.6.23-rc1 with the patchset from
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
> > double spin down doesn't occur during hibernation and the system is shut down
> > notceably faster.
>
> Can you please explain what the patch does?
It replaces the shutting down of devices done by kernel_shutdown_prepare()
with the suspending of the (just like before entering S3, but the target state
is now S4) and the shutting down of sysdevs with suspending them.
It also disables the nonboot CPUs before entering the sleep state (S4), which
generally always is a good idea.
In short, it makes hibernation_platform_enter() execute the enter-a-sleep-state
sequence instead of the mixed shutdown-with-entering-S4 thing.
> So, I take it that entering S4 also spins down the disk.
Yes.
> Does the patch remove the ACPI spin down or libata one?
I _think_ that it removes the ACPI one, although I'll need to do some more
testing to confirm that.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
On Wednesday, 8 August 2007 02:23, Robert Hancock wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Henrique de Moraes Holschuh wrote:
> >>> On Tue, 07 Aug 2007, Tejun Heo wrote:
> >>>> Michael Sedkowski wrote:
> >>>>>> Hmmm... If the problem only shows up on nx6325, it might be that ACPI is
> >>>>>> pulling unnecessary stunt. Please apply the attached patch and report
> >>>>>> when the disk spins down and up.
> >>>>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on
> >>>>> "Power down".
> >>>> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> >>>> it spins down the disk correctly. Does emergency unload count increase
> >>>> after each power down? Also, please post the result of 'dmidecode'.
> >>> You know, this actually make a lot of sense, and one can't even complain
> >>> about firmware that pulls that off.
> >> Well, I'm complaining. I think the problem here is that it isn't clear
> >> which one is who's responsibility. There's a Korean saying which
> >
> > The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
> > about it. Doing it through ACPI ATA objects is at least non-broken as far
> > as these things go, as one knows when to do it directly ("non-ACPI mode"),
> > and one doesn't talk to the disk directly.
> >
> >> approximately translates into "if you have too many boatmen on a ship,
> >> it goes to mountain". We also have a bunch of Toshiba laptops which
> >
> > Yeah, that's a problem. But we can avoid it if we start snooping what ACPI
> > is asking us to deliver to the disks, which IMO is an extremely good idea
> > anyway.
>
> Problem is I don't think we can do this. As far as I can tell, on my
> Compaq at least, it's not being done through ACPI AML in the DSDT, like
> in the _PTS function (which the kernel executes and can snoop), but when
> we actually do the power-off we write a value to a magic ACPI register.
> That likely triggers the BIOS to take control in SMM mode and access the
> controller directly before triggering the power off, which we have no
> control or knowledge of.
Yes, this also is my observation.
Greetings,
Rafael
--
"Premature optimization is the root of all evil." - Donald Knuth
Tejun Heo wrote:
> Michael Sedkowski wrote:
>> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
>>> Does emergency unload count increase
>>> after each power down?
>> I think I got it.
>> Using smartctl I've done a test and shut down, then repeted the test.
>> The only values that where diffrent are temperatures and
>> Hardware_ECC_Recovered which rised by 6 points.
>> However I have no idea which of those is the "emergency count"...
>> Full results in attachment.
>>
>> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 388
>
> I think this is the one. You can test it by forcefully powering off the
> machine (press power button for several secs or disconnect AC and
> battery) and see whether the count increases.
FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation.
It does not do any double spin-up/spin-down things though.
What a mess.
-ml
Mark Lord wrote:
> Tejun Heo wrote:
>> Michael Sedkowski wrote:
>>> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
>>>> Does emergency unload count increase
>>>> after each power down?
>>> I think I got it.
>>> Using smartctl I've done a test and shut down, then repeted the test.
>>> The only values that where diffrent are temperatures and
>>> Hardware_ECC_Recovered which rised by 6 points.
>>> However I have no idea which of those is the "emergency count"...
>>> Full results in attachment.
>>>
>>> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
>>> Always - 388
>>
>> I think this is the one. You can test it by forcefully powering off the
>> machine (press power button for several secs or disconnect AC and
>> battery) and see whether the count increases.
>
> FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
> increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation.
> It does not do any double spin-up/spin-down things though.
>
> What a mess.
Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering
STR. Can you instrument code a bit and see whether it actually gets issued?
Thanks.
--
tejun
Tejun Heo wrote:
> Mark Lord wrote:
>> > Tejun Heo wrote:
>>> >> Michael Sedkowski wrote:
>>>> >>> Dnia 07-08-2007, Wt o godzinie 03:43 +0900, Tejun Heo napisał(a):
>>>>> >>>> Does emergency unload count increase
>>>>> >>>> after each power down?
>>>> >>> I think I got it.
>>>> >>> Using smartctl I've done a test and shut down, then repeted the test.
>>>> >>> The only values that where diffrent are temperatures and
>>>> >>> Hardware_ECC_Recovered which rised by 6 points.
>>>> >>> However I have no idea which of those is the "emergency count"...
>>>> >>> Full results in attachment.
>>>> >>>
>>>> >>> 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age
>>>> >>> Always - 388
>>> >>
>>> >> I think this is the one. You can test it by forcefully powering off the
>>> >> machine (press power button for several secs or disconnect AC and
>>> >> battery) and see whether the count increases.
>> >
>> > FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
>> > increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation.
>> > It does not do any double spin-up/spin-down things though.
>> >
>> > What a mess.
>
> Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering
> STR. Can you instrument code a bit and see whether it actually gets issued?
Heh.. I haven't instrumented it yet, but I did discover a bit more about it:
The Power-Off_Retract_Count incrmenents *only* when there's data in the
on-drive write-cache. So if I haven't written anything significantly large
before suspending, then it often does NOT increment the retract counter.
But if I copy a couple of multi-MB files around and then suspend (to RAM),
the retract count gets incremented.
So I've now just stuck "hdparm -F /dev/sda" into my suspend script,
and that cures the problem completely for me. "-F" does a FLUSH_CACHE,
and requires a recent copy of hdparm.
Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command,
prior to entering STR, which is what my script is currently now doing..
I'll instrument libata and see what the current sequence is.
Mark Lord wrote:
> Heh.. I haven't instrumented it yet, but I did discover a bit more about
> it:
>
> The Power-Off_Retract_Count incrmenents *only* when there's data in the
> on-drive write-cache. So if I haven't written anything significantly large
> before suspending, then it often does NOT increment the retract counter.
>
> But if I copy a couple of multi-MB files around and then suspend (to RAM),
> the retract count gets incremented.
>
> So I've now just stuck "hdparm -F /dev/sda" into my suspend script,
> and that cures the problem completely for me. "-F" does a FLUSH_CACHE,
> and requires a recent copy of hdparm.
>
> Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command,
> prior to entering STR, which is what my script is currently now doing..
>
> I'll instrument libata and see what the current sequence is.
Hmmmm.. libata should issue FLUSH CACHE on STR too. sd_suspend() and
sd_shutdown() are pretty similar after all.
--
tejun
Mark Lord wrote:
> Tejun Heo wrote:
>> Mark Lord wrote:
..
>>>FWIW, Tejun, with 2.6.22, my new Seagate 160GB SATA drive (notebook)
>>>increments the "Power-Off_Retract_Count" on each suspend-to-RAM operation.
>>>It does not do any double spin-up/spin-down things though.
>>
>> Hmmm.. It shouldn't. libata now issues STANDBYNOW prior to entering
>> STR. Can you instrument code a bit and see whether it actually gets
>> issued?
>
> Heh.. I haven't instrumented it yet, but I did discover a bit more about it:
>
> The Power-Off_Retract_Count incrmenents *only* when there's data in the
> on-drive write-cache. So if I haven't written anything significantly large
> before suspending, then it often does NOT increment the retract counter.
>
> But if I copy a couple of multi-MB files around and then suspend (to RAM),
> the retract count gets incremented.
>
> So I've now just stuck "hdparm -F /dev/sda" into my suspend script,
> and that cures the problem completely for me. "-F" does a FLUSH_CACHE,
> and requires a recent copy of hdparm.
>
> Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW command,
> prior to entering STR, which is what my script is currently now doing..
>
> I'll instrument libata and see what the current sequence is.
Okay, instrumented it and all of that now.
Yes, sd + libata-scsi send the proper FLUSH_CACHE_EXT and STANDBY1 commands
immediately prior to the suspend-to-RAM, and there are no other commands
sneaking through at the same time. Good.
But the retract count still increments if I've recently written a signficant
amount of data.
My suspend script now has this little chunk of code at the point
where it actually does the suspend-to-RAM:
sync; sync
hdparm -F /dev/sda ## flush drive write cache
sleep 1 ## allow time for the flush to complete
echo mem > /sys/power/state ## suspend-to-RAM
Without the "sleep 1", it doesn't always eliminate the extra Retract,
so I hypothesize that the FLUSH_CACHE_EXT command is implemented in
an asynchronous fashion by the drive: it returns immediately before
it has actually completed writing cached data to disk. The "sleep 1"
seems to give it enough time to finish up, at least for me.
Cheers
Mark Lord wrote:
>
> My suspend script now has this little chunk of code at the point
> where it actually does the suspend-to-RAM:
>
> sync; sync
> hdparm -F /dev/sda ## flush drive write cache
> sleep 1 ## allow time for the flush to complete
> echo mem > /sys/power/state ## suspend-to-RAM
>
> Without the "sleep 1", it doesn't always eliminate the extra Retract,
> so I hypothesize that the FLUSH_CACHE_EXT command is implemented in
> an asynchronous fashion by the drive: it returns immediately before
> it has actually completed writing cached data to disk. The "sleep 1"
> seems to give it enough time to finish up, at least for me.
Further to this, if I have an active-writer running at the time of suspend,
then even my scripted "sleep 1" is not good enough, as additional writes
are still happening before/after the flush.
Now I'll reboot and try it with the "sleep 1" hardcoded inside sd_suspend().
Cheers
Mark Lord wrote:
> Further to this, if I have an active-writer running at the time of suspend,
> then even my scripted "sleep 1" is not good enough, as additional writes
> are still happening before/after the flush.
>
> Now I'll reboot and try it with the "sleep 1" hardcoded inside
> sd_suspend().
Hmmm... queue quiescing might be broken. Can you verify there's no
command issued between STANDBYNOW1 and suspending?
--
tejun
Tejun Heo wrote:
> Mark Lord wrote:
>> Further to this, if I have an active-writer running at the time of suspend,
>> then even my scripted "sleep 1" is not good enough, as additional writes
>> are still happening before/after the flush.
>>
>> Now I'll reboot and try it with the "sleep 1" hardcoded inside
>> sd_suspend().
>
> Hmmm... queue quiescing might be broken. Can you verify there's no
> command issued between STANDBYNOW1 and suspending?
Yeah, I verified that already. Nothing happens other than
the FLUSH_CACHE_EXT and STANDBY commands.
I've now tried adding various sleeps into the sd_suspend() routine.
The sleeps actually do sleep, but they don't seem to solve the problem there.
The "hdparm -F /dev/sda ; sleep 1" inside my script actually works better,
though even it fails if there's a ton of writes happening.
I put a 4-second sleep in front of the sd_start_stop_device() call,
and here is what I observed:
the disk light flickers briefly,
then the system does absolutely nothing for the 4-seconds,
and then it flickers again,
and then the light comes on solid for a second or two,
and then it suspends.
I am ssssoooooooo confused now. :)
We need Eric (from Seagate) to enlighten us.
Cheers
Tejun Heo wrote:
> Mark Lord wrote:
> > Heh.. I haven't instrumented it yet, but I did discover a bit more about
> > it:
> >
> > The Power-Off_Retract_Count incrmenents *only* when there's data in the
> > on-drive write-cache. So if I haven't written anything significantly
> > large before suspending, then it often does NOT increment the retract
> > counter.
> >
> > But if I copy a couple of multi-MB files around and then suspend (to
> > RAM), the retract count gets incremented.
> >
> > So I've now just stuck "hdparm -F /dev/sda" into my suspend script,
> > and that cures the problem completely for me. "-F" does a FLUSH_CACHE,
> > and requires a recent copy of hdparm.
> >
> > Perhaps libata should also do a FLUSH_CACHE before any STANDBYNOW
> > command, prior to entering STR, which is what my script is currently now
> > doing..
> >
> > I'll instrument libata and see what the current sequence is.
>
> Hmmmm.. libata should issue FLUSH CACHE on STR too. sd_suspend() and
> sd_shutdown() are pretty similar after all.
IMHO, this is a mess because we are essentially trying to work around
firmware bugs, which may only be solved by having the kernel load a
user-supplied shutdown sequence, instead of hardcoding it into the kernel.
Thanks!
--
Al
Hi!
> >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> >> it spins down the disk correctly. Does emergency unload count increase
> >> after each power down? Also, please post the result of 'dmidecode'.
> >
> > I know that my Compaq X1000-series laptop does do some kind of ACPI
> > games with the disk on ACPI power off (I assume it is putting the disk
> > in standby before power-off at least). It also does this if you boot
> > into DOS, GRUB, etc. and then hit the power button. Could be if the disk
> > is dumb enough to spin up for sync cache and standby when there is
> > nothing to flush, and the kernel does its own standby, this could cause
> > an extra spinup/down..
>
> Yeah, that seems to be what's going on. I don't think we have any other
> choice than blacklisting those notebooks. This is a mess. How does the
> other OS cope with this?
>
> I'm thinking about using DMI vendor/product match to detect the affected
> systems but I think it would be better to match the ACPI implementation
> directly. Is there a way to match specific ACPI implementation?
Well.. unless they use some SMM trick, it is ACPI AML code telling
kernel to spin the disk down. I guess we could detect that, and simply
ignore the request.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > firmwarekit-discuss <[email protected]> (added to CC list)
> > see: http://linuxfirmwarekit.org/
> >
> > But if I understand this problem right, this won't be easy.
> > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > errors/warnings are printed out.
> > I also thought about a test, interpreting the DSDT and read out values
> > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > not designed for that atm. You need to compile in most parts of the
> > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > whatever to find the functions/parts you like to examine. This is a lot
> > work and needs a proper design (providing an interface to plugins to let
> > them easily check specific AML/ASL code).
>
> Furthermore, we don't really know what we're looking for. How can you
> tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> trying to power the machine off? Adding to the fun, many modern ATA
> controller have more than one way to issue a command. Maybe we can
> match accesses inside regions specified by PCI BARs.... :-(
Hmmm... perhaps we should do it the other way. ACPI is allowed to
touch the embedded controller, what else? Maybe we should warn as soon
as API touches non-EC I/O port?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, 2007-08-09 at 15:16 +0000, Pavel Machek wrote:
> Hi!
>
> > > firmwarekit-discuss <[email protected]> (added to CC list)
> > > see: http://linuxfirmwarekit.org/
> > >
> > > But if I understand this problem right, this won't be easy.
> > > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > > errors/warnings are printed out.
> > > I also thought about a test, interpreting the DSDT and read out values
> > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > > not designed for that atm. You need to compile in most parts of the
> > > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > > whatever to find the functions/parts you like to examine. This is a lot
> > > work and needs a proper design (providing an interface to plugins to let
> > > them easily check specific AML/ASL code).
> >
> > Furthermore, we don't really know what we're looking for. How can you
> > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> > trying to power the machine off? Adding to the fun, many modern ATA
> > controller have more than one way to issue a command. Maybe we can
> > match accesses inside regions specified by PCI BARs.... :-(
>
> Hmmm... perhaps we should do it the other way. ACPI is allowed to
> touch the embedded controller, what else? Maybe we should warn as soon
> as API touches non-EC I/O port?
This is not working...
ACPI can and does access all kind of other I/O ports and other
resources.
Hmm, are the disk accesses done by ACPI via OperationRegion/Field
declared variables?
I try to get a check for those clashing with native drivers (hopefully
this approach is successful for 2.6.24, can't say for sure yet), I
wonder whether this one would give a warning like "Libata driver is
using the same SystemIO/SystemMem resources than ACPI OperationRegion
declaration XY".
This would not solve the problem, but at least show the need of such a
test. Such ACPI vs native driver interference problems are very hard
nuts (in identifying and solving).
Can someone post an ASL code snippet how ACPI actually access the disk
and in which parts/functions, pls.
Thanks,
Thomas
On Thursday, 9 August 2007 17:06, Pavel Machek wrote:
> Hi!
>
> > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
> > >> it spins down the disk correctly. Does emergency unload count increase
> > >> after each power down? Also, please post the result of 'dmidecode'.
> > >
> > > I know that my Compaq X1000-series laptop does do some kind of ACPI
> > > games with the disk on ACPI power off (I assume it is putting the disk
> > > in standby before power-off at least). It also does this if you boot
> > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk
> > > is dumb enough to spin up for sync cache and standby when there is
> > > nothing to flush, and the kernel does its own standby, this could cause
> > > an extra spinup/down..
> >
> > Yeah, that seems to be what's going on. I don't think we have any other
> > choice than blacklisting those notebooks. This is a mess. How does the
> > other OS cope with this?
> >
> > I'm thinking about using DMI vendor/product match to detect the affected
> > systems but I think it would be better to match the ACPI implementation
> > directly. Is there a way to match specific ACPI implementation?
>
> Well.. unless they use some SMM trick, it is ACPI AML code telling
> kernel to spin the disk down. I guess we could detect that, and simply
> ignore the request.
Please see: http://lkml.org/lkml/2007/8/8/187
Greetings,
Rafael
On Wednesday, 8 August 2007 14:24, Rafael J. Wysocki wrote:
> On Wednesday, 8 August 2007 04:56, Tejun Heo wrote:
> > Rafael J. Wysocki wrote:
> > > Well, on my box (nx6325) with the appended (experimental) patch applied
> > > on top of 2.6.23-rc1 with the patchset from
> > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc2/patches/ , the
> > > double spin down doesn't occur during hibernation and the system is shut down
> > > notceably faster.
> >
> > Can you please explain what the patch does?
>
> It replaces the shutting down of devices done by kernel_shutdown_prepare()
> with the suspending of the (just like before entering S3, but the target state
> is now S4) and the shutting down of sysdevs with suspending them.
>
> It also disables the nonboot CPUs before entering the sleep state (S4), which
> generally always is a good idea.
>
> In short, it makes hibernation_platform_enter() execute the enter-a-sleep-state
> sequence instead of the mixed shutdown-with-entering-S4 thing.
>
> > So, I take it that entering S4 also spins down the disk.
>
> Yes.
>
> > Does the patch remove the ACPI spin down or libata one?
>
> I _think_ that it removes the ACPI one, although I'll need to do some more
> testing to confirm that.
OK
I can confirm that the patch removes the ACPI spin down (ie. the one that
happens in the power down phase without the patch).
Greetings,
Rafael
Thomas Renninger wrote:
> On Thu, 2007-08-09 at 15:16 +0000, Pavel Machek wrote:
>> Hi!
>>
>>>> firmwarekit-discuss <[email protected]> (added to CC list)
>>>> see: http://linuxfirmwarekit.org/
>>>>
>>>> But if I understand this problem right, this won't be easy.
>>>> The ACPI tables are just parsed with system ("iasl ...") and syntactical
>>>> errors/warnings are printed out.
>>>> I also thought about a test, interpreting the DSDT and read out values
>>>> of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
>>>> not designed for that atm. You need to compile in most parts of the
>>>> acpica code and parse and interpret DSDT/SSDT code yourself in the
>>>> firmwarekit core or inside a plugin, then do a walk_namespace call or
>>>> whatever to find the functions/parts you like to examine. This is a lot
>>>> work and needs a proper design (providing an interface to plugins to let
>>>> them easily check specific AML/ASL code).
>>> Furthermore, we don't really know what we're looking for. How can you
>>> tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
>>> trying to power the machine off? Adding to the fun, many modern ATA
>>> controller have more than one way to issue a command. Maybe we can
>>> match accesses inside regions specified by PCI BARs.... :-(
>> Hmmm... perhaps we should do it the other way. ACPI is allowed to
>> touch the embedded controller, what else? Maybe we should warn as soon
>> as API touches non-EC I/O port?
>
> This is not working...
> ACPI can and does access all kind of other I/O ports and other
> resources.
> Hmm, are the disk accesses done by ACPI via OperationRegion/Field
> declared variables?
> I try to get a check for those clashing with native drivers (hopefully
> this approach is successful for 2.6.24, can't say for sure yet), I
> wonder whether this one would give a warning like "Libata driver is
> using the same SystemIO/SystemMem resources than ACPI OperationRegion
> declaration XY".
> This would not solve the problem, but at least show the need of such a
> test. Such ACPI vs native driver interference problems are very hard
> nuts (in identifying and solving).
>
> Can someone post an ASL code snippet how ACPI actually access the disk
> and in which parts/functions, pls.
Again, it's not believed that this is being done via AML, but via a BIOS
SMM trap on the ACPI sleep state hardware IO port. We have no real
ability to find out what the BIOS is doing or prevent it in this case.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Saturday, 8 September 2007 17:32, Michal Piotrowski wrote:
> Hi,
>
> On 05/08/2007, Micha? sed <[email protected]> wrote:
> > Greetings
> >
> > I'm experiencing double disk spin down issue on my HP nx6310 laptop
> > during shut down and suspend to disk. The drive is power down on "Will
> > now halt message" then turned back on and off again with the laptop
> > itself. I'm using the newest bios available F.0D, 2.6.23-rc1-mm kernel
> > along with Debian Unstable plus fixes from Sidux repository so I have
> > the updated shut down script. I have also verified on two other
> > systems [AMD/Nforce based] that the spin down issue has been resolved
> > by the Sidux update and I'm certain that this is a hp bios bug or a
> > piix kernel module problem.
> >
>
> What is the _actual_ state of this bug? Does anyone work on this?
>
> I see the report
> http://lkml.org/lkml/2007/8/5/214
>
> and a very long thread
> http://lkml.org/lkml/2007/8/6/4
>
> dmidecode stuff
> http://bugzilla.kernel.org/show_bug.cgi?id=8855
>
> and _only_one_fix_ - for Suspend To Disc (thanks Rafael)
> http://lkml.org/lkml/2007/8/7/316
There's an updated version of that patch at
http://lkml.org/lkml/2007/8/27/392
> Shutdown is completely broken on HP NX6??? laptops.
It's not completely broken, it just handles disks incorrectly and we are not
sure whether or not there are any serious consequences of that. Moreover,
it has happened for a long time now, AFAICT, so that's not a regression.
BTW, in my opinion, we don't really understand why the patch at
http://lkml.org/lkml/2007/8/27/392 actually helps and understanding that might
allow us to fix the problem in general.
Greetings,
Rafael
Rafael J. Wysocki pisze:
>> Shutdown is completely broken on HP NX6??? laptops.
>
> It's not completely broken, it just handles disks incorrectly and we are not
> sure whether or not there are any serious consequences of that. Moreover,
> it has happened for a long time now, AFAICT, so that's not a regression.
Maybe it isn't regression, we can call it no matter how, but this issue
can shorten disk live.
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Sunday, 9 September 2007 11:20, Maciek Rutecki wrote:
> Rafael J. Wysocki pisze:
> >> Shutdown is completely broken on HP NX6??? laptops.
> >
> > It's not completely broken, it just handles disks incorrectly and we are not
> > sure whether or not there are any serious consequences of that. Moreover,
> > it has happened for a long time now, AFAICT, so that's not a regression.
>
> Maybe it isn't regression, we can call it no matter how, but this issue
> can shorten disk live.
Well, I'll try to carry out some experiments with it later today ...