Bug 51507
| Summary: | wvlan_cs/orinoco_cs oops when put in promisc mode | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Pekka Savola <pekkas> | ||||
| Component: | kernel | Assignee: | Jeff Garzik <jgarzik> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.3 | CC: | herrold, peterm | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2003-06-06 16:53:32 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This defect is considered SHOULD-FIX for Fairfax. 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. 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. updated to wvlan_cs as of 2.4.7-2.4; please see if that also barfs As said, I can't reproduce this here as I suspected. So this is going to be in NEEDINFO state for a long time, I fear. Ok.. I think this is a candidate for "WORKSFORME" and please reopen when this actually happens again. Yeah.. unfortuantely, at the next IETF I was, this kept happening again. 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. Happens on both orinoco_cs and wvlan_cs. Firmware version is 7.52. This is the second-latest, latest is 8.10, I'll upgrade to that but I highly doubt that's it. 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) later. Created attachment 48806 [details]
latest oops using orinoco_cs
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 corrupted. Ok; I should be able to re-test this in a month or so. |
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