Opened 7 years ago

Closed 10 months ago

#8623 closed bug (fixed)

kernel panic

Reported by: grinder Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Network/iprowifi4965 Version: R1/Development
Keywords: Cc:
Blocked By: #11202 Blocking: #8622
Has a Patch: no Platform: All

Description (last modified by diver)

Notebook: Acer Aspire 6920G
Processor: Intel Core 2 Duo T5750
Chipset: Intel PM965 Express (Intel Centrino Duo)
WiFi: Intel WiFi 4965
Video: NVIDIA GeForce 9500, 512MB

Attachments (11)

panic.jpg (2.8 MB) - added by grinder 7 years ago.
DSC_0011-1.JPG (620.4 KB) - added by Max-Might 11 months ago.
DSC_0012-1.JPG (589.7 KB) - added by Max-Might 11 months ago.
DSC_0013-1.JPG (373.1 KB) - added by Max-Might 11 months ago.
DSC_0014.JPG (413.3 KB) - added by Max-Might 11 months ago.
DSC_0015.JPG (433.4 KB) - added by Max-Might 11 months ago.
DSC_0016.JPG (496.4 KB) - added by Max-Might 11 months ago.
DSC_0017.JPG (555.4 KB) - added by Max-Might 11 months ago.
DSC_0018.JPG (452.6 KB) - added by Max-Might 11 months ago.
DSC_0019.JPG (500.9 KB) - added by Max-Might 10 months ago.
syslog-17.07.2018.txt (174.2 KB) - added by Max-Might 10 months ago.

Change History (58)

Changed 7 years ago by grinder

Attachment: panic.jpg added

comment:1 Changed 7 years ago by grinder

Panic at boot time on the rocket icon.

comment:2 Changed 7 years ago by diver

Blocking: 8622 added

comment:3 Changed 7 years ago by diver

Is it the same with a nightly image? http://haiku-files.org/haiku/development

comment:4 Changed 7 years ago by diver

Description: modified (diff)

comment:5 Changed 7 years ago by diver

Component: Servers/net_serverDrivers/Network/iprowifi4965
Owner: changed from axeld to nobody

comment:6 Changed 7 years ago by grinder

With a stable release is also a bug. sorry for bad english.

comment:7 Changed 7 years ago by grinder

What is that? And when it is repaired?

comment:8 Changed 7 years ago by diver

Latest stable version is Alpha 3, nightly images are unstable, but often work better. Have you tried nightly?
Anyway, since this crash happens in iprowifi4965 driver you should be able to boot in Safe mode and then you will need to open /system/add-ons/kernel/drivers/bin folder and rename iprowifi4965 to iprowifi4965.disabled.

comment:9 Changed 7 years ago by grinder

I've tried stable and nightly. Thanks for the advice. When the repaired? I would like to WiFi worked.

comment:10 Changed 7 years ago by grinder

Please correct this bug. I want to use notebook onboard WiFi.

comment:11 Changed 7 years ago by grinder

Please fix this bug. Or tell me what's the problem and how to solve this problem.

comment:12 in reply to:  10 Changed 7 years ago by mmadia

Replying to grinder:

Please correct this bug. I want to use notebook onboard WiFi.

Replying to grinder:

Please fix this bug. Or tell me what's the problem and how to solve this problem.

Hello grinder. Thanks for your interest in Haiku and willingness to help contribute to development by filling out bug reports! But please, don't post these types of comments as they are unproductive and merely chip away at the limited free time of Haiku's contributors. Instead, if you are interested in learning how to provide more useful feedback and information on this bug tracker, BugTrackerEtiquette and ReportingBugs are worth reading.

comment:13 Changed 7 years ago by diver

Description: modified (diff)
Version: R1/alpha3R1/Development

comment:14 Changed 7 years ago by luroh

Blocking: 7665 added

grinder: could you please give R1 Alpha 4.1 a try?

comment:15 Changed 6 years ago by grinder

I tried R1 Alpha 4.1. Does not boot. The same error.

comment:16 Changed 6 years ago by grinder

Is it hard corrected this error? I think the problem is in the driver wi-fi card, because the system is loaded with a disabled driver.

comment:17 Changed 6 years ago by diver

Did you try a recent nightly image? This driver was updated after Alpha 4.1.

comment:18 Changed 6 years ago by grinder

I tried R1 Alpha 4.1. Does not boot. The same error.

