Re: HighPoint 374

Re: HighPoint 374

[Jindrich Makovicka]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

With my EPoX 8K9A3+, I had to hack the kernel to get the HPT374 running 
at all, as it reported slightly higher PCI clock than 33MHz, although 
the machine wasn't overclocked, but it seems to run fine. The current 
driver supports only 33MHz clock, which is probably the reason HPT374 
isn't even initialized in some cases.

-- 
Jindrich Makovicka

[-- Attachment #2: hpt366.c.patch2 --]
[-- Type: text/plain, Size: 404 bytes --]

--- hpt366.c.orig	2003-08-26 15:08:59.000000000 +0200
+++ hpt366.c	2003-08-26 15:09:46.000000000 +0200
@@ -808,6 +808,8 @@
 		printk("HPT37X: using 33MHz PCI clock\n");
 	} else if (freq < 0xb0) {
 		pll = F_LOW_PCI_40;
+		if (hpt_minimum_revision(dev,8))
+			pci_set_drvdata(dev, (void *) thirty_three_base_hpt374);
 	} else if (freq < 0xc8) {
 		pll = F_LOW_PCI_50;
 		if (hpt_minimum_revision(dev,8))

Re: HighPoint 374

[Tomi Orava]

> With my EPoX 8K9A3+, I had to hack the kernel to get the HPT374 running
> at all, as it reported slightly higher PCI clock than 33MHz, although
> the machine wasn't overclocked, but it seems to run fine. The current
> driver supports only 33MHz clock, which is probably the reason HPT374
> isn't even initialized in some cases.

Hmm, it looks like my motherboard doesn't suffer from the same problem.
I see that in my machine the correct frequency is selected:

------------------------------------------------------------
HPT374: IDE controller at PCI slot 00:0e.0
HPT374: chipset revision 7
HPT374: not 100% native mode: will probe irqs later
HPT37X: using 33MHz PCI clock
    ide2: BM-DMA at 0xb800-0xb807, BIOS settings: hde:DMA, hdf:pio
    ide3: BM-DMA at 0xb808-0xb80f, BIOS settings: hdg:DMA, hdh:pio
HPT37X: using 33MHz PCI clock
    ide4: BM-DMA at 0xcc00-0xcc07, BIOS settings: hdi:DMA, hdj:pio
    ide5: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdk:DMA, hdl:pio
SiI680: IDE controller at PCI slot 00:09.0
SiI680: chipset revision 1
SiI680: not 100% native mode: will probe irqs later
SiI680: BASE CLOCK == 133
    ide6: MMIO-DMA , BIOS settings: hdm:pio, hdn:pio
    ide7: MMIO-DMA , BIOS settings: hdo:pio, hdp:pio
------------------------------------------------------------

However, with the latest 2.4.23-pre7 kernel I get the following error
messages and I think the hdparm -i output looks wierd ...
Perhaps the display is incorrect as I have disabled for testing
purposes the CONFIG_IDEDMA_PCI_AUTO-option so that I'm able to
boot up even if raid1 resync is started at boot without hang.
(I use the hdparm -d1 to enabled dma-mode later)

---------------------------------------------------------------
hde: SAMSUNG SV8004H, ATA DISK drive
hde: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hde: set_drive_speed_status: error=0x04 { DriveStatusError }
hdg: SAMSUNG SV8004H, ATA DISK drive
hdg: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdg: set_drive_speed_status: error=0x04 { DriveStatusError }
hdi: SAMSUNG SV1604N, ATA DISK drive
hdi: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdi: set_drive_speed_status: error=0x04 { DriveStatusError }
hdk: SAMSUNG SV1604N, ATA DISK drive
hdk: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
hdk: set_drive_speed_status: error=0x04 { DriveStatusError }

---> Drives connected to Sil680 don't complain below -------------
hdm: MAXTOR 6L060J3, ATA DISK drive
blk: queue c04992f8, I/O limit 4095Mb (mask 0xffffffff)
hdo: MAXTOR 6L060J3, ATA DISK drive
blk: queue c049974c, I/O limit 4095Mb (mask 0xffffffff)
---------------------------------------------------------------

The output of hdparm -i /dev/hde (first drive connected to HPT374,
note the mode selection asterisk is missing as well as faster modes):

/dev/hde:

 Model=SAMSUNG SV8004H, FwRev=QR100-12, SerialNo=0357J1AT803561
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=38997, SectSize=619, ECCbytes=4
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156368016
 IORDY=yes, 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: ATA/ATAPI-6 T13 1410D revision 1:

 * signifies the current active mode


Does this tell anything to the IDE-guys ?

Regards,
Tomi Orava

PS. All the drives have been set with explicit hdparm -m 16 setting
    in order to see if it changes anything regarding the interrupt
    problem described previously.

-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Tomi Orava]

Ups, hit enter while still writing the message, sorry about that.

Anyway, I just wanted to know if the following error messages
tell you anything new.

The test was done by copying almost 40GB data simultaneously
from one RAID1-mirror (disks 1&2 on hpt374) to disks 3&4 on
hpt374 as well _and_ to disks 1&2 on an external Sil680 PCI-card.
Kernel version was 2.4.23-pre7.

In my tests the hdparm -m doesn't solve anything.
The hardware was Epox 8K9A3+ with integrated hpt374-chip.
Processor is AMD 1.4TB, no overclocking of any kind.

Regards,
Tomi Orava
---------------------------------------------------------------
Oct 21 20:15:05 alderan kernel: hdk: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct 21 20:15:05 alderan kernel: hdk: drive_cmd: error=0x04 {
DriveStatusError }
Oct 21 20:15:05 alderan kernel: hdk: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct 21 20:15:05 alderan kernel: hdk: drive_cmd: error=0x04 {
DriveStatusError }
Oct 21 20:15:17 alderan kernel: hdk: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Oct 21 20:15:17 alderan kernel: hdk: drive_cmd: error=0x04 {
DriveStatusError }
Oct 21 20:22:36 alderan kernel: hdg: set_drive_speed_status: status=0xff {
Busy }
Oct 21 20:30:57 alderan kernel: hdi: dma_timer_expiry: dma status == 0x20
Oct 21 20:30:57 alderan kernel: hdi: timeout waiting for DMA
Oct 21 20:30:57 alderan kernel: hdi: timeout waiting for DMA
Oct 21 20:30:57 alderan kernel: hdi: (__ide_dma_test_irq) called while not
waiting
Oct 21 20:30:57 alderan kernel: hdi: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Oct 21 20:30:57 alderan kernel:
Oct 21 20:30:57 alderan kernel: hdi: drive not ready for command
Oct 21 20:30:57 alderan kernel: hdi: status timeout: status=0xd0 { Busy }
Oct 21 20:30:57 alderan kernel:
Oct 21 20:30:57 alderan kernel: hdi: drive not ready for command
Oct 21 20:30:57 alderan kernel: ide4: reset: success
Oct 21 20:30:57 alderan kernel: blk: queue c0498a50, I/O limit 4095Mb
(mask 0xffffffff)
Oct 21 20:30:57 alderan kernel: hdi: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Oct 21 20:31:01 alderan kernel:
Oct 21 20:31:10 alderan kernel: hdi: drive not ready for command
Oct 21 20:31:17 alderan kernel: hdi: dma_timer_expiry: dma status == 0x20
Oct 21 20:31:20 alderan kernel: hdi: timeout waiting for DMA
Oct 21 20:31:20 alderan kernel: hdi: timeout waiting for DMA
Oct 21 20:31:20 alderan kernel: hdi: (__ide_dma_test_irq) called while not
waiting
Oct 21 20:31:20 alderan kernel: hdi: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Oct 21 20:31:20 alderan kernel:
Oct 21 20:31:20 alderan kernel: hdi: drive not ready for command
Oct 21 20:31:20 alderan kernel: hdi: status timeout: status=0xd0 { Busy }
Oct 21 20:31:20 alderan kernel:
Oct 21 20:31:20 alderan kernel: hdi: drive not ready for command
Oct 21 20:31:20 alderan kernel: ide4: reset: success
Oct 21 20:32:36 alderan kernel: hdi: lost interrupt



-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Tomi Orava]

Bartlomiej,

> multicount affects PIO transfers performance only...

This makes sense as I was finally able to run some tests
and hdparm -m doesn't seem to affect anything.

