Bug 51507 - wvlan_cs/orinoco_cs oops when put in promisc mode
Summary: wvlan_cs/orinoco_cs oops when put in promisc mode
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-11 11:32 UTC by Pekka Savola
Modified: 2013-07-03 02:04 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2003-06-06 16:53:32 UTC

Attachments (Terms of Use)
latest oops using orinoco_cs (5.42 KB, text/plain)
2002-03-17 20:44 UTC, Pekka Savola
no flags Details

Description Pekka Savola 2001-08-11 11:32:02 UTC
I'm experiencing oopses with orinoco_cs (also with wvlan_cs) within 10
seconds of putting the device into promisc mode.  Apparently there are
some weird packets on the wire that trigger this, as I don't recall seeing
this at work.

I'll check if I can reproduce this anymore next week..

Oops tracing done by hand so there may be errors..

On 2.4.7-0.8:

Call Trace: [<c587053f>] [<ff5e2000>] [<c01cb416>]
Warning (Oops_read): Code line not seen, dumping what data is available

Trace; c587053f <[hermes]hermes_bap_pread+43/64>
Trace; ff5e2000 <END_OF_CODE+39d66ded/????>
Trace; c01cb416 <alloc_skb+da/194>

On 2.4.6-3.1:

ops: 0000
CPU: 0
EIP: 0010:[<c012b73e>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010006
eax: 00000005 edx: c1257670 ecx: 00000800 edx: 000000a5
esi: 84008000 edi: 84008000 ebp: 00012800 esp: c0295dac
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage=c0295000)
Stack: 84008000 00000800 0000000? 00000246 c58755d9 c37f1a74 00000001 0000037e
       c4b24a04 00000020 80e72000 c37f1a74 c01da5d7 000005fc 00000020 00000001
       c37f18bc c58780bf 000005c0 00000020 c121968c c58782e4 00000594 c37f037c
Call Trace: [<c58755d9>] [<c01da5d7>] [<c58780bf>] [<c58782e4>] [<d44af9e0>]
[<c5877e2c>] [<c010856a>] [<c01086ed>] [<c022d2fa>] [<c021c084>] [<c01ce8a0>]
[<c010856c>] [<c0119e13>] [<c010871c>] [<c0105380>] [<c022d2f9>] [<c0105380>]
[<c01053a4>] [<c0105412>] [<C0105000>]
Code: f2 ae 74 05 bf 01 00 00 00 4f 89 7c 24 08 8b 14 24 8b 4c 24

>>EIP; c012b73e <kmalloc+10e/1e0>   <=====
Trace; c58755d9 <[hermes]hermes_bap_pread+49/70>
Trace; c01da5d7 <alloc_skb+e7/1b0>
Trace; c58780bf <[orinoco]__dldwd_ev_rx+17f/400>
Trace; c58782e4 <[orinoco]__dldwd_ev_rx+3a4/400>
Trace; d44af9e0 <END_OF_CODE+ec2e6ed/????>
Trace; c5877e2c <[orinoco]dldwd_interrupt+cc/180>
Trace; c010856a <handle_IRQ_event+3a/70>
Trace; c01086ed <do_IRQ+6d/b0>
Trace; c022d2fa <call_do_IRQ+5/b>
Trace; c021c084 <packet_rcv+4/280>
Trace; c01ce8a0 <fpatan+140/2e0>
Trace; c010856c <handle_IRQ_event+3c/70>
Trace; c0119e13 <do_softirq+53/a0>
Trace; c010871c <do_IRQ+9c/b0>
Trace; c0105380 <default_idle+0/30>
Trace; c022d2f9 <call_do_IRQ+4/b>
Trace; c0105380 <default_idle+0/30>
Trace; c01053a4 <default_idle+24/30>
Trace; c0105412 <cpu_idle+42/60>
Trace; c0105000 <_stext+0/0>
Code;  c012b73e <kmalloc+10e/1e0>
00000000 <_EIP>:
Code;  c012b73e <kmalloc+10e/1e0>   <=====
   0:   f2 ae                     repnz scas %es:(%edi),%al   <=====
