Re: [PATCH] p54: Fix regression due to commit b19fa1f

[Larry Finger <Larry.Finger@lwfinger.net>]

Chr wrote:
> 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 <chunkeey@web.de>
> 

These changes fix the problem on my system. If it is made into a proper patch, 
I'll ACK it.

Larry