Last edited 6 years ago by grinder (previous) (diff)

comment:19 Changed 6 years ago by diver

I know, I'm asking you to try a recent nightly image. It is newer than Alpha 4.1.

comment:20 Changed 6 years ago by grinder

Yes, I tried the latest nightly build. And tried Alpha 4.1.

comment:21 Changed 5 years ago by waddlesplash

Blocked By: 11202 added

(In #11202) And my bad again -- this is really a duplicate.

comment:22 Changed 11 months ago by waddlesplash

iprowifi4965 synced with FreeBSD in hrev52040. Please retest.

comment:23 Changed 11 months ago by Max-Might

I just retested with hrev52060 since I have the same laptop. The issue is still there, I get a KDL on boot and the backtrace is almost the same as described in this ticket.

Attaching KDL and syslog screenshots.

BTW, I think issue #12035 might be caused by the same issue.

Changed 11 months ago by Max-Might

Attachment: DSC_0011-1.JPG added

Changed 11 months ago by Max-Might

Attachment: DSC_0012-1.JPG added

comment:24 Changed 11 months ago by Max-Might

Also here is some more info about this device from linux:

max@max-Aspire-6920~> dmesg | grep 4965
[    5.645774] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree:
[    5.645776] iwl4965: Copyright(c) 2003-2011 Intel Corporation
[    5.645845] iwl4965 0000:08:00.0: can't disable ASPM; OS doesn't have ASPM control
[    5.646039] iwl4965 0000:08:00.0: Detected Intel(R) Wireless WiFi Link 4965AGN, REV=0x4
[    5.688713] iwl4965 0000:08:00.0: device EEPROM VER=0x36, CALIB=0x5
[    5.697676] iwl4965 0000:08:00.0: Tunable channels: 13 802.11bg, 19 802.11a channels
[    5.781453] iwl4965 0000:08:00.0: loaded firmware version 228.61.2.24
[    5.888568] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs'
[   13.332040] iwl4965 0000:08:00.0: Enabling power save might cause firmware crashes

comment:25 Changed 11 months ago by waddlesplash

Does this device work in FreeBSD 11.2?

comment:26 Changed 11 months ago by Max-Might

I don't have BSD but I think that something in iwn_attach seems to be failing since the next call is iwn_detach and from there it all goes down.

comment:27 Changed 11 months ago by waddlesplash

Yes, I'm very much already aware of that; the problem is indeed the bad EEPROM signature which then causes _attach to "goto fail" and call _detach. The KDL is thus a separate issue; it's trying to drain a NULL taskqueue. I'm not sure why FreeBSD would not also panic in this instance, but seeing as there are enough tickets like this one, I suppose it's time to add NULL checks in those functions in our compat layer.

Linux's driver is very different than FreeBSD's, so the fact that it works on Linux is not much help to me. If you can determine that it definitely works on FreeBSD, then that points to something wrong in our compatibility layer, instead of the driver itself.

comment:28 Changed 11 months ago by Max-Might

Ok, I am not familiar with the FBSD release artifacts, do I need the memstick or disc1 iso file in order to boot from a live usb? I hope it does not require me to install the whole OS since I do not have any available partitions to do that.

Also is it possible to compile the driver with debug options and replace/update the kernel object on the USB key that I already use for testing so we can see exactly what the error message is?

comment:29 in reply to:  28 Changed 11 months ago by korli

Replying to Max-Might:

Ok, I am not familiar with the FBSD release artifacts, do I need the memstick or disc1 iso file in order to boot from a live usb? I hope it does not require me to install the whole OS since I do not have any available partitions to do that.

There are runnable ISO of TrueOS (based on FreeBSD 12-current), should give some insights: https://download.trueos.org/master/amd64/

comment:30 Changed 11 months ago by Max-Might

I just started the TrueOS installer and it was able to successfully recognize and configure the wifi adapter. I was able to ping an external server.

So I guess that the issue lies somewhere in our compat layer?

Last edited 11 months ago by Max-Might (previous) (diff)

comment:31 Changed 11 months ago by korli

@Max-Might you should post a syslog with the wlan driver blacklisted.

comment:32 Changed 11 months ago by waddlesplash

12-CURRENT changed net80211 KPIs and probably also the 4965 driver significantly vs. 11.2, so it may still be the case there's something on the FreeBSD end. But yes, the EEPROM errors I've heard other reports of on chips that work on FreeBSD, so it is likely something is wrong in our compat layer. I didn't spend enough time to try and figure it out, and I don't have any hardware that reproduces the issue myself, so, help wanted.

Last edited 11 months ago by waddlesplash (previous) (diff)

comment:33 Changed 11 months ago by waddlesplash

BTW I've fixed the kernel crash, but I don't have working WiFi on the laptop I'm on (iwm driver, new in FreeBSD 11) yet, and I'm away from Ethernet, so I can't push it atm.

comment:34 Changed 11 months ago by waddlesplash

The kernel crashes should be gone as of hrev52068. For debugging, please do the following:

  1. blacklist the 4965 driver in the settings file
  2. define IWN_DEBUG here https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/network/wlan/iprowifi4965/dev/iwn/if_iwn_debug.h#n27
  3. In the same file on line 54, comment out the if-test using /* */
  4. Rebuild the driver, and copy it into non-packaged. (The old 4965 must be blacklisted at this point.)

The driver should load and spew a ton of debug information into the syslog before failing as before. Please attach that syslog (or at least just the relevant portions) here.

comment:35 Changed 11 months ago by Max-Might

I did this and I got this error:

if_iwn.c:3927: parse error before `*`

I guess this is a gcc2 thing? What do we need to make it happy?

comment:36 Changed 11 months ago by waddlesplash

Yes, it is a GCC2 thing. It wants C89, which means all variable declarations must come before any code within a block, which these drivers nominally adhere to but probably contain debug macros above the code body, which are normally compiled out but you have just enabled :)

