On Monday 04 August 2008 23:14:51 Larry Finger wrote: > In commit b19fa1fa91845234961c64dbd564671aa7c0fd27, the configuration > parameter NETDEVICES_MULTIQUEUE was eliminated making multiple TX queues > the normal behavior. For p54usb, enabling multiple queues broke the driver. > > The real failure is not known, but a temporary hack that forces only one > queue is presented here. > The real problem seems to be that skb_get_queue_mapping doesn't work the way it should when we process the firmwares callback. It's always "0" and unfortunately also when it should be something else like queue 1, 2 or 3..... problem solved? However someone should really take a closer look at the multiqueue thing, especially why it has to BLOCK/SPIN (uninterruptible?) when a queue is stopped and tx returns therefore NETDEV_BUSY. The is assumption that "a queue is in any case going to become free again" is well-intentioned, but as my devices are crashing left & right on a daily basis it's even dangerous for my RAID ;-). (BTW: patch is diffed against 2.6.27-rc2) Signed-off-by: Christian Lamparter