Opened 6 years ago

Closed 3 years ago

#9601 closed bug (fixed)

[attansic_l1] crashes on boot

Reported by: bob_ok Owned by: 3dEyes
Priority: normal Milestone: R1
Component: Drivers/Network/attansic_l1 Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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.

Attansic L1 KDL on Boot

Attachments (5)

attansic_l1.jpg (2.9 MB) - added by bob_ok 6 years ago.
Attansic L1 KDL on Boot
capture.minicom (118.4 KB) - added by pkacperski 3 years ago.
full debug log from UART
attansic_l1 (134.6 KB) - added by korli 3 years ago.
driver with KTR enabled in freebsd_network directory
bug9601.hpkg (57.7 KB) - added by korli 3 years ago.
package with the debug driver
24_03_2016_21_59.txt (245.4 KB) - added by pkacperski 3 years ago.
bug9601 log file from RS232

Change History (15)

Changed 6 years ago by bob_ok

Attachment: attansic_l1.jpg added

Attansic L1 KDL on Boot

comment:1 Changed 6 years ago by 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?

comment:2 Changed 6 years ago by korli

A syslog with the PCI log would be nice.

Changed 3 years ago by pkacperski

Attachment: capture.minicom added

full debug log from UART

Changed 3 years ago by korli

Attachment: attansic_l1 added

driver with KTR enabled in freebsd_network directory

Changed 3 years ago by korli

Attachment: bug9601.hpkg added

package with the debug driver

comment:3 Changed 3 years ago by 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.

Changed 3 years ago by pkacperski

Attachment: 24_03_2016_21_59.txt added

bug9601 log file from RS232

comment:4 Changed 3 years ago by pkacperski

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

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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.

Last edited 3 years ago by pkacperski (previous) (diff)

comment:7 in reply to:  6 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by KapiX

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

comment:9 Changed 3 years ago by 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.

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

Last edited 3 years ago by pkacperski (previous) (diff)

comment:10 Changed 3 years ago by mmlr

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.