Andre Hedrick wrote:
> edit ./drivers/block|ide/hpt366.c
>
> Find the something CAN_UDMA_4 and set to 0
> it is a #define type thing.
** Finally some good news then:
- #define CAN_DO_UDMA4 0 ... seems to "help", I mean that the brute
force floodping/harddrive combination does *not* work with this. It
safely pumps 15G and that's it :)
No long term testing, off course - sometimes this machine still needs to
do real work ;)
<voodoo mode>
As the hangs seemed to occur with certain data traffic volumes, and not
just because you pushed the HD to the max with seeks etc. I tried hard,
but could not find another way to crash the box - which means that only
long term tests can help us with UDMA33.
</voodoo mode>
** The other news is the IDE/network interaction.
I tried UDMA66 "cat /dev/hda" once more. If there's no other activity,
this seems to work. It seeeems to *need* some ethernet card activity to
freeze... this is speculation and would need extra investigation etc
etc, but a simple "ifconfig" could hang the machine, whereas no network
interfaces active would not do anything. I did not try to run X yet.
Anyway, setting the IDE driver to UDMA33 seems a good thing.
One silly question: I had put the BIOS of this beast to UDMA3 (and
lower), but as this test seems to show, the kernel does not listen to
those BIOS settings. Is that right?
Best regards,
Valentijn
--
Valentijn Sessink - [EMAIL PROTECTED]
-
No one can yet predict what future archaeologists may
find in Redmond. - John Pancharian, LinuxWorld
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
