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 прерывание. А поскольку видео с иксовым драйвером я не поднимал, то оно и не проявлялось.

Уведомление про проблемы с модулем я выслал по указанным адресам.
Багу закрываю.

Закрываю.
Спасибо за помощь!