Hm, looks like the driver didn't handle the BAP error right.

What is this BAP and BAP error? What may cause it?

From http://www.kismetwireless.net/documentation.shtml :

"'cisco_cvs': Linux kernel 2.4.20, sourceforge.net CVS driver release
Capture interface: wifiX
Notes: The new drivers use the interface ethX for normal operation and wifiX for
raw packet capturing. The interface for Kismet should be set to wifiX. These
drivers have a history of locking up under high loads and when entering/leaving
rfmon mode. "

As the newer  RedHat Linux kernels are 2.4.20 then maybe that is why it crashed
on me and perhaps it will crash on other reasons as well?

[root@ranume root]# uname -a
Linux ranume 2.4.20-8 #1 Thu Mar 13 16:42:56 EST 2003 i686 i686 i386
GNU/Linux
[root@ranume root]# cat /proc/version
Linux version 2.4.20-8 (bhcompile.redhat.com) (gcc version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 16:42:56 EST 2003


Apr  7 17:30:01 ranume kernel: airo: BAP error 4000 2
Apr  7 17:30:01 ranume kernel: Warning: kfree_skb passed an skb still on a
list (from c011f338).
Apr  7 17:30:01 ranume kernel: ------------[ cut here ]------------
Apr  7 17:30:01 ranume kernel: kernel BUG at skbuff.c:315!
Apr  7 17:30:01 ranume kernel: invalid operand: 0000
Apr  7 17:30:01 ranume kernel: ipt_mac cls_route cls_u32 cls_fw sch_prio
sch_sfq sch_tbf sch_cbq ipt_MARK iptable_mangle ipt_state iptable_filter
ipt_MASQUERADE ip_conntrack_irc ip_nat_irc
Apr  7 17:30:01 ranume kernel: CPU:    0
Apr  7 17:30:01 ranume kernel: EIP:    0060:[<c01d8a1f>]    Not tainted
Apr  7 17:30:01 ranume kernel: EFLAGS: 00010286
Apr  7 17:30:01 ranume kernel:
Apr  7 17:30:02 ranume kernel: EIP is at __kfree_skb [kernel] 0x12f
(2.4.20-8)
Apr  7 17:30:02 ranume kernel: eax: 00000045   ebx: cb47d4e0   ecx: 00000001
edx: cec26000
Apr  7 17:30:02 ranume kernel: esi: c132ff98   edi: c02eb8f0   ebp: c132e000
esp: c132ff84
Apr  7 17:30:02 ranume kernel: ds: 0068   es: 0068   ss: 0068
Apr  7 17:30:02 ranume kernel: Process keventd (pid: 2, stackpage=c132f000)
Apr  7 17:30:02 ranume kernel: Stack: c0255440 c011f338 c132ff98 c011f338
cb47d4e0 cd3742e4 cd3742e4 c01281b0
Apr  7 17:30:02 ranume kernel:        00000000 c01282a5 c02eb8f0 00000001
00000000 c0349b00 00010000 00000000
Apr  7 17:30:02 ranume kernel:        c01281b0 00000000 c03441fc 00000000
c132e000 00000000 00000000 c01281b0
Apr  7 17:30:02 ranume kernel: Call Trace:   [<c011f338>] __run_task_queue
[kernel] 0x48 (0xc132ff88))
Apr  7 17:30:02 ranume kernel: [<c011f338>] __run_task_queue [kernel] 0x48
(0xc132ff90))
Apr  7 17:30:02 ranume kernel: [<c01281b0>] context_thread [kernel] 0x0
(0xc132ffa0))
Apr  7 17:30:02 ranume kernel: [<c01282a5>] context_thread [kernel] 0xf5
(0xc132ffa8))
Apr  7 17:30:02 ranume kernel: [<c01281b0>] context_thread [kernel] 0x0
(0xc132ffc4))
Apr  7 17:30:02 ranume kernel: [<c01281b0>] context_thread [kernel] 0x0
(0xc132ffe0))
Apr  7 17:30:02 ranume kernel: [<c01072ad>] kernel_thread_helper [kernel]
0x5 (0xc132fff0))
Apr  7 17:30:02 ranume kernel:
Apr  7 17:30:02 ranume kernel:
Apr  7 17:30:02 ranume kernel: Code: 0f 0b 3b 01 33 42 25 c0 58 5a 8b 5c 24
08 e9 ce fe ff ff 8d

