prism54 module freezes system with 2.6.22-10

I tried with fglrx, same problem.
When the system freezes up, I can't even connect the the ssh server running on it.

I kept getting this in kmsg, so I blacklisted prism54 in /etc/modprobe.d/blacklist

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

<7>[ 312.693073] eth1: resetting device...
<7>[ 312.693094] eth1: uploading firmware...
<7>[ 312.754393] eth1: firmware version: 2.7.0.0
<7>[ 312.754461] eth1: firmware upload complete
<7>[ 312.932803] eth1: timeout waiting for mgmt response 250, triggering device
<7>[ 313.036766] eth1: timeout waiting for mgmt response 225, triggering device
<7>[ 313.136720] eth1: timeout waiting for mgmt response 200, triggering device
<7>[ 313.236658] eth1: timeout waiting for mgmt response 175, triggering device
<7>[ 313.336618] eth1: timeout waiting for mgmt response 150, triggering device
<7>[ 313.436562] eth1: timeout waiting for mgmt response 125, triggering device
<7>[ 313.536512] eth1: timeout waiting for mgmt response 100, triggering device
<7>[ 313.636466] eth1: timeout waiting for mgmt response 75, triggering device
<7>[ 313.736413] eth1: timeout waiting for mgmt response 50, triggering device
<7>[ 313.836370] eth1: timeout waiting for mgmt response 25, triggering device
<4>[ 313.836379] eth1: timeout waiting for mgmt response
<3>[ 313.836384] eth1: mgt_commit_list: failure. oid=ff020008 err=-110
<7>[ 313.936318] eth1: timeout waiting for mgmt response 250, triggering device
<7>[ 314.036270] eth1: timeout waiting for mgmt response 225, triggering device
<7>[ 314.136250] eth1: timeout waiting for mgmt response 200, triggering device
<7>[ 314.236234] eth1: timeout waiting for mgmt response 175, triggering device
<7>[ 314.336120] eth1: timeout waiting for mgmt response 150, triggering device
<7>[ 314.436072] eth1: timeout waiting for mgmt response 125, triggering device
<7>[ 314.536024] eth1: timeout waiting for mgmt response 100, triggering device
<7>[ 314.635976] eth1: timeout waiting for mgmt response 75, triggering device
<7>[ 314.735935] eth1: timeout waiting for mgmt response 50, triggering device
<7>[ 314.835920] eth1: timeout waiting for mgmt response 25, triggering device
<4>[ 314.835930] eth1: timeout waiting for mgmt response
<3>[ 314.835934] eth1: mgt_commit_list: failure. oid=ff020003 err=-110
<7>[ 314.935878] eth1: timeout waiting for mgmt response 250, triggering device
<7>[ 315.035926] eth1: timeout waiting for mgmt response 225, triggering device
<7>[ 315.137423] eth1: timeout waiting for mgmt response 200, triggering device
<7>[ 315.235683] eth1: timeout waiting for mgmt response 175, triggering device
<7>[ 315.335636] eth1: timeout waiting for mgmt response 150, triggering device
<7>[ 315.435589] eth1: timeout waiting for mgmt response 125, triggering device
<7>[ 315.535539] eth1: timeout waiting for mgmt response 100, triggering device
<7>[ 315.635490] eth1: timeout waiting for mgmt response 75, triggering device
<7>[ 315.735440] eth1: timeout waiting for mgmt response 50, triggering device
<7>[ 315.835392] eth1: timeout waiting for mgmt response 25, trigg...

The Hardy Heron Alpha series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

Also, we will keep this report open against the actively developed kernel bug against 2.6.22 this will be closed. Thanks.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Hi Roconda,

Is there any sort of kernel oops or panic that you see? Does blacklisting the prism54 modlule as mentioned above still prevent the system from freezing? It might also be helpful if you'd attach your dmesg output when running Intrepid. Thanks.

Dear Leann,

No, I don't see any kernel 'oops or panic' at all. prism54 Was already blacklisted. I blacklisted ipv6 manually too, some said it would prevent freezes. It didn't but my syslog got lots of spam for modprobing ipv6. I replaced intrepid for opensuse 11, would a livecd dmesg be anough for you too ? The dmesg for hardy is no problem at all if you need it too.

