Добрый вечер. Есть проблемма - помогите, пожалуйста, решить.
Суть ее такова :
Есть плата 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-а, но почему-то
его рекомеднации мне не помогли).

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

Уважаемые, помогите кто в курсе этой беды.
теперь и на ядре 2.6.33 тот же баг получаю (при большой нагрузке на LAN) :

kernel BUG at drivers/net/macb.c:428!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c3a24000
[00000000] *pgd=239d3031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1] PREEMPT
last sysfs file:
Modules linked in: vin_mod k16_mod scsi_wait_scan
CPU: 0 Not tainted (2.6.33 #33)
PC is at __bug+0x1c/0x28
LR is at __bug+0x18/0x28
pc : [<c002c8a4>] lr : [<c002c8a0>] psr: 60000013
sp : c39dbe50 ip : fefff200 fp : 00000040
r10: 00000100 r9 : c3884350 r8 : 000001a3
r7 : 000000d6 r6 : c3884320 r5 : c38435c0 r4 : 000001a2
r3 : 00000000 r2 : 00000102 r1 : 00001ab5 r0 : 0000002c
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 23a24000 DAC: 00000015
Process elgatos (pid: 504, stack limit = 0xc39da270)
Stack: (0xc39dbe50 to 0xc39dc000)
be40: 000001a1 c01b0bf0 00000040 00000000
be60: c39dbf74 c3884350 00000040 0000000c 0000012c c037f55c c037f56c 002753e2
be80: c03941e8 c01fca7c c39dbdb8 00000102 c39da000 0000000c 00000001 00000003
bea0: 0000000a c038b460 00000000 c0049cb4 c39da000 00000000 00000015 00000015
bec0: 00000000 00000015 00000001 00000000 c39da000 41977216 41977434 c004a004
bee0: 00000015 c0028080 0000c350 ffffffff fefff000 c0028ae8 c482f000 00000032
bf00: 000001ff 000000fd 00001090 0000001c c4841080 00000008 00000208 c39da000
bf20: 41977216 41977434 c4841090 c39dbf40 000001e3 bf0065b8 20000013 ffffffff
bf40: 165ac476 00000001 00000000 c39d83c0 41977216 c39dbf88 00000003 00000208
bf60: 00000000 c0098be4 00000000 00000000 00000000 00000000 c39d83c0 00000003
bf80: c0029088 c0098ff4 00000000 00000000 00000000 00000001 00000002 00000004
bfa0: 40041000 c0028ee0 00000002 00000004 0000000c 41977216 00000208 41977216
bfc0: 00000002 00000004 40041000 00000003 40041000 003d0f00 40029864 41977434
bfe0: 00000000 41976c00 40033624 40033ca4 80000010 0000000c 00000000 00000000
[<c002c8a4>] (__bug+0x1c/0x28) from [<c01b0bf0>] (macb_poll+0x164/0x248)
[<c01b0bf0>] (macb_poll+0x164/0x248) from [<c01fca7c>] (net_rx_action+0x68/0x180)
[<c01fca7c>] (net_rx_action+0x68/0x180) from [<c0049cb4>] (__do_softirq+0x78/0x100)
[<c0049cb4>] (__do_softirq+0x78/0x100) from [<c004a004>] (irq_exit+0x44/0x64)
[<c004a004>] (irq_exit+0x44/0x64) from [<c0028080>] (asm_do_IRQ+0x80/0xa0)
[<c0028080>] (asm_do_IRQ+0x80/0xa0) from [<c0028ae8>] (__irq_svc+0x48/0x8c)
Exception stack(0xc39dbef8 to 0xc39dbf40)
bee0: c482f000 00000032
bf00: 000001ff 000000fd 00001090 0000001c c4841080 00000008 00000208 c39da000
bf20: 41977216 41977434 c4841090 c39dbf40 000001e3 bf0065b8 20000013 ffffffff
[<c0028ae8>] (__irq_svc+0x48/0x8c) from [<bf0065b8>] (rchan_read+0x324/0x5b0 [k16_mod])
[<bf0065b8>] (rchan_read+0x324/0x5b0 [k16_mod]) from [<c0098be4>] (vfs_read+0xac/0x158)
[<c0098be4>] (vfs_read+0xac/0x158) from [<c0098ff4>] (sys_read+0x3c/0x68)
[<c0098ff4>] (sys_read+0x3c/0x68) from [<c0028ee0>] (ret_fast_syscall+0x0/0x28)
Code: e1a01000 e59f000c eb006336 e3a03000 (e5833000)
---[ end trace 4ca592b1fafad532 ]---
Kernel panic - not syncing: Fatal exception in interrupt
[<c002e998>] (unwind_backtrace+0x0/0xdc) from [<c0044878>] (panic+0x58/0x12c)
[<c0044878>] (panic+0x58/0x12c) from [<c002cd48>] (die+0x16c/0x198)
[<c002cd48>] (die+0x16c/0x198) from [<c002f6c0>] (__do_kernel_fault+0x68/0x80)
[<c002f6c0>] (__do_kernel_fault+0x68/0x80) from [<c002f89c>] (do_page_fault+0x1c4/0x1dc)
[<c002f89c>] (do_page_fault+0x1c4/0x1dc) from [<c0028318>] (do_DataAbort+0x38/0x9c)
[<c0028318>] (do_DataAbort+0x38/0x9c) from [<c0028a8c>] (__dabt_svc+0x4c/0x60)
Exception stack(0xc39dbe08 to 0xc39dbe50)
be00: 0000002c 00001ab5 00000102 00000000 000001a2 c38435c0
be20: c3884320 000000d6 000001a3 c3884350 00000100 00000040 fefff200 c39dbe50
be40: c002c8a0 c002c8a4 60000013 ffffffff
[<c0028a8c>] (__dabt_svc+0x4c/0x60) from [<c002c8a4>] (__bug+0x1c/0x28)
[<c002c8a4>] (__bug+0x1c/0x28) from [<c01b0bf0>] (macb_poll+0x164/0x248)
[<c01b0bf0>] (macb_poll+0x164/0x248) from [<c01fca7c>] (net_rx_action+0x68/0x180)
[<c01fca7c>] (net_rx_action+0x68/0x180) from [<c0049cb4>] (__do_softirq+0x78/0x100)
[<c0049cb4>] (__do_softirq+0x78/0x100) from [<c004a004>] (irq_exit+0x44/0x64)
[<c004a004>] (irq_exit+0x44/0x64) from [<c0028080>] (asm_do_IRQ+0x80/0xa0)

[<c0028080>] (asm_do_IRQ+0x80/0xa0) from [<c0028ae8>] (__irq_svc+0x48/0x8c)
Exception stack(0xc39dbef8 to 0xc39dbf40)
bee0: c482f000 00000032
bf00: 000001ff 000000fd 00001090 0000001c c4841080 00000008 00000208 c39da000
bf20: 41977216 41977434 c4841090 c39dbf40 000001e3 bf0065b8 20000013 ffffffff
[<c0028ae8>] (__irq_svc+0x48/0x8c) from [<bf0065b8>] (rchan_read+0x324/0x5b0 [k16_mod])
[<bf0065b8>] (rchan_read+0x324/0x5b0 [k16_mod]) from [<c0098be4>] (vfs_read+0xac/0x158)
[<c0098be4>] (vfs_read+0xac/0x158) from [<c0098ff4>] (sys_read+0x3c/0x68)
[<c0098ff4>] (sys_read+0x3c/0x68) from [<c0028ee0>] (ret_fast_syscall+0x0/0x28)


Причем строка 428 в исходнике macb.c выглядит так

BUG_ON(frag != last_frag);

кто-то же встречал такую беду ? отзовитесь пожалуйста

У меня есть мысль использовать аналог at91sam9g20ek, только с другим PHY, поэтому очень интересно узнать, как разрешилась ваша проблема.
Также буду рад услышать отзывы от всех, кто использует решения подобные at91sam9g20ek с linux-2.6.30. Главным образом интересует стабильность работы SPI и ethernet.

Попутно еще вопрос.

В исходниках ядра 2.6.30 (взятыx отсюда: http://armdevs.googlecode.com/files/linux-2.6.30.tar.bz2) я не нашел код,который мог бы выдавать такое сообщение. В drivers/net/arm/at91_ether.c я вижу такую строку:

printk(KERN_INFO "%s: Davicom 9161 PHY %s\n", dev->name, (lp->phy_media == PORT_FIBRE) ? "(Fiber)" : "(Copper)");

Вы использовали какой-то другой драйвер?

Ничем хорошим наша проблемма так и не решилась. Испробовал кучу ядер (2.6.33, 2.6.34, 2.6.39) результат один и тот же.
Ядро продолжает падать при интенсивном трафике через LAN (RTP пакеты) вот примерно с таким сообщением :
kernel BUG at drivers/net/macb.c:417!
. Пришлось пока задействовать один разъем usb под конвертор usb-lan (D-LINK на базе чипсета ASIX) и пустить по нему трафик, не фонтан конечно, но пока хоть что-то.
Нигде в инете так и не нашел вразумительного объяснения такому поведению драйвера macb.
А SPI мы вообще не используем, свой чипсет (Cyclon-III Altera) посадили прямо на шину процессора по NCS3.
Вообщем пара MACB-Davicom что-то не пошла у нас, хотим попробывать другой PHY вместо Davicom, например Micrel или что-то еще.

Чем PHY-то виноват, если проблема в драйвере EMAC?

Возможно и так, но тогда наверно не в EMAC а в атмеловском MACB
А у вас есть лекарство для драйвера ?

Так MACB - это и есть драйвер EMAC.


Просмотрел его бегло - увы, горбатого могила исправит.
Без нормальной обработки ошибок по приему он и должен падать на большой загрузке.

Правильно ли я понял, что на данный момент ожидать нормальной работы встроенного в at91 ethernet не стоит?

У нас связка такая фе91sam9g20ek + SMSC LAN9303
Что меняли в ядре, чтоб заработало:
На примере buildroot2011.05 и ядра 2.6.33

Отключить привязку ETH_IRQ и выключаем RMII

-открываем файл: аrch/arm/mach-at91/board-sam9g20ek.c

// MACB Ethernet device
static struct at91_eth_data __initdata ek_macb_data = {
// .phy_irq_pin = AT91_PIN_PA7, //Закоментировали
.is_rmii = 0, //было 1
};


Меняем пины для изернета вместо 23,24 ставим 10,11
- открываем файл: аrch/arm/mach-at91/at91sam9260_devices.c


После этого сеть заработала, уже 4 месяца, проводим отладку на сетевой FS, на другом оборудовании в этой же связке все хорошо. на счет нагрузки на сеть, работает веб интерфейс и вытягивает картинку jpeg, полученную от камеры - сеть ниразу не упала.

Не знаю, я посмотрел исключительно macb, с которым у ТС проблемы. Он кривой.
Но:
а) есть и другие
б) в конце концов можно и свой драйвер написать, ничего хитрого тут нет