[root@ranume root]# lsmod
Module                  Size  Used by    Not tainted
ipt_mac                 1144  42  (autoclean)
cls_route               5112   0  (unused)
cls_u32                 5916   1
cls_fw                  3288   0  (unused)
sch_prio                3712   0  (unused)
sch_sfq                 4032   0  (unused)
sch_tbf                 3360   1
sch_cbq                14368   1
ipt_MARK                1336   1  (autoclean)
iptable_mangle          2680   1  (autoclean)
ipt_state               1048   1  (autoclean)
iptable_filter          2316   1  (autoclean)
ipt_MASQUERADE          2072   4  (autoclean)
ip_conntrack_irc        3984   1  (autoclean)
ip_nat_irc              3152   0  (unused)
ip_conntrack_ftp        5008   1  (autoclean)
ip_nat_ftp              3888   0  (unused)
iptable_nat            20472   3  [ipt_MASQUERADE ip_nat_irc ip_nat_ftp]
ip_conntrack           25888   4  [ipt_state ipt_MASQUERADE ip_conntrack_irc
ip_nat_irc ip_conntrack_ftp ip_nat_ftp iptable_nat]
ip_tables              14488   9  [ipt_mac ipt_MARK iptable_mangle ipt_state
iptable_filter ipt_MASQUERADE iptable_nat]
airo                   45032   2
3c59x                  29360   1
ext3                   64704   5
jbd                    47828   5  [ext3]
[root@ranume root]#

... 2.4.18 series is working fine.

What is this bug 79579?
Any hope to get this fixed or at least confirmed?

Any Idea if or when this is going to be fixed in the kernel for RH 9?

I'm almost the same problems with RH9, first my keyboard stops working, but it
appears that I can still do things like check e-mail with the mouse.  The last
time the keyboard stopped working I tried connecting to my laptop from the
network but it was no longer on it,  one time it froze up everything and I had
to reset it.

kernel-2.4.20-9
kernel-pcmcia-cs-3.1.31-13

Message from /var/log/messages


May 14 13:51:30 localhost kernel: airo: BAP error 4000 2
May 14 13:51:31 localhost kernel: Warning: kfree_skb passed an skb still on a
list (from c01219fa).
May 14 13:51:31 localhost kernel: ------------[ cut here ]------------
May 14 13:51:31 localhost kernel: kernel BUG at skbuff.c:315!
May 14 13:51:31 localhost kernel: invalid operand: 0000
May 14 13:51:31 localhost kernel: nls_iso8859-1 nls_cp437 vfat fat ide-cd cdrom
ymfpci ac97_codec uart401 sound soundcore parport_pc lp parport autofs airo_cs
airo ds yenta_socket pcmcia_core
May 14 13:51:31 localhost kernel: CPU:    0
May 14 13:51:31 localhost kernel: EIP:    0060:[<c01f1994>]    Not tainted
May 14 13:51:31 localhost kernel: EFLAGS: 00010282
May 14 13:51:31 localhost kernel:
May 14 13:51:31 localhost kernel: EIP is at __kfree_skb [kernel] 0x144 (2.4.20-9)
May 14 13:51:31 localhost kernel: eax: 00000045   ebx: c36c8980   ecx: 00000001
  edx: c978e000
May 14 13:51:31 localhost kernel: esi: c1823f90   edi: c1822306   ebp: c1822000
  esp: c1823f78
May 14 13:51:31 localhost kernel: ds: 0068   es: 0068   ss: 0068
May 14 13:51:31 localhost kernel: Process keventd (pid: 2, stackpage=c1823000)
May 14 13:51:32 localhost kernel: Stack: c0275480 c01219fa c1822306 c1823f90
c01219fa c36c8980 ca56c2e4 ca56c2e4
May 14 13:51:32 localhost kernel:        00000001 c025e19b c012b9a3 c030ca70
c1823fb0 00000000 00000001 00000000
May 14 13:51:32 localhost kernel:        cbfa9f90 00010000 00000000 c012b890
00000000 c036945c 00000000 c1822000
May 14 13:51:32 localhost kernel: Call Trace:   [<c01219fa>] __run_task_queue
[kernel] 0x5a (0xc1823f7c))
May 14 13:51:32 localhost kernel: [<c01219fa>] __run_task_queue [kernel] 0x5a
(0xc1823f88))
May 14 13:51:32 localhost kernel: [<c012b9a3>] context_thread [kernel] 0x113
(0xc1823fa0))
May 14 13:51:32 localhost kernel: [<c012b890>] context_thread [kernel] 0x0
(0xc1823fc4))
May 14 13:51:32 localhost kernel: [<c012b890>] context_thread [kernel] 0x0
(0xc1823fe0))
May 14 13:51:32 localhost kernel: [<c010742d>] kernel_thread_helper [kernel] 0x5
(0xc1823ff0))
May 14 13:51:33 localhost kernel:
May 14 13:51:33 localhost kernel:
May 14 13:51:33 localhost kernel: Code: 0f 0b 3b 01 73 42 27 c0 8b 5c 24 14 e9
be fe ff ff 8d 74 26
May 14 13:51:33 localhost kernel:  <3>airo: BAP error 4000 2

