Scratches head -- this is from memory when I was thinking about this problem a long time ago... I think we can return an error in the qdisc destructor function - making sure legitimate interface removal is not the cause of the qdisc deletion first of course.
Simon -----Original Message----- From: Jiri Benc [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 10, 2007 6:20 PM To: Jan Kiszka Cc: netdev@vger.kernel.org; Ivo Van Doorn; [EMAIL PROTECTED]; Jouni Malinen; Simon Barber Subject: Re: d80211: How does TX flow control work? On Mon, 08 Jan 2007 21:18:48 +0100, Jan Kiszka wrote: > The actual problem was meanwhile identified: shorewall happened to > overwrite the queueing discipline of wmaster0 with pfifo_fast. I found > the magic knob to tell shorewall to no longer do this (at least until > I want to manage traffic control that way...), but I still wonder if > it is an acceptable situation. Currently, the user can intentionally > or accidentally screw up the stack this way. Hm, we probably need a way to tell the kernel not to remove 802.11 qdisc. Jouni, Simon, is that possible or do we need to patch NET_SCHED code? Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
