Very Computer

I'm not sure if there's a solution to this problem (after looking for
a while on the kernel mailing list), but here is my problem.

When I do heavy IO operations across two hard drives on the HPT366,
each on their own channel and set to primary, I get a lockup.  An
example of such operation, would be cp -a /home /other_drive
(home is a partition on the first drive, other_drive is a partition on
the other drive).  Both drives have DMA enabled, for performance
reasons.  This is the message it gives me:

hdg: timeout waiting for dma
ide_dmaproc: chipset supported ide_dma_timeout func only

Keyboard is locked up, and can't do anything.  Any ideas on what I
should do?  This occurs in both the 2.2.* series with the ide backpatch
and the 2.4.0test series as well.

Johnny Luong

Quote:>I'm not sure if there's a solution to this problem (after looking for
>a while on the kernel mailing list), but here is my problem.

>When I do heavy IO operations across two hard drives on the HPT366,
>each on their own channel and set to primary, I get a lockup.
>hdg: timeout waiting for dma
>ide_dmaproc: chipset supported ide_dma_timeout func only

Are you using any hdparm parameters that may cause the problem? Not all
drives are really comfortable with certain combinations of optimizations.
It may help locate the error if you could post the output from "hdparm -i
/dev/hdx" and "hdparm /dev/hdx" for the drives in question. The relevant
lines from "dmesg" would also be a good idea.

--
Kenneth R?rvik         91841353/22950312

0875 OSLO               home.no.net/stasis

Here is the relevant portions (at least in my mind) upon bootup....
HPT366: onboard version of chipset, pin1=1 pin2=2
HPT366: IDE controller on PCI bus 00 dev 98
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xe000-0xe007, BIOS settings: hde:pio, hdf:pio
HPT366: IDE controller on PCI bus 00 dev 99
HPT366: chipset revision 1
HPT366: not 100% native mode: will probe irqs later
    ide3: BM-DMA at 0xec00-0xec07, BIOS settings: hdg:pio, hdh:pio
hda: BCD-48SB CD-ROM, ATAPI CDROM drive
hde: WDC AC418000D, ATA DISK drive
hdg: IBM-DTLA-307030, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0xd800-0xd807,0xdc02 on irq 18
ide3 at 0xe400-0xe407,0xe802 on irq 18
hde: 35239680 sectors (18043 MB) w/1966KiB Cache, CHS=34960/16/63,
UDMA(66)
hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63,
UDMA(66)
Partition check:
 hde: [PTBL] [2330/240/63] hde1 hde2 hde3 hde4 < hde5 >
 hdg: hdg1 hdg2 hdg3 hdg4

(The hde line is slightly different in the 2.2 series.... it reports
UDMA(33) as opposed to UDMA 66.  The drive really is a WD 20G 7200RPM
drive with UDMA66.  So there is a slight difference between 2.2 and 2.4. )

I obviously can't show the above two lines, which are a part of my
complaint, because it is dumped to the screen plus the machine has
locked up, resulting in the data not being committed to disk...

At first I used the following parameters:

hdparm -d1 -c1 -u1 -m8 -X68 /dev/hde /dev/hdg
When I noticed the problem (as stated above), I forgoed any optimization
with hdparm.  By default, it sets up my drive as so:

/dev/hde:
 multcount    =  0 (off)
 I/O support  =  0 (off)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 2330/240/63, sectors = 35239680, start = 0

/dev/hdg:
 multcount    =  0 (off)
 I/O support  =  0 (off)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 59560/16/63, sectors = 60036480, start = 0

The problem still occurs even when I leave the hdparm optimizations out.
I've looked at the abit site and found a note about a problem with
the IBM-DTLA drives, so I decided to use their BIOS... and the problems
show up, regardless of what BIOS I use (whether it's their latest
"stable" RU or their beta RU).  Switching to PIO isn't really an option
either as a "workaround" because it slows down the throughput
tremendously... from 17 MB/s to about 3.6 MB/s.... plus it uses even
more CPU time as well.

Johnny Luong

Quote:>The hde line is slightly different in the 2.2 series.... it reports
>I obviously can't show the above two lines, which are a part of my
>complaint, because it is dumped to the screen plus the machine has
>locked up, resulting in the data not being committed to disk...

From the above, I am guessing that you are using a 2.4.0 test kernel - in
which case your problem _may_ be a bug in the kernel. You may want to
consider mailing the kernel IDE people with a detailed description.

I saw the same lockup upon boot with my *offboard* HPT366 controller.
However this was fixed in the 2.4.0-test1 release. I had no problems after
the 2.4.0-test1 release was out, though.

Quote:>tremendously... from 17 MB/s to about 3.6 MB/s.... plus it uses even
>more CPU time as well.

I know - my disk went from 8MB/s to 21.5 after switching to the test-
kernels and enabling UDMA4.

Hope you can work it out :)

My setup on a Quantum FB lct10 and HotRod 66 PCi controller card uses
hdparm -u1 -c1 -m16 /dev/hda for 21.5 MB/s.

--
Kenneth R?rvik         91841353/22950312

0875 OSLO               home.no.net/stasis

Hello!

Quote:> When I do heavy IO operations across two hard drives on the HPT366,
> each on their own channel and set to primary, I get a lockup.  

Same problems here... I get these when using my Maxtor 7200 RPM 20G HD
at UDMA4. The only thing that I found to help, is to down-throttle to
UDMA2. I've tried 2.2.16 patched, and 2.4.0-test1 upto test7 but no
luck here.

Searching Deja.com hinted that there can be Maxtor-HPT366 issues.
If anyone has more to say about this, I'd be glad to hear it,

Jeroen
--
                             --  Toevallig wel! --

Brouwersgracht 214 III                 | Member of the UvA RoboSoccer Team
1013 HD, Amsterdam, The Netherlands    | http://www.robocup.nl

On Fri, 08 Sep 2000 01:29:42 +0200, Jeroen Roodhart

Only what I hear...there are timing issues with (some?) Maxtors and the
HPT controller. Maybe other drives too. I remember Andre Hedrick saying
somewhere that it was not really Maxtor or HPT's fault, but the ATA/66
specs were written such that they could be interpreted differently. And
in this case, were. I hope am not misquoting or misunderstanding him. He
talks fast, even when he writes ;) And did elaborate as I recall. This
was on linux-kernel a few months ago IIRC. Might want to nail this down,
as it has been a while. I chased this for a while myself trying to
'confirm' this, but never found a definitive source (other than what I
remember Andre saying).

This has been a hot button issue with MS BP6 users too, if that is any
consolation.

--
Hal B


--

Thanks for that bit of info Hal, this will certainly keep me from
wasting a lot of time to see if I can get it working ;)

Hmmm, I haven't experienced any problems under Windows 2K or Windows SE,
but that may just follow from the fact that I run Linux for the vast majority
of time... I didn't do any bechmarks under Windows either, so I haven't checked
if the Highpoint Windows drivers actually use UDMA4 ;)

If this turns out to be a persistent problem, there probably should be something
of a black list compiled.

Are the same kind of problems existent in the ATA100 spec as well? I just got
used
to not looking very hard at the linux compatibility listing when buying new
hardware.
I guess I shouldn't have :)

Anyway, thanks again, we know Andrew Hedrick is doing a great job, I've used his
driver for quite some time now (albeit at UDMA2 ;)),

Jeroen
--
                             --  Toevallig wel! --

Brouwersgracht 214 III                 | Member of the UvA RoboSoccer Team
1013 HD, Amsterdam, The Netherlands    | http://www.robocup.nl

On Mon, 11 Sep 2000 00:47:00 +0200, Jeroen Roodhart

I followed BP6 issues on an abit.mainboard news group for some time back
when I was having lockups (unrelated issue). There was many lengthy
threads on this -- most from MS users that insisted Maxtor was broken
re: HPT. But, there were some (seemed to be a minority) that said they
were doing just fine. So? Maybe just certain models? Maybe other
contributing factors, eg load? Conflicts with other hardware?

Quote:>If this turns out to be a persistent problem, there probably should be
>something of a black list compiled.

Yea, but neither Maxtor nor HTP nor Abit want to admit the problem
(assuming I am right of course).

Quote:>Are the same kind of problems existent in the ATA100 spec as well? I

Dunno. What I am telling you is just word of mouth type stuff. I never
could find any hard evidence anywhere on this. I did have private email
correspondence with a guy who claimed he got someone at Maxtor to admit
to the problem. But I never could find a reference on their website, or
Highpoints, or Abit's for that matter.

