It seems Alexander Langer wrote:
> 20000320:
>                       * * * W A R N I N G * * *
>       The ata driver has some issues with the Apollo MVP3 chipset.
>       Drives work only in pio mode and must be set to pio mode early
>       int the boot process.  Do not upgrade.  If you must upgrade
>       in the face of this, add
>               /sbin/sysctl -w hw.atamodes=pio,pio,pio,pio
>       to the start of /etc/rc.conf.  Even if you do this, any and
>       all damage to your system is at your own risk.  You have been
>       warned.
>                       * * * W A R N I N G * * *
> Of _course_ I own such a thing.

Ehm, is that a warning you have written or ?? I certainly havn't
issued this warning as the maintainer/author of the ata driver...

> FreeBSD 5.0-CURRENT #0: Fri Mar 31 16:52:11 CEST 2000
>     [EMAIL PROTECTED]:/usr/src/sys/compile/cichlids
> pcib0: <VIA 82C598MVP (Apollo MVP3) host bridge> on motherboard
> pci0: <PCI bus> on pcib0
> pcib2: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device
> 1.0 on pci0
> atapci0: <VIA 82C586 ATA33 controller> port 0xe000-0xe00f at device
> 7.1 on pci0
> Two things: As you can see, my -current is from Mar 31,though I don't
> know exaclty if I've taken sourcs from Mar 31, but I'm kinda sure.
> Question is: Does the problem affect all versions?
> It doesn't seem so, since I'm running two disks at UDMA33 without
> problems:
> ad0: 4133MB <FUJITSU MPE3043AE> [8959/15/63] at ata0-master using UDMA33
> ad2: 6197MB <IBM-DHEA-36481> [12592/16/63] at ata1-master using UDMA33
> There still is a little chance that my sources wasn't from pre-03/20,
> so - is this problem fixed?

I have not changed anything in the ata driver related to the VIA'586 in
a long time, its works with all disks and ATAPI devices I have access to
on the MVP3 chaintec board I have...

But knowing VIA and their funny way of versioning the silicon, it could
be that they have made a newer version of the '586 that behaves differently
than the old (they have done that with the '596) and that will probably
cause problems..

So, I need a verbose boot from a working kernel, and the same from
a system that shows the problem from a newer kernel to be able to
tell if there is an issue here...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to