kuznet> Hello!
>> My first experiments when the problems where first observed was
>> to analyse the isdn code and to insert mark_bh everywhere where
kuznet> It was correct idea. The more butter is the better. It is
kuznet> a pity that you gave up 8)8)
:
:
:
kuznet> If tbusy is referenced out of such macros and it is not
kuznet> easy to encaplsulate them to such macros, because they are
kuznet> on a distance: the device is buggy. Look at isdn_net
kuznet> now...
kuznet> Yes, the only allowed in 2.2 exception is when tbusy is
kuznet> set to 1 in
dev-> hard_start_xmit() without any reasons and then reset to 0
kuznet> without marking BH. It is some magic combination, which is
kuznet> copied and pasted to new drivers for years without
kuznet> thinking 8) It lost its sense before linux-1.2... It is
Yes, I know. I even had a patched version of isdn_net.c running
where the tbusy handling was fixed (only set when busy condition
was detected). The problem by this time was that due the occasional hangs
(which, as we know now, were caused by the packet scheduler) I could never
be sure that the changed code was actually correct. And as the tbusy handling
changes did not fix the hangs (and on the other hand there was a risk
that I missed something in the complex isdn_net), I decided not
to commit the change until the ping-delay problem was actually resolved.
kuznet> harmless in 2.2, but it is not so harmless in 2.3/smp, by
kuznet> the way.
Thus, you think that it is rather worthy to resurrect my old patch,
otherwise isdn is likely to break in 2.3.x ?
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/