Сама же железка работает совершенно нормально.

Спасибо, я немного успокоился.
Свой драйвер писать не хочется. Готовая демо-плата была взята за основу именно для того чтобы не писать свой софт, а взять все готовое. Сроки жмут...


Подскажите, пожалуйста, где их можно взять.

[quote name='aaarrr' date='Dec 21 2011, 11:15' post='1008295']
Не знаю, я посмотрел исключительно macb, с которым у ТС проблемы. Он кривой.
Но:
а) есть и другие

Других драйверов для EMAC не приходилось встречать, может можите что-то порекомендовать ?
Или может кому-то удалось атмеловский драйвер подрихтовать ?

Пробовал у себя ваши рекомендации - (перевел u-boot в режим mii, естественно с аппаратными изменениями для этого режима),
ядру тоже сделал нужные исправления --- не помогло -> при увеличении трафика через LAN ядро 2.6.34 падает с той же ошибкой :
(kernel BUG at drivers/net/macb.c:417!) - это тотже вызов BUG_ON

Тут уже упоминался at91_ether. Насчет его кривизны ничего сказать не могу.


Можно попробовать замести ошибку под ковер, выставив более высокий приоритет EMAC в MATRIX. Не знаю только, поможет ли.

at91_ether упоминал я.
Я, видимо, чего-то не понимаю... at91_ether и macb - это два разных драйвера?
Выходит, в линуксе есть несколько альтернативных драйверов для одного и того же at91 emac?
В таком случае, правильно ли я понимаю, что для того чтобы вместо MACB у меня был at91_ether, надо в конфиге убрать "CONFIG_MACB=y" и добавить "CONFIG_ARM_AT91_ETHER=y"?

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

Судя по исходникам - 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

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

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