However, do the following errors tell you anything new ?
(They were seen while copying almost 40GB of files from
one RAID1-mirror (hpt374) to second RAID1-mirror(

>
> On Monday 20 of October 2003 23:07, Svetoslav Slavtchev wrote:
>> > BTW, isn't m0 supposed to reduce perfomance?
>>
>> hm here it also doesn't seem to change much,
>> may be it's ignored if UDMA is used
>>
>> mem is 1024Mb
>>
>> [root@svetljo kernel]#  hdparm -m0 /dev/hde
>>
>> /dev/hde:
>>  setting multcount to 0
>>  multcount    =  0 (off)
>>
>> [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
>> 20000+0 records in
>> 20000+0 records out
>> 0.09user 29.38system 5:44.49elapsed 8%CPU (0avgtext+0avgdata
>> 0maxresident)k
>> 0inputs+0outputs (149major+40minor)pagefaults 0swaps
>> [root@svetljo 1]#  hdparm -m8 /dev/hde
>>
>> /dev/hde:
>>  setting multcount to 8
>>  multcount    =  8 (on)
>> [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
>> 20000+0 records in
>> 20000+0 records out
>> 0.10user 28.99system 5:50.44elapsed 8%CPU (0avgtext+0avgdata
>> 0maxresident)k
>> 0inputs+0outputs (150major+41minor)pagefaults 0swaps
>>
>> root@svetljo 1]#  hdparm -m16 /dev/hde
>>
>> /dev/hde:
>>  setting multcount to 16
>>  multcount    = 16 (on)
>> [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
>> 20000+0 records in
>> 20000+0 records out
>> 0.09user 28.83system 5:53.57elapsed 8%CPU (0avgtext+0avgdata
>> 0maxresident)k
>> 0inputs+0outputs (165major+40minor)pagefaults 0swaps
>> [root@svetljo 1]#
>>
>> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
>> > bs=65536
>> > 20000+0 records in
>> > 20000+0 records out
>> >
>> > real    0m33.763s
>> > user    0m0.200s
>> > sys     0m10.920s
>> > [root@fulanito wd1200jb]# hdparm -m4 /dev/hdk
>> >
>> > /dev/hdk:
>> >  setting multcount to 4
>> >  multcount    =  4 (on)
>> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
>> > bs=65536
>> > 20000+0 records in
>> > 20000+0 records out
>> >
>> > real    0m30.321s
>> > user    0m0.150s
>> > sys     0m10.630s
>> > [root@fulanito wd1200jb]# hdparm -m0 /dev/hdk
>> >
>> > /dev/hdk:
>> >  setting multcount to 0
>> >  multcount    =  0 (off)
>> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
>> > bs=65536
>> > 20000+0 records in
>> > 20000+0 records out
>> >
>> > real    0m30.749s
>> > user    0m0.130s
>> > sys     0m10.900s
>> > [root@fulanito wd1200jb]#
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> multicount affects PIO transfers performance only...

how could it then " resolve" DMA timeouts ?

> On Monday 20 of October 2003 23:07, Svetoslav Slavtchev wrote:
> > > BTW, isn't m0 supposed to reduce perfomance?
> >
> > hm here it also doesn't seem to change much,
> > may be it's ignored if UDMA is used
> >
> > mem is 1024Mb
> >
> > [root@svetljo kernel]#  hdparm -m0 /dev/hde
> >
> > /dev/hde:
> >  setting multcount to 0
> >  multcount    =  0 (off)
> >
> > [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
> > 20000+0 records in
> > 20000+0 records out
> > 0.09user 29.38system 5:44.49elapsed 8%CPU (0avgtext+0avgdata
> 0maxresident)k
> > 0inputs+0outputs (149major+40minor)pagefaults 0swaps
> > [root@svetljo 1]#  hdparm -m8 /dev/hde
> >
> > /dev/hde:
> >  setting multcount to 8
> >  multcount    =  8 (on)
> > [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
> > 20000+0 records in
> > 20000+0 records out
> > 0.10user 28.99system 5:50.44elapsed 8%CPU (0avgtext+0avgdata
> 0maxresident)k
> > 0inputs+0outputs (150major+41minor)pagefaults 0swaps
> >
> > root@svetljo 1]#  hdparm -m16 /dev/hde
> >
> > /dev/hde:
> >  setting multcount to 16
> >  multcount    = 16 (on)
> > [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
> > 20000+0 records in
> > 20000+0 records out
> > 0.09user 28.83system 5:53.57elapsed 8%CPU (0avgtext+0avgdata
> 0maxresident)k
> > 0inputs+0outputs (165major+40minor)pagefaults 0swaps
> > [root@svetljo 1]#
> >
> > > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > > bs=65536
> > > 20000+0 records in
> > > 20000+0 records out
> > >
> > > real    0m33.763s
> > > user    0m0.200s
> > > sys     0m10.920s
> > > [root@fulanito wd1200jb]# hdparm -m4 /dev/hdk
> > >
> > > /dev/hdk:
> > >  setting multcount to 4
> > >  multcount    =  4 (on)
> > > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > > bs=65536
> > > 20000+0 records in
> > > 20000+0 records out
> > >
> > > real    0m30.321s
> > > user    0m0.150s
> > > sys     0m10.630s
> > > [root@fulanito wd1200jb]# hdparm -m0 /dev/hdk
> > >
> > > /dev/hdk:
> > >  setting multcount to 0
> > >  multcount    =  0 (off)
> > > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > > bs=65536
> > > 20000+0 records in
> > > 20000+0 records out
> > >
> > > real    0m30.749s
> > > user    0m0.130s
> > > sys     0m10.900s
> > > [root@fulanito wd1200jb]#
> 

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Bartlomiej Zolnierkiewicz]

multicount affects PIO transfers performance only...

On Monday 20 of October 2003 23:07, Svetoslav Slavtchev wrote:
> > BTW, isn't m0 supposed to reduce perfomance?
>
> hm here it also doesn't seem to change much,
> may be it's ignored if UDMA is used
>
> mem is 1024Mb
>
> [root@svetljo kernel]#  hdparm -m0 /dev/hde
>
> /dev/hde:
>  setting multcount to 0
>  multcount    =  0 (off)
>
> [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
> 20000+0 records in
> 20000+0 records out
> 0.09user 29.38system 5:44.49elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (149major+40minor)pagefaults 0swaps
> [root@svetljo 1]#  hdparm -m8 /dev/hde
>
> /dev/hde:
>  setting multcount to 8
>  multcount    =  8 (on)
> [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
> 20000+0 records in
> 20000+0 records out
> 0.10user 28.99system 5:50.44elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (150major+41minor)pagefaults 0swaps
>
> root@svetljo 1]#  hdparm -m16 /dev/hde
>
> /dev/hde:
>  setting multcount to 16
>  multcount    = 16 (on)
> [root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
> 20000+0 records in
> 20000+0 records out
> 0.09user 28.83system 5:53.57elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (165major+40minor)pagefaults 0swaps
> [root@svetljo 1]#
>
> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > bs=65536
> > 20000+0 records in
> > 20000+0 records out
> >
> > real    0m33.763s
> > user    0m0.200s
> > sys     0m10.920s
> > [root@fulanito wd1200jb]# hdparm -m4 /dev/hdk
> >
> > /dev/hdk:
> >  setting multcount to 4
> >  multcount    =  4 (on)
> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > bs=65536
> > 20000+0 records in
> > 20000+0 records out
> >
> > real    0m30.321s
> > user    0m0.150s
> > sys     0m10.630s
> > [root@fulanito wd1200jb]# hdparm -m0 /dev/hdk
> >
> > /dev/hdk:
> >  setting multcount to 0
> >  multcount    =  0 (off)
> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > bs=65536
> > 20000+0 records in
> > 20000+0 records out
> >
> > real    0m30.749s
> > user    0m0.130s
> > sys     0m10.900s
> > [root@fulanito wd1200jb]#

Re: HighPoint 374

[Svetoslav Slavtchev]

> BTW, isn't m0 supposed to reduce perfomance?

hm here it also doesn't seem to change much,
may be it's ignored if UDMA is used

mem is 1024Mb

[root@svetljo kernel]#  hdparm -m0 /dev/hde

/dev/hde:
 setting multcount to 0
 multcount    =  0 (off)

[root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
20000+0 records in
20000+0 records out
0.09user 29.38system 5:44.49elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (149major+40minor)pagefaults 0swaps
[root@svetljo 1]#  hdparm -m8 /dev/hde

/dev/hde:
 setting multcount to 8
 multcount    =  8 (on)
[root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
20000+0 records in
20000+0 records out
0.10user 28.99system 5:50.44elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (150major+41minor)pagefaults 0swaps

root@svetljo 1]#  hdparm -m16 /dev/hde

/dev/hde:
 setting multcount to 16
 multcount    = 16 (on)
[root@svetljo 1]# time dd if=/dev/zero of=10Gb.zeros count=20000 bs=512k
20000+0 records in
20000+0 records out
0.09user 28.83system 5:53.57elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (165major+40minor)pagefaults 0swaps
[root@svetljo 1]#

> [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> bs=65536
> 20000+0 records in
> 20000+0 records out
> 
> real    0m33.763s
> user    0m0.200s
> sys     0m10.920s
> [root@fulanito wd1200jb]# hdparm -m4 /dev/hdk
> 
> /dev/hdk:
>  setting multcount to 4
>  multcount    =  4 (on)
> [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> bs=65536
> 20000+0 records in
> 20000+0 records out
> 
> real    0m30.321s
> user    0m0.150s
> sys     0m10.630s
> [root@fulanito wd1200jb]# hdparm -m0 /dev/hdk
> 
> /dev/hdk:
>  setting multcount to 0
>  multcount    =  0 (off)
> [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> bs=65536
> 20000+0 records in
> 20000+0 records out
> 
> real    0m30.749s
> user    0m0.130s
> sys     0m10.900s
> [root@fulanito wd1200jb]#

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Carlos Fernandez Sanz]

512 Mb, file was 1.3 Gb.

----- Original Message ----- 
From: "Svetoslav Slavtchev" <svetljo@gmx.de>
To: "Carlos Fernandez Sanz" <cfs-lk@nisupu.com>
Cc: <Tomi.Orava@ncircle.nullnet.fi>; <linux-kernel@vger.kernel.org>
Sent: Monday, October 20, 2003 21:14
Subject: Re: HighPoint 374


> > BTW, isn't m0 supposed to reduce perfomance?
>
> have to retest probably
>
> how much RAM do you have,
> isn't your test file to small
>
> svetljo
>
>
> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > bs=65536
> > 20000+0 records in
> > 20000+0 records out
> >
> > real    0m33.763s
> > user    0m0.200s
> > sys     0m10.920s
> > [root@fulanito wd1200jb]# hdparm -m4 /dev/hdk
> >
> > /dev/hdk:
> >  setting multcount to 4
> >  multcount    =  4 (on)
> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > bs=65536
> > 20000+0 records in
> > 20000+0 records out
> >
> > real    0m30.321s
> > user    0m0.150s
> > sys     0m10.630s
> > [root@fulanito wd1200jb]# hdparm -m0 /dev/hdk
> >
> > /dev/hdk:
> >  setting multcount to 0
> >  multcount    =  0 (off)
> > [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> > bs=65536
> > 20000+0 records in
> > 20000+0 records out
> >
> > real    0m30.749s
> > user    0m0.130s
> > sys     0m10.900s
> > [root@fulanito wd1200jb]#
> >
> > ----- Original Message ----- 
> > From: "Svetoslav Slavtchev" <svetljo@gmx.de>
> > To: "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi>
> > Cc: <linux-kernel@vger.kernel.org>
> > Sent: Monday, October 20, 2003 11:03
> > Subject: Re: HighPoint 374
> >
> >
> > > >
> > > >
> > > > >> Are you capable of trying if the hdparm -m0 trick
> > > > >> works for you ?
> > > > >
> > > > > you mean the fs corruption on soft raid or the interupts problem ?
> > > > > i dumped the raid setup as i couldn't find a way to debug it
> > > > > and my drives are pretty full again, but i'll try to free some
space
> > > >
> > > > I meant the interrupt problem, because if that problem exists
> > > > there doesn't seem to be a reasonable way to figure out what
> > > > is the reason for the filesystem corruption.
> > > >
> > > > > for the interupts
> > > > > with test7-bk8  , acpi=off pci=noacpi &
> > > > > hdparm  -m0 -d1 -X69  /dev/hd[a,e,g]
> > > > > hdparm  -m16 -d1 -X69  /dev/hd[a,e,g]
> > > > > i don't see timeouts
> > > > > if i omit -m i do see them sometimes
> > > >
> > > > Ok, so if I understood you correctly, the interrupt problem
> > > > persists _only_ if you leave the multiple sector setting on
> > > > its default setting ? If you explicitly disable it, or set
> > > > it to maximum it works fine ? Does it work with any value ?
> > >
> > > -m4 & -m8 seems to work OK
> > > each time 3 runs of the dd test
> > > 1 to hda
> > > 2 to hde
> > >
> > > TCQ  not activated
> > >
> > >
> > > -- 
> > > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> > > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
> > >
> > > Jetzt kostenlos anmelden unter http://www.gmx.net
> > >
> > > +++ GMX - die erste Adresse für Mail, Message, More! +++
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe
linux-kernel"
> > in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > >
> >
>
> -- 
> NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
>
> Jetzt kostenlos anmelden unter http://www.gmx.net
>
> +++ GMX - die erste Adresse für Mail, Message, More! +++
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: HighPoint 374

[Svetoslav Slavtchev]

> BTW, isn't m0 supposed to reduce perfomance?

have to retest probably

how much RAM do you have,
isn't your test file to small

svetljo


> [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> bs=65536
> 20000+0 records in
> 20000+0 records out
> 
> real    0m33.763s
> user    0m0.200s
> sys     0m10.920s
> [root@fulanito wd1200jb]# hdparm -m4 /dev/hdk
> 
> /dev/hdk:
>  setting multcount to 4
>  multcount    =  4 (on)
> [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> bs=65536
> 20000+0 records in
> 20000+0 records out
> 
> real    0m30.321s
> user    0m0.150s
> sys     0m10.630s
> [root@fulanito wd1200jb]# hdparm -m0 /dev/hdk
> 
> /dev/hdk:
>  setting multcount to 0
>  multcount    =  0 (off)
> [root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
> bs=65536
> 20000+0 records in
> 20000+0 records out
> 
> real    0m30.749s
> user    0m0.130s
> sys     0m10.900s
> [root@fulanito wd1200jb]#
> 
> ----- Original Message ----- 
> From: "Svetoslav Slavtchev" <svetljo@gmx.de>
> To: "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi>
> Cc: <linux-kernel@vger.kernel.org>
> Sent: Monday, October 20, 2003 11:03
> Subject: Re: HighPoint 374
> 
> 
> > >
> > >
> > > >> Are you capable of trying if the hdparm -m0 trick
> > > >> works for you ?
> > > >
> > > > you mean the fs corruption on soft raid or the interupts problem ?
> > > > i dumped the raid setup as i couldn't find a way to debug it
> > > > and my drives are pretty full again, but i'll try to free some space
> > >
> > > I meant the interrupt problem, because if that problem exists
> > > there doesn't seem to be a reasonable way to figure out what
> > > is the reason for the filesystem corruption.
> > >
> > > > for the interupts
> > > > with test7-bk8  , acpi=off pci=noacpi &
> > > > hdparm  -m0 -d1 -X69  /dev/hd[a,e,g]
> > > > hdparm  -m16 -d1 -X69  /dev/hd[a,e,g]
> > > > i don't see timeouts
> > > > if i omit -m i do see them sometimes
> > >
> > > Ok, so if I understood you correctly, the interrupt problem
> > > persists _only_ if you leave the multiple sector setting on
> > > its default setting ? If you explicitly disable it, or set
> > > it to maximum it works fine ? Does it work with any value ?
> >
> > -m4 & -m8 seems to work OK
> > each time 3 runs of the dd test
> > 1 to hda
> > 2 to hde
> >
> > TCQ  not activated
> >
> >
> > -- 
> > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
> >
> > Jetzt kostenlos anmelden unter http://www.gmx.net
> >
> > +++ GMX - die erste Adresse für Mail, Message, More! +++
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> 

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Carlos Fernandez Sanz]

BTW, isn't m0 supposed to reduce perfomance?

[root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
bs=65536
20000+0 records in
20000+0 records out

real    0m33.763s
user    0m0.200s
sys     0m10.920s
[root@fulanito wd1200jb]# hdparm -m4 /dev/hdk

/dev/hdk:
 setting multcount to 4
 multcount    =  4 (on)
[root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
bs=65536
20000+0 records in
20000+0 records out

real    0m30.321s
user    0m0.150s
sys     0m10.630s
[root@fulanito wd1200jb]# hdparm -m0 /dev/hdk

/dev/hdk:
 setting multcount to 0
 multcount    =  0 (off)
[root@fulanito wd1200jb]# time dd if=/dev/zero of=filling count=20000
bs=65536
20000+0 records in
20000+0 records out

real    0m30.749s
user    0m0.130s
sys     0m10.900s
[root@fulanito wd1200jb]#

----- Original Message ----- 
From: "Svetoslav Slavtchev" <svetljo@gmx.de>
To: "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi>
Cc: <linux-kernel@vger.kernel.org>
Sent: Monday, October 20, 2003 11:03
Subject: Re: HighPoint 374


> >
> >
> > >> Are you capable of trying if the hdparm -m0 trick
> > >> works for you ?
> > >
> > > you mean the fs corruption on soft raid or the interupts problem ?
> > > i dumped the raid setup as i couldn't find a way to debug it
> > > and my drives are pretty full again, but i'll try to free some space
> >
> > I meant the interrupt problem, because if that problem exists
> > there doesn't seem to be a reasonable way to figure out what
> > is the reason for the filesystem corruption.
> >
> > > for the interupts
> > > with test7-bk8  , acpi=off pci=noacpi &
> > > hdparm  -m0 -d1 -X69  /dev/hd[a,e,g]
> > > hdparm  -m16 -d1 -X69  /dev/hd[a,e,g]
> > > i don't see timeouts
> > > if i omit -m i do see them sometimes
> >
> > Ok, so if I understood you correctly, the interrupt problem
> > persists _only_ if you leave the multiple sector setting on
> > its default setting ? If you explicitly disable it, or set
> > it to maximum it works fine ? Does it work with any value ?
>
> -m4 & -m8 seems to work OK
> each time 3 runs of the dd test
> 1 to hda
> 2 to hde
>
> TCQ  not activated
>
>
> -- 
> NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
>
> Jetzt kostenlos anmelden unter http://www.gmx.net
>
> +++ GMX - die erste Adresse für Mail, Message, More! +++
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> 
> >> Are you capable of trying if the hdparm -m0 trick
> >> works for you ?
> >
> > you mean the fs corruption on soft raid or the interupts problem ?
> > i dumped the raid setup as i couldn't find a way to debug it
> > and my drives are pretty full again, but i'll try to free some space
> 
> I meant the interrupt problem, because if that problem exists
> there doesn't seem to be a reasonable way to figure out what
> is the reason for the filesystem corruption.
> 
> > for the interupts
> > with test7-bk8  , acpi=off pci=noacpi &
> > hdparm  -m0 -d1 -X69  /dev/hd[a,e,g]
> > hdparm  -m16 -d1 -X69  /dev/hd[a,e,g]
> > i don't see timeouts
> > if i omit -m i do see them sometimes
> 
> Ok, so if I understood you correctly, the interrupt problem
> persists _only_ if you leave the multiple sector setting on
> its default setting ? If you explicitly disable it, or set
> it to maximum it works fine ? Does it work with any value ?

-m4 & -m8 seems to work OK
each time 3 runs of the dd test
1 to hda
2 to hde

TCQ  not activated


-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Geller Sandor]

On Sun, 19 Oct 2003, Tomi Orava wrote:

> I'd be really interested to hear if anyone has a working system
> with kernel included drivers & HPT374-controller integrated in
> motherboard and using PATA-drives ?

I have an Epox 8k5a3+ with 2 Maxtor drives (80GB) connected. It't running
fine, from 2.4.18-ac* kernels (currently 2.4.23-pre7-pac2). I haven't seen
any problems, the disks are mirrored (md driver), ext3, reiserfs, xfs and jfs
filesystems are on the disks. (I have very bad experiences with HTP372 and
80GB Maxtor drives)

  Geller Sandor <wildy@petra.hos.u-szeged.hu>

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> 
> Svetoslav Slavtchev wrote:
> 
> >>On Sun, Oct 19 2003, Bartlomiej Zolnierkiewicz wrote:
> >>
> >>>Andre, thanks for helpful hint.
> >>>Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).
> >>>
> >>Well that's correct, but this looks more like an AS iosched bug :)
> >>
> >>>>You do not enable TCQ on highpoint without using the hosted polling
> >>>>
> >>timer.
> >>
> >>>>Oh and I have not added it, and so hit Bartlomiej up for the
> >>>>
> >>additions.
> >>
> >>For what? TCQ tests fine on a HPT370 here.
> >>
> >
> >cmdline : acpi=off pci=noacpi elevator=deadline
> >
> 
> Thanks, that would be good if you would test IDE TCQ problems with
> elevator=deadline. If it is working fine there, but you still get
> problems when using the default (AS) elevator then report them to me
> please.
> 

note taken :-)

svetljo

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Nick Piggin]

Svetoslav Slavtchev wrote:

>>On Sun, Oct 19 2003, Bartlomiej Zolnierkiewicz wrote:
>>
>>>Andre, thanks for helpful hint.
>>>Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).
>>>
>>Well that's correct, but this looks more like an AS iosched bug :)
>>
>>>>You do not enable TCQ on highpoint without using the hosted polling
>>>>
>>timer.
>>
>>>>Oh and I have not added it, and so hit Bartlomiej up for the
>>>>
>>additions.
>>
>>For what? TCQ tests fine on a HPT370 here.
>>
>
>cmdline : acpi=off pci=noacpi elevator=deadline
>

Thanks, that would be good if you would test IDE TCQ problems with
elevator=deadline. If it is working fine there, but you still get
problems when using the default (AS) elevator then report them to me
please.

Re: HighPoint 374

[Svetoslav Slavtchev]

> On Sun, Oct 19 2003, Bartlomiej Zolnierkiewicz wrote:
> > 
> > Andre, thanks for helpful hint.
> > Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).
> 
> Well that's correct, but this looks more like an AS iosched bug :)
> > > You do not enable TCQ on highpoint without using the hosted polling
> timer.
> > > Oh and I have not added it, and so hit Bartlomiej up for the
> additions.
> 
> For what? TCQ tests fine on a HPT370 here.

cmdline : acpi=off pci=noacpi elevator=deadline

hdparm  -d1 -X69 -Q32 /dev/hd[a,e,g]
---------------------------------------------------------------------
blk: queue f7dd2e00, I/O limit 4095Mb (mask 0xffffffff)
hda: tagged command queueing enabled, command queue depth 32
blk: queue f7dd2400, I/O limit 4095Mb (mask 0xffffffff)
ide_dmaq_intr: stat=40, not expected
ide_dmaq_intr: stat=40, not expected
hde: tagged command queueing enabled, command queue depth 32
ide_dmaq_intr: stat=40, not expected
hdg: set_drive_speed_status: status=0x58 { DriveReady SeekComplete
DataRequest }
blk: queue f7dcce00, I/O limit 4095Mb (mask 0xffffffff)
hdg: dma_timer_expiry: dma status == 0x20
hdg: DMA timeout retry
hdg: timeout waiting for DMA
hdg: status error: status=0x58 { DriveReady SeekComplete DataRequest }

hdg: drive not ready for command
hdg: tagged command queueing enabled, command queue depth 32
ide_dmaq_intr: hdg: error status ff
hdg: ide_dmaq_complete: status=0xff { Busy }
hdg: invalidating tag queue (1 commands)
hdg: ide_intr: huh? expected NULL handler on exit
hdg: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdg: drive_cmd: error=0x04 { DriveStatusError }
hdg: set_drive_speed_status: status=0xff { Busy }
ide_tcq_intr_timeout: timeout waiting for completion interrupt
hdg: invalidating tag queue (0 commands)
hdg: status error: status=0x58 { DriveReady SeekComplete DataRequest }

hdg: drive not ready for command
hdg: status error: status=0x58 { DriveReady SeekComplete DataRequest }

hdg: drive not ready for command
hdg: CHECK for good STATUS
ide_dmaq_intr: hde: error status ff
hde: ide_dmaq_complete: status=0xff { Busy }
hde: invalidating tag queue (1 commands)
hde: ide_intr: huh? expected NULL handler on exit
hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hde: drive_cmd: error=0x04 { DriveStatusError
}
--------------------------------------------------------------------------------------

hdparm  -m16 -d1 -X69 -Q32
/dev/hd[a,e,g]
--------------------------------------------------------------------------------------
blk: queue f7dd2e00, I/O limit 4095Mb (mask 0xffffffff)
blk: queue f7dd2400, I/O limit 4095Mb (mask 0xffffffff)
hde: tagged command queueing enabled, command queue depth 32
blk: queue f7dcce00, I/O limit 4095Mb (mask 0xffffffff)
hdg: tagged command queueing enabled, command queue depth 32
ide_dmaq_intr: hdg: error status ff
hdg: ide_dmaq_complete: status=0xff { Busy }
hdg: invalidating tag queue (1 commands)
hdg: ide_intr: huh? expected NULL handler on exit
hdg: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdg: drive_cmd: error=0x04 { DriveStatusError
}
--------------------------------------------------------------------------------------

hdparm  -m0 -d1 -X69 -Q32
/dev/hd[a,e,g]
--------------------------------------------------------------------------------------
blk: queue f7dd2e00, I/O limit 4095Mb (mask 0xffffffff)
blk: queue f7dd2400, I/O limit 4095Mb (mask 0xffffffff)
blk: queue f7dcce00, I/O limit 4095Mb (mask 0xffffffff)
hdg: tagged command queueing enabled, command queue depth 32
ide_dmaq_intr: hdg: error status ff
hdg: ide_dmaq_complete: status=0xff { Busy }
hdg: invalidating tag queue (1 commands)
hdg: ide_intr: huh? expected NULL handler on exit
hdg: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdg: drive_cmd: error=0x04 { DriveStatusError
}
-------------------------------------------------------------------------------------

upto now no transfer to the drives, except to the root partition(system
activity) which is on hdg

dd if=/dev/zero of=/mnt/tmp/1/10Gb.zeros bs=512k count=20000
[/dev/hde]
------------------------------------------------------------------------------
ide_dmaq_intr: hde: error status ff
hde: ide_dmaq_complete: status=0xff { Busy }
hde: invalidating tag queue (1 commands)
hde: ide_intr: huh? expected NULL handler on exit
hde: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hde: drive_cmd: error=0x04 { DriveStatusError }

and a bit later

ide_dmaq_intr: hda: error status ff
hda: ide_dmaq_complete: status=0xff { Busy }
hda: invalidating tag queue (1 commands)
hda: ide_intr: huh? expected NULL handler on exit
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { DriveStatusError }

only /boot ~ 90Mb was mounted on hda and i don't think the system accessed
it

on second thoght i also have a swap partition on it,
but i have currently 1.9Mb swap used


svetljo

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Tomi Orava]

>> Are you capable of trying if the hdparm -m0 trick
>> works for you ?
>
> you mean the fs corruption on soft raid or the interupts problem ?
> i dumped the raid setup as i couldn't find a way to debug it
> and my drives are pretty full again, but i'll try to free some space

I meant the interrupt problem, because if that problem exists
there doesn't seem to be a reasonable way to figure out what
is the reason for the filesystem corruption.

> for the interupts
> with test7-bk8  , acpi=off pci=noacpi &
> hdparm  -m0 -d1 -X69  /dev/hd[a,e,g]
> hdparm  -m16 -d1 -X69  /dev/hd[a,e,g]
> i don't see timeouts
> if i omit -m i do see them sometimes

Ok, so if I understood you correctly, the interrupt problem
persists _only_ if you leave the multiple sector setting on
its default setting ? If you explicitly disable it, or set
it to maximum it works fine ? Does it work with any value ?

> (i see them both with -m and without -m if i try to use TCQ )

I'd really like to see the stable series working properly
before jumping into the 2.6-series test kernels ... Although,
I'm still wondering how come TCQ is known to work with 370-chip
as Jens said, but not with 374-chip ...

Regards,
Tomi Orava

-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> >> Yep, but it cannot be strictly via-chipset issue
> >> as I have verified that the same problem exists
> >> with Epox 4PCA3+ motherboard, which is P4 & Intel 875P
> >> based.
> >
> > may be epox got broken HPT's ?
> > anyone with mainboard from other vendor seeing this problems ?
> 
> This whole thread was opened by a person with HPT rocketraid 404
> PCI-card ...
> 
> >
> > my HPT BIOS is v1.24
> > mainboard BIOS last updated in september i think
> 
> I think I have exactly the same HPT-bios version.
> The mb's bios is anyway dated 2003-03-07 so I think
> we have the same version. Unfortunately, I'm unable
> to check the bios version of the 875P-base mb for now
> (but I think it was the same 1.24 as well).
> 
> Are you capable of trying if the hdparm -m0 trick
> works for you ?

you mean the fs corruption on soft raid or the interupts problem ?
i dumped the raid setup as i couldn't find a way to debug it
and my drives are pretty full again, but i'll try to free some space

for the interupts 
with test7-bk8  , acpi=off pci=noacpi &
hdparm  -m0 -d1 -X69  /dev/hd[a,e,g]
hdparm  -m16 -d1 -X69  /dev/hd[a,e,g]
i don't see timeouts
if i omit -m i do see them sometimes

(i see them both with -m and without -m if i try to use TCQ )

for testing copied several 6-10Gb directories &
dd if=/dev/zero of=/mnt/tmp/1/10Gb.zeros bs=512k count=21000
or
dd if=/dev/zero of=/mnt/tmp/1/10Gb.zeros bs=1024k count=10000

svetljo


-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Tomi Orava]

> On Sun, Oct 19 2003, Bartlomiej Zolnierkiewicz wrote:
>>
>> Andre, thanks for helpful hint.
>> Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).
>
> Well that's correct, but this looks more like an AS iosched bug :)

Pardon my ignorance, but what is this AS iosched ?

>> > You do not enable TCQ on highpoint without using the hosted polling
>> timer.
>> > Oh and I have not added it, and so hit Bartlomiej up for the
>> additions.
>
> For what? TCQ tests fine on a HPT370 here.

I'm not entirely sure if that proves something or not,
as the whole (interrupt & hang) problem seems to exist
only with HPT374 and not with any other version of the chip anyway.
I do personally have one mb with a 372-chip and it has always
worked just fine with this same driver (perhaps its harder
to detect the problem with only two disks?).

Regards,
Tomi Orava

Re: HighPoint 374

[Jens Axboe]

On Sun, Oct 19 2003, Bartlomiej Zolnierkiewicz wrote:
> 
> Andre, thanks for helpful hint.
> Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).

Well that's correct, but this looks more like an AS iosched bug :)

> > You do not enable TCQ on highpoint without using the hosted polling timer.
> > Oh and I have not added it, and so hit Bartlomiej up for the additions.

For what? TCQ tests fine on a HPT370 here.

-- 
Jens Axboe

Re: HighPoint 374

[Tomi Orava]

>> Yep, but it cannot be strictly via-chipset issue
>> as I have verified that the same problem exists
>> with Epox 4PCA3+ motherboard, which is P4 & Intel 875P
>> based.
>
> may be epox got broken HPT's ?
> anyone with mainboard from other vendor seeing this problems ?

This whole thread was opened by a person with HPT rocketraid 404
PCI-card ...

>
> my HPT BIOS is v1.24
> mainboard BIOS last updated in september i think

I think I have exactly the same HPT-bios version.
The mb's bios is anyway dated 2003-03-07 so I think
we have the same version. Unfortunately, I'm unable
to check the bios version of the 875P-base mb for now
(but I think it was the same 1.24 as well).

Are you capable of trying if the hdparm -m0 trick
works for you ?

Regards,
Tomi Orava

-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> > i have the same problems with epox 8k9a3+,
> > and may be even strange ones
> > (like fs coruption when soft raid & / or lvm is used)
> 
> I've seen the filesystem corruption with ext3 & xfs
> and RAID1 (md) as well. However, I don't seem to
> be able to get that far nowadays, as the machine
> is being used as NFS-server and thefore there is
> always "too much" disk-transfers going on and an
> IDE-system hang happens quite soon after boot.
> (it seems that my raid-disks get out of sync every time
> I switch from proprietary driver --> kernel driver
> and so it might be the raid resync that hangs the system).
> 
> > and i never had the problems with 8k5a3+,
> > the drives were actually taken from the 8k5a3+
> > when it died (me silly tried to update to XP2700)
> >
> > really strange, isn't it
> >
> > both boards should be the same, except
> > 8k5a3+ uses kt333
> > 8k9a3+ uses kt400
> 
> Yep, but it cannot be strictly via-chipset issue
> as I have verified that the same problem exists
> with Epox 4PCA3+ motherboard, which is P4 & Intel 875P
> based.

may be epox got broken HPT's ?
anyone with mainboard from other vendor seeing this problems ?

my HPT BIOS is v1.24
mainboard BIOS last updated in september i think

svetljo

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> > i have the same problems with epox 8k9a3+,
> > and may be even strange ones
> > (like fs coruption when soft raid & / or lvm is used)
> 
> I've seen the filesystem corruption with ext3 & xfs
> and RAID1 (md) as well. However, I don't seem to
> be able to get that far nowadays, as the machine
> is being used as NFS-server and thefore there is
> always "too much" disk-transfers going on and an
> IDE-system hang happens quite soon after boot.
> (it seems that my raid-disks get out of sync every time
> I switch from proprietary driver --> kernel driver
> and so it might be the raid resync that hangs the system).

i tested xfs/reiserfs & may be ext2 & jfs
both on plain(and with lvm over md)  soft raid 0/1/5
never tried the closed source drivers

> > and i never had the problems with 8k5a3+,
> > the drives were actually taken from the 8k5a3+
> > when it died (me silly tried to update to XP2700)
> >
> > really strange, isn't it
> >
> > both boards should be the same, except
> > 8k5a3+ uses kt333
> > 8k9a3+ uses kt400
> 
> Yep, but it cannot be strictly via-chipset issue
> as I have verified that the same problem exists
> with Epox 4PCA3+ motherboard, which is P4 & Intel 875P
> based.

may be a certain HPT BIOS version ?

i'll reboot to check what's here 

svetljo

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Tomi Orava]

> i have the same problems with epox 8k9a3+,
> and may be even strange ones
> (like fs coruption when soft raid & / or lvm is used)

I've seen the filesystem corruption with ext3 & xfs
and RAID1 (md) as well. However, I don't seem to
be able to get that far nowadays, as the machine
is being used as NFS-server and thefore there is
always "too much" disk-transfers going on and an
IDE-system hang happens quite soon after boot.
(it seems that my raid-disks get out of sync every time
I switch from proprietary driver --> kernel driver
and so it might be the raid resync that hangs the system).

> and i never had the problems with 8k5a3+,
> the drives were actually taken from the 8k5a3+
> when it died (me silly tried to update to XP2700)
>
> really strange, isn't it
>
> both boards should be the same, except
> 8k5a3+ uses kt333
> 8k9a3+ uses kt400

Yep, but it cannot be strictly via-chipset issue
as I have verified that the same problem exists
with Epox 4PCA3+ motherboard, which is P4 & Intel 875P
based.

Re: HighPoint 374

[Joel Smith]

> I get a "no such device" when I try to load the driver, what card exactly do
> you have and how do you load the driver? Any special parameter?

I don't use modules for stuff like this.  Have you tried compiling it
into the kernel?

Joel Smith

Re: HighPoint 374

[Joel Smith]

> > In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
> > "experimental" IDE Raid with two disks on a HPT 374 controller with the
> > drivers that come with the kernel.
> 
> I have tried these versions in the past as well without success.
> However, I don't use HPT-raid features at all ie. I'm using the
> disks as JBOD. What hardware do you have and have you enabled
> ACPI/local-apic/io-apic ? What brand & model of disk-drives you
> are using with HPT374 controller ? And finally what does
> the /proc/interrupts show for you ?

The disks are both 80 GB Western Digital 7200RPM/8 MB cache (WD800JB). 
FWIW, the motherboard is an Abit IT7-Max 2 v. 2.0, and I'm currently
using 2.4.22-ck2.  The HPT374 chip is on the motherboard.  I don't have
any ACPI stuff enabled, and I'm not sure what apic is.

Here's my /proc/interrupts:

           CPU0
  0:  490407020          XT-PIC  timer
  1:     160679          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:          0          XT-PIC  usb-uhci
  5:   31664356          XT-PIC  eth1, Intel 82801DB-ICH4
  7:   35088687          XT-PIC  usb-uhci, nvidia
  9:          0          XT-PIC  usb-uhci
 11:    1895235          XT-PIC  ide2, ide3
 12:    4340909          XT-PIC  PS/2 Mouse
 15:     117429          XT-PIC  ide1
NMI:          0
ERR:          0

HTH,

Joel Smith

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> Andre, thanks for helpful hint.
> Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).

j don't really care about TCQ that much anymore
(i bought the drives because they were marked as supported)

but the fs corruption when md/lvm is used,
and the dma timeouts ;( 

svetljo
 
> On Sunday 19 of October 2003 22:30, Andre Hedrick wrote:
> > You do not enable TCQ on highpoint without using the hosted polling
> timer.
> > Oh and I have not added it, and so hit Bartlomiej up for the additions.
> >
> > Andre Hedrick
> > LAD Storage Consulting Group
> >
> > On Sun, 19 Oct 2003, Svetoslav Slavtchev wrote:
> > > i have the same problems with epox 8k9a3+,
> > > and may be even strange ones
> > > (like fs coruption when soft raid & / or lvm is used)
> > >
> > > and i never had the problems with 8k5a3+,
> > > the drives were actually taken from the 8k5a3+
> > > when it died (me silly tried to update to XP2700)
> > >
> > > really strange, isn't it
> > >
> > > both boards should be the same, except
> > > 8k5a3+ uses kt333
> > > 8k9a3+ uses kt400
> > >
> > > only mainboard change -> hell of a lot unresolved problems
> > >
> > >
> > > svetljo
> > > kernels used 2.4.21-2.4.23-pre3 2.6.0-test3-test7bk8
> > >
> > > and a nice log when i try to enable TCQ
> > >
> > > all Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>]
> > > [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> > > Badness in as_remove_dispatched_request at
> > > drivers/block/as-iosched.c:1022 Call Trace: [<c0235ee3>]  [<c022e834>]
> 
> > > [<c025b0ef>]  [<c026e0ed>] [<c025c7e2>]  [<c026e080>]  [<c010df03>] 
> > > [<c010e233>]  [<c010c7d8>] Badness in as_remove_dispatched_request at
> > > drivers/block/as-iosched.c:1022 Call Trace: [<c0235ee3>]  [<c022e834>]
> 
> > > [<c025b0ef>]  [<c026e0ed>] [<c025c7e2>]  [<c026e080>]  [<c010df03>] 
> > > [<c010e233>]  [<c010c7d8>] Badness in as_remove_dispatched_request at
> > > drivers/block/as-iosched.c:1022 Call Trace: [<c0235ee3>]  [<c022e834>]
> 
> > > [<c025b0ef>]  [<c026e0ed>] [<c025c7e2>]  [<c026e080>]  [<c010df03>] 
> > > [<c010e233>]  [<c010c7d8>]
> 

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Bartlomiej Zolnierkiewicz]

Andre, thanks for helpful hint.
Svetoslav, the right person to whine about TCQ stuff is Jens Axboe 8-).

--bartlomiej

On Sunday 19 of October 2003 22:30, Andre Hedrick wrote:
> You do not enable TCQ on highpoint without using the hosted polling timer.
> Oh and I have not added it, and so hit Bartlomiej up for the additions.
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> On Sun, 19 Oct 2003, Svetoslav Slavtchev wrote:
> > i have the same problems with epox 8k9a3+,
> > and may be even strange ones
> > (like fs coruption when soft raid & / or lvm is used)
> >
> > and i never had the problems with 8k5a3+,
> > the drives were actually taken from the 8k5a3+
> > when it died (me silly tried to update to XP2700)
> >
> > really strange, isn't it
> >
> > both boards should be the same, except
> > 8k5a3+ uses kt333
> > 8k9a3+ uses kt400
> >
> > only mainboard change -> hell of a lot unresolved problems
> >
> >
> > svetljo
> > kernels used 2.4.21-2.4.23-pre3 2.6.0-test3-test7bk8
> >
> > and a nice log when i try to enable TCQ
> >
> > all Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>]
> > [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> > Badness in as_remove_dispatched_request at
> > drivers/block/as-iosched.c:1022 Call Trace: [<c0235ee3>]  [<c022e834>] 
> > [<c025b0ef>]  [<c026e0ed>] [<c025c7e2>]  [<c026e080>]  [<c010df03>] 
> > [<c010e233>]  [<c010c7d8>] Badness in as_remove_dispatched_request at
> > drivers/block/as-iosched.c:1022 Call Trace: [<c0235ee3>]  [<c022e834>] 
> > [<c025b0ef>]  [<c026e0ed>] [<c025c7e2>]  [<c026e080>]  [<c010df03>] 
> > [<c010e233>]  [<c010c7d8>] Badness in as_remove_dispatched_request at
> > drivers/block/as-iosched.c:1022 Call Trace: [<c0235ee3>]  [<c022e834>] 
> > [<c025b0ef>]  [<c026e0ed>] [<c025c7e2>]  [<c026e080>]  [<c010df03>] 
> > [<c010e233>]  [<c010c7d8>]

Re: HighPoint 374

[Svetoslav Slavtchev]

> 
> You do not enable TCQ on highpoint without using the hosted polling timer.
> Oh and I have not added it, and so hit Bartlomiej up for the additions.

good info :-)

but it sometimes seems to enable it

the 4 drives are identical,
and the drive failing is almost always different

and this doesn't explain the md/ lvm corupption,
even when TCQ is not enabled both in 2.4 and 2.5
 
/dev/hda:

ATA device, with non-removable media
powers-up in standby; SET FEATURES subcmd spins-up.
        Model Number:       IC35L080AVVA07-0
        Serial Number:      VNC402A4CVHNEA
        Firmware Revision:  VA4OA52A
Standards:
        Used: ATA/ATAPI-5 T13 1321D revision 1
        Supported: 5 4 3 2 & some of 6
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  160836480
        device size with M = 1024*1024:       78533 MBytes
        device size with M = 1000*1000:       82348 MBytes (82 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        bytes avail on r/w long: 52     Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 0
        Advanced power management level: unknown setting (0x0000)
        Recommended acoustic management value: 128, current value: 254
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    NOP cmd
           *    READ BUFFER cmd
           *    WRITE BUFFER cmd
           *    Host Protected Area feature set
                Release interrupt
           *    Look-ahead
           *    Write cache
           *    Power Management feature set
                Security Mode feature set
           *    SMART feature set
           *    Mandatory FLUSH CACHE command
           *    Device Configuration Overlay feature set
.................................................................
           *    READ/WRITE DMA QUEUED
...................................................................

> > i have the same problems with epox 8k9a3+,
> > and may be even strange ones
> > (like fs coruption when soft raid & / or lvm is used)
> > 
> > and i never had the problems with 8k5a3+,
> > the drives were actually taken from the 8k5a3+
> > when it died (me silly tried to update to XP2700)
> > 
> > really strange, isn't it
> > 
> > both boards should be the same, except
> > 8k5a3+ uses kt333
> > 8k9a3+ uses kt400
> > 
> > only mainboard change -> hell of a lot unresolved problems
> > 
> > 
> > svetljo
> > kernels used 2.4.21-2.4.23-pre3 2.6.0-test3-test7bk8
> > 
> > and a nice log when i try to enable TCQ
> > 
> > all Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> > [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> > Badness in as_remove_dispatched_request at
> drivers/block/as-iosched.c:102
> 2
> > Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> > [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> > Badness in as_remove_dispatched_request at
> drivers/block/as-iosched.c:102
> 2
> > Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> > [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> > Badness in as_remove_dispatched_request at
> drivers/block/as-iosched.c:102
> 2
> > Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> > [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> > 
> > 
> > -- 
> > NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> > Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
> > 
> > Jetzt kostenlos anmelden unter http://www.gmx.net
> > 
> > +++ GMX - die erste Adresse für Mail, Message, More! +++
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> i
> n
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 

-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Andre Hedrick]

You do not enable TCQ on highpoint without using the hosted polling timer.
Oh and I have not added it, and so hit Bartlomiej up for the additions.

Andre Hedrick
LAD Storage Consulting Group

On Sun, 19 Oct 2003, Svetoslav Slavtchev wrote:

> i have the same problems with epox 8k9a3+,
> and may be even strange ones
> (like fs coruption when soft raid & / or lvm is used)
> 
> and i never had the problems with 8k5a3+,
> the drives were actually taken from the 8k5a3+
> when it died (me silly tried to update to XP2700)
> 
> really strange, isn't it
> 
> both boards should be the same, except
> 8k5a3+ uses kt333
> 8k9a3+ uses kt400
> 
> only mainboard change -> hell of a lot unresolved problems
> 
> 
> svetljo
> kernels used 2.4.21-2.4.23-pre3 2.6.0-test3-test7bk8
> 
> and a nice log when i try to enable TCQ
> 
> all Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> Badness in as_remove_dispatched_request at drivers/block/as-iosched.c:1022
> Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> Badness in as_remove_dispatched_request at drivers/block/as-iosched.c:1022
> Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> Badness in as_remove_dispatched_request at drivers/block/as-iosched.c:1022
> Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
> [<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
> 
> 
> -- 
> NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService
> 
> Jetzt kostenlos anmelden unter http://www.gmx.net
> 
> +++ GMX - die erste Adresse für Mail, Message, More! +++
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: HighPoint 374

[Carlos Fernandez Sanz]

Tomi,

Copied one large DVD image from one to drive to another a couple of times,
no problems whatsoever. Compared the file each time, everything looks good.

As for the email, it's not my ISP gateway but mine personally. By blocking
the entire Telefonica IP pool you are denying access to a huge userbase, as
Telefonica is, in the end, the ISP for almost everyone here. But well, it's
your decision :-)

----- Original Message ----- 
From: "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi>
To: "Carlos Fernandez Sanz" <cfs-lk@nisupu.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Sunday, October 19, 2003 21:39
Subject: Re: HighPoint 374


>
> > Tomy,
> >
> > The
> >
> > hdparm -m0 device
> >
> > seems to have fixed the problem for me. I'll try increasing the number
in
> > the following days and run extensive tests, but for now, it's quite
> > enough.
>
> That is *very* interesting. I quess that's about the only hdparm
> option that I have never tried before. I'm really interested in hearing
> if that really fixes the problem for you and for good. The thing is
> that the machine with HPT374-chip is running as a server so I'm
> not very eager to use it as a test bed (unless it's absolutely necessary).
> Please, if it's possible for you, try to copy say two big files from
> one disk to another at the same time couple of times in order to see if
> your machine is able to handle it ... I have been able to run mine
> 2-3 days in the past without any problems if there are _no_ major
> disk transfers going on.
>
> The question of course is why does that hdparm option seem to fix
> the problem in this case ? Is it perhaps a bug in HPT374-driver or
> some lower IDE-layer ? (Just quessing ...)
>
> > BTW your email server doesn't seem to like my address and refuses to
> > deliver
> > any mail, if you aren't running it maybe you should tell the admin that
> > he's
> > blocking Spain's largest ISP for some reason?
>
> I'm sorry, I don't accept mails coming from dsl/cable/modem-pools due to
> high amount of spam. I will accept mails coming from your ISP's mail
> gateway though.
>
> Regards,
> Tomi Orava
>
>
> -- 
> Tomi.Orava@ncircle.nullnet.fi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

HighPoint 374

[Svetoslav Slavtchev]

i have the same problems with epox 8k9a3+,
and may be even strange ones
(like fs coruption when soft raid & / or lvm is used)

and i never had the problems with 8k5a3+,
the drives were actually taken from the 8k5a3+
when it died (me silly tried to update to XP2700)

really strange, isn't it

both boards should be the same, except
8k5a3+ uses kt333
8k9a3+ uses kt400

only mainboard change -> hell of a lot unresolved problems


svetljo
kernels used 2.4.21-2.4.23-pre3 2.6.0-test3-test7bk8

and a nice log when i try to enable TCQ

all Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
[<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
Badness in as_remove_dispatched_request at drivers/block/as-iosched.c:1022
Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
[<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
Badness in as_remove_dispatched_request at drivers/block/as-iosched.c:1022
Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
[<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]
Badness in as_remove_dispatched_request at drivers/block/as-iosched.c:1022
Call Trace: [<c0235ee3>]  [<c022e834>]  [<c025b0ef>]  [<c026e0ed>] 
[<c025c7e2>]  [<c026e080>]  [<c010df03>]  [<c010e233>]  [<c010c7d8>]


-- 
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Re: HighPoint 374

[Tomi Orava]

>>There really must be some explanation why some of us are
>>having really huge problems with HPT374-contollers while for
>>others it's working just fine. I haven't exactly heard anyone
>>been too succesfull for example with Epox 8K9A3+ motherboard
>>even on this mailing-list based on previous questions seen here.
>
> well, it's not an Epox 8k9a3+ here, but an 8k5a3+ with two HPT374 onboard
> and it is working well with recent 2.6.0-test* kernels.
> I also just use JBOD - only one disk connected as /dev/hde to the first
> HPT 374,
> an IBM-DTLA-305040, and I really don't see any probs here.

Ok, this is good to know. Have you ever tried 2.4 based kernels with
that motherboard ? Also, have you ever tried running multiple
drives with that controller ? Somehow I still have this feeling
that with only one disk connected to a HPT374-controller it might
work without problems, while with multiple disks it becomes
unstable (this is the case with a a friends Epox 4PCA3+
based machine in addition to my two machines).

Can you perhaps send me off-the-list your .config and output of
/proc/interrupts so that I could compare those to mine ?

Regards,
Tomi Orava

Re: HighPoint 374

[David B. Stevens]

Tomi,

I also copied you in my email to Carlos.  But my email got bounced.

You might be interested in the problems with Seagate 120 GB drive thread.

Multiple controllers and hard drive mentioned.

Cheers,
   Dave

Re: HighPoint 374

[Christian Guggenberger]

>>
>>> What's the current status of HPT 374 support? Is it working in any
>>> kernel
>>> version?
>>
>> In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
>> "experimental" IDE Raid with two disks on a HPT 374 controller with the
>> drivers that come with the kernel.
>
>I have tried these versions in the past as well without success.
>However, I don't use HPT-raid features at all ie. I'm using the
>disks as JBOD. What hardware do you have and have you enabled
>ACPI/local-apic/io-apic ? What brand & model of disk-drives you
>are using with HPT374 controller ? And finally what does
>the /proc/interrupts show for you ?
>
>There really must be some explanation why some of us are
>having really huge problems with HPT374-contollers while for
>others it's working just fine. I haven't exactly heard anyone
>been too succesfull for example with Epox 8K9A3+ motherboard
>even on this mailing-list based on previous questions seen here.

well, it's not an Epox 8k9a3+ here, but an 8k5a3+ with two HPT374 onboard
and it is working well with recent 2.6.0-test* kernels.
I also just use JBOD - only one disk connected as /dev/hde to the first HPT 374, 
an IBM-DTLA-305040, and I really don't see any probs here.

Christian

Re: HighPoint 374

[Måns Rullgård]

"Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi> writes:

>> I'm using a RocketRAID 1540 SATA card (hpt374 based) in an Alpha
>> system.  It has no such thing as ACPI.  The disks are four Seagate
>> Barracuda 7200.7 running software raid5.  My /proc/interrupts:
>
> Ok, that might be one reason why it's working for you but not for me.
> If I've understood correctly, people who have problems with HPT374
> are using the integrated Parallel-ATA interface instead of SATA.

The chip on the SATA controller is the same as the PATA version.  The
SATA interface is handled by external bridge chips.  I don't really
see how it would make any difference if the hpt374 is on a PCI board
on on the motherboard.  The Alpha system is quite different from your
average PC in some ways, though.  That could explain some differences.

-- 
Måns Rullgård
mru@users.sf.net

Re: HighPoint 374

[Tomi Orava]

> Tomy,
>
> The
>
> hdparm -m0 device
>
> seems to have fixed the problem for me. I'll try increasing the number in
> the following days and run extensive tests, but for now, it's quite
> enough.

That is *very* interesting. I quess that's about the only hdparm
option that I have never tried before. I'm really interested in hearing
if that really fixes the problem for you and for good. The thing is
that the machine with HPT374-chip is running as a server so I'm
not very eager to use it as a test bed (unless it's absolutely necessary).
Please, if it's possible for you, try to copy say two big files from
one disk to another at the same time couple of times in order to see if
your machine is able to handle it ... I have been able to run mine
2-3 days in the past without any problems if there are _no_ major
disk transfers going on.

The question of course is why does that hdparm option seem to fix
the problem in this case ? Is it perhaps a bug in HPT374-driver or
some lower IDE-layer ? (Just quessing ...)

> BTW your email server doesn't seem to like my address and refuses to
> deliver
> any mail, if you aren't running it maybe you should tell the admin that
> he's
> blocking Spain's largest ISP for some reason?

I'm sorry, I don't accept mails coming from dsl/cable/modem-pools due to
high amount of spam. I will accept mails coming from your ISP's mail
gateway though.

Regards,
Tomi Orava


-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Carlos Fernandez Sanz]

Tomi,

> Hmm, if I checked correctly, your motherboard (Asus CUSL2) doesn't seem to
> include a HPT374 based (integrated) IDE-controller. Are you using some
> add-on PCI-card for IDE ? If yes, are you using older style Parallel-ATA
> or newer Serial-ATA interface ?

I'm using HighPoint's RocketRaid 404 card (HPT374 based PCI card).

Re: HighPoint 374

[Tomi Orava]

>>
>> Very interesting. The other type of errors I have received (the last
>> time
>> with 2.4.23-pre4) were:
>>
>> Sep 14 14:29:49 alderan kernel: hde: set_drive_speed_status: status=0xff
>> {
>> Busy }
>> Sep 14 14:29:49 alderan kernel: blk: queue c0492188, I/O limit 4095Mb
>> (mask 0xffffffff)
>
> Same here.
>
>> Currently my disk-drivers are made by 2*samsung (SV8004H) and
>> 2*Samsung(SV1604N), in case that changes anything.
>
> I'm using two seagates (different models), one Samsung and one Maxtor,
> this happens in all 4.
> I'm not using any kind of RAID.

Hmm, if I checked correctly, your motherboard (Asus CUSL2) doesn't seem to
include a HPT374 based (integrated) IDE-controller. Are you using some
add-on PCI-card for IDE ? If yes, are you using older style Parallel-ATA
or newer Serial-ATA interface ?

>>
>> And have you tried with ACPI on/off and io-apic on/off ?
>
> No, to be honest I didn't even think of this. You think it could make a
> difference? Given the fact that the card works correctly with the HPT
> drivers, pretty much everything that does not relate directly to the IDE
> drivers seems ruled out as the cause...

Based on previous questions and answers on this list, those settings
might very well affect you, as they affect the way interrupts are handled
in your system. Unfortunately, they haven't fixed my problems no matter
what I combination I have tried.

Regards,
Tomi Orava

-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Carlos Fernandez Sanz]

Tomy,

The

hdparm -m0 device

seems to have fixed the problem for me. I'll try increasing the number in
the following days and run extensive tests, but for now, it's quite enough.

BTW your email server doesn't seem to like my address and refuses to deliver
any mail, if you aren't running it maybe you should tell the admin that he's
blocking Spain's largest ISP for some reason?


----- Original Message ----- 
From: "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi>
To: "Måns Rullgård" <mru@users.sourceforge.net>
Cc: <linux-kernel@vger.kernel.org>
Sent: Sunday, October 19, 2003 21:14
Subject: Re: HighPoint 374


>
> > "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi> writes:
> >
> >>> In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
> >>> "experimental" IDE Raid with two disks on a HPT 374 controller with
the
> >>> drivers that come with the kernel.
> >>
> >> I have tried these versions in the past as well without success.
> >> However, I don't use HPT-raid features at all ie. I'm using the
> >> disks as JBOD. What hardware do you have and have you enabled
> >> ACPI/local-apic/io-apic ? What brand & model of disk-drives you
> >> are using with HPT374 controller ? And finally what does
> >> the /proc/interrupts show for you ?
> >
> > I'm using a RocketRAID 1540 SATA card (hpt374 based) in an Alpha
> > system.  It has no such thing as ACPI.  The disks are four Seagate
> > Barracuda 7200.7 running software raid5.  My /proc/interrupts:
>
> Ok, that might be one reason why it's working for you but not for me.
> If I've understood correctly, people who have problems with HPT374
> are using the integrated Parallel-ATA interface instead of SATA.
>
> I'd be really interested to hear if anyone has a working system
> with kernel included drivers & HPT374-controller integrated in
> motherboard and using PATA-drives ?
>
> Regards,
> Tomi Orava
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: HighPoint 374

[Tomi Orava]

> "Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi> writes:
>
>>> In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
>>> "experimental" IDE Raid with two disks on a HPT 374 controller with the
>>> drivers that come with the kernel.
>>
>> I have tried these versions in the past as well without success.
>> However, I don't use HPT-raid features at all ie. I'm using the
>> disks as JBOD. What hardware do you have and have you enabled
>> ACPI/local-apic/io-apic ? What brand & model of disk-drives you
>> are using with HPT374 controller ? And finally what does
>> the /proc/interrupts show for you ?
>
> I'm using a RocketRAID 1540 SATA card (hpt374 based) in an Alpha
> system.  It has no such thing as ACPI.  The disks are four Seagate
> Barracuda 7200.7 running software raid5.  My /proc/interrupts:

Ok, that might be one reason why it's working for you but not for me.
If I've understood correctly, people who have problems with HPT374
are using the integrated Parallel-ATA interface instead of SATA.

I'd be really interested to hear if anyone has a working system
with kernel included drivers & HPT374-controller integrated in
motherboard and using PATA-drives ?

Regards,
Tomi Orava

Re: HighPoint 374

[Måns Rullgård]

"Tomi Orava" <Tomi.Orava@ncircle.nullnet.fi> writes:

>> In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
>> "experimental" IDE Raid with two disks on a HPT 374 controller with the
>> drivers that come with the kernel.
>
> I have tried these versions in the past as well without success.
> However, I don't use HPT-raid features at all ie. I'm using the
> disks as JBOD. What hardware do you have and have you enabled
> ACPI/local-apic/io-apic ? What brand & model of disk-drives you
> are using with HPT374 controller ? And finally what does
> the /proc/interrupts show for you ?

I'm using a RocketRAID 1540 SATA card (hpt374 based) in an Alpha
system.  It has no such thing as ACPI.  The disks are four Seagate
Barracuda 7200.7 running software raid5.  My /proc/interrupts:

  1:      11440          XT-PIC   keyboard
  2:          0          XT-PIC   cascade
  8:  179530685             RTC  +timer
 14:        198          XT-PIC  +ide0
 15:         11          XT-PIC  +ide1
 22:          0             SRM   timer-cascade
 24:          0             SRM   usb-ohci
 25:    2327086             SRM  +CMI8738-MC6
 26:    4198981             SRM   ide2,  ide3,  ide4,  ide5
 28:      92591             SRM   usb-ohci
 32:   21577855             SRM   ehci-hcd
ERR:          0

The hpt374 is on IRQ 26.

-- 
Måns Rullgård
mru@users.sf.net

Re: HighPoint 374

[Carlos Fernandez Sanz]

>
> Very interesting. The other type of errors I have received (the last time
> with 2.4.23-pre4) were:
>
> Sep 14 14:29:49 alderan kernel: hde: set_drive_speed_status: status=0xff {
> Busy }
> Sep 14 14:29:49 alderan kernel: blk: queue c0492188, I/O limit 4095Mb
> (mask 0xffffffff)

Same here.

> Currently my disk-drivers are made by 2*samsung (SV8004H) and
> 2*Samsung(SV1604N), in case that changes anything.

I'm using two seagates (different models), one Samsung and one Maxtor, this
happens in all 4.
I'm not using any kind of RAID.

>
> BTW. Have you noticed in what situation the lock up happens ?

If the filesystems are mounted read only it seems to run stable (even though
I do see those errors)....if I mount r/w, any write is likely to make the
system crash rather soon.

> What does /proc/interrupts show in your case ?

Using the HPT drivers:

           CPU0
  0:     118661          XT-PIC  timer
  1:         14          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:       2698          XT-PIC  eth1
  5:       1133          XT-PIC  hpt374
  7:          0          XT-PIC  usb-uhci
  8:          1          XT-PIC  rtc
  9:       1098          XT-PIC  usb-uhci, eth0
 12:         28          XT-PIC  PS/2 Mouse
 14:      69807          XT-PIC  ide0
 15:         54          XT-PIC  ide1
NMI:          0
ERR:          0

Using the regular kernel IDE drivers

           CPU0
  0:       9318          XT-PIC  timer
  1:         12          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:        151          XT-PIC  eth1
  5:        130          XT-PIC  ide2, ide3, ide4, ide5
  7:          0          XT-PIC  usb-uhci
  8:          1          XT-PIC  rtc
  9:        573          XT-PIC  usb-uhci, eth0
 12:         28          XT-PIC  PS/2 Mouse
 14:       9163          XT-PIC  ide0
 15:         54          XT-PIC  ide1
NMI:          0
ERR:          0

>
> And have you tried with ACPI on/off and io-apic on/off ?

No, to be honest I didn't even think of this. You think it could make a
difference? Given the fact that the card works correctly with the HPT
drivers, pretty much everything that does not relate directly to the IDE
drivers seems ruled out as the cause...

Re: HighPoint 374

[Carlos Fernandez Sanz]

I get a "no such device" when I try to load the driver, what card exactly do
you have and how do you load the driver? Any special parameter?

----- Original Message ----- 
From: "Joel Smith" <joelsmith17@comcast.net>
To: <linux-kernel@vger.kernel.org>
Sent: Sunday, October 19, 2003 17:59
Subject: Re: HighPoint 374


>
> > What's the current status of HPT 374 support? Is it working in any
kernel
> > version?
>
> In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
> "experimental" IDE Raid with two disks on a HPT 374 controller with the
> drivers that come with the kernel.
>
>
> Joel Smith
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: HighPoint 374

[Tomi Orava]

>
>> What's the current status of HPT 374 support? Is it working in any
>> kernel
>> version?
>
> In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
> "experimental" IDE Raid with two disks on a HPT 374 controller with the
> drivers that come with the kernel.

I have tried these versions in the past as well without success.
However, I don't use HPT-raid features at all ie. I'm using the
disks as JBOD. What hardware do you have and have you enabled
ACPI/local-apic/io-apic ? What brand & model of disk-drives you
are using with HPT374 controller ? And finally what does
the /proc/interrupts show for you ?

There really must be some explanation why some of us are
having really huge problems with HPT374-contollers while for
others it's working just fine. I haven't exactly heard anyone
been too succesfull for example with Epox 8K9A3+ motherboard
even on this mailing-list based on previous questions seen here.

Regards,
Tomi Orava

Re: HighPoint 374

[Tomi Orava]

>> I have tested the kernel hpt374 drivers with all possible kernel
>> configurations with and without ACPI/APM, local apic, io-apic and
>> they don't seem to change anything in my case. I just get the following
>> error message sooner or later and the whole system hangs.
>>
>> Sep 26 23:07:42 alderan kernel: blk: queue c0466908, I/O limit 4095Mb
>> (mask 0xffffffff)
>> Sep 26 23:07:42 alderan kernel: hde: dma_timer_expiry: dma status ==
>> 0x20
>> Sep 26 23:07:42 alderan kernel: hde: timeout waiting for DMA
>> Sep 26 23:07:42 alderan kernel: hde: timeout waiting for DMA
>
> This is the EXACT same things I see in my logs.

Very interesting. The other type of errors I have received (the last time
with 2.4.23-pre4) were:

Sep 14 14:29:49 alderan kernel: hde: set_drive_speed_status: status=0xff {
Busy }
Sep 14 14:29:49 alderan kernel: blk: queue c0492188, I/O limit 4095Mb
(mask 0xffffffff)
Sep 14 14:29:49 alderan kernel: hde: set_drive_speed_status: status=0xff {
Busy }
Sep 14 14:29:49 alderan kernel: hde: dma_timer_expiry: dma status == 0x21
Sep 14 14:29:49 alderan kernel: hde: error waiting for DMA
Sep 14 14:29:49 alderan kernel: hde: dma timeout retry: status=0x50 {
DriveReady SeekComplete }
Sep 14 14:29:49 alderan kernel:
Sep 14 14:29:49 alderan kernel: hdg: set_drive_speed_status: status=0xff {
Busy }
Sep 14 14:29:49 alderan kernel: blk: queue c04925dc, I/O limit 4095Mb
(mask 0xffffffff)
Sep 14 14:29:49 alderan kernel: hdg: dma_timer_expiry: dma status == 0x00
Sep 14 14:29:49 alderan kernel: hdg: timeout waiting for DMA
Sep 14 14:29:49 alderan kernel: hdg: timeout waiting for DMA
Sep 14 14:29:49 alderan kernel: hdg: (__ide_dma_test_irq) called while not
waiting
Sep 14 14:29:49 alderan kernel: blk: queue c0492a30, I/O limit 4095Mb
(mask 0xffffffff)
Sep 14 14:29:49 alderan kernel: hdk: set_drive_speed_status: status=0xff {
Busy }
Sep 14 14:29:49 alderan kernel: blk: queue c0492e84, I/O limit 4095Mb
(mask 0xffffffff)
Sep 14 14:29:49 alderan kernel: hdk: dma_timer_expiry: dma status == 0x01
Sep 14 14:29:49 alderan kernel: hdk: set_drive_speed_status: status=0xff {
Busy }
Sep 14 14:29:49 alderan kernel: hdk: error waiting for DMA
Sep 14 14:29:49 alderan kernel: hdk: dma timeout retry: status=0x50 {
DriveReady SeekComplete }


>>
>> It might be that my problems are somehow related to the motherboards
>> I've been using, as the first one is "Epox 8K9A3+ (Via KT400 chipset)"
>> while the another one is "Epox 4PCA3+ (Intel 875p chipset)". But they
>> are 100% reproduceble with multiple brands of disk-drives.
>
> Mine is an Asus CUSL2, Pentium III motherboard with 512 Mb.

Ok, so it doesn't sound that the fault is only with Epox mb's.
I sincerely hope that someone with more knowledge about ide-stuff
could figure out something to overcome this particular problem ...
Currently my disk-drivers are made by 2*samsung (SV8004H) and
2*Samsung(SV1604N), in case that changes anything.

BTW. Have you noticed in what situation the lock up happens ?
As all my drivers are mirrored in pairs (ie. Raid1) the system
might run stable for 2-3 days before a lockup unless there is
some heavy transfers going on. In case any of the mirrors required
syncing when bootingg up the system, the system will lockup immediately.

What does /proc/interrupts show in your case ?
Mine is:
/proc/interrupts:

           CPU0
  0:  138788842    IO-APIC-edge  timer
  1:     328481    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  8:   21357900    IO-APIC-edge  rtc
 14:      14205    IO-APIC-edge  ide0
 16:  104139080   IO-APIC-level  radeon@PCI:1:0:0
 17:  136188388   IO-APIC-level  ide2, ide3, hpt374
 19:   98331044   IO-APIC-level  eth0
 21:   70689058   IO-APIC-level  ehci_hcd, usb-uhci, usb-uhci, usb-uhci
 22:   10181857   IO-APIC-level  VIA8233
NMI:          0
LOC:  138780432
ERR:          0
MIS:     109612

And have you tried with ACPI on/off and io-apic on/off ?

Regards,
Tomi Orava

-- 
Tomi.Orava@ncircle.nullnet.fi

Re: HighPoint 374

[Carlos Fernandez Sanz]

> I have tested the kernel hpt374 drivers with all possible kernel
> configurations with and without ACPI/APM, local apic, io-apic and
> they don't seem to change anything in my case. I just get the following
> error message sooner or later and the whole system hangs.
> 
> Sep 26 23:07:42 alderan kernel: blk: queue c0466908, I/O limit 4095Mb
> (mask 0xffffffff)
> Sep 26 23:07:42 alderan kernel: hde: dma_timer_expiry: dma status == 0x20
> Sep 26 23:07:42 alderan kernel: hde: timeout waiting for DMA
> Sep 26 23:07:42 alderan kernel: hde: timeout waiting for DMA

This is the EXACT same things I see in my logs.
> 
> It might be that my problems are somehow related to the motherboards
> I've been using, as the first one is "Epox 8K9A3+ (Via KT400 chipset)"
> while the another one is "Epox 4PCA3+ (Intel 875p chipset)". But they
> are 100% reproduceble with multiple brands of disk-drives.

Mine is an Asus CUSL2, Pentium III motherboard with 512 Mb.

Re: HighPoint 374

[Joel Smith]

> What's the current status of HPT 374 support? Is it working in any kernel
> version?

In 2.4.21 and 2.4.22 it's working great for me.  I'm using the
"experimental" IDE Raid with two disks on a HPT 374 controller with the
drivers that come with the kernel.


Joel Smith

Re: HighPoint 374

[Tomi Orava]

> What's the current status of HPT 374 support? Is it working in any kernel
> version?

Unfortunately, in my experience the included kernel driver doesn't work
reliable at all with my hardware either. I have tried all possible
kernel versions up to and including 2.4.23-pre5 without success.

> I know HP provides binaries, but that's no good, I need to use other
> kernel
> builds.

The Highpoint proprietary drivers work fine in my case as well, but
I'm not too happy about the fact that I simply can't access the
SMART stats of my drivers at all for example.

>
> 2.4.20-8 detects the card and provides the devices but data corruptions
> happens all the time. Using the HP drivers everything works fine (note

I have tested the kernel hpt374 drivers with all possible kernel
configurations with and without ACPI/APM, local apic, io-apic and
they don't seem to change anything in my case. I just get the following
error message sooner or later and the whole system hangs.

Sep 26 23:07:42 alderan kernel: blk: queue c0466908, I/O limit 4095Mb
(mask 0xffffffff)
Sep 26 23:07:42 alderan kernel: hde: dma_timer_expiry: dma status == 0x20
Sep 26 23:07:42 alderan kernel: hde: timeout waiting for DMA
Sep 26 23:07:42 alderan kernel: hde: timeout waiting for DMA
Sep 26 23:07:42 alderan kernel: blk: queue c0466d5c, I/O limit 4095Mb
(mask 0xffffffff)
Sep 26 23:07:42 alderan kernel: hdg: dma_timer_expiry: dma status == 0x20
Sep 26 23:07:42 alderan kernel: hdg: timeout waiting for DMA
Sep 26 23:07:42 alderan kernel: hdg: timeout waiting for DMA

It might be that my problems are somehow related to the motherboards
I've been using, as the first one is "Epox 8K9A3+ (Via KT400 chipset)"
while the another one is "Epox 4PCA3+ (Intel 875p chipset)". But they
are 100% reproduceble with multiple brands of disk-drives.

Regards,
Tomi Orava

Re: HighPoint 374

[Måns Rullgård]

"Carlos Fernandez Sanz" <cfs-lk@nisupu.com> writes:

> What's the current status of HPT 374 support? Is it working in any kernel
> version?

Works fine with 2.4.21 and 2.6.0-testX, at least.  I guess 2.4.22
should work too, but I haven't tried it.

-- 
Måns Rullgård
mru@users.sf.net

HighPoint 374

[Carlos Fernandez Sanz]

What's the current status of HPT 374 support? Is it working in any kernel
version?

I know HP provides binaries, but that's no good, I need to use other kernel
builds.

2.4.20-8 detects the card and provides the devices but data corruptions
happens all the time. Using the HP drivers everything works fine (note that
access is via /dev/sd* instead of /dev/hd*)...except that I can't replace
the kernel.

Thanks.