Добрый вечер. Есть проблемма - помогите, пожалуйста, решить.
Суть ее такова :
Есть плата at91sam9g20ek с PHY Davicom DM9161AEP.

с ядром linux 2.6.30 вот такая беда твориться :

kernel BUG at drivers/net/macb.c:442!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c79e4000
[00000000] *pgd=279fa031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
Modules linked in: vin_mod dss_mod k16_mod scsi_wait_scan
CPU: 0 Not tainted (2.6.30 #40)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<c002974c>] lr : [<c0029748>] psr: 60000013
sp : c79e1e58 ip : fefff200 fp : 00000040
r10: 00000100 r9 : c78ebb38 r8 : 00000121
r7 : 000000d6 r6 : c78ebb00 r5 : c782e4e0 r4 : 00000120
r3 : 00000000 r2 : 80000013 r1 : 000019c1 r0 : 00000029
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 279e4000 DAC: 00000015
Process elgatos (pid: 497, stack limit = 0xc79e0268)
Stack: (0xc79e1e58 to 0xc79e2000)
1e40: 0000011f c0185ee8
1e60: 00000040 00000000 c79e0000 c78ebb38 00000040 00000100 0000012c c031410c
......
......

перед этим ifconfig мне показывал ошибки overruns :

eth0 Link encap:Ethernet HWaddr 00:12:34:56:09:8F
inet addr:192.100.101.254 Bcast:192.100.101.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:170240 errors:82 dropped:0 overruns:82 frame:0
TX packets:188302 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:31242471 (29.7 MiB) TX bytes:40814141 (38.9 MiB)
Interrupt:21 Base address:0x4000

когда грузилось ядро было такое сообщение :

MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffc4000 irq 21 (00:12:34:56:10:8f)
eth0: attached PHY driver [Davicom DM9161A] (mii_bus:phy_addr=ffffffff:00, irq=-1)

плюнул на это ядро и перешел на 2.6.33 (с патчем от linux4sam),
ядро больше не падает, но ошибки overruns остались, причем их количество
растет при увеличении трафика (sip, rtp-пакеты) через LAN.
Подключил плату к свитчу с портом в 10Mbps/Full-Duplex - ошибки overruns исчезли.
Однако на плате не могу принудительно установить режим 10/Full-Duplex:

mii-tool говорит :
SIOCGMIIPHY on 'eth0' failed: Operation not supported
no MII interfaces found
примерно тоже говорит ifconfig при попытке сменить media у LAN-а

Вопрос такой :
режим MII не поддерживается драйвером ядра macb для PHY Davicom DM9161AEP ????????????
может кто-то с такой проблеммой уже сталкивался (что-то подобное читал у miniMax-а, но почему-то
его рекомеднации мне не помогли).

Кто вкурсе, помогите, пожалуйста.

Разные. Хотя есть у меня подозрение, что один списан с другого.

Судя по исходникам - at91_ether применим для процессора at91rm9200. он у меня довольно хорошо работает на этом чипе
(board ar91rm9200-dk с PHY Rtl)
А вот на at91sam9g20, я так понимаю, его ипользовать не получится, по крайней мере без изменений (он и хэадеры использует
от at91rm9200)

А вот насчет "замести ошибку под ковер" - хотелось бы попробывать , только вот не знаю как, можите надоумить ?

Кстати, может кто-то пытался отправить в Atmel кляузу на macb ? честно говоря - я пробовал, но ни ответа и привета....(хотя назад письмо не вернулось)

Сами модули у этих процессоров практически идентичные, поэтому должен запуститься с минимальными изменениями.


Попробуйте записать 0x10000 в MATRIX_PRAS3 - это даст приоритет EMAC'у на шине. Не факт, что в этом дело, но возможно.


Ну, тут как бы as is и все такое. Быстрее будет исправить самому. Тем более что атмеловский софт, на мой взгляд, отличается отвратным качеством изначально.

Вклинюсь в вашу беседу. Колега некоторое время назад боролся с аналогичной проблемой на 9260. Его решение - это перенос дескрипторов DMA во внутреннюю SRAM, т.к. доступ к ней несколько быстрее.

Вот этот патч.

Кроме того, на более свежих ядрах это проявляется редко и патч, в принципе, не требуется.

У 9260 был пункт в еррате, касающийся расположения дескрипторов в SDRAM (может слететь передача). Но в 9G20 по этому поводу тишина.

Пробовал поднять приоритет - писал 0x10000 -> MATRIX_PRAS3 - не помогло, посмотрел по доке этот регистр и похоже
туда надо писать 2 разряда, то есть не 0х10000 а 0х30000 (константа M4PR) - записал. по началу вроде ничего было,
overruns-ов не было (на одиночных sip-вызовах), но как только завел sipp - начали копится overruns-ы (это на 100Мбитах),
спустился на 10Мбит - стали копиться ошибки frame. блин, наказание какое-то. похоже не удалось "загнать проблемму под ковер"

А насчет патча - так ведь он вроде передачи касается (буфер на передачу в SRAM переезжает- или я ошибаюсь ? да и размер SRAM у 9260 и g20 разные вроде), а у меня на интерфейсе по передаче не ошибок, так что и не знаю - пробовать его или нет....





а на более свежих это каких ? я уже пробовал даже 3.0.3 - результат тот же (да там и macb старый и похоже не правился
со времен царя гороха).

Мне кажется, корни у underrun'ов и overrun'ов одни - DMA не успевает. Или память. Можно так же попробовать и с буферами для приема.

Сомневаюсь насчет DMA да и памяти тоже (хотя с DMA что-то неладное делается, при попутке перенести буфер на передачу
в SRAM ядро пракитчески сразу падает -> "kernel BUG at arch/arm/mm/dma-mapping.c:426!", что-то видимо я не включил через menuconfig для ядра). При работе через конвертор usb-lan все же нормально и с памятью и с dma (хотя может в этом случае dma
и вовсе не используется)

Свершилось ! Нашелся человек, который вправил мозги атмеловскому драйверу macb. Теперь у меня lan (на at91sam9g20ek) работает отлично !

И? Патч не хотите здесь опубликовать?

патча как такового нет, правили по-живому, но кому надо - дам исправленный исходник macb.c (под 2.6.33)

Надо!!!

ftp://elgato@ltd.com.ua/g20/macb.c_correct.tar.gz
pwd=login
для ядра 2.6.33

Сообщение отредактировал salara - Aug 9 2012, 09:02

Спасибо.
Не ожидал такого объема изменений... Приемная часть чуть ли не переписана заново...
Можете в нескольких словах описать суть сделанных изменений?

Не я автор изменений, могу только сказать что основные изменения претерпели функции macb_rx_frame (на ней
собственно ядро и падало при приеме фрэйма), macb_rx, macb_poll