If you can figure it out on your own, excellent; otherwise I'll take a look when I get the chance.

comment:37 Changed 11 months ago by Max-Might

So that explains it. In the meantime I just commented out the three lines that were affected since they are called much later and will not show up in the syslog anyway.

For some reason it crashed again but this time there is a little bit more info in the syslog. Attaching image...

Changed 11 months ago by Max-Might

Attachment: DSC_0013-1.JPG added

comment:38 Changed 11 months ago by waddlesplash

What is the backtrace on this one?

Changed 11 months ago by Max-Might

Attachment: DSC_0014.JPG added

Changed 11 months ago by Max-Might

Attachment: DSC_0015.JPG added

Changed 11 months ago by Max-Might

Attachment: DSC_0016.JPG added

comment:39 Changed 11 months ago by Max-Might

The bt is very similar to the one we had previously (see image 16). The interesting thing is that once it crashed in a very different place - see image 14 and 15 for backtrace and syslog.

comment:40 Changed 11 months ago by waddlesplash

OK, that panic should be fixed in hrev52071.

The new KDL looks like some sort of race condition; it's still failing to read the EEPROM as far as I can see.

comment:41 Changed 11 months ago by waddlesplash

Blocking: 7665 removed

comment:42 Changed 11 months ago by Max-Might

Just tested with hrev52093 and this crash happens consistently on every boot now.

The syslog says that it timeouts reading data. Does this driver need any firmware binaries and if yes do we have the correct ones?

Changed 11 months ago by Max-Might

Attachment: DSC_0017.JPG added

Changed 11 months ago by Max-Might

Attachment: DSC_0018.JPG added

comment:43 Changed 10 months ago by waddlesplash

It's possible we have the wrong ones. It should say somewhere in the syslog if it loaded firmware or not and then if it loaded it.

comment:44 Changed 10 months ago by Max-Might

Now it crashed in detach again. I do not see anything about the firmware in the syslog. Maybe it is supposed to be loaded at a later stage.

Changed 10 months ago by Max-Might

Attachment: DSC_0019.JPG added

comment:45 Changed 10 months ago by waddlesplash

Can you please show the output of the message command, and also dis -b 6?

comment:46 Changed 10 months ago by Max-Might

I just tested with hrev52107 and it was able to boot to desktop with no KDL. I guess one of the recent commits fixed the last remaining crash.

We still have the eeprom read errors and the driver does not work but at least it boots now. Attaching syslog.

Changed 10 months ago by Max-Might

Attachment: syslog-17.07.2018.txt added

comment:47 Changed 10 months ago by waddlesplash

Resolution: fixed
Status: newclosed

Hooray, it's fixed! Please open a new ticket for the EEPROM error.

Note: See TracTickets for help on using tickets.