Драйвер eepro100 сетевого контроллера Intel Corporation 8255xER/82551IT Fast Ethernet Controller (rev 10) перестал работать. Замечено на PC/104 процессорной плате с такой сеткой. На ядре 2.6.18-wks-smp-alt2 драйвер работает. Вобщем-то драйвер подгружается, инициируется, интерфейс поднимается и даже линк виден через ethtool, но пакеты в сеть не идут, ничего не пингуется и не видно. Информация о сетевом контроллере: 00:09.0 Ethernet controller: Intel Corporation 8255xER/82551IT Fast Ethernet Controller (rev 10) Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at effff000 (32-bit, non-prefetchable) [size=4K] I/O ports at ff00 [size=64] Memory at effa0000 (32-bit, non-prefetchable) [size=128K] [virtual] Expansion ROM at 10000000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Про eepro100 сообщает pciscan, на самом деле грузится e100. Пробовал ставить use_io=1 - в dmesg сообщило о использовании io режима. Однако пакеты в сеть не идут. Попробовал руками подгрузить eepro100 - результат тотже. Прерывания не приходят. Вообще одиннадцатое прерывание разделяют между собой eth0, usb0 и usb1. Ругани не наблюдается. Единственно e100_watchdog сообщает о поднятии линка 100Mbps и всё. В случае с ядром 2.6.18 используется модуль e100. Сеть работает. Прерывания идут: [root@plx8 ~]# cat /proc/interrupts CPU0 0: 91555 XT-PIC timer 2: 0 XT-PIC cascade 7: 1 XT-PIC parport0 8: 1 XT-PIC rtc 11: 709 XT-PIC ohci_hcd:usb1, ehci_hcd:usb2, eth0 14: 50174 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 В случае с 2.6.24 всё тоже, только вместо 709 на 11 прерывании 0. Отключение ACPI (noacpi,noapic,nolapic) проблемы не исправляет. Вкладываю логи для ядра 2.6.18 (сеть работает) и 2.6.24 (не работает).
Created attachment 2548 [details] Архив основных логов Архив основных логов: lspci, pciscan, dmesg, /proc/interrupts
>Попробовал руками подгрузить eepro100 - результат тотже. Вы перед этим e100 выгружали?
Конечно выгружал.
>На ядре 2.6.18-wks-smp-alt2 драйвер работает А на std-smp?
и ещё судя по dmesg там был запущен wks-alt1, вы это на каком ядре проверяли? Можно dmesg с std-def?
(In reply to comment #5) > и ещё судя по dmesg там был запущен wks-alt1, вы это на каком ядре проверяли? Логи делал на wks-alt1. А недавно решил попробовать на последних сборках, может исправилось. Взял std-def - проблема осталась. А поскольку ядро появилось в сизифе решил багу повесить. Логи переделывать не стал, поскольку суть не поменялась. > Можно dmesg с std-def? Можно. Сейчас сделаю и залью.
Created attachment 2549 [details] dmesg2.6.24-std-def-alt6 Лог dmesg ядра 2.6.24-std-def-alt6 На ядре 2.6.18-std-smp-alt12 сетевая карта работает.
Там в модуле, есть возможность включить дебаг, попробуйте пожалуйста, и вывод сюда киньте
Created attachment 2552 [details] Dmesg e100 debug16 Опция debug для драйвера e100 установлена в 16. В архиве лог dmesg как для 2.6.18, так и для 2.6.24.
На ядре kernel-image-led-ws-2.6.25-alt0.3.i586.rpm тоже не работает.
Уже не работает на ядрах: kernel-image-led-std-2.6.22-alt13.i586.rpm kernel-image-led-ws-2.6.22-alt13.i586.rpm
С новыми ядрами не пробовали?
Вообще я регулярно пробую, с тем-же результатом. Но попробую ещё раз.
kernel-image-2.6.25-std-def Не работает!
Подскажите хотя бы процедуру отладки, что-бы самостоятельно выявить проблему.
Что происходит при загрузке с опцией irqpoll? Покажите dmesg в таком варианте (хотя debug=16 с этой опцией будет бесполезен из-за постоянных вызовов e100_intr, разве что пересобрать драйвер, переместив вывод после проверки stat_ack).
Created attachment 2941 [details] dmesg irqpoll 2.6.26 C irqpoll сеть работает. Это получается прерывания от железа не идут? Или пересечение мешает. Может как-то развести их?
В 2.6.18 те же разделяемые прерывания работали правильно: 11: 840 XT-PIC ohci_hcd:usb1, ehci_hcd:usb2, eth0 Можно ещё попробовать проверить работу USB без использования irqpoll - это тоже сломалось в новых ядрах?
Попробовал. Оказывается USB тоже не работает. Пробовал вставлять usb-flash на 2.6.26 реакции никакой и счётчик прерываний не меняется. При загрузке на 2.6.18 или с irqpoll всё работает. И ещё один интересный момент. Сделал загружаемую флешку с rescue (тестю для создания прошивки). Bios видит и начинает грузиться, но где-то после стадии populate /dev погнали ошибки доступа на чтение. При загрузке с этой флешкой и irqpoll всё корректно грузится. Это получается целиком прерывание 11 где-то лочится? И кстати, в 2.6.26 якобы используются 3 и 4 прерывание, но кем не понятно. В 2.6.18 они не используются.
(In reply to comment #19) > Сделал загружаемую флешку с rescue (тестю для создания прошивки). > Bios видит и начинает грузиться, но где-то после стадии populate /dev погнали ошибки > доступа на чтение. Вот это действительно очень интересно. Загрузка действительно доходит до этой стадии (это уже после монтирования корня из initramfs)? Тогда получается, что как минимум на начальном этапе загрузки USB работает. В этом случае можно попытаться снять логи при загрузке с init=/sbin/sash, а потом попробовать отловить, какой модуль при загрузке всё ломает: dmesg -n8 mount -t sysfs sysfs /sys find /sys/devices -type f -name modalias | while read f; do mod="$(cat "$f")"; printf '\n%s\n%s\n' "$f" "$mod" modprobe -vb "$mod" sleep 1 done
Нашёл модуль-виновник всего этого. Называется он geode_aes. Поместил его в blacklist и всё заработало. Большое спасибо Сергей за помощь! Может куда уведомить про проблемы с этим модулем?
(In reply to comment #21) > Может куда уведомить про проблемы с этим модулем? Видимо, по адресу, указанному в файле MAINTAINERS: AMD GEODE PROCESSOR/CHIPSET SUPPORT P: Jordan Crouse L: linux-geode@lists.infradead.org (moderated for non-subscribers) W: http://www.amd.com/us-en/ConnectivitySolutions/TechnicalResources/0,,50_2334_2452_11363,00.html S: Supported Ну и Cc: по адресу из git log: commit 9fe757b0cfcee0724027a675c533077287a21b96 Author: Jordan Crouse <jordan.crouse@amd.com> Date: Wed Oct 4 18:48:57 2006 +1000 [PATCH] crypto: Add support for the Geode LX AES hardware Add a driver to support the AES hardware on the Geode LX processor. Этот драйвер сейчас вряд ли используется при работе, а в инициализации с тех пор ничего вроде бы не меняли. Не совсем понятно, каким образом эта инициализация влияет на IRQ 11, назначенное другим устройствам, если для 00:01.2 назначается IRQ 10 (и в дальнейшем это прерывание вообще не используется драйвером). Ещё странное явление: в dmesg от 2.6.18 при определении прерываний для PCI-устройств пишется: PCI: Found IRQ 11 for device 0000:00:09.0 В аналогичной ситуации под 2.6.24: PCI: Assigned IRQ 11 for device 0000:00:09.0 Причём в логе для 2.6.24-std-def-alt6 ситуация ещё более интересная - до загрузки модуля geode_aes пишется Found, а после этого - Assigned (включая сообщение для самого устройства AES). Создаётся впечатление, что после загрузки модуля geode_aes пропадает доступ к конфигурации CS5536. Приложите ещё вывод lspci -vvxxx, снятый при загрузке с 2.6.18, и два вывода со свежим ядром - до и после загрузки модуля geode_aes.
Created attachment 2951 [details] lspci2618 lspci2626 lspci2626_aes Оказывается в 2.6.18 проблемного модуля ещё нет. И хотя geode_aes вешается на 12 прерывание, а не на 11 у них всё равно есть одна общая черта. Оба эти прерывания конфигурируются в BIOS как "Основное" и "Дополнительное" прерывание PCI шины. Есть подозрение, что он лочит и 12 прерывание. А поскольку видео с иксовым драйвером я не поднимал, то оно и не проявлялось.
Уведомление про проблемы с модулем я выслал по указанным адресам. Багу закрываю.
Закрываю. Спасибо за помощь!