Code;  c012b740 <kmalloc+110/1e0>
   2:   74 05                     je     9 <_EIP+0x9> c012b747 <kmalloc+117/1e0>
Code;  c012b742 <kmalloc+112/1e0>
   4:   bf 01 00 00 00            mov    $0x1,%edi
Code;  c012b747 <kmalloc+117/1e0>
   9:   4f                        dec    %edi
Code;  c012b748 <kmalloc+118/1e0>
   a:   89 7c 24 08               mov    %edi,0x8(%esp,1)
Code;  c012b74c <kmalloc+11c/1e0>
   e:   8b 14 24                  mov    (%esp,1),%edx
Code;  c012b74f <kmalloc+11f/1e0>
  11:   8b 4c 24 00               mov    0x0(%esp,1),%ecx

Comment 1 Glen Foster 2001-08-13 19:09:21 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 2 Pekka Savola 2001-08-13 19:13:53 UTC
Note: the same kernel && driver does not oops here at work; tcpdump works without problems.

However, there is no IPv6 traffic on the wire, or anything like that, which I believe might have been
causing the problems.  Or some weird traffic in any case, as this isn't reproducible in current environment.

Comment 3 Pekka Savola 2001-08-14 18:58:39 UTC
Also reported to the driver maintainer(s).  We'll see if they have some ideas; the location where the oops is happening
seemed rather unobvious to them though.

Comment 4 Arjan van de Ven 2001-08-17 09:50:54 UTC
updated to wvlan_cs as of 2.4.7-2.4; please see if that also barfs

Comment 5 Pekka Savola 2001-08-29 12:00:49 UTC
As said, I can't reproduce this here as I suspected.  So this is going to be in
state for a long time, I fear.

Comment 6 Arjan van de Ven 2001-08-29 12:03:55 UTC
Ok.. I think this is a candidate for "WORKSFORME" and please reopen when this
actually happens again.

Comment 7 Pekka Savola 2002-03-17 18:15:27 UTC
Yeah.. unfortuantely, at the next IETF I was, this kept happening again.

Comment 8 Pekka Savola 2002-03-17 19:49:34 UTC
Crash.. I wasn't able to ksymoops this properly:

[<c01d1fe0>] ip_rcv_finish [kernel] 0x0
[<c01c862b>] nf_hook_slow
[<c01d1fe0>] ip_rcv_finish
[<d88bd320>] __insmod_ipchains_S.data.L1884
[<c01d1e3b>] ip_rcv
[<c01d1fe0>] ip_rcv_finish
[<c01c30fa>] net_rx_action

Without ipchains being loaded, I got:

[<d8924204>] dldwd_interrupt_R8ef2b2c
[<c0114470>] do_page_fault
[<c0107038>] error_code
[<d88af880>] rh_int_timer_do

The problem also happened on 2.4.18-0.1 kernel.

Comment 9 Pekka Savola 2002-03-17 19:56:36 UTC
Happens on both orinoco_cs and wvlan_cs.  Firmware version is 7.52.  This is the
latest is 8.10, I'll upgrade to that but I highly doubt that's it.

Comment 10 Pekka Savola 2002-03-17 20:41:48 UTC
This didn't happen with a different card (airo_cs), so this is most probably a
driver problem.  Will try a different card (but one also using wvlan/orinoco)

Comment 11 Pekka Savola 2002-03-17 20:44:23 UTC
Created attachment 48806 [details]
latest oops using orinoco_cs

Comment 12 Jeff Garzik 2002-10-25 20:00:45 UTC
Can you please verify this continues to occur in Red Hat 8.0, and/or
the current stock kernel.org kernel (2.4.20-pre11)?

If so, please attach _another_ ksymoops trace, as the latest one appears to be

Comment 13 Pekka Savola 2002-10-25 20:13:10 UTC
Ok; I should be able to re-test this in a month or so.

Note You need to log in before you can comment on or make changes to this bug.