I upgraded my Centos 4.7 server last night. Switched from a cheaper 50$ asus motherboard to a Supermicro motherboard. I also, using dd, copied entire 500g SATA seagate drive to new 500g SATA seagate drive so as to have two copies in case something went wrong.
Anyway, now I keep getting this error:
Nov 21 06:08:33 server kernel: hda: status timeout: status=0xd0 { Busy } Nov 21 06:08:33 server kernel: Nov 21 06:08:33 server kernel: ide: failed opcode was: unknown Nov 21 06:08:33 server kernel: hda: no DRQ after issuing WRITE Nov 21 06:08:34 server kernel: ide0: reset: success
Found one website that told me too try hdparm -i to see whats up:
/dev/hda:
Model=ST3500320AS, FwRev=SD15, SerialNo= Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 AdvancedPM=no WriteCache=enabled Drive conforms to: unknown:
* signifies the current active mode
So from recommendation on website I did this to match MaxMultiSect:
hdparm -m16 /dev/hda
then tried this to turn MultSect off:
hdparm -m0 /dev/hda
Still getting error. The Supermicro MBD-X7SBL-LN1-O motherboard has basically all defaults set in bios.
Any ideas? Thanks.
Matt
I am coming to conclusion that CentOS 4.7 does not support the Intel ICH9R SATA controller very well. My disk I/O is really slowing down as well. Any solutions besides replacing motherboard to fix it?
Thanks.
Matt
I upgraded my Centos 4.7 server last night. Switched from a cheaper 50$ asus motherboard to a Supermicro motherboard. I also, using dd, copied entire 500g SATA seagate drive to new 500g SATA seagate drive so as to have two copies in case something went wrong.
Anyway, now I keep getting this error:
Nov 21 06:08:33 server kernel: hda: status timeout: status=0xd0 { Busy } Nov 21 06:08:33 server kernel: Nov 21 06:08:33 server kernel: ide: failed opcode was: unknown Nov 21 06:08:33 server kernel: hda: no DRQ after issuing WRITE Nov 21 06:08:34 server kernel: ide0: reset: success
Found one website that told me too try hdparm -i to see whats up:
/dev/hda:
Model=ST3500320AS, FwRev=SD15, SerialNo= Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 AdvancedPM=no WriteCache=enabled Drive conforms to: unknown:
- signifies the current active mode
So from recommendation on website I did this to match MaxMultiSect:
hdparm -m16 /dev/hda
then tried this to turn MultSect off:
hdparm -m0 /dev/hda
Still getting error. The Supermicro MBD-X7SBL-LN1-O motherboard has basically all defaults set in bios.
Any ideas? Thanks.
Matt
on 11-21-2008 4:41 AM Matt spake the following:
I upgraded my Centos 4.7 server last night. Switched from a cheaper 50$ asus motherboard to a Supermicro motherboard. I also, using dd, copied entire 500g SATA seagate drive to new 500g SATA seagate drive so as to have two copies in case something went wrong.
Anyway, now I keep getting this error:
Nov 21 06:08:33 server kernel: hda: status timeout: status=0xd0 { Busy } Nov 21 06:08:33 server kernel: Nov 21 06:08:33 server kernel: ide: failed opcode was: unknown Nov 21 06:08:33 server kernel: hda: no DRQ after issuing WRITE Nov 21 06:08:34 server kernel: ide0: reset: success
Found one website that told me too try hdparm -i to see whats up:
/dev/hda:
Model=ST3500320AS, FwRev=SD15, SerialNo= Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 AdvancedPM=no WriteCache=enabled Drive conforms to: unknown:
- signifies the current active mode
So from recommendation on website I did this to match MaxMultiSect:
hdparm -m16 /dev/hda
then tried this to turn MultSect off:
hdparm -m0 /dev/hda
Still getting error. The Supermicro MBD-X7SBL-LN1-O motherboard has basically all defaults set in bios.
Any ideas? Thanks.
Matt
If the drives were different in size, dd could have truncated something. It isn't always the best tool to use. Maybe try again with a different tool.
Also the fact that the drive is showing up as /dev/hda instead of /dev/sda means that you are not using the best driver for the hard drive. Go into the bios and try either native mode to serial ATA or SATA AHCI enable. You might need to rebuild the initrd from a rescue disk after you boot.
Also the fact that the drive is showing up as /dev/hda instead of /dev/sda means that you are not using the best driver for the hard drive. Go into the bios and try either native mode to serial ATA or SATA AHCI enable. You might need to rebuild the initrd from a rescue disk after you boot.
native mode to serial ATA
Did that. Now it shows up as sda again. I no longer get the errors either but I get this now.
[root@server log]# hdparm -i /dev/sda
/dev/sda: HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
Smartd also complains on boot up.
Any ideas?
Matt
Matt wrote:
/dev/sda: HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
I was looking into your original issue earlier and saw a post mentioning that hdparm didn't work with sata drives?
Not sure how old the post was or how accurate, I've never had to use hdparm myself.
Perhaps 'sdparm' is what you need, never heard of that until about 10 seconds ago looking at this topic again.
http://linux.die.net/man/8/sdparm
nate
On Fri, Nov 21, 2008 at 3:48 PM, Matt lm7812@gmail.com wrote:
Also the fact that the drive is showing up as /dev/hda instead of /dev/sda means that you are not using the best driver for the hard drive. Go into the bios and try either native mode to serial ATA or SATA AHCI enable. You might need to rebuild the initrd from a rescue disk after you boot.
native mode to serial ATA
Did that. Now it shows up as sda again. I no longer get the errors either but I get this now.
[root@server log]# hdparm -i /dev/sda
/dev/sda: HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
Smartd also complains on boot up.
Smartd is not that smart - it has known issues with SATA drives, as I have posted on in this group recently.
I ran smartctl and Seatool (from Seagate, since mine is a Seagate drive) tests on it and had no problems. Of course, my WD and Hitachi SATA drives don't do this, so maybe it is peculiar to Seagates....
mhr
Also the fact that the drive is showing up as /dev/hda instead of /dev/sda means that you are not using the best driver for the hard drive. Go into the bios and try either native mode to serial ATA or SATA AHCI enable. You might need to rebuild the initrd from a rescue disk after you boot.
native mode to serial ATA
Did that. Now it shows up as sda again. I no longer get the errors either but I get this now.
[root@server log]# hdparm -i /dev/sda
/dev/sda: HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
Smartd also complains on boot up.
Smartd is not that smart - it has known issues with SATA drives, as I have posted on in this group recently.
I ran smartctl and Seatool (from Seagate, since mine is a Seagate drive) tests on it and had no problems. Of course, my WD and Hitachi SATA drives don't do this, so maybe it is peculiar to Seagates....
Smartd is having a fit about Seek_Error_Rate. Like you said from looking at a few google searches this is normal with Seagate drives and does not mean they will fail.
I think I may be close to having most issues straightened out with this messy upgrade. My iostats are still 3 times higher then prior to upgrade though. Is it perhaps an issue that Centos 4.7 does not support the Intel ICH9R SATA controller very well?
Thanks.
Matt
-
Matt -
MHR -
nate -
Scott Silva