Bug 51507 - wvlan_cs/orinoco_cs oops when put in promisc mode
wvlan_cs/orinoco_cs oops when put in promisc mode
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-08-11 07:32 EDT by Pekka Savola
Modified: 2013-07-02 22:04 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-06 12:53:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Pekka Savola 2001-08-11 07:32:02 EDT
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 15:09:21 EDT
This defect is considered SHOULD-FIX for Fairfax.
Comment 2 Pekka Savola 2001-08-13 15:13:53 EDT
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 14:58:39 EDT
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 05:50:54 EDT
updated to wvlan_cs as of 2.4.7-2.4; please see if that also barfs
Comment 5 Pekka Savola 2001-08-29 08:00:49 EDT
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 08:03:55 EDT
Ok.. I think this is a candidate for "WORKSFORME" and please reopen when this
actually happens again.
Comment 7 Pekka Savola 2002-03-17 13:15:27 EST
Yeah.. unfortuantely, at the next IETF I was, this kept happening again.
Comment 8 Pekka Savola 2002-03-17 14:49:34 EST
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 14:56:36 EST
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 15:41:48 EST
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 15:44:23 EST
Created attachment 48806 [details]
latest oops using orinoco_cs
Comment 12 Jeff Garzik 2002-10-25 16:00:45 EDT
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 16:13:10 EDT
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.