Cheers!

Hi Roconda,

Being able to capture and attach any relevant log information regarding the freeze when running Intrepid would be the most helpful. Particularly any error message would be of interest. Thanks.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I ran syslog in kernel debug mode and tried to force a freeze. The freeze happened in 34th minute. There is nothing in the 34th minute but I hope this file is useful.

Happy 2009 to all

Hi Roconda,

How about testing the latest pre-relase of Jaunty (currently Alpha 3) and let us know your results - http://cdimage.ubuntu.com/releases/jaunty/ . Thanks.

Since nobody reply after Jaunty released. I've been using Jaunty (x86_64) with, prism54 (isl3890) pcmcia, prism54 module and p54pci module. Both modules still getting problem until the latest patches (2.6.28-15-generic) and latest firmware from http://daemonizer.de/prism54/prism54-fw/.

Here is the output from p54pci module:
[ 1196.510172] p54pci 0000:03:00.0: enabling device (0000 -> 0002)
[ 1196.510186] p54pci 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 1196.510204] p54pci 0000:03:00.0: setting latency timer to 64
[ 1196.510396] p54pci 0000:03:00.0: firmware: requesting isl3886
[ 1196.545866] p54: LM86 firmware
[ 1196.545872] p54: FW rev 2.17.2.0 - Softmac protocol 7.6
[ 1197.652065] phy1: Cannot boot firmware!
[ 1197.652135] p54pci 0000:03:00.0: PCI INT A disabled
[ 1197.652162] p54pci: probe of 0000:03:00.0 failed with error -110

Here is the output from prism54 module:
[ 1268.644653] Loaded prism54 driver, version 1.2
[ 1268.644721] prism54 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 1273.428435] eth1: resetting device...
[ 1273.428456] eth1: uploading firmware...
[ 1273.478087] prism54 0000:03:00.0: firmware: requesting isl3890
[ 1273.525538] eth1: firmware version: 1.0.4.3
[ 1273.525595] eth1: firmware upload complete
[ 1273.848045] eth1: timeout waiting for mgmt response 250, triggering device
[ 1273.948064] eth1: timeout waiting for mgmt response 225, triggering device
[ 1274.048051] eth1: timeout waiting for mgmt response 200, triggering device
[ 1274.148054] eth1: timeout waiting for mgmt response 175, triggering device
[ 1274.248042] eth1: timeout waiting for mgmt response 150, triggering device
[ 1274.348038] eth1: timeout waiting for mgmt response 125, triggering device
[ 1274.448055] eth1: timeout waiting for mgmt response 100, triggering device
... and so on.
After unloading prism54 module will lead to kernel panic and system rebooting.

Thanks.

Hi Fatah,

Thanks for testing and the feedback. I'd like to try to keep this bug as up to date as possible. If you'd be willing, could you confirm this is still an issue with the latest Karmic 9.10 Alpha release http://cdimage.ubuntu.com/releases/karmic/ . It contains a 2.6.31 based kernel. Thanks.

Hi,
I should add, that the isl3890-support does not work out of the box with the Karmic 9.10 release. While it worked flawlessly with 9.04 (already when booting the live-CD), you have to manually change the firmware files in /lib/firmware.
I'm using a isl3890-based cardbus-card in an old IBM Thinkpad.

I have lock up issues with this card (ISL3886) when using Ubuntu 10.04 with 2.6.32-19-generic kernel. The system hangs after various times but otherwise works fine, speed is normal etc.

00:0b.0 Network controller: Intersil Corporation ISL3886 [Prism Javelin/Prism Xbow] (rev 01)
 Subsystem: Intersil Corporation Device 0000
 Flags: medium devsel, IRQ 19
 Memory at dfff8000 (32-bit, non-prefetchable) [size=8K]
 Capabilities: <access denied>
 Kernel modules: p54pci, prism54

My machine is Fujitsu Siemens Amilo A7640 laptop. When I disable this card and use USB or PCMCIA WLAN-adapters the system does not hang.

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]