"Dan Mack" wrote:
> I have basically the same system. BP6 (dual 400 SMP) + 2 UDMA66 Maxtor
> Drives. Under
> high I/O load, I get the lost disk contact messages. Sometimes I recover
> from
> the hang other times I have to hard reset the system.
>
> Yes I know that maxtor is not the highest quality but at $120 for 13GB ;-)
>
> Is there anything I can do to solve this problem besides buying new disks?
I use this, it solves my lockup problems at UDMA66 completely (ie: disables
it :-). After this I run reliably.
Index: ata-all.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
retrieving revision 1.47
diff -u -r1.47 ata-all.c
--- ata-all.c 2000/02/04 10:20:20 1.47
+++ ata-all.c 2000/02/12 07:59:08
@@ -1188,8 +1188,10 @@
ata_umode(struct ata_params *ap)
{
if (ap->atavalid & ATA_FLAG_88) {
+#if 0
if (ap->udmamodes & 0x10) return (ap->cblid ? 4 : 2);
if (ap->udmamodes & 0x08) return (ap->cblid ? 3 : 2);
+#endif
if (ap->udmamodes & 0x04) return 2;
if (ap->udmamodes & 0x02) return 1;
if (ap->udmamodes & 0x01) return 0;
> Dan
> ----- Original Message -----
> From: "Hans Ottevanger" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, February 12, 2000 10:31 AM
> Subject: ABIT BP6 + UDMA66: ad_timeout: lost disk contact
>
>
> > Hi folks,
> >
> > I am currently having problems with my new Dual Celeron testsystem,
> > when trying to use UDMA66.
> >
> > Hardware:
> >
> > ABIT BP6
> > 2x Celeron 466 (NOT overclocked)
> > 128 Mbyte RAM
> > Matrox G400 16 MByte
> > 3Com 905B
> > 2x Maxtor 92041U4 20 GByte
> > Aopen CDROM 48x
> >
> > One of the disks is master on the first "standard" disk channel, and
> > uses
> > UDMA33, the other is master on the first "fast" channel controlled by
> > the
> > on-board HPT-366, and is probed as UDMA66.
> >
> > When I use the UDMA33 disk, no problem occurs at all, I can even run
> > "make buildworld" without any problems. When accessing the disk on the
> > UDMA66 channel however, the system regularly hangs, followed by a
> > message
> > like:
> >
> > Feb 12 12:39:54 myhost /kernel: ad4: ad_timeout: lost disk contact -
> > resetting
> > Feb 12 12:39:54 myhost /kernel: ata2: resetting devices .. done
> >
> > After a few of these messages the system hangs completely, and needs to
> > be
> > rebooted.
> >
> > The problem already occurred during my first attempts to use UDMA66 last
> > week, but now persists using today's 4.0-CURRENT.
> > My kernel is derived from GENERIC, with SMP added, and devices removed
> > that
> > are not present. I do not yet use softupdates.
> >
> >
> > The problem can easily be reproduced by creating a large file as
> > follows:
> >
> > dd if=/dev/zero of=junk bs=1024k count=512
> >
> > This command runs without any problem. Reading this file with:
> >
> > dd if=junk of=/dev/null bs=1024k
> >
> > causes the problem to occur within a few seconds. Decreasing the
> > blocksize
> > makes the system survive somewhat longer, but the problem still occurs.
> > Only with a blocksize lower than 4k the system does not hang.
> >
> > Very strange is the fact that reading the raw device file with:
> >
> > dd if=/dev/ad4s1c of=/dev/null bs=1024k
> >
> > completes without problems, even with two commands running concurrently.
> >
> > I already tried to swap the disks, but the problem still occurs on the
> > one
> > that is using UDMA66. Even when switching to PIO using 'sysctl', the
> > system
> > still hangs, it just takes somewhat longer before it happens.
> >
> > Does anybody have an idea what happens ?
> >
> >
> > Kind regards,
> >
> > Hans
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
