I marked this as a regression.

$ git log v2.6.29..v2.6.30 drivers/net/wireless/hostap/
commit 5ae4efbcd2611562a8b93596be034e63495706a5
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Fri Mar 20 19:36:43 2009 +0000

    hostap: convert to net_device_ops
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 4cfa8e45f4bb26ff38155f94a810a876b739958d
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Fri Mar 20 19:36:42 2009 +0000

    hostap: convert to internal net_device_stats
    
    Use pre-existing net_device_stats in network_device struct.
    
    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 1ea893fde29d8cf1639da8989f4b843dc3283ca8
Author: Dan Williams <dcbw@redhat.com>
Date:   Wed Feb 11 17:17:10 2009 -0500

    hostap: convert usage of net/ieee80211.h to linux/ieee80211.h
    
    So that net/ieee80211.h can be made private to ipw2x00 in a follow-up.
    
    Signed-off-by: Dan Williams <dcbw@redhat.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

commit c1b4aa3fb619782213af2af6652663c8f9cef373
Author: Harvey Harrison <harvey.harrison@gmail.com>
Date:   Thu Jan 29 13:26:44 2009 -0800

    wireless: replace uses of __constant_{endian}
    
    The base versions handle constant folding now.
    
    Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Yasen, are you git savvy enough to revert each of those patches, rebuild, and give the resulting kernels a try?

I promise to try this week. Should not be rocket science.

I reverted the first one 
5ae4efbcd2611562a8b93596be034e63495706a5
and AP started to work. 

Should I try the other ones?

The problem is indeed in commit 5ae4efbcd2611562a8b93596be034e63495706a5.

Have a look into hostap_main.c before the commit. The original fragment of code in the function hostap_setup_dev() was:

if (type != HOSTAP_INTERFACE_MASTER) {
    /* use main radio device queue */
    dev->tx_queue_len = 0;
}

While the equivalent new fragment (with unrelated lines marked) is:

switch(type) {
case HOSTAP_INTERFACE_AP:
    dev->netdev_ops = &hostap_mgmt_netdev_ops;  /* unrelated */
    dev->type = ARPHRD_IEEE80211;               /* unrelated */
    dev->header_ops = &hostap_80211_ops;        /* unrelated */
    break;
case HOSTAP_INTERFACE_MASTER:
    dev->tx_queue_len = 0;                 /* use main radio device queue */
    dev->netdev_ops = &hostap_master_ops;  /* unrelated */
    break;
default:
    dev->netdev_ops = &hostap_netdev_ops;  /* unrelated */
}

Apparently the condition when dev->tx_queue_len should be set to 0 was reversed in the new code, which is wrong.

I have already sent a trivial patch to linux-kernel@vger.kernel.org (see http://lkml.org/lkml/2009/9/9/418). I am also posting the patch here so it won't get lost and somebody applies it ASAP.

Created attachment 23057 [details]
patch to revert the toxic part of the conversion to net_device_ops

I'm usually in managed mode with my Wifi card, connecting to an AP downstairs.  I do get a LOT of warnings in the logs of the form "Virtual device wifi0 asks to queue packet!".  This fills up my /var partition within a day.  Am I being affected by the bug discussed here or is that something else?  Again, this computer is not acting as the AP, but only connecting to one.

(In reply to comment #8)

Although I am not an expert on the hostap driver, I believe that the bug discussed here can affect you also, based on the same reasoning (zero-length queue on wifi0). It's easy to prove or disprove the hypothesis, just use the patch from my comment #7 and recompile your kernel.

The patch should not break anything and it should apply easily to any kernel since 2.6.30. Even if the kernel from your distro is heavily patched, it should be very easy to patch the sources by hand (there are only 3 lines of code to be modified). I can even send you a spec-file for Fedora 11 if you like ..

The patch from comment 7 is in 2.6.32-rc1.  Can you try that and post the results here?  Thanks!

The patch from comment #7 works for me. Thanks, Martin!

(In reply to comment #10)

2.6.32-rc1 works for me perfectly. Therefore I suggest closing this bug.

Would it be possible to see this patch committed to the 2.6.31 kernel branch?  That was suggested in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/444801/comments/5 as the best way forward for Ubuntu Karmic.

Just forwarded the patch to stable@kernel.org for 2.6.31...