Re: iwn driver issue
On 0613T1251, David Wolfskill wrote: On Fri, Jun 13, 2014 at 09:36:35PM +0200, Edward Tomasz Napiera??a wrote: ... I normally don't spend a huge amount of time in head -- enough to build it do a quick smoke-test. So it's certainly possible that it merits further exploration. And I'm willing experiment, but I cannot test it while I'm at work (as I don't use the wireless NIC at work -- I use it almost exclusively while I'm at home (and other places), though). It would be great if you could help me with this. Basically you need to enable crashdumps, as described below, and obtain a backtrace. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html I have had crash dumps on panics running head (slice 4 of the boot device, in my case) in the past, so that process works. I just didn't get a dump this morning. :-( d130(9.3)[1] grep dump /S4/etc/rc.conf dumpdev=AUTO d130(9.3)[2] Hm. Well, if it fails the second time then I guess I'll just add a sysctl to disable the fix. But let's try to get a crashdump anyway :-) Just for the record, the easiest way to make iwn firmware panic is to enter ddb (ctrl-alt-esc), wait five seconds and exit it (center). Does that process yield useful information? (That is, is that process sufficiently similar to a sequence of events that occurs in the real world that the resulting information may be used to figure out how to make the code avoid misbehavior?) Well, it triggers the iwn firmware panic, which in turn triggers the code I've attached, which apparently causes kernel panic. But I cannot guarantee that it _will_ trigger the problem. If so, I can try that soonish (e.g., en route home today, once I've boarded the train -- vs. while I'm still on my bike :-}). Thanks. Even just replying to emails whilst on bike is impressive, especially with mutt. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn driver issue
On 0613T1126, Stefan Parvu wrote: Hi, Im running FreeBSD current: FreeBSD nereid 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265628: Thu May 8 08:05:37 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/VT amd64 on Asus Zenbook UX32VD. My wireless network works ok, however from time to time I need to restart the netif service since my link does not work anymore. After restart everything is ok. The device is: Wifi: Intel Centrino Advanced-N 6235. Sometimes Im able to see something like: iwn0: iwn_scan: called whilst scanning! iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x198A) program counter = 0x00015920 source line = 0x01DC error data = 0x0296 branch link = 0x000159115910 interrupt link = 0xDBEA time= 2479833477 driver status: tx ring 0: qid=0 cur=14 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=19 queued=0 tx ring 4: qid=4 cur=0 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=1 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=24 After restarting the networking service everything is back to normal. Can you update to at least r266546 and try again? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn driver issue
On Fri, 13 Jun 2014 18:36:44 +0200 Edward Tomasz Napierała tr...@freebsd.org wrote: Can you update to at least r266546 and try again? to do this I need to svn update all my /usr/src code and rebuild the kernel - no iso images available for it ? Correct ? How often are iso images published for current ? I will update my machine a bit later. Were there many fixes for iwn driver on latest branch ? Thanks, -- Stefan Parvu spa...@systemdatarecorder.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn driver issue
On Fri, Jun 13, 2014 at 06:36:44PM +0200, Edward Tomasz Napiera??a wrote: On 0613T1126, Stefan Parvu wrote: Hi, Im running FreeBSD current: FreeBSD nereid 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265628: Thu May 8 08:05:37 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/VT amd64 on Asus Zenbook UX32VD. My wireless network works ok, however from time to time I need to restart the netif service since my link does not work anymore. After restart everything is ok. The device is: Wifi: Intel Centrino Advanced-N 6235. Sometimes Im able to see something like: iwn0: iwn_scan: called whilst scanning! iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x198A) program counter = 0x00015920 source line = 0x01DC error data = 0x0296 branch link = 0x000159115910 interrupt link = 0xDBEA time= 2479833477 driver status: tx ring 0: qid=0 cur=14 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=19 queued=0 ... After restarting the networking service everything is back to normal. Can you update to at least r266546 and try again? In case it's of interest or use, in tracking head daily for some time on a Dell Precision M4400, I've seen similar symptoms. But this morning, something happene dthat was rather worse than usual: during make installworld, (while I was otherwise occupied getting ready to head in to work), the machine apparently rebooted. Here are the last several builds I've done: FreeBSD 11.0-CURRENT #1271 r267264M/267264:1100022: Mon Jun 9 07:47:43 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1272 r267321M/267323:1100022: Tue Jun 10 06:31:13 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1273 r267358M/267358:1100022: Wed Jun 11 08:51:08 PDT 2014 r...@d130.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1274 r267378M/267384:1100022: Thu Jun 12 12:51:53 PDT 2014 r...@d130.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1275 r267441M/267441:1100023: Fri Jun 13 06:34:57 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Note that the reboot referenced above was while it was doiong the installworld for FreeBSD 11.0-CURRENT #1275 r267441M/267441:1100023, so it was running FreeBSD 11.0-CURRENT #1274 r267378M/267384:1100022 at the time. And (to bring this back to the topic at hand), when I checked the logs, the last thing I found before the start-up messages fro the reboot was: Jun 13 06:00:29 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:00:29 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:11:35 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:16:46 g1-252 kernel: Expensive timeout(9) function: 0xc0c858e0(0xd15728d0) 3.292387227 s Jun 13 06:16:46 g1-252 kernel: iwn0: iwn_intr: fatal firmware error Jun 13 06:16:46 g1-252 kernel: firmware error log: Jun 13 06:16:46 g1-252 kernel: error type = SYSASSERT (0x0005) Jun 13 06:16:46 g1-252 kernel: program counter = 0x24EC Jun 13 06:16:46 g1-252 kernel: source line = 0x0489 Jun 13 06:16:46 g1-252 kernel: error data = 0x00FF0489 Jun 13 06:16:46 g1-252 kernel: branch link = 0x24C824C8 Jun 13 06:16:46 g1-252 kernel: interrupt link = 0x0916 Jun 13 06:16:46 g1-252 kernel: time= 2183893590 Jun 13 06:16:46 g1-252 kernel: driver status: Jun 13 06:16:46 g1-252 kernel: tx ring 0: qid=0 cur=203 queued=6 Jun 13 06:16:46 g1-252 kernel: tx ring 1: qid=1 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 2: qid=2 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 3: qid=3 cur=4 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 4: qid=4 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 5: qid=5 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 6: qid=6 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 7: qid=7 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 8: qid=8 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 9: qid=9 cur=206 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 10: qid=10 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 11: qid=11 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 12: qid=12 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 13: qid=13 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 14: qid=14 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 15: qid=15 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 16: qid=16 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 17: qid=17 cur=0 queued=0 Jun 13
Re: iwn driver issue
This isn't this first time this has been reported, right? I think we may need to back this patch out until it's better resolved. -a On 13 June 2014 11:52, David Wolfskill da...@catwhisker.org wrote: On Fri, Jun 13, 2014 at 06:36:44PM +0200, Edward Tomasz Napiera??a wrote: On 0613T1126, Stefan Parvu wrote: Hi, Im running FreeBSD current: FreeBSD nereid 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265628: Thu May 8 08:05:37 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/VT amd64 on Asus Zenbook UX32VD. My wireless network works ok, however from time to time I need to restart the netif service since my link does not work anymore. After restart everything is ok. The device is: Wifi: Intel Centrino Advanced-N 6235. Sometimes Im able to see something like: iwn0: iwn_scan: called whilst scanning! iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x198A) program counter = 0x00015920 source line = 0x01DC error data = 0x0296 branch link = 0x000159115910 interrupt link = 0xDBEA time= 2479833477 driver status: tx ring 0: qid=0 cur=14 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=19 queued=0 ... After restarting the networking service everything is back to normal. Can you update to at least r266546 and try again? In case it's of interest or use, in tracking head daily for some time on a Dell Precision M4400, I've seen similar symptoms. But this morning, something happene dthat was rather worse than usual: during make installworld, (while I was otherwise occupied getting ready to head in to work), the machine apparently rebooted. Here are the last several builds I've done: FreeBSD 11.0-CURRENT #1271 r267264M/267264:1100022: Mon Jun 9 07:47:43 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1272 r267321M/267323:1100022: Tue Jun 10 06:31:13 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1273 r267358M/267358:1100022: Wed Jun 11 08:51:08 PDT 2014 r...@d130.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1274 r267378M/267384:1100022: Thu Jun 12 12:51:53 PDT 2014 r...@d130.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1275 r267441M/267441:1100023: Fri Jun 13 06:34:57 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Note that the reboot referenced above was while it was doiong the installworld for FreeBSD 11.0-CURRENT #1275 r267441M/267441:1100023, so it was running FreeBSD 11.0-CURRENT #1274 r267378M/267384:1100022 at the time. And (to bring this back to the topic at hand), when I checked the logs, the last thing I found before the start-up messages fro the reboot was: Jun 13 06:00:29 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:00:29 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:11:35 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:16:46 g1-252 kernel: Expensive timeout(9) function: 0xc0c858e0(0xd15728d0) 3.292387227 s Jun 13 06:16:46 g1-252 kernel: iwn0: iwn_intr: fatal firmware error Jun 13 06:16:46 g1-252 kernel: firmware error log: Jun 13 06:16:46 g1-252 kernel: error type = SYSASSERT (0x0005) Jun 13 06:16:46 g1-252 kernel: program counter = 0x24EC Jun 13 06:16:46 g1-252 kernel: source line = 0x0489 Jun 13 06:16:46 g1-252 kernel: error data = 0x00FF0489 Jun 13 06:16:46 g1-252 kernel: branch link = 0x24C824C8 Jun 13 06:16:46 g1-252 kernel: interrupt link = 0x0916 Jun 13 06:16:46 g1-252 kernel: time= 2183893590 Jun 13 06:16:46 g1-252 kernel: driver status: Jun 13 06:16:46 g1-252 kernel: tx ring 0: qid=0 cur=203 queued=6 Jun 13 06:16:46 g1-252 kernel: tx ring 1: qid=1 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 2: qid=2 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 3: qid=3 cur=4 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 4: qid=4 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 5: qid=5 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 6: qid=6 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 7: qid=7 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 8: qid=8 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 9: qid=9 cur=206 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 10: qid=10 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 11: qid=11 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 12: qid=12 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 13: qid=13 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 14: qid=14 cur=0 queued=0 Jun 13
Re: iwn driver issue
On Fri, Jun 13, 2014 at 12:34:00PM -0500, Adrian Chadd wrote: This isn't this first time this has been reported, right? I think we may need to back this patch out until it's better resolved. I normally don't spend a huge amount of time in head -- enough to build it do a quick smoke-test. So it's certainly possible that it merits further exploration. And I'm willing experiment, but I cannot test it while I'm at work (as I don't use the wireless NIC at work -- I use it almost exclusively while I'm at home (and other places), though). Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpUls4FQ3Jar.pgp Description: PGP signature
Re: iwn driver issue
I have mixed feelings about this. Sure, a panic is a problem, but without it the problem will remain unfixed - I'm unable to reproduce it, even though I'm using the driver all the time. And it's pretty much useless without that patch. The fix will probably be trivial; I just need a proper backtrace. On 0613T1234, Adrian Chadd wrote: This isn't this first time this has been reported, right? I think we may need to back this patch out until it's better resolved. -a On 13 June 2014 11:52, David Wolfskill da...@catwhisker.org wrote: On Fri, Jun 13, 2014 at 06:36:44PM +0200, Edward Tomasz Napiera??a wrote: On 0613T1126, Stefan Parvu wrote: Hi, Im running FreeBSD current: FreeBSD nereid 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r265628: Thu May 8 08:05:37 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/VT amd64 on Asus Zenbook UX32VD. My wireless network works ok, however from time to time I need to restart the netif service since my link does not work anymore. After restart everything is ok. The device is: Wifi: Intel Centrino Advanced-N 6235. Sometimes Im able to see something like: iwn0: iwn_scan: called whilst scanning! iwn0: iwn_intr: fatal firmware error firmware error log: error type = UNKNOWN (0x198A) program counter = 0x00015920 source line = 0x01DC error data = 0x0296 branch link = 0x000159115910 interrupt link = 0xDBEA time= 2479833477 driver status: tx ring 0: qid=0 cur=14 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=19 queued=0 ... After restarting the networking service everything is back to normal. Can you update to at least r266546 and try again? In case it's of interest or use, in tracking head daily for some time on a Dell Precision M4400, I've seen similar symptoms. But this morning, something happene dthat was rather worse than usual: during make installworld, (while I was otherwise occupied getting ready to head in to work), the machine apparently rebooted. Here are the last several builds I've done: FreeBSD 11.0-CURRENT #1271 r267264M/267264:1100022: Mon Jun 9 07:47:43 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1272 r267321M/267323:1100022: Tue Jun 10 06:31:13 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1273 r267358M/267358:1100022: Wed Jun 11 08:51:08 PDT 2014 r...@d130.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1274 r267378M/267384:1100022: Thu Jun 12 12:51:53 PDT 2014 r...@d130.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 11.0-CURRENT #1275 r267441M/267441:1100023: Fri Jun 13 06:34:57 PDT 2014 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 Note that the reboot referenced above was while it was doiong the installworld for FreeBSD 11.0-CURRENT #1275 r267441M/267441:1100023, so it was running FreeBSD 11.0-CURRENT #1274 r267378M/267384:1100022 at the time. And (to bring this back to the topic at hand), when I checked the logs, the last thing I found before the start-up messages fro the reboot was: Jun 13 06:00:29 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:00:29 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:11:35 g1-252 kernel: iwn0: iwn_scan: called whilst scanning! Jun 13 06:16:46 g1-252 kernel: Expensive timeout(9) function: 0xc0c858e0(0xd15728d0) 3.292387227 s Jun 13 06:16:46 g1-252 kernel: iwn0: iwn_intr: fatal firmware error Jun 13 06:16:46 g1-252 kernel: firmware error log: Jun 13 06:16:46 g1-252 kernel: error type = SYSASSERT (0x0005) Jun 13 06:16:46 g1-252 kernel: program counter = 0x24EC Jun 13 06:16:46 g1-252 kernel: source line = 0x0489 Jun 13 06:16:46 g1-252 kernel: error data = 0x00FF0489 Jun 13 06:16:46 g1-252 kernel: branch link = 0x24C824C8 Jun 13 06:16:46 g1-252 kernel: interrupt link = 0x0916 Jun 13 06:16:46 g1-252 kernel: time= 2183893590 Jun 13 06:16:46 g1-252 kernel: driver status: Jun 13 06:16:46 g1-252 kernel: tx ring 0: qid=0 cur=203 queued=6 Jun 13 06:16:46 g1-252 kernel: tx ring 1: qid=1 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 2: qid=2 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 3: qid=3 cur=4 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 4: qid=4 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 5: qid=5 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 6: qid=6 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx ring 7: qid=7 cur=0 queued=0 Jun 13 06:16:46 g1-252 kernel: tx
Re: iwn driver issue
On 0613T1941, Stefan Parvu wrote: On Fri, 13 Jun 2014 18:36:44 +0200 Edward Tomasz Napierała tr...@freebsd.org wrote: Can you update to at least r266546 and try again? to do this I need to svn update all my /usr/src code and rebuild the kernel - no iso images available for it ? Correct ? How often are iso images published for current ? I'm not sure if there are any ISO images. And yes, you need a new kernel. I will update my machine a bit later. Were there many fixes for iwn driver on latest branch ? This specific problem should be fixed by the revision above. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn driver issue
On 0613T1058, David Wolfskill wrote: On Fri, Jun 13, 2014 at 12:34:00PM -0500, Adrian Chadd wrote: This isn't this first time this has been reported, right? I think we may need to back this patch out until it's better resolved. I normally don't spend a huge amount of time in head -- enough to build it do a quick smoke-test. So it's certainly possible that it merits further exploration. And I'm willing experiment, but I cannot test it while I'm at work (as I don't use the wireless NIC at work -- I use it almost exclusively while I'm at home (and other places), though). It would be great if you could help me with this. Basically you need to enable crashdumps, as described below, and obtain a backtrace. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Just for the record, the easiest way to make iwn firmware panic is to enter ddb (ctrl-alt-esc), wait five seconds and exit it (center). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: iwn driver issue
On Fri, Jun 13, 2014 at 09:36:35PM +0200, Edward Tomasz Napiera??a wrote: ... I normally don't spend a huge amount of time in head -- enough to build it do a quick smoke-test. So it's certainly possible that it merits further exploration. And I'm willing experiment, but I cannot test it while I'm at work (as I don't use the wireless NIC at work -- I use it almost exclusively while I'm at home (and other places), though). It would be great if you could help me with this. Basically you need to enable crashdumps, as described below, and obtain a backtrace. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html I have had crash dumps on panics running head (slice 4 of the boot device, in my case) in the past, so that process works. I just didn't get a dump this morning. :-( d130(9.3)[1] grep dump /S4/etc/rc.conf dumpdev=AUTO d130(9.3)[2] Just for the record, the easiest way to make iwn firmware panic is to enter ddb (ctrl-alt-esc), wait five seconds and exit it (center). Does that process yield useful information? (That is, is that process sufficiently similar to a sequence of events that occurs in the real world that the resulting information may be used to figure out how to make the code avoid misbehavior?) If so, I can try that soonish (e.g., en route home today, once I've boarded the train -- vs. while I'm still on my bike :-}). Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp1PJ3GMUEcY.pgp Description: PGP signature
