Opened 12 years ago
Closed 6 years 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 |
Platform: | All |
Description (last modified by )
Attachments (11)
Change History (58)
by , 12 years ago
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Blocking: | 8622 added |
---|
comment:3 by , 12 years ago
Is it the same with a nightly image? http://haiku-files.org/haiku/development
comment:4 by , 12 years ago
Description: | modified (diff) |
---|
comment:5 by , 12 years ago
Component: | Servers/net_server → Drivers/Network/iprowifi4965 |
---|---|
Owner: | changed from | to
comment:8 by , 12 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 , 12 years ago
I've tried stable and nightly. Thanks for the advice. When the repaired? I would like to WiFi worked.
follow-up: 12 comment:10 by , 12 years ago
Please correct this bug. I want to use notebook onboard WiFi.
comment:11 by , 12 years ago
Please fix this bug. Or tell me what's the problem and how to solve this problem.
comment:12 by , 12 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 , 12 years ago
Description: | modified (diff) |
---|---|
Version: | R1/alpha3 → R1/Development |
comment:14 by , 12 years ago
Blocking: | 7665 added |
---|
grinder: could you please give R1 Alpha 4.1 a try?
comment:16 by , 12 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 , 12 years ago
Did you try a recent nightly image? This driver was updated after Alpha 4.1.
comment:19 by , 12 years ago
I know, I'm asking you to try a recent nightly image. It is newer than Alpha 4.1.
comment:21 by , 10 years ago
Blocked By: | 11202 added |
---|
(In #11202) And my bad again -- this is really a duplicate.
comment:23 by , 6 years ago
by , 6 years ago
Attachment: | DSC_0011-1.JPG added |
---|
by , 6 years ago
Attachment: | DSC_0012-1.JPG added |
---|
comment:24 by , 6 years 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:26 by , 6 years 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 , 6 years 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.
follow-up: 29 comment:28 by , 6 years 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?
comment:29 by , 6 years ago
Replying to Max-Might:
Ok, I am not familiar with the FBSD release artifacts, do I need the
memstick
ordisc1
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 , 6 years 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?
comment:32 by , 6 years 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.
comment:33 by , 6 years 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 , 6 years ago
The kernel crashes should be gone as of hrev52068. For debugging, please do the following:
- blacklist the 4965 driver in the settings file
- 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
- In the same file on line 54, comment out the if-test using
/* */
- 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 , 6 years 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 , 6 years 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 , 6 years 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 , 6 years ago
Attachment: | DSC_0013-1.JPG added |
---|
by , 6 years ago
Attachment: | DSC_0014.JPG added |
---|
by , 6 years ago
Attachment: | DSC_0015.JPG added |
---|
by , 6 years ago
Attachment: | DSC_0016.JPG added |
---|
comment:39 by , 6 years 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 , 6 years 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 , 6 years ago
Blocking: | 7665 removed |
---|
comment:42 by , 6 years 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 , 6 years ago
Attachment: | DSC_0017.JPG added |
---|
by , 6 years ago
Attachment: | DSC_0018.JPG added |
---|
comment:43 by , 6 years 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 , 6 years 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 , 6 years ago
Attachment: | DSC_0019.JPG added |
---|
comment:45 by , 6 years ago
Can you please show the output of the message
command, and also dis -b 6
?
comment:46 by , 6 years 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 , 6 years ago
Attachment: | syslog-17.07.2018.txt added |
---|
comment:47 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Hooray, it's fixed! Please open a new ticket for the EEPROM error.
Panic at boot time on the rocket icon.