Opened 7 years ago

Closed 14 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 15 months ago.
DSC_0012-1.JPG (589.7 KB ) - added by Max-Might 15 months ago.
DSC_0013-1.JPG (373.1 KB ) - added by Max-Might 15 months ago.
DSC_0014.JPG (413.3 KB ) - added by Max-Might 15 months ago.
DSC_0015.JPG (433.4 KB ) - added by Max-Might 15 months ago.
DSC_0016.JPG (496.4 KB ) - added by Max-Might 15 months ago.
DSC_0017.JPG (555.4 KB ) - added by Max-Might 14 months ago.
DSC_0018.JPG (452.6 KB ) - added by Max-Might 14 months ago.
DSC_0019.JPG (500.9 KB ) - added by Max-Might 14 months ago.
syslog-17.07.2018.txt (174.2 KB ) - added by Max-Might 14 months ago.

Change History (58)

by grinder, 7 years ago

Attachment: panic.jpg added

comment:1 by grinder, 7 years ago

Panic at boot time on the rocket icon.

comment:2 by diver, 7 years ago

Blocking: 8622 added

comment:3 by diver, 7 years ago

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

comment:4 by diver, 7 years ago

Description: modified (diff)

comment:5 by diver, 7 years ago

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

comment:6 by grinder, 7 years ago

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

comment:7 by grinder, 7 years ago

What is that? And when it is repaired?

comment:8 by diver, 7 years ago

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 by grinder, 7 years ago

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

comment:10 by grinder, 7 years ago

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

comment:11 by grinder, 7 years ago

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

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

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 by diver, 7 years ago

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

comment:14 by luroh, 7 years ago

Blocking: 7665 added

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

comment:15 by grinder, 7 years ago

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

comment:16 by grinder, 7 years ago

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 by diver, 7 years ago

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

comment:18 by grinder, 7 years ago

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

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

comment:19 by diver, 7 years ago

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

comment:20 by grinder, 7 years ago

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

comment:21 by waddlesplash, 5 years ago

Blocked By: 11202 added

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

comment:22 by waddlesplash, 15 months ago

iprowifi4965 synced with FreeBSD in hrev52040. Please retest.

comment:23 by Max-Might, 15 months ago

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.

by Max-Might, 15 months ago

Attachment: DSC_0011-1.JPG added

by Max-Might, 15 months ago

Attachment: DSC_0012-1.JPG added

comment:24 by Max-Might, 15 months ago

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 by waddlesplash, 15 months ago

Does this device work in FreeBSD 11.2?

comment:26 by Max-Might, 15 months ago

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 by waddlesplash, 15 months ago

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 by Max-Might, 15 months ago

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?

in reply to:  28 comment:29 by korli, 15 months ago

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 by Max-Might, 15 months ago

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 15 months ago by Max-Might (previous) (diff)

comment:31 by korli, 15 months ago

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

comment:32 by waddlesplash, 15 months ago

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 15 months ago by waddlesplash (previous) (diff)

comment:33 by waddlesplash, 15 months ago

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 by waddlesplash, 15 months ago

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 by Max-Might, 15 months ago

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 by waddlesplash, 15 months ago

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 by Max-Might, 15 months ago

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...

by Max-Might, 15 months ago

Attachment: DSC_0013-1.JPG added

comment:38 by waddlesplash, 15 months ago

What is the backtrace on this one?

by Max-Might, 15 months ago

Attachment: DSC_0014.JPG added

by Max-Might, 15 months ago

Attachment: DSC_0015.JPG added

by Max-Might, 15 months ago

Attachment: DSC_0016.JPG added

comment:39 by Max-Might, 15 months ago

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 by waddlesplash, 15 months ago

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 by waddlesplash, 14 months ago

Blocking: 7665 removed

comment:42 by Max-Might, 14 months ago

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?

by Max-Might, 14 months ago

Attachment: DSC_0017.JPG added

by Max-Might, 14 months ago

Attachment: DSC_0018.JPG added

comment:43 by waddlesplash, 14 months ago

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 by Max-Might, 14 months ago

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.

by Max-Might, 14 months ago

Attachment: DSC_0019.JPG added

comment:45 by waddlesplash, 14 months ago

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

comment:46 by Max-Might, 14 months ago

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.

by Max-Might, 14 months ago

Attachment: syslog-17.07.2018.txt added

comment:47 by waddlesplash, 14 months ago

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.