[Prism54-users] WG511: complete lockups every now and then

[Daniel Roesen]

Hi,

I'm seeing complete lockups every few days or so. The RX/TX LED is then
steady on. Nothing in dmesg. Cure by reinsterting the card.

This is with Fedora Core 1 vendor kernel 2.4.22-1.2199.5.legacy.nptl,
prism54 1.2 release and firmware 1.0.4.3.

I've tried prism54 SVN snapshot 2005-06-14 but that one seems to lock
much quicker... in a matter of a couple dozent of minutes to hours.
Getting the card to work again was more difficult. Cannot remember
details, but at least once had to reboot.

After one of the lock-ups I even got an oops when trying to reinsert
the card. This was with prism54 1.2 and firmware 1.0.4.3 and after some
15 hours uptime:

eth1: hot unplug detected
eth1: removing device
eth1: islpci_close ()
divert: freeing divert_blk for eth1
Warning: kfree_skb passed an skb still on a list (from d89a1fd6).
------------[ cut here ]------------
kernel BUG at skbuff.c:316!
invalid operand: 0000
r128 agpgart radeon nfs lockd sunrpc maestro soundcore autofs rfcomm
prism54 l2cap firmware_class bluez ds yenta_socket pcmcia_core e100 ipv6
floppy sg sr_mod
CPU:    0
EIP:    0060:[<c020b104>]    Not tainted
EFLAGS: 00010286

EIP is at __kfree_skb [kernel] 0x134 (2.4.22-1.2199.5.legacy.nptl)
eax: 00000045   ebx: 00000003   ecx: 00000001   edx: d66da000
esi: d6a44b1c   edi: d6a44980   ebp: d6ceb800   esp: d7fabedc
ds: 0068   es: 0068   ss: 0068
Process keventd (pid: 2, stackpage=d7fab000)
Stack: c0299c20 d89a1fd6 d6a44980 d89a1fd6 d6adeb80 00018400 d6220000 16220000
       d6a44800 d6ceb800 d6a44980 d89a3b60 d6a44980 d6a44980 d6ceb800 00000001
       d7cad000 c01e8926 d6ceb800 0044d1e0 d6ceb800 d89768d9 d6ceb800 d7faa332
Call Trace:   [<d89a1fd6>] islpci_free_memory [prism54] 0x86
(0xd7fabee0)
[<d89a1fd6>] islpci_free_memory [prism54] 0x86 (0xd7fabee8)
[<d89a3b60>] prism54_remove [prism54] 0x60 (0xd7fabf08)
[<c01e8926>] pci_remove_device [kernel] 0x86 (0xd7fabf20)
[<d89768d9>] cb_free [pcmcia_core] 0x39 (0xd7fabf30)
[<d8972bc1>] shutdown_socket [pcmcia_core] 0x71 (0xd7fabf4c)
[<d89730ad>] parse_events [pcmcia_core] 0xcd (0xd7fabf60)
[<d897e04c>] yenta_bh [yenta_socket] 0x2c (0xd7fabf7c)
[<c01220fa>] __run_task_queue [kernel] 0x5a (0xd7fabf88)
[<d8980080>] pci_socket_array [yenta_socket] 0x0 (0xd7fabf8c)
[<d89800bc>] pci_socket_array [yenta_socket] 0x3c (0xd7fabf90)
[<d89800bc>] pci_socket_array [yenta_socket] 0x3c (0xd7fabf94)
[<c012c3d3>] context_thread [kernel] 0x113 (0xd7fabfa0)
[<c012c2c0>] context_thread [kernel] 0x0 (0xd7fabfc4)
[<c012c2c0>] context_thread [kernel] 0x0 (0xd7fabfe0)
[<c010734d>] kernel_thread_helper [kernel] 0x5 (0xd7fabff0)

Code: 0f 0b 3c 01 f5 89 29 c0 8b 54 24 10 e9 ce fe ff ff 8d 74 26

As the screen went black and no disk activity anymore I thought that the
box crashed hard so I tried restarting it by pressing the on/suspend/
resume button of the laptop. Result was (according to syslog) that the
box tried to go into suspend mode, and then crashed again in
isl38xx_disable_interrupts():

 <5>eth1: got suspend request (state 3)
Unable to handle kernel NULL pointer dereference at virtual address
00000018
 printing eip:
d89a1064
*pde = 00000000
Oops: 0002
r128 agpgart radeon nfs lockd sunrpc maestro soundcore autofs rfcomm
prism54 l2cap firmware_class bluez ds yenta_socket pcmcia_core e100 ipv6
floppy sg sr_mod
CPU:    0
EIP:    0060:[<d89a1064>]    Not tainted
EFLAGS: 00010246

EIP is at isl38xx_disable_interrupts [prism54] 0x4
(2.4.22-1.2199.5.legacy.nptl)
eax: 00000000   ebx: d6a44800   ecx: 8002003c   edx: 00000cfc
esi: d6a44980   edi: 00000000   ebp: 00000003   esp: d65d3ea4 ds: 0068
es: 0068   ss: 0068
Process apmd (pid: 1578, stackpage=d65d3000)
Stack: d89a3c3d 00000000 d6a44a4c 00000003 d6ceb808 d7fe2f94 d7fe2f80
c01e9cae
       d6ceb800 00000003 c01e9d9f d6ceb800 00000003 d7fe2f80 d7fe2d0c
d7fe2d00
       00000003 c01e9d7c d7fe2f80 00000003 d7fe2d00 00000003 00000003
00000003
Call Trace:   [<d89a3c3d>] prism54_suspend [prism54] 0x5d (0xd65d3ea4)
[<c01e9cae>] pci_pm_suspend_device [kernel] 0x2e (0xd65d3ec0)
[<c01e9d9f>] pci_pm_suspend_bus [kernel] 0x4f (0xd65d3ecc)
[<c01e9d7c>] pci_pm_suspend_bus [kernel] 0x2c (0xd65d3ee8)
[<c01e9e9c>] pci_pm_suspend [kernel] 0x2c (0xd65d3f04)
[<c01e9f4c>] pci_pm_callback [kernel] 0x3c (0xd65d3f18)
[<c012deb2>] pm_send [kernel] 0x72 (0xd65d3f20)
[<c012dfb4>] pm_send_all [kernel] 0x74 (0xd65d3f3c)
[<c0115f18>] suspend [kernel] 0x18 (0xd65d3f5c)
[<c011673c>] do_ioctl [kernel] 0x10c (0xd65d3f6c)
[<c01537b9>] sys_ioctl [kernel] 0xc9 (0xd65d3f94)
[<c0145354>] fsync_dev [kernel] 0x54 (0xd65d3fa8)
[<c0109747>] system_call [kernel] 0x33 (0xd65d3fc0)

Code: c7 40 18 00 00 00 00 8b 40 18 b8 bc a7 00 00 89 44 24 04 e9

Interestingly, the lockups happen quite seldom here at home (every
few days perhaps), but much more often in my parent's house. Perhaps
because signal strength/quality is worse there. Both sites use the
WRT54G AP.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0