Hi Jean,
I hope you are the right person for this problem. I've found your E-Mail address in the code..
I use the kernel pcmcia driver for the aironet-card. Every time when I copy some larger files over the net with samba, scp or nfs, I get a kernel-oops. After that my keyboard hangs and I have to reboot. Alt-SysRq-XY still works. Today I saw (In xosview) that the keyboard still generates Interrupts.
With Kernel 2.4.19 there are no such problems..
Thank you.
Kind regards
Marc
ksymoops -m /boot/System.map oops3.txt
ksymoops 2.4.8 on i686 2.4.20. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.20/ (default)
-m /boot/System.map (specified)
Feb 3 11:24:55 vaio kernel: Warning: kfree_skb passed an skb still on a list (from c0121fca).
Feb 3 11:24:55 vaio kernel: kernel BUG at skbuff.c:315!
Feb 3 11:24:55 vaio kernel: invalid operand: 0000
Feb 3 11:24:55 vaio kernel: CPU: 0
Feb 3 11:24:55 vaio kernel: EIP: 0010:[__kfree_skb+324/352] Not tainted
Feb 3 11:24:55 vaio kernel: EIP: 0010:[<c026cd54>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Feb 3 11:24:55 vaio kernel: EFLAGS: 00010286
Feb 3 11:24:55 vaio kernel: eax: 00000045 ebx: cb41fbe0 ecx: cba0e000 edx: cba0ff7c
Feb 3 11:24:55 vaio kernel: esi: c1339f84 edi: 00000000 ebp: c1338000 esp: c1339f6c
Feb 3 11:24:55 vaio kernel: ds: 0018 es: 0018 ss: 0018
Feb 3 11:24:55 vaio kernel: Process keventd (pid: 2, stackpage=c1339000)
Feb 3 11:24:55 vaio kernel: Stack: c0314840 c0121fca 00000000 c1339f84 c0121fca cb41fbe0 cb5142e4 cb5142e4
Feb 3 11:24:55 vaio kernel: 00000000 00000000 c012ac83 c032abd0 c1339fb0 00000000 c1338560 c1338570
Feb 3 11:24:55 vaio kernel: c1338000 00000001 00000000 cffe5f90 00010000 00000000 00000700 c012ab50
Feb 3 11:24:55 vaio kernel: Call Trace: [__run_task_queue+90/112] [__run_task_queue+90/112] [context_thread+307/448] [context_thread+0/448] [rest_init+0/64]
Feb 3 11:24:55 vaio kernel: Call Trace: [<c0121fca>] [<c0121fca>] [<c012ac83>] [<c012ab50>] [<c0105000>]
Feb 3 11:24:55 vaio kernel: [<c010749e>] [<c012ab50>]
Feb 3 11:24:55 vaio kernel: Code: 0f 0b 3b 01 cf 2d 31 c0 8b 5c 24 14 e9 be fe ff ff 90 8d 76
>>EIP; c026cd54 <__kfree_skb+144/160> <=====
>>ebx; cb41fbe0 <_end+b073014/10826494>
>>ecx; cba0e000 <_end+b661434/10826494>
>>edx; cba0ff7c <_end+b6633b0/10826494>
>>esi; c1339f84 <_end+f8d3b8/10826494>
>>ebp; c1338000 <_end+f8b434/10826494>
>>esp; c1339f6c <_end+f8d3a0/10826494>
Trace; c0121fca <__run_task_queue+5a/70>
Trace; c0121fca <__run_task_queue+5a/70>
Trace; c012ac83 <context_thread+133/1c0>
Trace; c012ab50 <context_thread+0/1c0>
Trace; c0105000 <_stext+0/0>
Trace; c010749e <kernel_thread+2e/40>
Trace; c012ab50 <context_thread+0/1c0>
Code; c026cd54 <__kfree_skb+144/160>
00000000 <_EIP>:
Code; c026cd54 <__kfree_skb+144/160> <=====
0: 0f 0b ud2a <=====
Code; c026cd56 <__kfree_skb+146/160>
2: 3b 01 cmp (%ecx),%eax
Code; c026cd58 <__kfree_skb+148/160>
4: cf iret
Code; c026cd59 <__kfree_skb+149/160>
5: 2d 31 c0 8b 5c sub $0x5c8bc031,%eax
Code; c026cd5e <__kfree_skb+14e/160>
a: 24 14 and $0x14,%al
Code; c026cd60 <__kfree_skb+150/160>
c: e9 be fe ff ff jmp fffffecf <_EIP+0xfffffecf>
Code; c026cd65 <__kfree_skb+155/160>
11: 90 nop
Code; c026cd66 <__kfree_skb+156/160>
12: 8d 76 00 lea 0x0(%esi),%esi
I've had oopses in 2.4.19 if I leave Cisco's acu utility running while
I have much net activity. Haven't looked to see if it still happens
in 2.4.20 or expended the effort to get better debug info. I'm using
a cisco 352lmc card fwiw.
Tim
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************
On Wed, Feb 12, 2003 at 04:18:50PM -0800, Tim Pepper wrote:
> I've had oopses in 2.4.19 if I leave Cisco's acu utility running while
> I have much net activity. Haven't looked to see if it still happens
> in 2.4.20 or expended the effort to get better debug info. I'm using
> a cisco 352lmc card fwiw.
>
> Tim
Why don't you report it to the driver maintainers ?
Please note that ACU is closed source, so it will be probably
more difficult to debug.
Regards,
Jean
> [[email protected]]
>
> I've had oopses in 2.4.19 if I leave Cisco's acu utility running while
> I have much net activity. Haven't looked to see if it still happens
> in 2.4.20 or expended the effort to get better debug info. I'm using
> a cisco 352lmc card fwiw.
Also the driver deterministically oopses upon the rmmod of airo.o.
It's been like that since 2.4.18 or so.
--
Tomas Szepe <[email protected]>
On Wed 12 Feb at 16:21:19 -0800 [email protected] done said:
>
> Why don't you report it to the driver maintainers ?
> Please note that ACU is closed source, so it will be probably
> more difficult to debug.
I was just adding my input in case Mr. Giger was running acu. Since acu's
closed source I stopped using it...symptom solved. I did drop a line
to what I thought was one of the airo driver maintainers...no response.
t.
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************
On Wed, Feb 12, 2003 at 06:16:11PM -0800, Tim Pepper wrote:
> On Wed 12 Feb at 16:21:19 -0800 [email protected] done said:
> >
> > Why don't you report it to the driver maintainers ?
> > Please note that ACU is closed source, so it will be probably
> > more difficult to debug.
>
> I was just adding my input in case Mr. Giger was running acu. Since acu's
> closed source I stopped using it...symptom solved. I did drop a line
> to what I thought was one of the airo driver maintainers...no response.
>
> t.
Ben or Javier ?
Jean
Hi,
On Wed, 12 Feb 2003 18:18:22 -0800
Jean Tourrilhes <[email protected]> wrote:
> On Wed, Feb 12, 2003 at 06:16:11PM -0800, Tim Pepper wrote:
> > On Wed 12 Feb at 16:21:19 -0800 [email protected] done said:
> > >
> > > Why don't you report it to the driver maintainers ?
> > > Please note that ACU is closed source, so it will be probably
> > > more difficult to debug.
> >
> > I was just adding my input in case Mr. Giger was running acu. Since acu's
No, I don't use acu. iwconfig does the job for me..
> > closed source I stopped using it...symptom solved. I did drop a line
> > to what I thought was one of the airo driver maintainers...no response.
> >
> > t.
>
> Ben or Javier ?
As you mentioned, I wrote Ben AND Javier an e-mail. I got also no response......:-(
greets
Marc
On Thu, 13 Feb 2003 01:54:43 +0100
Tomas Szepe <[email protected]> wrote:
> > [[email protected]]
> >
> > I've had oopses in 2.4.19 if I leave Cisco's acu utility running while
> > I have much net activity. Haven't looked to see if it still happens
> > in 2.4.20 or expended the effort to get better debug info. I'm using
> > a cisco 352lmc card fwiw.
>
> Also the driver deterministically oopses upon the rmmod of airo.o.
> It's been like that since 2.4.18 or so.
I've never made this experience..I use the driver for more than 2 years.
On my laptop the driver will be unloaded 2-3 times per day...no oops..
Interesting is that some of my friends use the same card and the same driver / kernel and they don't have any problems..
Perhaps my card is defective? How can I test it?
greets
Marc
On Wed 12 Feb at 18:18:22 -0800 [email protected] done said:
>
> Ben or Javier ?
I just tried Ben since I kinda know him through work.
t.
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************
I'm reporting mine as well. Using the kernel PCMCIA and airo.o module.
This occurred after 90 minutes of use, where the card was streaming
under a megabit of traffic at all times. Lost control of everything but
video and the USB bus.
Cisco AiroNet 350 card.
Linux Odyssey.brad-x.com 2.4.20 #10 Fri Feb 28 10:57:59 EST 2003 i686
Feb 28 11:01:15 Odyssey kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Feb 28 11:01:15 Odyssey kernel: ac97_codec: AC97 Audio codec, id:
\203\204v9(SigmaTel STAC9721/23)
Feb 28 14:59:22 Odyssey kernel: cs: memory probe 0xa0000000-0xa0ffffff:
clean.
Feb 28 16:16:08 Odyssey kernel: Warning: kfree_skb passed an skb still
on a list (from c01201ba).
Feb 28 16:16:08 Odyssey kernel: kernel BUG at skbuff.c:315!
Feb 28 16:16:08 Odyssey kernel: invalid operand: 0000
Feb 28 16:16:08 Odyssey kernel: CPU: 0
Feb 28 16:16:08 Odyssey kernel: EIP: 0010:[start_request+164/528]
Tainted: P
Feb 28 16:16:08 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
Feb 28 16:16:08 Odyssey kernel: EFLAGS: 00010286
Feb 28 16:16:08 Odyssey kernel: eax: 00000045 ebx: c8c504a0 ecx:
cec36000
edx: cec37f7c
Feb 28 16:16:08 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp:
c12f0000
esp: c12f1f6c
Feb 28 16:16:08 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
Feb 28 16:16:08 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
Feb 28 16:16:08 Odyssey kernel: Stack: c0244620 c01201ba 00000000
c12f1f84 c01201ba c8c504a0 ca2dc2e4 ca2dc2e4
Feb 28 16:16:08 Odyssey kernel: 00000000 00000000 c0128df3
c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
Feb 28 16:16:08 Odyssey kernel: c12f0000 00000001 00000000
c0253fa0 00010000 00000000 00000700 c0128cc0
Feb 28 16:16:08 Odyssey kernel: Call Trace:
[sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224]
[vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
Feb 28 16:16:08 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>]
[<c0128df3>] [<c0128cc0>] [<c0105000>]
Feb 28 16:16:08 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
Feb 28 16:16:08 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24
14 e9 0e
ff ff ff 8d 74 26
>>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>>ebx; c8c504a0 <___strtok+897dc6c/1062382c>
>>ecx; cec36000 <___strtok+e9637cc/1062382c>
>>edx; cec37f7c <___strtok+e965748/1062382c>
>>esi; c12f1f84 <___strtok+101f750/1062382c>
>>ebp; c12f0000 <___strtok+101d7cc/1062382c>
>>esp; c12f1f6c <___strtok+101f738/1062382c>
Trace; c01201ba <__run_task_queue+5a/140>
Trace; c01201ba <__run_task_queue+5a/140>
Trace; c0128df3 <schedule_task+1a3/230>
Trace; c0128cc0 <schedule_task+70/230>
Trace; c0105000 <empty_zero_page+1000/1380>
Trace; c01057ce <kernel_thread+2e/240>
Trace; c0128cc0 <schedule_task+70/230>
Code; c01dca24 <__kfree_skb+f4/110>
00000000 <_EIP>:
Code; c01dca24 <__kfree_skb+f4/110> <=====
0: 0f 0b ud2a <=====
Code; c01dca26 <__kfree_skb+f6/110>
2: 3b 01 cmp (%ecx),%eax
Code; c01dca28 <__kfree_skb+f8/110>
4: b1 38 mov $0x38,%cl
Code; c01dca2a <__kfree_skb+fa/110>
6: 24 c0 and $0xc0,%al
Code; c01dca2c <__kfree_skb+fc/110>
8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
Code; c01dca30 <__kfree_skb+100/110>
c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
Code; c01dca35 <__kfree_skb+105/110>
11: 8d 74 26 00 lea 0x0(%esi,1),%esi
--
// -- http://www.BRAD-X.com/ -- //
Using the kernel PCMCIA and airo.o module. This occurred after 90
minutes of use, where the card was streaming under a megabit of traffic
at all times. Lost control of everything but video and the USB bus.
Cisco AiroNet 350 card. Several protocols in use at the time including
HTTP/SSH/NFS.
Linux Odyssey.brad-x.com 2.4.20 #10 Fri Feb 28 10:57:59 EST 2003 i686
KSymoops:
Feb 28 11:01:15 Odyssey kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Feb 28 11:01:15 Odyssey kernel: ac97_codec: AC97 Audio codec, id:
\203\204v9(SigmaTel STAC9721/23)
Feb 28 14:59:22 Odyssey kernel: cs: memory probe 0xa0000000-0xa0ffffff:
clean.
Feb 28 16:16:08 Odyssey kernel: Warning: kfree_skb passed an skb still
on a list (from c01201ba).
Feb 28 16:16:08 Odyssey kernel: kernel BUG at skbuff.c:315!
Feb 28 16:16:08 Odyssey kernel: invalid operand: 0000
Feb 28 16:16:08 Odyssey kernel: CPU: 0
Feb 28 16:16:08 Odyssey kernel: EIP: 0010:[start_request+164/528]
Tainted: P
Feb 28 16:16:08 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
Feb 28 16:16:08 Odyssey kernel: EFLAGS: 00010286
Feb 28 16:16:08 Odyssey kernel: eax: 00000045 ebx: c8c504a0 ecx:
cec36000
edx: cec37f7c
Feb 28 16:16:08 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp:
c12f0000
esp: c12f1f6c
Feb 28 16:16:08 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
Feb 28 16:16:08 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
Feb 28 16:16:08 Odyssey kernel: Stack: c0244620 c01201ba 00000000
c12f1f84 c01201ba c8c504a0 ca2dc2e4 ca2dc2e4
Feb 28 16:16:08 Odyssey kernel: 00000000 00000000 c0128df3
c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
Feb 28 16:16:08 Odyssey kernel: c12f0000 00000001 00000000
c0253fa0 00010000 00000000 00000700 c0128cc0
Feb 28 16:16:08 Odyssey kernel: Call Trace:
[sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224]
[vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
Feb 28 16:16:08 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>]
[<c0128df3>] [<c0128cc0>] [<c0105000>]
Feb 28 16:16:08 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
Feb 28 16:16:08 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24
14 e9 0e
ff ff ff 8d 74 26
>>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>>ebx; c8c504a0 <___strtok+897dc6c/1062382c>
>>ecx; cec36000 <___strtok+e9637cc/1062382c>
>>edx; cec37f7c <___strtok+e965748/1062382c>
>>esi; c12f1f84 <___strtok+101f750/1062382c>
>>ebp; c12f0000 <___strtok+101d7cc/1062382c>
>>esp; c12f1f6c <___strtok+101f738/1062382c>
Trace; c01201ba <__run_task_queue+5a/140>
Trace; c01201ba <__run_task_queue+5a/140>
Trace; c0128df3 <schedule_task+1a3/230>
Trace; c0128cc0 <schedule_task+70/230>
Trace; c0105000 <empty_zero_page+1000/1380>
Trace; c01057ce <kernel_thread+2e/240>
Trace; c0128cc0 <schedule_task+70/230>
Code; c01dca24 <__kfree_skb+f4/110>
00000000 <_EIP>:
Code; c01dca24 <__kfree_skb+f4/110> <=====
0: 0f 0b ud2a <=====
Code; c01dca26 <__kfree_skb+f6/110>
2: 3b 01 cmp (%ecx),%eax
Code; c01dca28 <__kfree_skb+f8/110>
4: b1 38 mov $0x38,%cl
Code; c01dca2a <__kfree_skb+fa/110>
6: 24 c0 and $0xc0,%al
Code; c01dca2c <__kfree_skb+fc/110>
8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
Code; c01dca30 <__kfree_skb+100/110>
c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
Code; c01dca35 <__kfree_skb+105/110>
11: 8d 74 26 00 lea 0x0(%esi,1),%esi
--
// -- http://www.BRAD-X.com/ -- //
Hi All,
I've reached Javier! He said that we should try the latest CVS Version of the driver at airo-linux.sf.net.
greets
Marc
ksymoops 2.4.8 on i686 2.4.20. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.20/ (default)
-m /boot/System.map (specified)
Warning (compare_maps): mismatch on symbol __nvsym03120 , NVdriver says d09e7a60, /lib/modules/2.4.20/video/NVdriver says d09e0320. Ignoring /lib/modules/2.4.20/video/NVdriver entry
Mar 1 18:04:30 Odyssey kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Mar 1 18:04:30 Odyssey kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
Mar 1 18:04:30 Odyssey kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Mar 1 18:05:08 Odyssey kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
Mar 1 18:14:39 Odyssey kernel: Warning: kfree_skb passed an skb still on a list (from c01201ba).
Mar 1 18:14:39 Odyssey kernel: kernel BUG at skbuff.c:315!
Mar 1 18:14:39 Odyssey kernel: invalid operand: 0000
Mar 1 18:14:39 Odyssey kernel: CPU: 0
Mar 1 18:14:39 Odyssey kernel: EIP: 0010:[start_request+164/528] Tainted: P
Mar 1 18:14:39 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
Mar 1 18:14:39 Odyssey kernel: EFLAGS: 00010286
Mar 1 18:14:39 Odyssey kernel: eax: 00000045 ebx: c267c860 ecx: cd36e000 edx: cd36ff7c
Mar 1 18:14:39 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp: c12f0000 esp: c12f1f6c
Mar 1 18:14:39 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
Mar 1 18:14:39 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
Mar 1 18:14:39 Odyssey kernel: Stack: c0244620 c01201ba 00000000 c12f1f84 c01201ba c267c860 cea682e4 cea682e4
Mar 1 18:14:39 Odyssey kernel: 00000000 00000000 c0128df3 c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
Mar 1 18:14:39 Odyssey kernel: c12f0000 00000001 00000000 c0253fa0 00010000 00000000 00000700 c0128cc0
Mar 1 18:14:39 Odyssey kernel: Call Trace: [sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224] [vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
Mar 1 18:14:39 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>] [<c0128df3>] [<c0128cc0>] [<c0105000>]
Mar 1 18:14:39 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
Mar 1 18:14:39 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24 14 e9 0e ff ff ff 8d 74 26
>>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>>ebx; c267c860 <_end+23aa028/10623828>
>>ecx; cd36e000 <_end+d09b7c8/10623828>
>>edx; cd36ff7c <_end+d09d744/10623828>
>>esi; c12f1f84 <_end+101f74c/10623828>
>>ebp; c12f0000 <_end+101d7c8/10623828>
>>esp; c12f1f6c <_end+101f734/10623828>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c0128df3 <context_thread+133/1c0>
Trace; c0128cc0 <context_thread+0/1c0>
Trace; c0105000 <_stext+0/0>
Trace; c01057ce <kernel_thread+2e/40>
Trace; c0128cc0 <context_thread+0/1c0>
Code; c01dca24 <__kfree_skb+f4/110>
00000000 <_EIP>:
Code; c01dca24 <__kfree_skb+f4/110> <=====
0: 0f 0b ud2a <=====
Code; c01dca26 <__kfree_skb+f6/110>
2: 3b 01 cmp (%ecx),%eax
Code; c01dca28 <__kfree_skb+f8/110>
4: b1 38 mov $0x38,%cl
Code; c01dca2a <__kfree_skb+fa/110>
6: 24 c0 and $0xc0,%al
Code; c01dca2c <__kfree_skb+fc/110>
8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
Code; c01dca30 <__kfree_skb+100/110>
c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
Code; c01dca35 <__kfree_skb+105/110>
11: 8d 74 26 00 lea 0x0(%esi,1),%esi
Mar 1 18:17:01 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 18:17:01 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
Mar 1 18:18:51 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 18:18:51 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
1 warning issued. Results may not be reliable.
On Sat, 1 Mar 2003, Brad Laue wrote:
> Still crashes:
>
> static const char version[] = "$Revision: 1.46 $";
>
> ksymoops output attached.
>
Can you reproduce the crash without the Nvidia module loaded?
- James
--
James Morris
<[email protected]>
ksymoops 2.4.8 on i686 2.4.20. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.20/ (default)
-m /boot/System.map (specified)
Mar 1 18:04:30 Odyssey kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Mar 1 18:04:30 Odyssey kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
Mar 1 18:04:30 Odyssey kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Mar 1 18:05:08 Odyssey kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
Mar 1 18:14:39 Odyssey kernel: Warning: kfree_skb passed an skb still on a list (from c01201ba).
Mar 1 18:14:39 Odyssey kernel: kernel BUG at skbuff.c:315!
Mar 1 18:14:39 Odyssey kernel: invalid operand: 0000
Mar 1 18:14:39 Odyssey kernel: CPU: 0
Mar 1 18:14:39 Odyssey kernel: EIP: 0010:[start_request+164/528] Tainted: P
Mar 1 18:14:39 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
Mar 1 18:14:39 Odyssey kernel: EFLAGS: 00010286
Mar 1 18:14:39 Odyssey kernel: eax: 00000045 ebx: c267c860 ecx: cd36e000 edx: cd36ff7c
Mar 1 18:14:39 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp: c12f0000 esp: c12f1f6c
Mar 1 18:14:39 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
Mar 1 18:14:39 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
Mar 1 18:14:39 Odyssey kernel: Stack: c0244620 c01201ba 00000000 c12f1f84 c01201ba c267c860 cea682e4 cea682e4
Mar 1 18:14:39 Odyssey kernel: 00000000 00000000 c0128df3 c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
Mar 1 18:14:39 Odyssey kernel: c12f0000 00000001 00000000 c0253fa0 00010000 00000000 00000700 c0128cc0
Mar 1 18:14:39 Odyssey kernel: Call Trace: [sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224] [vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
Mar 1 18:14:39 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>] [<c0128df3>] [<c0128cc0>] [<c0105000>]
Mar 1 18:14:39 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
Mar 1 18:14:39 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24 14 e9 0e ff ff ff 8d 74 26
>>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>>ebx; c267c860 <_end+23aa028/10623828>
>>ecx; cd36e000 <_end+d09b7c8/10623828>
>>edx; cd36ff7c <_end+d09d744/10623828>
>>esi; c12f1f84 <_end+101f74c/10623828>
>>ebp; c12f0000 <_end+101d7c8/10623828>
>>esp; c12f1f6c <_end+101f734/10623828>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c0128df3 <context_thread+133/1c0>
Trace; c0128cc0 <context_thread+0/1c0>
Trace; c0105000 <_stext+0/0>
Trace; c01057ce <kernel_thread+2e/40>
Trace; c0128cc0 <context_thread+0/1c0>
Code; c01dca24 <__kfree_skb+f4/110>
00000000 <_EIP>:
Code; c01dca24 <__kfree_skb+f4/110> <=====
0: 0f 0b ud2a <=====
Code; c01dca26 <__kfree_skb+f6/110>
2: 3b 01 cmp (%ecx),%eax
Code; c01dca28 <__kfree_skb+f8/110>
4: b1 38 mov $0x38,%cl
Code; c01dca2a <__kfree_skb+fa/110>
6: 24 c0 and $0xc0,%al
Code; c01dca2c <__kfree_skb+fc/110>
8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
Code; c01dca30 <__kfree_skb+100/110>
c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
Code; c01dca35 <__kfree_skb+105/110>
11: 8d 74 26 00 lea 0x0(%esi,1),%esi
Mar 1 18:17:01 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 18:17:01 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
Mar 1 18:18:51 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 18:18:51 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
Mar 1 19:00:06 Odyssey kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Mar 1 19:00:06 Odyssey kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
Mar 1 19:00:06 Odyssey kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Mar 1 19:01:11 Odyssey kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
Mar 1 19:13:19 Odyssey kernel: Warning: kfree_skb passed an skb still on a list (from c01201ba).
Mar 1 19:13:19 Odyssey kernel: kernel BUG at skbuff.c:315!
Mar 1 19:13:19 Odyssey kernel: invalid operand: 0000
Mar 1 19:13:19 Odyssey kernel: CPU: 0
Mar 1 19:13:19 Odyssey kernel: EIP: 0010:[start_request+164/528] Tainted: P
Mar 1 19:13:19 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
Mar 1 19:13:19 Odyssey kernel: EFLAGS: 00010286
Mar 1 19:13:19 Odyssey kernel: eax: 00000045 ebx: c550f760 ecx: cf026000 edx: cf027f7c
Mar 1 19:13:19 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp: c12f0000 esp: c12f1f6c
Mar 1 19:13:19 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
Mar 1 19:13:19 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
Mar 1 19:13:19 Odyssey kernel: Stack: c0244620 c01201ba 00000000 c12f1f84 c01201ba c550f760 cedd82e4 cedd82e4
Mar 1 19:13:19 Odyssey kernel: 00000000 00000000 c0128df3 c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
Mar 1 19:13:19 Odyssey kernel: c12f0000 00000001 00000000 c0253fa0 00010000 00000000 00000700 c0128cc0
Mar 1 19:13:19 Odyssey kernel: Call Trace: [sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224] [vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
Mar 1 19:13:19 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>] [<c0128df3>] [<c0128cc0>] [<c0105000>]
Mar 1 19:13:19 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
Mar 1 19:13:19 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24 14 e9 0e ff ff ff 8d 74 26
>>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>>ebx; c550f760 <_end+523cf28/10623828>
>>ecx; cf026000 <_end+ed537c8/10623828>
>>edx; cf027f7c <_end+ed55744/10623828>
>>esi; c12f1f84 <_end+101f74c/10623828>
>>ebp; c12f0000 <_end+101d7c8/10623828>
>>esp; c12f1f6c <_end+101f734/10623828>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c0128df3 <context_thread+133/1c0>
Trace; c0128cc0 <context_thread+0/1c0>
Trace; c0105000 <_stext+0/0>
Trace; c01057ce <kernel_thread+2e/40>
Trace; c0128cc0 <context_thread+0/1c0>
Code; c01dca24 <__kfree_skb+f4/110>
00000000 <_EIP>:
Code; c01dca24 <__kfree_skb+f4/110> <=====
0: 0f 0b ud2a <=====
Code; c01dca26 <__kfree_skb+f6/110>
2: 3b 01 cmp (%ecx),%eax
Code; c01dca28 <__kfree_skb+f8/110>
4: b1 38 mov $0x38,%cl
Code; c01dca2a <__kfree_skb+fa/110>
6: 24 c0 and $0xc0,%al
Code; c01dca2c <__kfree_skb+fc/110>
8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
Code; c01dca30 <__kfree_skb+100/110>
c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
Code; c01dca35 <__kfree_skb+105/110>
11: 8d 74 26 00 lea 0x0(%esi,1),%esi
Mar 1 19:16:52 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 19:16:52 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
Mar 1 19:17:25 Odyssey kernel: cs: IO port probe 0x0c00-0x0cff: clean.
Mar 1 19:17:25 Odyssey kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7
Mar 1 19:17:25 Odyssey kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Mar 1 19:17:38 Odyssey kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.
Mar 1 19:22:28 Odyssey kernel: Warning: kfree_skb passed an skb still on a list (from c01201ba).
Mar 1 19:22:28 Odyssey kernel: kernel BUG at skbuff.c:315!
Mar 1 19:22:28 Odyssey kernel: invalid operand: 0000
Mar 1 19:22:28 Odyssey kernel: CPU: 0
Mar 1 19:22:28 Odyssey kernel: EIP: 0010:[start_request+164/528] Tainted: P
Mar 1 19:22:28 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
Mar 1 19:22:28 Odyssey kernel: EFLAGS: 00010286
Mar 1 19:22:28 Odyssey kernel: eax: 00000045 ebx: caaf3320 ecx: ccd20000 edx: ccd21f7c
Mar 1 19:22:28 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp: c12f0000 esp: c12f1f6c
Mar 1 19:22:28 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
Mar 1 19:22:28 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
Mar 1 19:22:28 Odyssey kernel: Stack: c0244620 c01201ba 00000000 c12f1f84 c01201ba caaf3320 ccedc2e4 ccedc2e4
Mar 1 19:22:28 Odyssey kernel: 00000000 00000000 c0128df3 c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
Mar 1 19:22:28 Odyssey kernel: c12f0000 00000001 00000000 c0253fa0 00010000 00000000 00000700 c0128cc0
Mar 1 19:22:28 Odyssey kernel: Call Trace: [sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224] [vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
Mar 1 19:22:28 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>] [<c0128df3>] [<c0128cc0>] [<c0105000>]
Mar 1 19:22:28 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
Mar 1 19:22:28 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24 14 e9 0e ff ff ff 8d 74 26
>>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>>ebx; caaf3320 <_end+a820ae8/10623828>
>>ecx; ccd20000 <_end+ca4d7c8/10623828>
>>edx; ccd21f7c <_end+ca4f744/10623828>
>>esi; c12f1f84 <_end+101f74c/10623828>
>>ebp; c12f0000 <_end+101d7c8/10623828>
>>esp; c12f1f6c <_end+101f734/10623828>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c01201ba <__run_task_queue+5a/70>
Trace; c0128df3 <context_thread+133/1c0>
Trace; c0128cc0 <context_thread+0/1c0>
Trace; c0105000 <_stext+0/0>
Trace; c01057ce <kernel_thread+2e/40>
Trace; c0128cc0 <context_thread+0/1c0>
Code; c01dca24 <__kfree_skb+f4/110>
00000000 <_EIP>:
Code; c01dca24 <__kfree_skb+f4/110> <=====
0: 0f 0b ud2a <=====
Code; c01dca26 <__kfree_skb+f6/110>
2: 3b 01 cmp (%ecx),%eax
Code; c01dca28 <__kfree_skb+f8/110>
4: b1 38 mov $0x38,%cl
Code; c01dca2a <__kfree_skb+fa/110>
6: 24 c0 and $0xc0,%al
Code; c01dca2c <__kfree_skb+fc/110>
8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
Code; c01dca30 <__kfree_skb+100/110>
c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
Code; c01dca35 <__kfree_skb+105/110>
11: 8d 74 26 00 lea 0x0(%esi,1),%esi
Mar 1 19:24:00 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 19:24:00 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
Mar 1 19:25:31 Odyssey kernel: Receiver lock-up bug exists -- enabling work-around.
Mar 1 19:25:31 Odyssey kernel: ac97_codec: AC97 Audio codec, id: \203\204v9(SigmaTel STAC9721/23)
On Sat, 1 Mar 2003, Brad Laue wrote:
> Yes.
>
> In the attached is a full dump of three crashes. The first, at 18:14
> occurs with NVdriver loaded, and the subsequent two occur with a system
> which has booted without being touched by NVdriver.
The latter two are still happening with a tainted kernel. Are you able to
generate the crash if these modules have never been loaded?
- James
--
James Morris
<[email protected]>
James Morris wrote:
>The latter two are still happening with a tainted kernel. Are you able to
>generate the crash if these modules have never been loaded?
>
>
>- James
>
>
I'm not sure I follow - the NVdriver module had not been loaded at all
for the other two. How is the kernel tainted?
Brad
--
// -- http://www.BRAD-X.com/ -- //
On Sun, 02 Mar 2003 12:01:34 -0500
Brad Laue <[email protected]> wrote:
> James Morris wrote:
>
> >The latter two are still happening with a tainted kernel. Are you able to
> >generate the crash if these modules have never been loaded?
> >
> >
> >- James
> >
> >
> I'm not sure I follow - the NVdriver module had not been loaded at all
> for the other two. How is the kernel tainted?
What he meant is that you still have some modules loaded which arent't GPL'd licensed like the nvidia module. If you are unsure, please mail the ouptut of lsmod...
Anyway, I think it's not the problem of these modules. The airo module sucks:-) But I think Javier and Benjamin will help us to solve the problem..
>
> Brad
>
> --
> // -- http://www.BRAD-X.com/ -- //
>
>
I have updated the CVS (airo-linux.sf.net) with a version that correctly
implementes locking (there was a bug there). Please test it and tell me if
it still panics.
Javier Achirica
On Sun, 2 Mar 2003, Brad Laue wrote:
> James Morris wrote:
>
> >The latter two are still happening with a tainted kernel. Are you able to
> >generate the crash if these modules have never been loaded?
> >
> >
> >- James
> >
> >
> I'm not sure I follow - the NVdriver module had not been loaded at all
> for the other two. How is the kernel tainted?
>
> Brad
>
> --
> // -- http://www.BRAD-X.com/ -- //
>
>
>
>
I got this one last night as well. It was the first I was actually able to
record (machine not stuck with led's flashing). FWIW mine's non-tainted and
was preceeded in the log with:
kernel: airo: BAP error 4000 2
I'll see what I get witht he latest from sf.net.
> Feb 28 16:16:08 Odyssey kernel: Warning: kfree_skb passed an skb still
> on a list (from c01201ba).
> Feb 28 16:16:08 Odyssey kernel: kernel BUG at skbuff.c:315!
> Feb 28 16:16:08 Odyssey kernel: invalid operand: 0000
> Feb 28 16:16:08 Odyssey kernel: CPU: 0
> Feb 28 16:16:08 Odyssey kernel: EIP: 0010:[start_request+164/528]
> Tainted: P
> Feb 28 16:16:08 Odyssey kernel: EIP: 0010:[<c01dca24>] Tainted: P
> Using defaults from ksymoops -t elf32-i386 -a i386
> Feb 28 16:16:08 Odyssey kernel: EFLAGS: 00010286
> Feb 28 16:16:08 Odyssey kernel: eax: 00000045 ebx: c8c504a0 ecx:
> cec36000
> edx: cec37f7c
> Feb 28 16:16:08 Odyssey kernel: esi: c12f1f84 edi: 00000000 ebp:
> c12f0000
> esp: c12f1f6c
> Feb 28 16:16:08 Odyssey kernel: ds: 0018 es: 0018 ss: 0018
> Feb 28 16:16:08 Odyssey kernel: Process keventd (pid: 2, stackpage=c12f1000)
> Feb 28 16:16:08 Odyssey kernel: Stack: c0244620 c01201ba 00000000
> c12f1f84 c01201ba c8c504a0 ca2dc2e4 ca2dc2e4
> Feb 28 16:16:08 Odyssey kernel: 00000000 00000000 c0128df3
> c0256d70 c12f1fb0 00000000 c12f0560 c12f0570
> Feb 28 16:16:08 Odyssey kernel: c12f0000 00000001 00000000
> c0253fa0 00010000 00000000 00000700 c0128cc0
> Feb 28 16:16:08 Odyssey kernel: Call Trace:
> [sys_old_getrlimit+42/224] [sys_old_getrlimit+42/224]
> [vmalloc_area_pages+243/368] [vmfree_area_pages+320/384] [rest_init+0/40]
> Feb 28 16:16:08 Odyssey kernel: Call Trace: [<c01201ba>] [<c01201ba>]
> [<c0128df3>] [<c0128cc0>] [<c0105000>]
> Feb 28 16:16:08 Odyssey kernel: [<c01057ce>] [<c0128cc0>]
> Feb 28 16:16:08 Odyssey kernel: Code: 0f 0b 3b 01 b1 38 24 c0 8b 5c 24
> 14 e9 0e
> ff ff ff 8d 74 26
>
>
> >>EIP; c01dca24 <__kfree_skb+f4/110> <=====
>
> >>ebx; c8c504a0 <___strtok+897dc6c/1062382c>
> >>ecx; cec36000 <___strtok+e9637cc/1062382c>
> >>edx; cec37f7c <___strtok+e965748/1062382c>
> >>esi; c12f1f84 <___strtok+101f750/1062382c>
> >>ebp; c12f0000 <___strtok+101d7cc/1062382c>
> >>esp; c12f1f6c <___strtok+101f738/1062382c>
>
> Trace; c01201ba <__run_task_queue+5a/140>
> Trace; c01201ba <__run_task_queue+5a/140>
> Trace; c0128df3 <schedule_task+1a3/230>
> Trace; c0128cc0 <schedule_task+70/230>
> Trace; c0105000 <empty_zero_page+1000/1380>
> Trace; c01057ce <kernel_thread+2e/240>
> Trace; c0128cc0 <schedule_task+70/230>
>
> Code; c01dca24 <__kfree_skb+f4/110>
> 00000000 <_EIP>:
> Code; c01dca24 <__kfree_skb+f4/110> <=====
> 0: 0f 0b ud2a <=====
> Code; c01dca26 <__kfree_skb+f6/110>
> 2: 3b 01 cmp (%ecx),%eax
> Code; c01dca28 <__kfree_skb+f8/110>
> 4: b1 38 mov $0x38,%cl
> Code; c01dca2a <__kfree_skb+fa/110>
> 6: 24 c0 and $0xc0,%al
> Code; c01dca2c <__kfree_skb+fc/110>
> 8: 8b 5c 24 14 mov 0x14(%esp,1),%ebx
> Code; c01dca30 <__kfree_skb+100/110>
> c: e9 0e ff ff ff jmp ffffff1f <_EIP+0xffffff1f>
> Code; c01dca35 <__kfree_skb+105/110>
> 11: 8d 74 26 00 lea 0x0(%esi,1),%esi
>
> --
> // -- http://www.BRAD-X.com/ -- //
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************
Hi Javier,
I have tested your CVS version in the last tree days. It seems to be ok now for me. No oops happened!
If it is working for other peoples too, will you send a patch to Marcelo
so that it will be included in 2.4.21?
Thank you very much!
Marc Giger
On Sun, 2 Mar 2003 23:14:59 +0100 (MET)
<[email protected]> wrote:
>
> I have updated the CVS (airo-linux.sf.net) with a version that correctly
> implementes locking (there was a bug there). Please test it and tell me if
> it still panics.
>
> Javier Achirica
Seems to be working for me.
Re: the tainting...when I got this cvs version it reported no license and thus
tainted the kernel.
Tim
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************
Javier Achirica wrote:
> I have updated the CVS (airo-linux.sf.net) with a version that
> correctly implementes locking (there was a bug there). Please
> test it and tell me if it still panics.
The 2.4.19 - 2.4.20 airo driver was giving me the infamous
skb_free() related oops every few days, usually after I
downloaded something big.
2.4.21-pre5 with the airo driver from airo-linux.sf.net has
been running perfectly for four days now. Looks good.
--
Thomas Hood <[email protected]>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
I've got a caveat to my previously posted 'works for me'. Before I'd
notice that my net connection was no longer moving and then see the oops
in my log if I looked. With the cvs driver I still tend to see that my
net connection dies sometimes, but no oops. I've found hotplugging the pcmcia
card brings it back to life.
It seems like I hit this with either driver primarily if I've put my
laptop to sleep earlier in its current uptime. Is there possibly a
deadlock somewhere around the previously oopsing code and/or the airo_cs
interaction with apm?
t.
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************
I'm aware of this "lock up" problem. I was hoping it was a locking issue
and the last changes would solve it. Looks like not. The biggest problem
I'm having with that issue is that I'm not able to reproduce it. Any
suggestion?
Javier Achirica
On Sun, 16 Mar 2003, Tim Pepper wrote:
> I've got a caveat to my previously posted 'works for me'. Before I'd
> notice that my net connection was no longer moving and then see the oops
> in my log if I looked. With the cvs driver I still tend to see that my
> net connection dies sometimes, but no oops. I've found hotplugging the pcmcia
> card brings it back to life.
>
> It seems like I hit this with either driver primarily if I've put my
> laptop to sleep earlier in its current uptime. Is there possibly a
> deadlock somewhere around the previously oopsing code and/or the airo_cs
> interaction with apm?
>
> t.
> --
> *********************************************************
> * tpepper@vato dot org * Venimus, Vidimus, *
> * http://www.vato.org/~tpepper * Dolavimus *
> *********************************************************
>
>
>
Hi Javier,
next oops happened today with the latest cvs version
Device: wifi0
Mar 17 15:15:15 vaio kernel: Short packet 0
Mar 17 15:15:15 vaio kernel: Warning: kfree_skb passed an skb still on a list (from c0121fca).
Mar 17 15:15:15 vaio kernel: kernel BUG at skbuff.c:315!
Mar 17 15:15:15 vaio kernel: invalid operand: 0000
Mar 17 15:15:15 vaio kernel: CPU: 0
Mar 17 15:15:15 vaio kernel: EIP: 0010:[__kfree_skb+324/352] Not tainted
Mar 17 15:15:15 vaio kernel: EIP: 0010:[<c026cd54>] Not tainted
Mar 17 15:15:15 vaio kernel: EFLAGS: 00010286
Mar 17 15:15:15 vaio kernel: eax: 00000045 ebx: c3bcb9e0 ecx: cb392000 edx: cb393f7c
Mar 17 15:15:15 vaio kernel: esi: c1339f84 edi: 00000000 ebp: c1338000 esp: c1339f6c
Mar 17 15:15:15 vaio kernel: ds: 0018 es: 0018 ss: 0018
Mar 17 15:15:15 vaio kernel: Process keventd (pid: 2, stackpage=c1339000)
Mar 17 15:15:15 vaio kernel: Stack: c0314840 c0121fca 00000000 c1339f84 c0121fca c3bcb9e0 cd0942f8 cd0942f8
Mar 17 15:15:15 vaio kernel: 00000000 00000000 c012ac83 c032abd0 c1339fb0 00000000 c1338560 c1338570
Mar 17 15:15:15 vaio kernel: c1338000 00000001 00000000 cffe5f90 00010000 00000000 00000700 c012ab50
Mar 17 15:15:15 vaio kernel: Call Trace: [__run_task_queue+90/112] [__run_task_queue+90/112] [context_thread+307/448] [c
ontext_thread+0/448] [rest_init+0/64]
Mar 17 15:15:15 vaio kernel: Call Trace: [<c0121fca>] [<c0121fca>] [<c012ac83>] [<c012ab50>] [<c0105000>]
Mar 17 15:15:15 vaio kernel: [kernel_thread+46/64] [context_thread+0/448]
Mar 17 15:15:15 vaio kernel: [<c010749e>] [<c012ab50>]
Mar 17 15:15:15 vaio kernel:
Mar 17 15:15:15 vaio kernel: Code: 0f 0b 3b 01 cf 2d 31 c0 8b 5c 24 14 e9 be fe ff ff 90 8d 76
Mar 17 15:16:34 vaio kernel: <3>airo: BAP setup error too many retries
Mar 17 15:16:59 vaio kernel: mtrr: no MTRR for fd000000,400000 found
Mar 17 15:17:10 vaio kernel: SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem Off showPc unRaw Sync showTasks Unmoun
t
On Mon, 17 Mar 2003 02:28:58 +0100 (MET)
Javier Achirica <[email protected]> wrote:
>
> I'm aware of this "lock up" problem. I was hoping it was a locking issue
> and the last changes would solve it. Looks like not. The biggest problem
> I'm having with that issue is that I'm not able to reproduce it. Any
> suggestion?
>
> Javier Achirica
It seems like the following does it:
- run for a while
- suspend
- wake..run for a while
- maybe suspend and wake a few more times?
- cause a heavish burst of net traffic
If it would matter I'm running wep. It may happen more often when I've
got an ipsec tunnel running over the connection as well (tunnel never
left open during suspend nor ipsec module left loaded). When it's
happened cpu utilisation was pretty low.
t.
--
*********************************************************
* tpepper@vato dot org * Venimus, Vidimus, *
* http://www.vato.org/~tpepper * Dolavimus *
*********************************************************