> Network driver in (1) was a 3c59x as shipped in 34p16 with the transmit
> protect patch from DaveM; in (2) it was the vanilla 34p16 driver.
Actually driver driver in 34p16 _has_ the DaveM protect patch, by the
looks of it. I extended the save_flags() protection in (1) to encompass
more of the transmit routine, effectively making the send and receieve
routines on the card mutually exclusive. We'll see if that helps.
> Are either of these worth investigating? (Chris reckons that the oopses
> are due to an unprotected error path in 3c59x which dereferences NULL
> pointers left, right and centre.)
No, I reckon the nasty oopses are caused by dangling pointers to a
"struct device*", which is kmalloc'ed upon insmod of driver and kfree'd
upon module unload.
struct skbuff has a device pointer, to name one important example ;-)
This nasty bug looks very awkward to fix, do we want to go mad with module
usage counts? Or scanning packet lists and setting device pointers to some
kind of bucket device?? yuck.
As for the 3c59x driver bugs, well bleh. I thought upgrading our 3c590 to
a 3c900 would give us some plain sailing. It seems a tulip card is on the
shopping list after all.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu