>Have I missed something that's obvious, or is it something unhappy
>with 2.0.36?
I've done some followup testing with 2.0.28 and the VIA apollo UDMA
patches (I patched them into 2.0.28, then commented out the code
section that dealt with putting the drives into UDMA mode and threw
out the rejected patches for ide-floppy.c), and I get the sneaking
suspicion it's a 2.0.36 problem.
My 2.0.28 kernel is pretty much a bog-standard 2.0.28 kernel with
my enhanced memory detection patches, the VIA apollo patch, the
logo patch, and the 2.0.36 AMD PCscsi driver backpatched into it.
My 2.0.36 kernel is bog-standard, with the exception of the logo
patch and the VIA apollo patch.
The 2.0.28 kernel didn't die during bonnie for either two disks
on one chain (performance here *sucked*) or one disk per chain
(which failed to suck up to the point where they exhausted core
bandwidth.)
The gory details of the server in question are:
AMD K6-2/333
3 x 128mb EDO dimms (60ns, or a whopping 32mb/sec bandwidth)
FIC 2013 m/b (1mb L2 cache)
2 x SMC EtherPower 100s (which weren't doing anything for this test)
BusLogic 958 (which wasn't doing anything for this test)
some generic Intel i740 agp card.
2 x IBM 13gb UDMA drives.
An ancient 4x atapi CD-ROM (slave on channel 2, not doing anything)
The ob-floppy.
oopsen available on request, as well as snippets of the map file and
the system configuration.
____
david parsons \bi/ 8.5mb per second off a cheap IDE drive is good, when
\/ the kernel doesn't oops up on it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/