eth0: Outofsync dirty pointer 471

Dances With Crows Software can...in conjunction with asynchronous events..cause random flakiness.

I wrote an OS for a single board computer. About once every couple of hours it would crash...I had never tested it for that long...turned out to be that if a timer interrupt happened in one, and on only place in the operation of it..it would crash.

I lefet in on the hardware emulator , did something else..came back when it had crashed..spottted teh two lines of buttembler..and shoved a 'interrupt off-on' pair round them :D

Likewise a friend who was involved in designing an early home computer OS..discovered that a similar situation could occur in the hardware. It would crash about every hour..they added another wait state, calculated it out...and realised it would crash once every 75 years.

It went into production like that. "if a user crashes, he will reboot it anyway, and chances are it will never happen to him again" :)

D-link use similar design methodology I think :-)

What we reckoned was that the interrupt latency on the PC they were connected to was high enough that in a significant proportion of cases the data had gone before the ISR could pull it of the chip.

I mention all tis to give an idea about how SOFTWARE can cause 'random' flakiness in conjunction with random asynchronous events..even when its essentially bug free and the hardware is functioning correctly.

However I take your point that if this code and NIC have been around a long time, its unlikely to be the problem.

What MAY be is bus timing on the NIC and mother board. I've seen cards an board that worked OK with other cards and boards, but not as a pair.

Sometimes fiddling around in the bios with bus timings helps.

Otherwise sling the motherboard.

Its one reason why I use a mate who has a one stop shop and supplies the whole thing: If any bit doesn't work we swap till it does..and at no cost. Apart from the fact that he charges 15% more than bucket shops..to be able to give that service.