Quote:>just got used to not looking very hard at the linux compatibility
>listing when buying new hardware. I guess I shouldn't have :)

Actually, if you look at linux-ide, Maxtor, IBM, and Quantam (IIRC), seem
to be recommended drives. Specific issues don't seem to be addressed.

Quote:>Anyway, thanks again, we know Andrew Hedrick is doing a great job, I've
>used his driver for quite some time now (albeit at UDMA2 ;)),

Yea, Andre is OK.

--
Hal B


--

Shrug, if the problems are associated with the components, then ultimately
it falls on the vendor of such components.... and that would probably
be ABIT in my case.  I've had to return the board myself for a defective
transistor (?) and the HPT366 just add to the list of woes that I have
with the board... (amonsgst acpi, etc.)  And yes Hedrick does a good
job, but if the hardware is lacking, then I'm not gonna blame the
programmer who made it possible for me to use in the first place.  Other
people on the kernel mailing list posted something similar but offered
no solutions (other than the usual hdparm look at, which still didn't
address the problem).  And if Abit is releasing a distro on it, they
should be concerned because of possible data corruption since their
redhat-based distro uses the hpt366 code that is publicly available. (the
nice gentus cd that comes with your board)

Just my two cents... I've about given up on trying to figure it out
and I'm putting my hard drive into another case with a different board.
Oh well, I was kinda hoping somebody had some unique idea to solve it. :)

Johnny Luong

I've heard/read somewhere that the HPT366/Maxtors can be finnicky with
regard to lone master/master & slave settings.  ie if you are running two
drives, one on primary the other on secondary, both as masters then changing
to both slaves may cure the problem - also on my segate U10 there is a
jumper to set if it's the only drive on the ide channel.
But on to why I posted........

Quote:>hdg: timeout waiting for dma
>ide_dmaproc: chipset supported ide_dma_timeout func only

>Keyboard is locked up, and can't do anything.  Any ideas on what I
>should do?  This occurs in both the 2.2.* series with the ide backpatch
>and the 2.4.0test series as well.

I've got a BE6-II - HPT366 (RHL7) and a BE6-IIv2 - HPT370(Windows Pee).  I'm
currently running a seagate 20.5GB U10 on the HPT366 giving the address of
the IDE controller as a boot parameter in lilo.

With regard to patching the kernel is there an idiot guide to patching the
2.2.16-22 kernel that comes with RHL7.0 for the HPT366 - to be honest I'm
confused by how it all fits together and the Kernel howto does not clarify
some issues for me.  I don't think I helped much by going to linux-ide.org
and working backwards.  I've seen statements that say the HPT366 is
supported in later releases of 2.2.x but if that is so why do I have to
apply a patch?

I copied two versions (one for each attempt - the original RHL7.0 source and
the soruce for 2.2.16 from kernel.org)) of kernel source code into
/usr/src/linux* and tried applying the patch (successfully) and 'make clean'
and 'make config' went fine (I think - ie no errors but I might not have
configured perfectly!).  When I come to 'make bzdisk' it rattles on the then
exits due to redefinitions and no declarations for HPT366.

Also, I'm wanting to keep up to date with beta (even) releases of the kernel
just to ensure I'm active with my linux box.  I've yet to find some
resources that I'm at home with to refer to - I don't know much about linux
but I know a lot about programming (asm,ada,c,lisp...), computing,
electronics etc (ahem and DOS/Windows).

On from that I managed to get the Tulip driver for the linksys LNE100TX 4.1
(ok not totally related) but the final bit that got it to work fine was
adding a line in a file.  I can't remember the name or where this file is
but I know it contains all the net drivers and possible IRQ and address
settings - in the version that comes with RHL7.0 the IRQ information has
been omitted (hence I assume it won't probe on any IRQ for a card compatible
with the tulip driver) - so any tips on how to find files based on
modification dates / ranges etc because in the pages I read (I read a lot)
nothing was mentioned about this line - it may only effect RHL7.  I'll stop
now cos I'm straying.

Regards,
Al
the replyto: is fake try using westar at blueyonder  .c o.uk

This is a well known problem with the HPT366 on the BP6 Motherboard.  Find
the Abit Linux mailing list.

One work round is to set the drives to UDMA2 mode, 33MB/s rather than the
full 66MB/s, part of the problem may be tight timing issues etc.

May sure your BIOS on the BP6 is qq01_beta or later, ru is the current one.