You could also just revert to kernel 2.4.25 or earlier. Someone who was apparently oblivious to the fact that device driver send routines were "routinely" called in irq context and/or that it was a <very bad thing> to call schedule() under such circumstances slipped that one in sometime between 2.4.25 which is OK and 2.4.28 where it is broken.
In 2.4.25 and earlier it was a simple busy wait loop in which "goto retry_here;" immediately followed the "if" statement. This was safe, albeit MP unfriendly because of the spin_lock()/unlock() on each iteration.
I'd say just delete the if and drop the damn packet.
At any rate someone who has access to the golden code should fix this one way or another ASAP because its definitely seriously broken the way it is now.
Mike
chas williams - CONTRACTOR wrote:
In message <[EMAIL PROTECTED]>,Lukasz Trabinsk i writes:
Sorry, but I don;t understand, what line, i am not kernel guru. :/
look for the following code:
/* retry once again? */ if(--retry > 0) { schedule(); goto retry_here; }
change schedule() to udelay(50) and see if things are 'better'.
Is was happened on 2.4.29, too. It is a interrupt problem?
its calling a routine that might sleep while in the transmit routine. this is not allow.
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Linux-atm-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-atm-general
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
