Re: Laptop hard drive and emergency unload
At the risk of replying to a months-old thread which I was guilty of starting, I want to close it with the following observation. I hope this might be of use to others with newer laptops with SATA-drive and crappy Intel chipsets. Today I installed my newly-arrived OpenBSD 5.0 CD (amd64) on my laptop, which has a newer Intel chipset and SATA drive. Initially I ran into the same click sound on halt problem as I had with 4.9. This time however, I noticed that on shutdown, the disk LED didn't light up, as it does when halting Slackware. I then took a look into my BIOS and changed the SATA MODE setting from AHCI to IDE. Now, when shutting down the laptop in IDE mode, the disk LED lights up - indicating the disk is being commanded to shut off, plus there's no more loud click from the drive's emergency unload. Thanks to everyone who provided some observations and advice on this issue. My laptop is now perfectly happy, running the newest release of OpenBSD. Steve On 11-09-05 02:25 PM, Steve wrote: For the fun of it, I just installed 4.9 (AMD64) on an SD card, booted from the card and mounted one of my Ext3 partitions on the hard disk. I copied a file from the disk to the card to be sure it was active, umounted the hard disk and halted. Not a sound from the disk no click, nothing. On 11-09-05 11:13 AM, Philippe Meunier wrote: Steve wrote: 6.3.6.1 Emergency unload [... ]Emergency unload is intended to be invoked in rare situations. Because this operation is inherently uncontrolled, it is more mechanically stressful than a normal unload. Yes. I have a Thinkpad T43 with a Hitachi Travelstar 5K100 (HTS541060G9AT00) and used to have the same problem: when shutting down the computer, the power would be removed from the hard disk while the heads were still loaded and the disk would then have to perform an emergency unload, which resulted in the disk making a loud click. This was the case for me from (I think) OpenBSD 3.9, when I first installed OpenBSD, up to and including 4.8. A few months ago I upgraded to 4.9 (stable) and since then I can hear the disk normally unloading the heads (a short series of 4-5 muffled clicks in very short succession with a slightly increasing pitch) before powering down, which is much quieter. My disk and I both thank whoever implemented that change :-) On Sep 3, 2011, at 15:41, Steve wrote: Can anyone suggest what I could do to stop this from happening? Well, it depends... You could try to manually sync(8) the disk, do something like atactl wd0 apmset 1 (YMMV) to put the disk into standby power saving mode, which would result in the heads being unloaded after a short time, and then halt(8) the computer. The problem is that, as part of the normal powerdown sequence, OpenBSD writes some logs of the shutdown on the disk (which would then reload its heads) and also syncs the disk (I don't know if that action alone would reload the disk heads or not if there were no actual data to sync to the disk; using sync(8) twice in sequence results in my disk's light blinking twice but whether the second blink actually means anything with regard to the disk's heads is an entirely different question...) You could try to play with halt(8)'s -q and -n options and see what happens, but I wouldn't recommend it... Even if you were lucky and it worked, it would be an annoyance to do that every time and it'd be very easy to make a mistake and lose data. You could write scripts to automate the process but you'd be on your own if something went wrong... You could also try the following: - put the root partition, /var/log, and everything else required for a normal shutdown, on a USB stick and boot from that - have all the other stuff (/home, /usr/local, etc) on your disk - before shutting down, manually unmount all the partitions that are on the disk (forcing the unmount if necessary), use atactl to put the disk in a low-power mode that results in the heads being unloaded, then shutdown the computer as usual. Slightly better than the above, but again it'd be annoying to do and it'd be easy to make a mistake... With all that being said, I happily used OpenBSD on my laptop for about five years with my hard disk doing an emergency unload on every shutdown, and never had any problem. It's up to you to decide whether you can sleep at night knowing that your disk goes through a very small number of mechanically stressful events every day. 2 emergency unloads supported by your disk at a minimum (or so Hitachi says...) / 5 shutdowns a day (say) = about 11 years... So it might be an acceptable solution to you until time (and if...) an OpenBSD developer decides to fix your problem. You have backups anyway, right? :-) Philippe
Re: Laptop hard drive and emergency unload
Steve wrote: 6.3.6.1 Emergency unload [... ]Emergency unload is intended to be invoked in rare situations. Because this operation is inherently uncontrolled, it is more mechanically stressful than a normal unload. Yes. I have a Thinkpad T43 with a Hitachi Travelstar 5K100 (HTS541060G9AT00) and used to have the same problem: when shutting down the computer, the power would be removed from the hard disk while the heads were still loaded and the disk would then have to perform an emergency unload, which resulted in the disk making a loud click. This was the case for me from (I think) OpenBSD 3.9, when I first installed OpenBSD, up to and including 4.8. A few months ago I upgraded to 4.9 (stable) and since then I can hear the disk normally unloading the heads (a short series of 4-5 muffled clicks in very short succession with a slightly increasing pitch) before powering down, which is much quieter. My disk and I both thank whoever implemented that change :-) On Sep 3, 2011, at 15:41, Steve wrote: Can anyone suggest what I could do to stop this from happening? Well, it depends... You could try to manually sync(8) the disk, do something like atactl wd0 apmset 1 (YMMV) to put the disk into standby power saving mode, which would result in the heads being unloaded after a short time, and then halt(8) the computer. The problem is that, as part of the normal powerdown sequence, OpenBSD writes some logs of the shutdown on the disk (which would then reload its heads) and also syncs the disk (I don't know if that action alone would reload the disk heads or not if there were no actual data to sync to the disk; using sync(8) twice in sequence results in my disk's light blinking twice but whether the second blink actually means anything with regard to the disk's heads is an entirely different question...) You could try to play with halt(8)'s -q and -n options and see what happens, but I wouldn't recommend it... Even if you were lucky and it worked, it would be an annoyance to do that every time and it'd be very easy to make a mistake and lose data. You could write scripts to automate the process but you'd be on your own if something went wrong... You could also try the following: - put the root partition, /var/log, and everything else required for a normal shutdown, on a USB stick and boot from that - have all the other stuff (/home, /usr/local, etc) on your disk - before shutting down, manually unmount all the partitions that are on the disk (forcing the unmount if necessary), use atactl to put the disk in a low-power mode that results in the heads being unloaded, then shutdown the computer as usual. Slightly better than the above, but again it'd be annoying to do and it'd be easy to make a mistake... With all that being said, I happily used OpenBSD on my laptop for about five years with my hard disk doing an emergency unload on every shutdown, and never had any problem. It's up to you to decide whether you can sleep at night knowing that your disk goes through a very small number of mechanically stressful events every day. 2 emergency unloads supported by your disk at a minimum (or so Hitachi says...) / 5 shutdowns a day (say) = about 11 years... So it might be an acceptable solution to you until time (and if...) an OpenBSD developer decides to fix your problem. You have backups anyway, right? :-) Philippe
Re: Laptop hard drive and emergency unload
For the fun of it, I just installed 4.9 (AMD64) on an SD card, booted from the card and mounted one of my Ext3 partitions on the hard disk. I copied a file from the disk to the card to be sure it was active, umounted the hard disk and halted. Not a sound from the disk no click, nothing. On 11-09-05 11:13 AM, Philippe Meunier wrote: Steve wrote: 6.3.6.1 Emergency unload [... ]Emergency unload is intended to be invoked in rare situations. Because this operation is inherently uncontrolled, it is more mechanically stressful than a normal unload. Yes. I have a Thinkpad T43 with a Hitachi Travelstar 5K100 (HTS541060G9AT00) and used to have the same problem: when shutting down the computer, the power would be removed from the hard disk while the heads were still loaded and the disk would then have to perform an emergency unload, which resulted in the disk making a loud click. This was the case for me from (I think) OpenBSD 3.9, when I first installed OpenBSD, up to and including 4.8. A few months ago I upgraded to 4.9 (stable) and since then I can hear the disk normally unloading the heads (a short series of 4-5 muffled clicks in very short succession with a slightly increasing pitch) before powering down, which is much quieter. My disk and I both thank whoever implemented that change :-) On Sep 3, 2011, at 15:41, Steve wrote: Can anyone suggest what I could do to stop this from happening? Well, it depends... You could try to manually sync(8) the disk, do something like atactl wd0 apmset 1 (YMMV) to put the disk into standby power saving mode, which would result in the heads being unloaded after a short time, and then halt(8) the computer. The problem is that, as part of the normal powerdown sequence, OpenBSD writes some logs of the shutdown on the disk (which would then reload its heads) and also syncs the disk (I don't know if that action alone would reload the disk heads or not if there were no actual data to sync to the disk; using sync(8) twice in sequence results in my disk's light blinking twice but whether the second blink actually means anything with regard to the disk's heads is an entirely different question...) You could try to play with halt(8)'s -q and -n options and see what happens, but I wouldn't recommend it... Even if you were lucky and it worked, it would be an annoyance to do that every time and it'd be very easy to make a mistake and lose data. You could write scripts to automate the process but you'd be on your own if something went wrong... You could also try the following: - put the root partition, /var/log, and everything else required for a normal shutdown, on a USB stick and boot from that - have all the other stuff (/home, /usr/local, etc) on your disk - before shutting down, manually unmount all the partitions that are on the disk (forcing the unmount if necessary), use atactl to put the disk in a low-power mode that results in the heads being unloaded, then shutdown the computer as usual. Slightly better than the above, but again it'd be annoying to do and it'd be easy to make a mistake... With all that being said, I happily used OpenBSD on my laptop for about five years with my hard disk doing an emergency unload on every shutdown, and never had any problem. It's up to you to decide whether you can sleep at night knowing that your disk goes through a very small number of mechanically stressful events every day. 2 emergency unloads supported by your disk at a minimum (or so Hitachi says...) / 5 shutdowns a day (say) = about 11 years... So it might be an acceptable solution to you until time (and if...) an OpenBSD developer decides to fix your problem. You have backups anyway, right? :-) Philippe
Re: Laptop hard drive and emergency unload
On Mon, 05 Sep 2011 14:25:46 -0400 Steve scha...@aei.ca wrote: For the fun of it, I just installed 4.9 (AMD64) on an SD card, booted from the card and mounted one of my Ext3 partitions on the hard disk. I copied a file from the disk to the card to be sure it was active, umounted the hard disk and halted. Not a sound from the disk no click, nothing. for testing, use -current/snapshots. http://marc.info/?l=openbsd-cvsm=127460880427991w=2 Changes by: kette...@cvs.openbsd.org2010/05/23 03:58:58 Modified files: sys/dev/ata: wd.c Log message: Place drive in standby mode before shutdown. Avoids the loud click heard on many laptops when powering them down. That went into 4.8, the oldest supported OpenBSD version. Hail to the kettenis@, baby!
Re: Laptop hard drive and emergency unload
Lies On Sep 4, 2011, at 0:39, David Vasek va...@fido.cz wrote: No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. Regards, David On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller
Re: Laptop hard drive and emergency unload
On 2011-09-04 07.39, David Vasek wrote: No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. That used to be true in the dark ages, when disk drives were as large as washing machines and the actual disk packs were removable and 14 in diameter. But in this day and age, what Marco says is entirely correct. The OP can safely ignore this from a disk durability standpoint, although it may of course be a nuisance that the disk doesn't power down when shutting down OpenBSD (if that's indeed what happens, I'm not sure I fully understood the description). Also, emergency retract is a misnomer, the SMART attribute in quesetion is actually called Power-off Retract Count. Only Fujitsu (to my knowledge) for some reason calles it Emergency Retract Cycle Count. In any case it's a bullshit value to base any reliability predictions on, unless maybe, MAYBE if it runs into the tens or hundreds of thousands. Regards, /Benny On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: Laptop hard drive and emergency unload
after reading that fbsd thread it seems that it's problem of shitty hw where acer can be count for sure. I saw a lot of them with fine numbers in specs, but together it was worse then some older laptop from ibm or similar vendor. Slow buses, cheap hw, missing specs and so on. In the end expensive slow toy On 9/4/11, Benny Lofgren bl-li...@lofgren.biz wrote: On 2011-09-04 07.39, David Vasek wrote: No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. That used to be true in the dark ages, when disk drives were as large as washing machines and the actual disk packs were removable and 14 in diameter. But in this day and age, what Marco says is entirely correct. The OP can safely ignore this from a disk durability standpoint, although it may of course be a nuisance that the disk doesn't power down when shutting down OpenBSD (if that's indeed what happens, I'm not sure I fully understood the description). Also, emergency retract is a misnomer, the SMART attribute in quesetion is actually called Power-off Retract Count. Only Fujitsu (to my knowledge) for some reason calles it Emergency Retract Cycle Count. In any case it's a bullshit value to base any reliability predictions on, unless maybe, MAYBE if it runs into the tens or hundreds of thousands. Regards, /Benny On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lofgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se -- b If youbre good at something, never do it for free.b B bThe Joker
Re: Laptop hard drive and emergency unload
I have read through some of the Hitachi documents for my hard disk, and came across this, in the Hard Disk Drive Specification (available on-line as TS5K500.B_OEMSpec_r12a.pdf). Does this provide any useful information? 6.3.6 Load/unload The product supports a minimum of 600,000 normal load/unloads. Load/unload is a functional mechanism of the hard disk drive. It is controlled by the drive micro code. Specifically, unloading of the heads is invoked by the following commands: Standby Standby immediate Sleep Load/unload is also invoked as one of the idle modes of the drive. The specified start/stop life of the product assumes that load/unload is operated normally, not in emergency mode. 6.3.6.1 Emergency unload When hard disk drive power is interrupted while the heads are still loaded the micro code cannot operate and the normal 5-volt power is unavailable to unload the heads. In this case, normal unload is not possible. The heads are unloaded by routing the back EMF of the spinning motor to the voice coil. The actuator velocity is greater than the normal case and the unload process is inherently less controllable without a normal seek current profile. Emergency unload is intended to be invoked in rare situations. Because this operation is inherently uncontrolled, it is more mechanically stressful than a normal unload. The drive supports a minimum of 20,000 emergency unloads. 6.3.6.2 Required Power-Off Sequence The required host system sequence for removing power from the drive is as follows: Step 1: Issue one of the following commands. Standby Standby immediate Sleep Note: Do not use the Flush Cache command for the power off sequence because this command does not invoke Unload. Step 2: Wait until the Command Complete status is returned. In a typical case 500 ms are required for the command to finish completion; however, the host system time out value needs to be 30 seconds considering error recovery time. Step 3: Terminate power to HDD. This power-down sequence should be followed for entry into any system power-down state, system suspend state, or system hibernation state. In a robustly designed system, emergency unload is limited to rare scenarios, such as battery removal during operation. Steve On 11-09-04 01:47 PM, Tomas Bodzar wrote: after reading that fbsd thread it seems that it's problem of shitty hw where acer can be count for sure. I saw a lot of them with fine numbers in specs, but together it was worse then some older laptop from ibm or similar vendor. Slow buses, cheap hw, missing specs and so on. In the end expensive slow toy On 9/4/11, Benny Lofgrenbl-li...@lofgren.biz wrote: On 2011-09-04 07.39, David Vasek wrote: No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. That used to be true in the dark ages, when disk drives were as large as washing machines and the actual disk packs were removable and 14 in diameter. But in this day and age, what Marco says is entirely correct. The OP can safely ignore this from a disk durability standpoint, although it may of course be a nuisance that the disk doesn't power down when shutting down OpenBSD (if that's indeed what happens, I'm not sure I fully understood the description). Also, emergency retract is a misnomer, the SMART attribute in quesetion is actually called Power-off Retract Count. Only Fujitsu (to my knowledge) for some reason calles it Emergency Retract Cycle Count. In any case it's a bullshit value to base any reliability predictions on, unless maybe, MAYBE if it runs into the tens or hundreds of thousands. Regards, /Benny On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Stevescha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a
Re: Laptop hard drive and emergency unload
On Sun, 4 Sep 2011, Benny Lofgren wrote: On 2011-09-04 07.39, David Vasek wrote: No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. That used to be true in the dark ages, when disk drives were as large as washing machines and the actual disk packs were removable and 14 in diameter. But in this day and age, what Marco says is entirely correct. No. What Marco says was correct in 90's and early 2000's when disks employed CSS (Contact Start-Stop) mechanism. In recent years all laptop drives and almost all desktop and server drives (with exception of some lower end Seagates) use parking on a ramp. This is the docs for the drive Steve (the OP) has in his Acer laptop. Please look at the chapter 6.3 (pages 29, 30). http://www.hgst.com/tech/techlib.nsf/techdocs/1F70FDFFB4DE1EBB86257538007E4CFE/$file/TS5K500.B_OEM_Specification_R18.pdf The same is true for other modern Hitachi drives and for drives from other vendors probably too, but they do not provide any useful documentation for their drives. There is some more detailed description of ramp parking: http://www.hgst.com/tech/techlib.nsf/techdocs/9076679E3EE4003E86256FAB005825FB/$file/LoadUnload_white_paper_FINAL.pdf Regards, David The OP can safely ignore this from a disk durability standpoint, although it may of course be a nuisance that the disk doesn't power down when shutting down OpenBSD (if that's indeed what happens, I'm not sure I fully understood the description). Also, emergency retract is a misnomer, the SMART attribute in quesetion is actually called Power-off Retract Count. Only Fujitsu (to my knowledge) for some reason calles it Emergency Retract Cycle Count. In any case it's a bullshit value to base any reliability predictions on, unless maybe, MAYBE if it runs into the tens or hundreds of thousands. Regards, /Benny On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller
Re: Laptop hard drive and emergency unload
Do you have latest bios? Did you try current snapshot? Where's the dmesg, pcidump -v, atactl identify and maybe other outputs? On 9/3/11, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller -- b If youbre good at something, never do it for free.b B bThe Joker
Re: Laptop hard drive and emergency unload
Sorry, I had removed OpenBSD from the hard disk due to the shutdown problems. Here are the dmesg, pcidump -v and atactl sd0 identify from a UBS stick installation. I had tried both i386 and AMD64 on the hard drive with the same shutdown result. I have the latest BIOS, verified from Acer's web site. DMESG: OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT real mem = 3009232896 (2869MB) avail mem = 2949853184 (2813MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/28/10, SMBIOS rev. 2.6 @ 0xea690 (51 entries) bios0: vendor INSYDE version V1.20 date 09/28/2010 bios0: Acer Aspire 1430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC BOOT ASPT WDAT SSDT acpi0: wakeup devices P0P2(S4) PEGP(S4) P0P1(S0) EHC1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) EHC2(S4) USB5(S4) USB6(S4) USB7(S4) HDEF(S0) PXSX(S5) RP01(S5) PXSX(S5) RP02(S0) PXSX(S5) RP03(S0) PXSX(S5) RP04(S0) PXSX(S5) RP05(S0) PXSX(S5) RP07(S0) PXSX(S5) RP08(S0) GLAN(S0) PEG3(S4) PEG5(S4) PEG6(S4) SLPB(S3) LID0(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu2: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu3: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 3 (P0P1) acpiprt3 at acpi0: bus 1 (RP01) acpiprt4 at acpi0: bus 2 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus -1 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG3) acpiprt11 at acpi0: bus -1 (PEG5) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpitz0 at acpi0: critical temperature 102 degC acpitz1 at acpi0: critical temperature 90 degC acpibat0 at acpi0: BAT0 model AL10C31 serial 10726 type LION oem 4f594e4153 acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 bios0: ROM list: 0xc/0xfa00! 0xd/0x2c00! cpu0: Enhanced SpeedStep 1331 MHz: speeds: 1333, 1199, 1066, 933, 799, 666 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel Mobile HD graphics rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 10) drm0 at inteldrm0 Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x05: apic 2 int 16 (irq 10) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x05: apic 2 int 22 (irq 11) azalia0: codecs: Realtek ALC269, Intel/0x2804, using Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x05: apic 2 int 17 (irq 255) pci1 at ppb0 bus 1 Attansic Technology L1D rev 0xc0 at pci1 dev 0 function 0 not configured ppb1 at pci0 dev 28 function 1 Intel 3400 PCIE rev 0x05: apic 2 int 16 (irq 255) pci2 at ppb1 bus 2 athn0 at pci2 dev 0 function 0 Atheros AR9287 rev 0x01: apic 2 int 17 (irq 10) athn0: AR9287 rev 2 (2T2R), ROM rev 4, address 88:9f:fa:57:5a:cd ehci1 at pci0 dev 29 function 0
Re: Laptop hard drive and emergency unload
Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller
Re: Laptop hard drive and emergency unload
Why would you run that shit on a laptop? Have you no life? Or glutton for punishment? Re, Mb On Sep 3, 2011 6:32 PM, Steve scha...@aei.ca wrote: Sorry, I had removed OpenBSD from the hard disk due to the shutdown problems. Here are the dmesg, pcidump -v and atactl sd0 identify from a UBS stick installation. I had tried both i386 and AMD64 on the hard drive with the same shutdown result. I have the latest BIOS, verified from Acer's web site. DMESG: OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT real mem = 3009232896 (2869MB) avail mem = 2949853184 (2813MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/28/10, SMBIOS rev. 2.6 @ 0xea690 (51 entries) bios0: vendor INSYDE version V1.20 date 09/28/2010 bios0: Acer Aspire 1430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC BOOT ASPT WDAT SSDT acpi0: wakeup devices P0P2(S4) PEGP(S4) P0P1(S0) EHC1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) EHC2(S4) USB5(S4) USB6(S4) USB7(S4) HDEF(S0) PXSX(S5) RP01(S5) PXSX(S5) RP02(S0) PXSX(S5) RP03(S0) PXSX(S5) RP04(S0) PXSX(S5) RP05(S0) PXSX(S5) RP07(S0) PXSX(S5) RP08(S0) GLAN(S0) PEG3(S4) PEG5(S4) PEG6(S4) SLPB(S3) LID0(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu2: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu3: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 3 (P0P1) acpiprt3 at acpi0: bus 1 (RP01) acpiprt4 at acpi0: bus 2 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus -1 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG3) acpiprt11 at acpi0: bus -1 (PEG5) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpitz0 at acpi0: critical temperature 102 degC acpitz1 at acpi0: critical temperature 90 degC acpibat0 at acpi0: BAT0 model AL10C31 serial 10726 type LION oem 4f594e4153 acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 bios0: ROM list: 0xc/0xfa00! 0xd/0x2c00! cpu0: Enhanced SpeedStep 1331 MHz: speeds: 1333, 1199, 1066, 933, 799, 666 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel Mobile HD graphics rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 10) drm0 at inteldrm0 Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x05: apic 2 int 16 (irq 10) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x05: apic 2 int 22 (irq 11) azalia0: codecs: Realtek ALC269, Intel/0x2804, using Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x05: apic 2 int 17 (irq 255) pci1 at ppb0 bus 1 Attansic Technology L1D rev 0xc0 at pci1 dev 0 function 0 not configured ppb1 at pci0 dev 28 function 1 Intel 3400 PCIE rev 0x05: apic 2 int 16
Re: Laptop hard drive and emergency unload
you have two devices not configured. Maybe just because running from live media. One of them is Intel MEI see here for details about that device software.intel.com/en-us/blogs/2009/12/18/intel-amt-software-lms-heci-mei-why -do-i-need-those-part-10-in-the-series/ so try current if it's better. Hw support improves a lot during every release On 9/4/11, Steve scha...@aei.ca wrote: Sorry, I had removed OpenBSD from the hard disk due to the shutdown problems. Here are the dmesg, pcidump -v and atactl sd0 identify from a UBS stick installation. I had tried both i386 and AMD64 on the hard drive with the same shutdown result. I have the latest BIOS, verified from Acer's web site. DMESG: OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT real mem = 3009232896 (2869MB) avail mem = 2949853184 (2813MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 09/28/10, SMBIOS rev. 2.6 @ 0xea690 (51 entries) bios0: vendor INSYDE version V1.20 date 09/28/2010 bios0: Acer Aspire 1430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC BOOT ASPT WDAT SSDT acpi0: wakeup devices P0P2(S4) PEGP(S4) P0P1(S0) EHC1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) EHC2(S4) USB5(S4) USB6(S4) USB7(S4) HDEF(S0) PXSX(S5) RP01(S5) PXSX(S5) RP02(S0) PXSX(S5) RP03(S0) PXSX(S5) RP04(S0) PXSX(S5) RP05(S0) PXSX(S5) RP07(S0) PXSX(S5) RP08(S0) GLAN(S0) PEG3(S4) PEG5(S4) PEG6(S4) SLPB(S3) LID0(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu2: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz (GenuineIntel 686-class) 1.34 GHz cpu3: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3 ,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 3 (P0P1) acpiprt3 at acpi0: bus 1 (RP01) acpiprt4 at acpi0: bus 2 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus -1 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG3) acpiprt11 at acpi0: bus -1 (PEG5) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpitz0 at acpi0: critical temperature 102 degC acpitz1 at acpi0: critical temperature 90 degC acpibat0 at acpi0: BAT0 model AL10C31 serial 10726 type LION oem 4f594e4153 acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 bios0: ROM list: 0xc/0xfa00! 0xd/0x2c00! cpu0: Enhanced SpeedStep 1331 MHz: speeds: 1333, 1199, 1066, 933, 799, 666 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel Mobile HD graphics rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 10) drm0 at inteldrm0 Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x05: apic 2 int 16 (irq 10) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x05: apic 2 int 22 (irq 11) azalia0: codecs: Realtek ALC269, Intel/0x2804, using Realtek ALC269 audio0 at azalia0
Re: Laptop hard drive and emergency unload
No, Marco, it is not true. There is a difference between unloading the heads in a controlled way and by an emergency retract. Doing emergency retract repeatedly is not good, really. Regards, David On Sat, 3 Sep 2011, Marco Peereboom wrote: Removing power from a running drive won't do anything to it. Just use OpenBSD and stop looking at worthless diagnostics tools. On Sep 3, 2011, at 15:41, Steve scha...@aei.ca wrote: Hi all, I've got a strange situation with OpenBSD 4.9 on a new laptop, an Acer Aspire 1430 with an Hitachi 500 GB SATA disk, model HTS545050B9A300. When shutting down, OpenBSD does not spin down the disk, resulting in an emergency unload according to Smart terminology. Until I can resolve this issue, I've uninstalled OpenBSD from it, since smartctl reports in Slackware that there have been 17 Power-off Retract events so far, which could damage the disk in the long run. However I would really love to run OpenBSD on my laptop for the simple reason that I love it so much more than Linux. Can anyone suggest what I could do to stop this from happening? I found a discussion on a FreeBSD mailing list identifying and trying to resolve the exact same thing through kernel recompilations: http://freebsd.1045724.n5.nabble.com/Re-Spin-down-HDD-after-disk-sync-or-befo re-power-off-td4043068.html However, neither using FreeBSD nor patching the OpenBSD kernel would be a preferred choice for me. I'm sure there must be a simpler solution, maybe a sysctl setting I'm over-looking...? I've tried both IDE and AHCI modes in the BIOS with the same results. Thanks, Steve Schaller
