kuznet> Hello!
>> Just a final question: was the problem solely caused by the
>> packet scheduler
kuznet> Yes. And it was utterly stupid.
>> in the device drivers that we nevertheless should try to find
>> and fix?
kuznet> It is always useful 8)
And this particular bug was also useful because when hunting for it
without beeing successful I detected at least several other ones :-)
kuznet> At least, looking at isdn, I see that it sometimes forgets
kuznet> to mark NET_BH clearing tbusy. And even the fact that in
kuznet> the cases when it does not forget it, clearing tbusy and
kuznet> marking bh are made in different parts of code tells that
kuznet> the driver assumes wrong things.
My first experiments when the problems where first observed was to
analyse the isdn code and to insert mark_bh everywhere where
tbusy was cleared. Analsysis also showed that mostly, tbusy was cleared
correctly although that was not allways obvious from a first look at
(but from more detailed study of) the code. As this did not change
anything, those additinally inserted (but redundant) mark_bh where
never commited to the offical source (only those that were really missing).
Iīm fairly sure that now marking NET_BH is done correctly (although
somewhat messily) as far as single link isdn connections are concerned
(there might be possible problems with multilink, but as I cannot test
these, I havenīt done further work on this).
Henner
-
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/