Hello, all.
I am using an ABIT BP6 board (SMP, 2 Celerons at 366MHz, none
overclocked, *very* stable) which uses the HPT366 controller. I am getting
through these messages when using the *original* ATA cable (never touched
before) or a replacement one:
hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
(when the drive first fscks from a dirty reboot)
And, in kernel messages, whilst doing hdparm -tT /dev/hde3:
-> invalidate: busy buffer
(from fs/buffer.c)
(yes, it is wrong to use hde3, but when I use hde, but whatever;
using hda3 or hda did not matter when I used this *same* HDD with normal
IDE cable (not using HPT366))
I am not using *any* special features (untuned HDD), drive was set
to DMA mode 4 at the HPT BIOS.
Any clues on this? I am using kernel 2.4.17, libc 2.2.4, hdparm
4.1.
PS: For now, I'll use this HDD with the normal cables, as I fear
corruption. (yes, the drive runs *perfectly* with the normal cables and
not connected to the HPT366 IDE. It is a Seagate ST310211A HDD.)
Thanks,
Cesar Suga <[email protected]>
> through these messages when using the *original* ATA cable (never touched
> before) or a replacement one:
>
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
CRC error -> cable/wiring problem. If you are using UDMA66/100 you must
have an 80pin cable. If you are using UDMA33 and can't pin it down then
an 80pin cable doesnt do any harm
Alan
On Fri, 22 Feb 2002, Alan Cox wrote:
> > through these messages when using the *original* ATA cable (never touched
> > before) or a replacement one:
> > hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
> CRC error -> cable/wiring problem. If you are using UDMA66/100 you must
> have an 80pin cable. If you are using UDMA33 and can't pin it down then
> an 80pin cable doesnt do any harm
Yes, I am using the 80pin cable. The BP6 board has the normal IDE
controller and the HPT controller. The normal IDE controller which I said
was the common 40pin one. The DMA66 cable, certainly, is the 80 pin.
I cannot use the 80pin cable with the normal IDE for it does not
fit. But I tried with two 80-pin cables.
Thanks,
Cesar Suga <[email protected]>
On Thu, Feb 21, 2002 at 11:55:34PM -0300, Cesar Suga wrote:
> I cannot use the 80pin cable with the normal IDE for it does not
> fit. But I tried with two 80-pin cables.
>
Is that because one of the connector holes is blocked on the cable conector?
If so, I have had success with just breaking the correct pin so that the 80
pin cable can be plugged into old motherboard IDE connectors. As always
with hardware mods, YMMV.
Mike
On Thu, 21 Feb 2002, Mike Fedyk wrote:
> Is that because one of the connector holes is blocked on the cable conector?
>
> If so, I have had success with just breaking the correct pin so that the 80
> pin cable can be plugged into old motherboard IDE connectors. As always
> with hardware mods, YMMV.
But if I use the old motherboard IDE connector I'll not be using
DMA66, so no need to use those new cables if I have a chunk of the other
cables... (even if I agree that hardware mods are possible, I avoid them
while I can)
Thanks,
Cesar Suga <[email protected]>
On 2002-02-21 23:14:11-0300, Cesar Suga wrote:
> Hello, all.
>
> I am using an ABIT BP6 board (SMP, 2 Celerons at 366MHz, none
> overclocked, *very* stable) which uses the HPT366 controller. I am getting
> through these messages when using the *original* ATA cable (never touched
> before) or a replacement one:
>
> hde: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hde: dma_intr: error=0x84 { DriveStatusError BadCRC }
I got this very same error on my normal VIA ide controller with every cable
I tried until I figured out that perhaps I should like, actually compile in
the VIA driver :)
Basically, reading would go without problems but writing would give the
above error and make the controller go back to PIO mode access. I agree
that it is most likely a cable problem but I wouldn't rule out the driver a
priori.
--
Wessel Dankers <[email protected]>
Small animal kamikaze attack on power supplies
On Thu, 21 Feb 2002, Cesar Suga wrote:
> And, in kernel messages, whilst doing hdparm -tT /dev/hde3:
>
> -> invalidate: busy buffer
> (from fs/buffer.c)
>
> (yes, it is wrong to use hde3, but when I use hde, but whatever;
> using hda3 or hda did not matter when I used this *same* HDD with normal
> IDE cable (not using HPT366))
>
> I am not using *any* special features (untuned HDD), drive was set
> to DMA mode 4 at the HPT BIOS.
My though would be that when something is working right, the first step
is to check that you are doing things in a known safe way. Therefore I
would (a) use /dev/hde, and (b) set -X34 with hdparm.
I do those things, I have two internal systems working and two at
client sites, which I assume are working since they aren't teling me
otherwise.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.