I've recently seen the same problem on 4.2-stable, probably a early version
of it, I go to make my kernel and it locks up for a few mins, then I get
some ata error and then it says resetting devices and it all runs ok, it
resets the ata devices during boot also.
----- Original Message -----
From: "Ben Jackson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, December 27, 2000 2:28 PM
Subject: Re: HDD Problem
> > I've heard tell that there are problems with the VIA chipset and UDMA on
> > FreeBSD. Is this true, and if so, what is the problem with?
> >
> > FreeBSD 4.2-STABLE #0: Fri Dec 8 01:52:44 EST 2000
> > atapci0: <VIA 82C686 ATA66 controller> port 0xe000-0xe00f at device 7.1
on
> > pci0
> > ad0: 19546MB <FUJITSU MPF3204AT> [39714/16/63] at ata0-master UDMA66
>
> Sounds similar to the problem I've had with the HPT controller on my
> Abit BP6. If you look at the -stable archives from the last few days
> you'll see some suggestions. I should really move this drive to one
> of the ATA33 controllers since the drive itself only (??) does about
> 30M/s sustained anyway.
>
> atapci1: <HighPoint HPT366 ATA66 controller> port
0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007 irq 18 at device 19.0 on pci0
> ata2: at 0xd000 on atapci1
> ad4: 29311MB <Maxtor 53073U6> [59554/16/63] at ata2-master UDMA66
>
> > The drive has enough space and I have 512MB RAM. If I hit the system
hard,
> > lets say, rm -rf /usr/ports, the system locks up.
>
> I have to hit mine harder. The more I upgrade FreeBSD, the more times
> it successfully resets the devices after a read timeout, but eventually
> it hangs while resetting. With 4.2 (or maybe it's softupdates) it
> manages to save some of the errors in /var/log/messages.
>
> No page faults. Haven't had a persistant kernel "page not present"
> problem since FreeBSD 1.1.5. Also, my UDMA66 problem is happening
> on a machine with ECC mem.
>
> Another datapoint: my desktop machine (until yesterday running 3.4)
> has an IBM disk in it which likes to spin down on its own, causing
> timeouts on the first access afterwards. It's irritating (though not
> enough that I've investigated jumpering it for always-on) but it has
> never hung the system.
>
> --Ben
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message