Intel 6000 and kernel panic (ThinkPad T510)

A

andrnils

Hello,

after install FreeBSD 8.0 and then updating to FreeBSD-8 stable I have some problems with the Intel Wireless 6000 card ( iwn0: <Intel(R) PRO/Wireless 6000> mem 0xf2000000-0xf2001fff irq 17 at device 0.0 on pci3 ). After a short period of usage, the computer kernel panics.

Is this a known issue? The computer is a ThinkPad T510.
 
As a workaround you could try to use WinXP driver for the chip via NDIS. You will need to compile a kernel without iwn driver unless you are loading it as a module.
 
Thanks,

that is of course a possibility ;) I'd rather not go down that path ( I don't really need wireless yet). I'll keep tracking stable and hope for improvements :)

There are more pressing issuses with the laptop I want to deal with first...
 
No, there are no known issues with this card, you are pretty much the first one I know of who is using that card. ;)

Are you able to get a backtrace for the panic, that would help a lot.
 
Ok, modern hardware isn't always good ;)

I added
Code: 
dumpdev="/dev/label/swap"
dumpdi="/var/crash"
to /etc/rc.conf and rebooted. Check one; Is this the correct/desired procedure?

I then loaded the iwn module. It doesn't panic as 'reliably' as my ipw3945, but after moving some data about with scp and running ping it paniced and core was saved. An interesting observation from the ping output: It would only manage to send 9 sucessive pings before the net went down a short while ( two pings ).

The files are about 1.8G, which is a bit of a problem on my 70kb/s upload. Is there a place where I can put files to make them available to interested developers? I could perhaps get KTH to host them for me temporarily.

Best regards
andrnils
 
Would you try this patch?

Also, it would help if you can post the last few lines of
# wlandebug 0xffffffff
# sysctl dev.iwn.0.debug=0xffffffff
before the panic, in case the patch doesn't fix it.
 
I applied the patch and recompiled the modules if_iwn and iwnfw, installed them and tried again.

It took a while longer to get it to crash, but it still looses net very regularly :(

The result of
[CMD=""]# wlandebug 0xffffffff
# sysctl dev.iwn.0.debug=0xffffffff[/CMD]

is
Code: 
net.wlan.0.debug: 0x0 => 0xffffffff<11n,debug,dumppkts,crypto,input,xrate,elemid,node,assoc,auth,scan,output,state,power,hwmp,dot1xsm,
radius,raddump,mesh,wpa,acl,wme,superg,doth,inact,roam,rate,action,wds,ioctl,tdma>
dev.iwn.0.debug: 0 -> -1

Unfortunately the dump didn't capture the instruction pointer, but the backtrace looks similar.

Let me know if you need anything else.

Best regards
andrnils
 
andrnils said:
I applied the patch and recompiled the modules if_iwn and iwnfw, installed them and tried again.

It took a while longer to get it to crash, but it still looses net very regularly :(
Click to expand...

Ok, thanks for trying anyway.

andrnils said:
The result of
[CMD=""]# wlandebug 0xffffffff
# sysctl dev.iwn.0.debug=0xffffffff[/CMD]

is
Code: 
net.wlan.0.debug: 0x0 => 0xffffffff<11n,debug,dumppkts,crypto,input,xrate,elemid,node,assoc,auth,scan,output,state,power,hwmp,dot1xsm,
radius,raddump,mesh,wpa,acl,wme,superg,doth,inact,roam,rate,action,wds,ioctl,tdma>
dev.iwn.0.debug: 0 -> -1
Click to expand...

This enables debugging and should give you a whole lot of spam in either # dmesg or /var/log/messages. You should still have those messages after a crash.
 
You might also run [CMD="(kgdb)"]symbol-file /boot/kernel/if_iwn.ko.symbol[/CMD] and then [CMD="(kgdb)"]backtrace[/CMD] again. I'm not sure, but it might show a line number for the iwn calls then. Afaik, just building the module doesn't install the symbol file (no debugging enabled) so you might have to rebuild/reinstall the kernel itself.
 
Ahh, I did the testing from withing X. There was a whole bunch of spam in /var/log/messages.0.bz2. The result is available at here.

Loading the symbols in kgdb lead to a completely different backtrace:
Code: 
(kgdb) backtrace
#0  0xffffffff8057c54e in ?? ()
#1  0xffffffff8057c573 in ?? ()
#2  0xffffff80ae54c730 in ?? ()
#3  0xffffffff8057cab0 in ?? ()
#4  0x0000000000000001 in iwn_dma_map_addr (arg=0x0, segs=0x0, nsegs=0, error=0) at /usr/src/sys/modules/iwn/../../dev/iwn/if_iwn.c:1070
#5  0x0000000000000000 in ?? ()
#6  0x0000000000000104 in iwn5000_get_temperature ()
Previous frame inner to this frame (corrupt stack?)

Best regards
andrnils
 
This is weird, both backtraces show different errors (at least the location differs). Hmm, I'll have to look into bus dma stuff again.
 
Hi

I've just bought a T510 and on first inspection it looks like I'm having the same, or a very similar, issue. Intel Ultimate-n 6300, works fine for a while then panics. I haven't looked into it yet, nor have I tried any of the suggestions above as I'm busy sorting out various other issues first. I will come back to it though and post back when I have more info.

sim
 
You must log in or register to reply here.
Back
Top