X230 Intel Centrino Wireless-N 2200 not working

[Adrian Chadd]

hi!

nope - it looks like you had the whole transmit side get out of sync,
it threw a seqno != seqno error, then firmware panic.

I wish i knew what else was lurking here to cause this :(

Does it happen often?


-a


On 23 August 2015 at 05:56, Toby Slight <tobyslight at gmail.com> wrote:
>
> On 23 August 2015 at 06:26, Adrian Chadd <adrian.chadd at gmail.com> wrote:
>>
>> email -wireless with some info, and if it's something we can poke,
>> file a bug at bugs.freebsd.org/submit
>>
>
> Cool. Well since this is already going to -wireless, here's the exert from
> my /var/log/messages. Do you think enabling acpi_ibm or coretemp might have
> had anything to do with it?
>
> Aug 23 00:45:17 xbsd kernel: acpi_ibm0: <IBM ThinkPad ACPI Extras> on acpi0
> Aug 23 00:51:07 xbsd kernel: coretemp0: <CPU On-Die Thermal Sensors> on cpu0
> Aug 23 00:51:07 xbsd kernel: coretemp1:
> Aug 23 00:51:07 xbsd kernel: <CPU On-Die Thermal Sensors> on cpu1
> Aug 23 00:51:07 xbsd kernel: coretemp2: <CPU On-Die Thermal Sensors> on cpu2
> Aug 23 00:51:07 xbsd kernel: coretemp3: <CPU On-Die Thermal Sensors> on cpu3
> Aug 23 00:54:58 xbsd kernel: iwn0: device timeout
> Aug 23 00:54:58 xbsd kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
> Aug 23 00:55:03 xbsd kernel: iwn0: iwn_tx_data: m=0xfffff800105a7b00: seqno
> (11604) (84) != ring index (0) !
> Aug 23 00:55:03 xbsd kernel: iwn0: iwn_intr: fatal firmware error
> Aug 23 00:55:03 xbsd kernel: firmware error log:
> Aug 23 00:55:03 xbsd kernel: error type      = "UNKNOWN" (0x0000102C)
> Aug 23 00:55:03 xbsd kernel: program counter = 0x0000CEA8
> Aug 23 00:55:03 xbsd kernel: source line     = 0x000006A4
> Aug 23 00:55:03 xbsd kernel: error data      = 0x000000FE80000000
> Aug 23 00:55:03 xbsd kernel: branch link     = 0x0000CDBA0000CDBA
> Aug 23 00:55:03 xbsd kernel: interrupt link  = 0x0000E1AE00000000
> Aug 23 00:55:03 xbsd kernel: time            = 4610402
> Aug 23 00:55:03 xbsd kernel: driver status:
> Aug 23 00:55:03 xbsd kernel: tx ring  0: qid=0  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  1: qid=1  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  2: qid=2  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  3: qid=3  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  4: qid=4  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  5: qid=5  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  6: qid=6  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  7: qid=7  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  8: qid=8  cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring  9: qid=9  cur=14  queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 10: qid=10 cur=1   queued=1
> Aug 23 00:55:03 xbsd kernel: tx ring 11: qid=11 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 12: qid=12 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 13: qid=13 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 14: qid=14 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 15: qid=15 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 16: qid=16 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 17: qid=17 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 18: qid=18 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: tx ring 19: qid=19 cur=0   queued=0
> Aug 23 00:55:03 xbsd kernel: rx ring: cur=24
> Aug 23 00:55:03 xbsd kernel: iwn0: iwn_panicked: controller panicked,
> iv_state = 5; resetting...
> Aug 23 00:55:03 xbsd kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
>
> I was hoping to have a crash dump to poke at (or at least try and learn how
> to poke at), but it seems that despite having dumpdev set to AUTO in
> rc.conf, because I don't have sufficient swap space and/or because I'm using
> a full ZFS system nothing was saved in /var/crash.
>
> Is there any other information that might be useful? And is this worth
> filing an official bug report about?