[attansic_l1] crashes on boot

[bob_ok]

Attansic L1 driver (Atheros L1 chip on ASUS M3A motherboard) crashes in KDL on boot and if I move/rename the driver, then after complete booting without the networking it goes into KDL again after I put driver file back and restart net_server.

Couldn't get syslog, so I took the photo.

[bob_ok]

Attansic L1 KDL on Boot

[mmlr]

The following (normalized) syslog snipped was recovered:

vesa: vesa_init() completed successfully!
vesa: acc: vesa.accelerant
attansic_l1: init_driver(0xcd9a4c90)
[attansic_l1] (age) bus_alloc_resource(3, [16], 0x0, 0xffffffff, 0x1,0x2)
add_memory_type_range(3519, 0xfebc0000, 0x20000, 0)
set MTRRs to:
  mtrr:  0: base:    0xee000, size:     0x1000, type: 0
  mtrr:  1: base: 0xc7fb0000, size:    0x10000, type: 0
  mtrr:  2: base: 0xc7fc0000, size:    0x40000, type: 0
  mtrr:  3: base: 0xe0000000, size: 0x20000000, type: 0
  mtrr:  4: base: 0xc8000000, size:  0x8000000, type: 1
[attansic_l1] (age) PCI device revision : 0x00b0
[attansic_l1] (age) Chip id/revision : 0x9006
[attansic_l1] (age) 1280 Tx FIFO, 2364 Rx FIFO
[attansic_l1] (age) MSIX count : 0
[attansic_l1] (age) MSI count : 1
allocate_io_interrupt_vectors: allocated 1 vectors starting from 24
msi_allocate_vectors: allocated 1 vectors starting from 24
[attansic_l1] (age) Using 1 MSI messages.
[attansic_l1] (age) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
[attansic_l1] (age) Read request size : 512 bytes.
[attansic_l1] (age) TLP payload size : 128 bytes.
[attansic_l1] (age) could not load DMA'able memory for Rx ring.
add_memory_type_range(3524, 0x90000, 0x70000, 0)
set MTRRs to:
  mtrr:  0: base:    0x90000, size:    0x10000, type: 0
  mtrr:  1: base:    0xa0000, size:    0x20000, type: 0
  mtrr:  2: base:    0xc0000, size:    0x40000, type: 0
  mtrr:  3: base: 0xc7fb0000, size:    0x10000, type: 0
  mtrr:  4: base: 0xc7fc0000, size:    0x40000, type: 0
  mtrr:  5: base: 0xe0000000, size: 0x20000000, type: 0
  mtrr:  6: base: 0xc8000000, size:  0x8000000, type: 1
if_initname(0xcf48e400, age, 3)
[attansic_l1] attansic_l1: /dev/net/attansic_l1/0
[attansic_l1] () Found MII: atphy
[attansic_l1] () OUI 0x00c82e, model 0x0001, rev. 5
[attansic_l1] ()  
ifmedia_add: Adding Entry...
...
msi enabled: 0x0081
loaded driver /boot/system/add-ons/kernel/drivers/dev/net/attansic_l1
etherpci: init_driver init_driver: etherpci not found
loaded driver /boot/system/add-ons/kernel/drivers/dev/net/pegasus
sis19x:00.24.724:init_hardware::SiS19X:init_hardware()
remove_memory_type_range(3524, 0x90000, 0x70000, 0)
set MTRRs to:
  mtrr:  0: base:    0xee000, size:     0x1000, type: 0
  mtrr:  1: base: 0xc7fb0000, size:    0x10000, type: 0
  mtrr:  2: base: 0xc7fc0000, size:    0x40000, type: 0
  mtrr:  3: base: 0xe0000000, size: 0x20000000, type: Entry...

The relevant line being:

[attansic_l1] (age) could not load DMA'able memory for Rx ring.

Which points to ​ if_age.c line 1009 which obviously hides the error by not setting an error if the address is 0. The bus_dmamap_load() call on line 1004 calls into ​ fbsd_busdma_x86.c line 711 which in turn calls into _bus_dmamap_load_buffer() on line 569 of that file. Something other than EINPROGRESS and ENOMEM goes on there, as those two would be returned as result in bus_dmamap_load(). The other errors are only sent to the supplied callback. The callback is age_dmamap_cb() on line 794 of the former file and in the error case simply returns immediately, leaving the ctx->age_busaddr at it's previous value of 0 (set in 1003). Hence error = 0, age_busaddr = 0, resulting in the error message, but not actually failing the init.

