kernel panic

[grinder]

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

[grinder]

Panic at boot time on the rocket icon.

[diver]

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

[grinder]

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

[grinder]

What is that? And when it is repaired?

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

[grinder]

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

[grinder]

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

[grinder]

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

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

[luroh]

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

[grinder]

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

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

[diver]

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

[grinder]

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

[diver]

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

[grinder]

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

[waddlesplash]

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

[waddlesplash]

iprowifi4965 synced with FreeBSD in hrev52040. Please retest.

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

[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

[waddlesplash]

Does this device work in FreeBSD 11.2?

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

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

[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?

[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/

[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?

[korli]

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

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

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

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

[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?

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

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

[waddlesplash]

What is the backtrace on this one?

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

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

[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?

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

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

[waddlesplash]

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

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

[waddlesplash]

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