Здравствуйте.
Есть устройства на базе 9G45, и есть странная проблема - при загрузке очень часто появляется сообщение - eth0: tx retry limit exceeded resetting buffers, Ethernet в таком состоянии не работает. Если просто переключить кабель, то с вероятность 100% заработает. Но это очень неудобно, т.к. высокий риск не подключиться удаленно после перезагрузки.
Есть подозрение, что такое поведение связано с uboot, но подтвердить не могу.
Может кто сталкивался и знает, как побороть?
Буду очень признателен.

А что за плата - я такое замечал на ядре 3.2.18 на местной OEM где тактирование PHY c процессора а не с отдельного кварца - у меня подозрение что отключается тактирование из-за управления питанием

9G45-OEM
Материнская своя.

Как уже Вам сказали смотрите что с клоком творится (лучше осциллографом).
Для сравнительного эксперимента, можете впаять кварц с конденсаторами (разорвав цепь тактирования).
Пропишите пин аппаратного сброса, а еще лучше впилите его в процедуру поднятия линка, тогда скриптовые ifconfig eth down/up будут должны выводить из любого каматоза (это будет еще надежней передергвания сетевого кабеля).

Павел, спасибо.
Подскажите, пожалуйста, номиналы элементов (кварц, емкость, что-то еще). И где разрывать цепь (R15?).
Вообще не очень понятно почему все проходит после перетыкания провода и потом работает стабильно до следующего выключения питания.

Павел, спасибо.
Подскажите, пожалуйста, номиналы элементов (кварц, емкость, что-то еще). И где разрывать цепь (R15?).
Вообще не очень понятно почему все проходит после перетыкания провода и потом работает стабильно до следующего выключения питания.

Убрать R15 (0Ом), поставить C18,21 - 18-24пФ

Полагаю, аппаратный сброс решили оставить как есть (т.е. без него) - зря, если при эксплуатации если возникнет "каматоз", ничем как передергиванием питания не восстановите.

Павел, спасибо. Реально помогло решить проблему.
Непонятно только почему вы сами этого не делаете.

Я в этой ветке Вам дважды указал на необходимость прописать аппаратный сброс чипа - как в пустоту ...
Уверен на 99.99% прописав его как того требует документация на чип - никакой проблемы не будет.

Павел, я на ваше сообщение про аппаратный сброс не реагировал по простой причине - это колхоз и костыли. А мне не надо ни того, ни другого - я хочу надежное аппаратное решение, а не "впилите его в процедуру поднятия линка, тогда скриптовые ifconfig eth down/up будут должны выводить из любого каматоза (это будет еще надежней передергвания сетевого кабеля)".
И по какому критерию предлагаете использовать это "решение"? По таймеру? Или по пингу microsoft.com?
Как говориться, можно из булки белого хлеба и двух карандашей сделать отличный троллейбус - но зачем?

Дабы нам не эскалировать конфликт, тему предлагаю закрыть.