To actually debug the reason for the bus_dmamap_load() failure, adding some debug output to the driver before the call or enabling debug output in fbsd_busdma_x86.c should be tried. A panic at the point of the callback in the error case would be helpful as well. Note that it doesn't seem to be a general problem with bus_dmamap_load(), as the same call for the tx ring a couple lines higher seems to work, as do the following calls judging by the lack of their error messages.

Note the RX ring size calculated from ​ if_agevar.h line 123 where AGE_RX_RING_CNT is the same as AGE_TX_RING_CNT at 256 each and sizeof(struct rx_desc) from ​ if_agereg.h line 610 being 6 bytes = 1536 bytes. Note that the TX ring is 2048 due to tx_desc being 8 bytes. So possibly an alignment/block size issue?

[korli]

A syslog with the PCI log would be nice.

[pkacperski]

full debug log from UART

[korli]

driver with KTR enabled in freebsd_network directory

[korli]

package with the debug driver

[korli]

You should be able to install the bug9601.hpkg package in /system/packages/ on a x86_gcc2 Haiku, and have the driver with debug trace loaded. Eventually reboot.

[pkacperski]

bug9601 log file from RS232

[pkacperski]

by mistake I appended new log to the old one, sorry for that.

[korli]

Relevant lines:

[attansic_l1] (age) Using 1 MSI messages.
[attansic_l1] (age) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
[attansic_l1] (age) Read request size : 512 bytes.
[attansic_l1] (age) TLP payload size : 128 bytes.
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:323) bus_dma_tag_create returned tag 0xe166e418 tag flags 0x0 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:323) bus_dma_tag_create returned tag 0xe165c568 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:323) bus_dma_tag_create returned tag 0xe165c478 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:323) bus_dma_tag_create returned tag 0xe165c3d8 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:323) bus_dma_tag_create returned tag 0xe165c068 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:323) bus_dma_tag_create returned tag 0xe1667c50 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:535) bus_dmamem_alloc: tag 0xe165c568 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:728) bus_dmamap_load: tag 0xe165c568 tag flags 0x40 error 0 nsegs 1
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:535) bus_dmamem_alloc: tag 0xe165c478 tag flags 0x40 error 0
[attansic_l1] (/home/korli/githaiku/haiku/src/libs/compat/freebsd_network/fbsd_busdma_x86.c:728) bus_dmamap_load: tag 0xe165c478 tag flags 0x40 error -2147454972 nsegs 2
[attansic_l1] (age) could not load DMA'able memory for Rx ring.
[attansic_l1] (age) PCI VPD capability not found!

-2147454972 => EFBIG this hints to an ​exit in the loop of _bus_dmamap_load_buffer().

We alloc only one segment ​if_age.c line 901 and that alloc uses a simple malloc which could deliver allocations on a boundary ​fbsd_busdma_x86.c line 515. However the code at ​fbsd_busdma_x86.c line 680 should extend the first page segment when a page boundary is met. The failure is still unclear, but I suppose this code could be tested in the context of another driver.

[pkacperski]

I don't know whether it's relevant or not, but haiku usually boots successfully once per 5-6 attempts.

...and when it does, TCP/IP stack is fully operational.

[mmlr]

Replying to pkacperski:

I don't know whether it's relevant or not, but haiku usually boots successfully once per 5-6 attempts.

That observation might hint at it being dependent on memory layout that changes between boots. The memory alignment enforced in hrev50755 might therefore fix this issue.

[KapiX]

I can confirm it doesn't crash anymore with hrev50755.

[pkacperski]

I have abandoned the idea of running Haiku on that computer, so I wasn't updating that copy of the system for quite a long.

Nontheless, on hrev50755 the problem seems to be gone, ie the driver does not crash during the boot any more.

[mmlr]

Thanks for the quick feedback! Closing as fixed in hrev50755.