> >
> > That's good enough. :) Thanks....
> >
> > Maybe _that_ will keep that ata code from over-riding
> > the bios to disable dma (or maybe the bios just wasn't
> > doing it's job right ;)
>
>
> This won't work.
What do you mean with this? The procedure that I described (barring
typos) do work here and was used here to install and run FreeBSD
on a silly A+ motherboard. Without disabling the DMA the install
would fail and even if I installed with DMA disabled, but rebooted
afterwards with DMA enabled, it would corrupt the filesystem to
an almost unusable state.
>
> Someone was having the same problem the other day, and
> I suggested the same soloution, but after probe, the
> damn driver enabled UDMA at attach time anyway.
>
> So we removed it from the kernel config... and the damn
> thing enabled it again.
>
> I don't know if the #ifdef was intended to only guard
> in the boot case, but it doesn't help, because there
> are several missign guards around the code, if that's
> the case, and at least four places in the code ignore
> the tuning variable, as well, if it isn't commented
> out of the kernel at build time (thus disabling one of
> the places).
>
> Look for the #ifdef, and then look for the function
> call to do the enable, and the problem will be obvious.
I'm not sure where the #ifdef comes into play. I didn't even
recompile anything, so whatever #ifdef can be whatever it likes
to be.
Jun 5 18:42:51 d-5-71 /boot/kernel/kernel: ad0: 4104MB <SAMSUNG SW0434A (4.3GB)>
[8896/15/63] at ata0-master PIO4
John
--
John Hay -- [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
