Hi, After attaching Intel Wireless WiFi Link 4965AGN through PCIe slot I have experienced a kernel panic on startup with stack trace pointing to ieee80211_chan_init() originating from iwn_attach(). Probably the kernel is pointing at a more precise piece of code but I'm using an USB keyboard and the keyboard driver is not yet loaded so I can't type anything on DDB console. Despite kernel panic coredump was not created. This is most probably because on this device I have only limited amount of disk space (4GB). If there is a way of using devctl rescan to hotplug this device after system startup it would be great. The only idea I had is to modify iwn.c and remove code from it until the system start panicking again to point me to the correct line of code. But this is very time consuming because of all the recompiles. I've made a low-tech picture with my phone.
The picture doesn't appear to be attached. If there's not enough disk space for a dump, try adding "-Z" to a dumpon(8) invocation or set dumpon_flags="-Z" in /etc/rc.conf to enable in-kernel compression.
Hi, Sorry for this, it seems I forgot to add it. I was looking into the code to figure out where the problem is originating from and the actual problem turned out to be that I was getting "timeout reading ROM" error messages at startup, this in turn was causing all the values to be 0 and since the code in ieee80211_get_ratetable() (called from ieee80211_chan_init()) assumed that the channel value passed in was valid it was calling panic() to indicate that there is missing implementation for this device. I have then drilled down to the code which was reading EEPROM and compared it with Linux (where the device is working). I had not seen any significant differences apart from a different timeout handling. After modifying the timeout the device was successfully initiated. I own an Intel 4965AGN MM2 with TA: D74676-004 and the measured EEPROM read time for it with 5 us delay is 60 us and with 1 us delay 25 us. This is larger than what the current code supports. It's also strange since the code is already several years old and this particular chip is quite popular (at least from what I have read). Either this is specific to my hardware setup or the hardware is not used so often. I will post a separate email with a patch for adjusted read timeout and timeout error handling.
Created attachment 224750 [details] [PATCH] Adjust EEPROM read timeout for Intel 4965AGN M2 I'm sorry for a very simplistic change but propagating ETIMEODOUT error from iwn_read_prom_data upwards is still causing kernel panic as iwn_detach assumes that the device data structure is complete. I will work on this problem (error handling) in the future, but since time is scarce it's better to have at least something working than nothing.
Hi again, Mark, do You have any other ideas how to fix it or can my small change be incorporated into the source code?
Hi again, Just wanted to bump the topic up. Can the issue be analyzed or the simplistic patch applied?
(In reply to Radosław Chmielarz from comment #5) I'm sorry for the delayed reply. I took a look at the Linux iwlwifi code and it seemingly uses a much more generous timeout (5,000us) than we do for EEPROM reads. So I can't see any reason not to double it if that fixes the driver for you. I'll put the patch in my queue and commit. Thanks!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=03d4b58feee396d392668f192ecdde08ecc8036c commit 03d4b58feee396d392668f192ecdde08ecc8036c Author: RadosÅaw Chmielarz <radoslaw.chmielarz@emersi.eu> AuthorDate: 2021-06-06 20:42:10 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-06-06 20:44:47 +0000 iwn: adjust EEPROM read timeout for Intel 4965AGN M2 Reading EEPROM from Intel 4965AGN M2 takes 60 us which was causing panic on system startup. PR: 255465 Reviewed by: markj MFC after: 1 week sys/dev/iwn/if_iwn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=71efecb7eb1ad713f2d4c58f479baaf0bd861db0 commit 71efecb7eb1ad713f2d4c58f479baaf0bd861db0 Author: Radosław Chmielarz <radoslaw.chmielarz@emersi.eu> AuthorDate: 2021-06-06 20:42:10 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-06-14 20:24:48 +0000 iwn: adjust EEPROM read timeout for Intel 4965AGN M2 Reading EEPROM from Intel 4965AGN M2 takes 60 us which was causing panic on system startup. PR: 255465 Reviewed by: markj (cherry picked from commit 03d4b58feee396d392668f192ecdde08ecc8036c) sys/dev/iwn/if_iwn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=67b7e2de4fc5dc1165feee8ca281c44444425d0f commit 67b7e2de4fc5dc1165feee8ca281c44444425d0f Author: Radosław Chmielarz <radoslaw.chmielarz@emersi.eu> AuthorDate: 2021-06-06 20:42:10 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-06-14 20:25:14 +0000 iwn: adjust EEPROM read timeout for Intel 4965AGN M2 Reading EEPROM from Intel 4965AGN M2 takes 60 us which was causing panic on system startup. PR: 255465 Reviewed by: markj (cherry picked from commit 03d4b58feee396d392668f192ecdde08ecc8036c) sys/dev/iwn/if_iwn.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks for the patch. I'll close the PR for now since the proximate cause is fixed and iwn(4) isn't getting many updates these days.
Hi, It's works now so it's fine. Thanks for the help!