Ar Gwe, 2006-08-11 am 09:52 +0100, ysgrifennodd Chris Pringle:
on it. However, when the port is receiving a lot of data, it has the
tendency to either get corrupted data, or to crash the kernel.
What do the crash traces look like
Perhaps - I'm in discussion with them at the moment, but neither our, nor their department have managed to come up with an answer yet.The "inb" as it is will sometimes return bad data - I'm guessing this
is due to ISA bus instability... Anyway I changed it to "inb_p" which
cured the corruption problem, but has introduced another issue - it
hangs the kernel.
Maybe you need to have a chat with your hardware guys. Certainly if
inb_p makes a difference you've got hardware not software side problems.
Thats interesting, but wouldn't this produce strange side affects for the 2.4 kernel as well? 2.4 works fine on both VIAs and Celerons.Interestingly, it only hangs on systems with a VIA Nehemiah CPU, the
Intel Celerons seem to work fine. Could this be a problem with writing
to that dreaded port 0x080 within inb_p?
Unlikely as it would affect both. More likely would be that the ISA bus
clock is generated off the PCI bus clock and you have one of the
multipliers wrong or too high for the board.
I'll give the interrupt disabling a go...it only occur on the VIA chip and not the Celeron? I don't think the
problem is there when the low latency patches are not applied - so I'm
thinking it's probably a timing problem of some sort.
That bit is interesting. Something really off the wall to try - disable
interrupts around the inb_p(), especially if you are using pre-emption
and let me know what happens.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/