*** Bug 88675 has been marked as a duplicate of this bug. ***

*** Bug 97187 has been marked as a duplicate of this bug. ***

According to http://sourceforge.net/tracker/?
atid=382983&group_id=24926&func=browse this is related to the firmware version 
on the card. (i.e. 5.X does this, 4.25.30 does not). However, I run with 
4.25.30 firware and it's happening to me.

The author of this driver appears to have abandoned it. (Ben Reed) He told me 
himself he hasn't messed with it in a year.

One other person at that URL suggests that the drivers from Cisco don't have 
this problem. I have not yet been able to verify that, but if true, are they 
GPL? Can our next kernel update have the cisco drivers?

I managed to reboot the box today and in 4 hours there was "Kernel PANIC!" all
over the place - somehow kernel-2.4.20-18.9 has managed to to set itself as
default kernel. 
Can anyone confirm if some newer release (2.4/2.6) of kernel has the aironet
driver fixed or when it may happen?

Javier Achirica and Ben Reed worked on it in the last few days. They have 
posted a 1.53 version of airo.c at sourceforge, in the cvs tree, not in 
the "files" section.

According to Javier, he found a race in the transmission path. Download airo.c 
and airo.h, put them in the right place in your kernel src tree, make modules, 
and copy the resulting airo.o into your /lib/modules.

Let's hope the major vendors pick up on this fix (if it works) and update the 
kernel rpm's.

I can confirm that for my situation (vnc via the wireless interface to a laptop
also on the wireless) the updated drivers from the sourceforge page work. I have
been using vnc via the wireless interface now for the past 20 minutes (usually
crashes the kernel after ~2 seconds of heavy traffic).

My method for building:

1) Get kernel-2.4.20-8.src.rpm, transfer to the affected machine (could be
problematic if the airo wireless is the only network interface ;) - in this
case, 'split' and 'cat' are your friends)

2) Install the rpm: rpm -Uvh kernel-2.4.20-8.src.rpm

3) cd /usr/src/redhat/SPECS

4) sudo rpmbuild -bp kernel-2.4.spec (patch a source tree)

5) cd /usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20

6) Edit the top level makefile, change 'EXTRAVERSION' from '-pre3' to '-8'

7) Copy the appropriate config from /usr/src/redhat/SOURCES - eg:
     cp /usr/src/redhat/SOURCES/kernel-2.4.20-athlon.config
/usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20/.config

8) Get the airo files from sourceforge cvs: see
http://sourceforge.net/cvs/?group_id=24926 for instructions on how to do this.
The module you want is 'airo-linux'

9) Copy the files from the 'airo-linux/kernel' directory to
/usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20/drivers/net/wireless

10) build dependencies: make dep

11) build modules: make modules

12) Copy the module object files into the appropriate directory: cp
/usr/src/redhat/BUILD/kernel-2.4.20/linux-2.4.20/drivers/net/wireless/airo*.o
/lib/modules/2.4.20-8/kernel/drivers/net/wireless
 *NOTE: you may want to back up the original driver object files first*

13) Bring the wireless interface down (/sbin/ifdown ethN)

14) Unload the old modules: /sbin/rmmod airo airo_cs

15) /sbin/depmod

16) Load the new modules (in my case, /sbin/cardctl eject 0; /sbin/cardctl insert 0)

Test it out!

Hope this helps.

Regards,
   Richard

I grabbed the 1.53 after Javier fixed it. Copied airo.c and airo.h 
to /usr/src/linux/blah/blah/blah
Edit airo.c to undefine MICSUPPORT (If you want it, get the other .c and .h 
files from the CVS tree)
make modules
copied the resulting airo.o up to /lib/modules

Works like a charm, haven't had a single problem since doing this.

Kernel is 2.4.20-86 Uniprocessor, laptop, Dell Latitude C600

This may or may not be relevant.  I never had this problem until I
started to run Fluxbox with GKRellM.  I have a Dell Inspiron 4150 and
an Airo 350.  My co-worker has a Sony Vaio R505-EL and he *also* did
not have this problem until he started running Flux / GKRellM.  We
both ditched GKRellM and have never had the problem again.

I am somewhat concerned that the major vendors appear to not have
picked up on the update. Last time I checked, everyone's latest distro
shipped with 0.6, STILL.

Anyone have a clue why this is?

We hesitate to pick up drivers that are not included in the upstream
kernel... I'm sure the others have the same or a very similar policy 

My kernel RH9 2.4.20-31.9 reports this error when i runn snmpd and 
mrtg 5min query from another point.
Bug crash afther 12 hours.

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/