[Prism54-devel] [Bug 33] New: kernel bug with higher rts
bugzilla-daemon@mcgrof.com
bugzilla-daemon@mcgrof.com
Mon, 26 Jan 2004 23:45:02 +0000 (UTC)
http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=33
Summary: kernel bug with higher rts
Product: prim54
Version: 1.0.2.2
Platform: ia32
OS/Version: Linux 2.4
Status: ASSIGNED
Severity: normal
Priority: P2
Component: Device Driver
AssignedTo: prism54-devel@prism54.org
ReportedBy: john-and-kathy@shaw.ca
CC: Jens.Maurer@gmx.net,verwilst@pyxa.org
Software
kernel 2.4.23-pre9
wireless tools v16
driver snapshot 2004 01 03
modified to have VERBOSE = 0x2
driver installed with
modprobe prism54 eth1 pc_debug=7
hardware
133MHz pentium
PCI bus
SMC EZ Connect g
symptoms
bug when setting up driver with essid (which always worked) and new parameter
rts to be 2432 to match the AP. Default for rts on SMC is 2347 according to
iwconfig. So I am
increasing it. This is in aid of trying to fix a 15s to 40s timeout on
function (see web postings http://prism54.org/forums/viewtopic.php?t=212 .)
syslog was not very helpful as it has only this
Jan 4 12:23:32 192.68.1.1 kernel: Loaded prism54 driver, version 1.0.2.2
Jan 4 12:23:32 192.68.1.1 kernel: islpci_alloc_memory
Jan 4 12:23:50 192.68.1.1 kernel: eth1: islpci_open()
Jan 4 12:23:50 192.68.1.1 kernel: eth1: resetting device...
Jan 4 12:23:50 192.68.1.1 kernel: eth1: uploading firmware...
Jan 4 12:23:50 192.68.1.1 kernel: eth1: firmware uploaded done, now triggering
reset...
ksymoops 2.4.5 on i586 2.4.23-is. Options used
-V (default)
-k /var/log/ksymoops/20040104122214.ksyms (specified)
-l /var/log/ksymoops/20040104122214.modules (specified)
-o /lib/modules/2.4.23-is/ (default)
-m /boot/System.map-2.4.23-is (default)
kernel BUG at isl_38xx.h:176!
invalid operand: 0000
CPU: 0
EIP: 0010:<c3884380> Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010297
eax: 00000002 ebx: 00000000 ecx: 00000001 edx: ffffffff
esi: c20bb160 edi: 00000000 ebp: c1200000 esp: c26dbde4
Process syslogd (pid: 191, stackpage=c26db000)
Stack: 00000000 c20bb160 00000000 00000000 00000002 00000000 00000022 00000000
00000006 c38838bc c20bb160 c20bb160 c1b4ce60 04000001 0000000a c26dbe74
00000000 00000000 c0107f6f 0000000a c20bb160 c26dbe74 00000140 c02ffa40
Call Trace: <c38838bc> <c0107f6f> <c01080de> <c010a2a8> <c0124589>
<c0124724> <c0124d83> <c012f532> <c0124c84> <c012f665> <c0106c33>
Code: 0f 0b b0 00 4a a2 88 c3 83 fa 04 7e 08 0f 0b b5 00 4a a2 88
>>EIP; c3884380 <[prism54]islpci_alloc_memory+1f8/224> <=====
>>edx; ffffffff <END_OF_CODE+3c773f00/????>
>>esi; c20bb160 <_end+1d8e764/354c604>
>>ebp; c1200000 <_end+ed3604/354c604>
>>esp; c26dbde4 <_end+23af3e8/354c604>
Trace; c38838bc <[prism54]islpci_interrupt+17c/3d8>
Trace; c0107f6f <handle_IRQ_event+2f/58>
Trace; c01080de <do_IRQ+72/b4>
Trace; c010a2a8 <call_do_IRQ+5/d>
Trace; c0124589 <precheck_file_write+bd/200>
Trace; c0124724 <do_generic_file_write+58/3dc>
Trace; c0124d83 <generic_file_write+ff/11c>
Trace; c012f532 <do_readv_writev+1a2/240>
Trace; c0124c84 <generic_file_write+0/11c>
Trace; c012f665 <sys_writev+41/54>
Trace; c0106c33 <system_call+33/40>
Code; c3884380 <[prism54]islpci_alloc_memory+1f8/224>
00000000 <_EIP>:
Code; c3884380 <[prism54]islpci_alloc_memory+1f8/224> <=====
0: 0f 0b ud2a <=====
Code; c3884382 <[prism54]islpci_alloc_memory+1fa/224>
2: b0 00 mov $0x0,%al
Code; c3884384 <[prism54]islpci_alloc_memory+1fc/224>
4: 4a dec %edx
Code; c3884385 <[prism54]islpci_alloc_memory+1fd/224>
5: a2 88 c3 83 fa mov %al,0xfa83c388
Code; c388438a <[prism54]islpci_alloc_memory+202/224>
a: 04 7e add $0x7e,%al
Code; c388438c <[prism54]islpci_alloc_memory+204/224>
c: 08 0f or %cl,(%edi)
Code; c388438e <[prism54]islpci_alloc_memory+206/224>
e: 0b b5 00 4a a2 88 or 0x88a24a00(%ebp),%esi
<0> Kernel panic: Aiee, killing interrupt handler!
------- Additional Comments From Jens.Maurer@gmx.net 2004-01-08 22:57 -------
*** Bug 29 has been marked as a duplicate of this bug. ***
------- Additional Comments From Jens.Maurer@gmx.net 2004-01-08 23:00 -------
*** Bug 36 has been marked as a duplicate of this bug. ***
------- Additional Comments From john-and-kathy@shaw.ca 2004-01-13 22:59 -------
This (and bug 36) were using the 20040103 snapshot.
Trying to ping 1498 byte packets again, this time with cvs 2004 01 13. Same
results as before, which is to say, with short pings after 3 or 4 tries, a ping
attempt stops responding. Big packets hang or crash the machine.
Each test is
ifconfig eth1 down
ifconfig eth1 (inet) netmask (mask) broadcast (bcast) up
iwconfig eth1 essid etc
ping (ipofap) -c 3
ping (ipofap) -c 3
ping (ipofap) -c 3
usually get 100% 100% then 0%; sometimes the echo times are 1000ms. I get
similar response trying iwlist (instead of ping). After about 5 to 20 seconds
it doesn't work anymore. Instead of correct output I get jiffies countdowns.
When trying 1498 byte packets it gives a bug report immediately.
kernel is built from
linux-2.4.22.tar.bz2
patch-2.4.23-pre9.bz2
firmware is version 1.0.4.3, although the card shipped with 1.0.3.0.
ksymoops 2.4.5 on i586 2.4.23-is. Options used
-V (default)
-k /var/log/ksymoops/20040113140155.ksyms (specified)
-l /var/log/ksymoops/20040113140155.modules (specified)
-o /lib/modules/2.4.23-is/ (default)
-m /boot/System.map-2.4.23-is (default)
kernel BUG at isl_38xx.h:176!
invalid operand: 0000
CPU: 0
EIP: 0010<c3884df7> Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ffffffff ebx: c21b95c0 ecx: 00000004 edx: ffffffff
esi: c2017160 edi: c2017160 ebp: c1e80000 esp: c28f1d50
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 186, stackpage=c28f1000)
Stack: c21b95c0 c2017160 00000000 00000000 10000002 00000005 00000000 00000022
c3883581 c2017160 c2017160 c21b95c0 04000001 0000000a c28f1ddc 00000000
00000000 c0107f6f 0000000a c2017160 c28f1ddc 00000140 c02ffa40 0000000a
Call Trace: <c3883581> <c0107f6f> <c01080de> <c010a2a8> <c01278e3>
<c020a26a> <c020a27b> <c020a3e4> <c020d913> <c011693a> <c010810d>
<c010a2a8> <c0124796> <c01107a6> <c0124d83> <c012f532> <c0124c84>
<c012f665> <c0106c33>
Code: 0f 0b b0 00 8a 99 88 c3 90 83 f8 04 7e 0b 0f 0b b5 00 8a 99
>>EIP; c3884df7 <[prism54]islpci_mgt_transmit+53/1a8> <=====
>>eax; ffffffff <END_OF_CODE+3c774c3c/????>
>>ebx; c21b95c0 <_end+1e8cbc4/354c604>
>>edx; ffffffff <END_OF_CODE+3c774c3c/????>
>>esi; c2017160 <_end+1cea764/354c604>
>>edi; c2017160 <_end+1cea764/354c604>
>>ebp; c1e80000 <_end+1b53604/354c604>
>>esp; c28f1d50 <_end+25c5354/354c604>
Trace; c3883581 <[prism54]islpci_interrupt+c1/268>
Trace; c0107f6f <handle_IRQ_event+2f/58>
Trace; c01080de <do_IRQ+72/b4>
Trace; c010a2a8 <call_do_IRQ+5/d>
Trace; c01278e3 <kfree+af/b4>
Trace; c020a26a <skb_release_data+6e/74>
Trace; c020a27b <kfree_skbmem+b/54>
Trace; c020a3e4 <__kfree_skb+120/128>
Trace; c020d913 <net_tx_action+4f/b0>
Trace; c011693a <do_softirq+5a/ac>
Trace; c010810d <do_IRQ+a1/b4>
Trace; c010a2a8 <call_do_IRQ+5/d>
Trace; c0124796 <do_generic_file_write+ca/3dc>
Trace; c01107a6 <schedule+2ea/314>
Trace; c0124d83 <generic_file_write+ff/11c>
Trace; c012f532 <do_readv_writev+1a2/240>
Trace; c0124c84 <generic_file_write+0/11c>
Trace; c012f665 <sys_writev+41/54>
Trace; c0106c33 <system_call+33/40>
Code; c3884df7 <[prism54]islpci_mgt_transmit+53/1a8>
00000000 <_EIP>:
Code; c3884df7 <[prism54]islpci_mgt_transmit+53/1a8> <=====
0: 0f 0b ud2a <=====
Code; c3884df9 <[prism54]islpci_mgt_transmit+55/1a8>
2: b0 00 mov $0x0,%al
Code; c3884dfb <[prism54]islpci_mgt_transmit+57/1a8>
4: 8a 99 88 c3 90 83 mov 0x8390c388(%ecx),%bl
Code; c3884e01 <[prism54]islpci_mgt_transmit+5d/1a8>
a: f8 clc
Code; c3884e02 <[prism54]islpci_mgt_transmit+5e/1a8>
b: 04 7e add $0x7e,%al
Code; c3884e04 <[prism54]islpci_mgt_transmit+60/1a8>
d: 0b 0f or (%edi),%ecx
Code; c3884e06 <[prism54]islpci_mgt_transmit+62/1a8>
f: 0b b5 00 8a 99 00 or 0x998a00(%ebp),%esi
<0>Kernel panic: Aiee, killing interrupt handler!
------- Additional Comments From john-and-kathy@shaw.ca 2004-01-19 01:38 -------
Todays snapshot 20040118 just now downloaded continues to fail the same way. I
was hoping based on changlog that some symptom might have improved, but, not
yet.
------- Additional Comments From Jens.Maurer@gmx.net 2004-01-26 23:45 -------
If you have CVS access, please try the "mgmt_rework" branch; it may fix your
problem.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.