From: Artur Jasowicz <hidden> Date: 2002-05-09 21:13:03
I've posted the message below to linux-kernel, but there were no replies. Does anyone here have any suggestions?
I am building a file server with 5 drive software RAID5 array. I am using three IWill SIDE-100 (Highpoint 370A) controllers as my IDE interfaces, not using their RAID functionality. One Maxtor 160GB drive per channel, two channels per controller. I plan on adding hot spare as the sixth drive in the future. There's one 160GB partition on each drive. Linux version 2.4.19-pre7smp-020502b (root@production) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #6 SMP Thu May 2 12:15:34 CDT 2002
This is a dual Athlon 2000+ MP on Tyan Tiger S2466N-4 with 1GB RAM. OS and swap runs on separate drives and controllers. This array will be just for data once it is configured.
Below are the most relevant parts of my logs. I will post further details if anyone is willing to help, just let me know what info you need. Any suggestions greatly appreciated.
Artur
After issuing mkraid the system went to syncing RAID and following appeared in my syslog:
May 7 17:34:39 production kernel: RAID5 conf printout:
May 7 17:34:39 production kernel: --- rd:5 wd:5 fd:0
May 7 17:34:39 production kernel: disk 0, s:0, o:1, n:0 rd:0 us:1 dev:hde1
May 7 17:34:39 production kernel: disk 1, s:0, o:1, n:1 rd:1 us:1 dev:hdg1
May 7 17:34:39 production kernel: disk 2, s:0, o:1, n:2 rd:2 us:1 dev:hdi1
May 7 17:34:39 production kernel: disk 3, s:0, o:1, n:3 rd:3 us:1 dev:hdk1
May 7 17:34:39 production kernel: disk 4, s:0, o:1, n:4 rd:4 us:1 dev:hdm1
May 7 17:34:39 production kernel: md: updating md3 RAID superblock on device
May 7 17:34:39 production kernel: md: hdm1 [events: 00000001]<6>(write) hdm1's sb offset: 160079552
May 7 17:34:39 production kernel: md: syncing RAID array md3
May 7 17:34:39 production kernel: md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc.
May 7 17:34:39 production kernel: md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction.
May 7 17:34:39 production kernel: md: using 124k window, over a total of 160079488 blocks.
May 7 17:34:39 production kernel: md: hdk1 [events: 00000001]<6>(write) hdk1's sb offset: 160079552
May 7 17:34:39 production kernel: hde: 0 bytes in FIFO
May 7 17:34:39 production kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
May 7 17:34:39 production kernel: hde: dma_intr: bad DMA status (dma_stat=1)
May 7 17:34:39 production kernel: hde: dma_intr: status=0x50 { DriveReady SeekComplete }
May 7 17:34:39 production kernel: hdi: 4 bytes in FIFO
May 7 17:34:39 production kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
May 7 17:34:39 production kernel: hdi: dma_intr: bad DMA status (dma_stat=1)
May 7 17:34:39 production kernel: hdi: dma_intr: status=0x50 { DriveReady SeekComplete }
May 7 17:34:39 production kernel: hdi: 192 bytes in FIFO
May 7 17:34:39 production kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
May 7 17:34:39 production kernel: hdi: dma_intr: bad DMA status (dma_stat=1)
May 7 17:34:39 production kernel: hdi: dma_intr: status=0x50 { DriveReady SeekComplete }
May 7 17:34:39 production kernel: md: hdi1 [events: 00000001]<6>(write) hdi1's sb offset: 160079552
May 7 17:34:39 production kernel: hdi: 128 bytes in FIFO
May 7 17:34:39 production kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
May 7 17:34:39 production kernel: hdi: dma_intr: bad DMA status (dma_stat=1)
May 7 17:34:39 production kernel: hdi: dma_intr: status=0x50 { DriveReady SeekComplete }
May 7 17:34:39 production kernel: hdk: 128 bytes in FIFO
[...snip...]
May 7 17:34:41 production kernel: hdk: 64 bytes in FIFO
May 7 17:34:41 production kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
May 7 17:34:41 production kernel: hdk: dma_intr: bad DMA status (dma_stat=1)
May 7 17:34:41 production kernel: hdk: dma_intr: status=0x50 { DriveReady SeekComplete }
May 7 17:34:41 production kernel: hdk: recal_intr: status=0xd0 { Busy }
May 7 17:34:41 production kernel: hdk: DMA disabled
May 7 17:34:41 production kernel: ide5: reset: success
May 7 17:34:50 production kernel: hdi: timeout waiting for DMA
May 7 17:34:50 production kernel: hdi: 12 bytes in FIFO
May 7 17:34:50 production kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14
May 7 17:34:50 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 17:34:50 production kernel: hdi: drive not ready for command
Simillar messages were reported for /dev/hdm, hdi, hde, hdk
I've mdstopped the process and disbled DMA for all RAID members with hdparm -d 0. Tried mdrun again and got following messages:
May 7 18:43:26 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:43:26 production kernel: hdi: drive not ready for command
May 7 18:44:40 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:44:40 production kernel: hdi: drive not ready for command
May 7 18:44:52 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:44:52 production kernel: hdi: drive not ready for command
May 7 18:46:45 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:46:45 production kernel: hdi: drive not ready for command
May 7 18:47:11 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:47:11 production kernel: hdi: drive not ready for command
May 7 18:47:32 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:47:32 production kernel: hdi: drive not ready for command
May 7 18:47:57 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:47:57 production kernel: hdi: drive not ready for command
May 7 18:48:09 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:48:09 production kernel: hdi: drive not ready for command
May 7 18:48:18 production kernel: hdk: write_intr error1: nr_sectors=128, stat=0xd0
May 7 18:48:18 production kernel: hdk: write_intr: status=0xd0 { Busy }
May 7 18:48:18 production kernel: ide5: reset: success
May 7 18:48:27 production kernel: hdi: status error: status=0x58 { DriveReady SeekComplete DataRequest }
May 7 18:48:27 production kernel: hdi: drive not ready for command
May 7 18:48:27 production kernel: hdi: status timeout: status=0xd0 { Busy }
May 7 18:48:27 production kernel: hdi: drive not ready for command
May 7 18:48:28 production kernel: ide4: reset: success
May 7 18:48:43 production kernel: raid5: parity resync was not fully finished, restarting next time.
May 7 18:48:43 production kernel: md: md_do_sync() got signal ... exiting
May 7 18:48:44 production kernel: raid5: resync aborted!
I've posted the message below to linux-kernel, but there were no replies. Does anyone here have any suggestions?
I am building a file server with 5 drive software RAID5 array. I am using three IWill SIDE-100 (Highpoint 370A) controllers as my IDE interfaces, not using their RAID functionality. One Maxtor 160GB drive per channel, two channels per controller. I plan on adding hot spare as the sixth drive in the future. There's one 160GB partition on each drive. Linux version 2.4.19-pre7smp-020502b (root@production) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #6 SMP Thu May 2 12:15:34 CDT 2002
This is a dual Athlon 2000+ MP on Tyan Tiger S2466N-4 with 1GB RAM. OS and swap runs on separate drives and controllers. This array will be just for data once it is configured.
Below are the most relevant parts of my logs. I will post further details if anyone is willing to help, just let me know what info you need. Any suggestions greatly appreciated.
I Had the same problem on my old Server. I found out that gigabyte said,
this is a 33UDMA-Board but linux tried to run the disk in UDMA66.
Throtteling down the disks using HDPARM -X was the solution for me.
cheers,
Karsten
From: Artur Jasowicz <hidden> Date: 2002-05-10 03:37:37
From: Karsten Becker <redacted>
Artur Jasowicz wrote:
quoted
I've posted the message below to linux-kernel, but there were no replies.
Does anyone here have any suggestions?
quoted
I am building a file server with 5 drive software RAID5 array. I am using
three IWill SIDE-100 (Highpoint 370A) controllers as my IDE interfaces, not
using their RAID functionality. One Maxtor 160GB drive per channel, two
channels per controller. I plan on adding hot spare as the sixth drive in
the future. There's one 160GB partition on each drive. Linux version
2.4.19-pre7smp-020502b (root@production) (gcc version 2.96 20000731 (Red Hat
Linux 7.1 2.96-98)) #6 SMP Thu May 2 12:15:34 CDT 2002
quoted
This is a dual Athlon 2000+ MP on Tyan Tiger S2466N-4 with 1GB RAM. OS
and swap runs on separate drives and controllers. This array will be just
for data once it is configured.
quoted
Below are the most relevant parts of my logs. I will post further details
if anyone is willing to help, just let me know what info you need. Any
suggestions greatly appreciated.
quoted
I Had the same problem on my old Server. I found out that gigabyte said,
this is a 33UDMA-Board but linux tried to run the disk in UDMA66.
Throtteling down the disks using HDPARM -X was the solution for me.
cheers,
Karsten
Thanks for the comment. Actually, the card is 100-capable and the drives are
133s, but hdparm indicates that they run at 100. I've tried taking the
drives down to UDMA2 (33M) with hdparm -X66, but same problem occured.
I wonder if that's not the PCI getting killed with too much traffic.
Artur
From: Mikael Abrahamsson <hidden> Date: 2002-05-12 08:27:39
On Thu, 9 May 2002, Artur Jasowicz wrote:
I am building a file server with 5 drive software RAID5 array. I am
using three IWill SIDE-100 (Highpoint 370A) controllers as my IDE
interfaces, not using their RAID functionality. One Maxtor 160GB drive
per channel, two channels per controller. I plan on adding hot spare as
the sixth drive in the future. There's one 160GB partition on each
drive. Linux version 2.4.19-pre7smp-020502b (root@production) (gcc
version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #6 SMP Thu May 2
12:15:34 CDT 2002 This is a dual Athlon 2000+ MP on Tyan Tiger S2466N-4
with 1GB RAM. OS and swap runs on separate drives and controllers. This
array will be just for data once it is configured.
I get the exact same errors you get with my VP-6 SMP board when using its
onboard HPT370 controller.
cat /proc/interrupts
CPU0 CPU1
0: 6197040 6197246 IO-APIC-edge timer
1: 440 380 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 0 1 IO-APIC-edge rtc
14: 63320 61241 IO-APIC-edge ide0
15: 3548204 3537369 IO-APIC-edge ide1
16: 429475 430742 IO-APIC-level aic7xxx
18: 4602335 4601175 IO-APIC-level ide2, ide3, aic7xxx
19: 30045123 30046213 IO-APIC-level eth0
My theory is that it's the interrupt sharing that is causing some of the
problems, or some kind of DMA channel mixup. I have no problem with any of
the other drives connected to the primary IDE controller (ide0 and ide1).
Anyone know if I can force the kernel to not share interrupts.
I am using the Red Hat supplied 2.4.18 kernel that comes with redhat 7.3.
When I used the 2.4.9-31 kernel with redhat 7.2 before I got no errors but
instead data corruption on the ide2 and ide3 drives (which are two 120 gig
maxtors in a raid0 config). This could be due to a faulty cable though, I
swapped that one too.
Currently I have stability problems with the box, if I use the ide2 and
ide3 drives a lot the machine freezes.
--
Mikael Abrahamsson email: swmike@swm.pp.se
From: Artur Jasowicz <hidden> Date: 2002-05-13 04:41:10
Anyone know if I can force the kernel to not share interrupts.
I think that Highpoint chip only uses one IRQ for both channels, but it
might be helpfull to move your SCSI card's IRQ to another slot.
Currently I have stability problems with the box, if I use the ide2 and
ide3 drives a lot the machine freezes.
If your DMA is on on the Highpoint drives, this might cause lockups. That's
what I was getting with another machine I have. It is a M571 mobo (Chinese
cheapo generic crap) with two IWills driving four 80 GB Maxtors in RAID 5.
As long as DMA was on, I couldn't complete syncing array after configuring
it. Contstant lockups. After I did hdparm -d 0 /dev/hd[e,g,i,k] the arrays
synced and seem to be working correctly now. I need to develop a way of
checking for data corruption. Of course the price is the speed. With DMA on
I was getting 2000K/s syncing speed. without DMA - 800K. I am running plain
RH 7.2 on this machine. It may be worth trying hdparm -X to set drives to a
slower DMA, although this is just a patch, not a solution. Before trying to
use this configuration I had a single IWill with two Maxtors in RAID1.
Worked without a glitch. I wish I remembered if the controlled had it's own
IRQ. Although I doubt it. I was running RH 7.1 back then.
Is your CPU usage also close to 100% when using RAID?
Artur
From: Mikael Abrahamsson <hidden> Date: 2002-05-13 05:01:28
On Sun, 12 May 2002, Artur Jasowicz wrote:
quoted
Anyone know if I can force the kernel to not share interrupts.
I think that Highpoint chip only uses one IRQ for both channels, but it
might be helpfull to move your SCSI card's IRQ to another slot.
How?
Is your CPU usage also close to 100% when using RAID?
Nope, I barely have any CPU usage at all. If you turn off DMA though, I am
not surprised you have high CPU usage problems.
--
Mikael Abrahamsson email: swmike@swm.pp.se
As long as DMA was on, I couldn't complete syncing array after configuring
it. Contstant lockups. After I did hdparm -d 0 /dev/hd[e,g,i,k] the arrays
synced and seem to be working correctly now. I need to develop a way of
checking for data corruption. Of course the price is the speed. With DMA on
I was getting 2000K/s syncing speed. without DMA - 800K. I am running plain
I'm used to sync speeds above 20000K/s these days. With DMA, of course.
Is your CPU usage also close to 100% when using RAID?
Nope, not even close. But having the DMA turned off is certanly a way to
put a lot of load on your CPU(s).
It seems that either the HPTs have a design flaw or the driver is not
fully supporting them.
D.