USB адаптер Ethernet (Realtek r8153) продолжает разъединяться

Начиная с обновления до Ubuntu 18.04 от 17,10 моих usb адаптер Ethernet продолжает разъединяться. Это раньше работало отлично с 17,10.

dmesg показывает следующий вывод после отбрасывания соединения:

[  273.462732] usb 4-1.4: usb_reset_and_verify_device Failed to disable LTM
               .
[  273.643622] usb 4-1.4: USB disconnect, device number 11
[  273.795468] usb 4-1.4: new SuperSpeed USB device number 12 using xhci_hcd
[  273.816520] usb 4-1.4: New USB device found, idVendor=0bda, idProduct=8153
[  273.816522] usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  273.816523] usb 4-1.4: Product: USB 10/100/1000 LAN
[  273.816524] usb 4-1.4: Manufacturer: Realtek
[  273.816525] usb 4-1.4: SerialNumber: 0000A5
[  273.896167] usb 4-1.4: reset SuperSpeed USB device number 12 using xhci_hcd
[  273.948778] r8152 4-1.4:1.0 eth0: v1.09.9
[  274.503001] r8152 4-1.4:1.0 enx144fd7d04a3c: renamed from eth0
[  274.539481] IPv6: ADDRCONF(NETDEV_UP): enx144fd7d04a3c: link is not ready
[  274.543857] IPv6: ADDRCONF(NETDEV_UP): enx144fd7d04a3c: link is not ready
[  276.431243] r8152 4-1.4:1.0 enx144fd7d04a3c: carrier on
[  276.431258] IPv6: ADDRCONF(NETDEV_CHANGE): enx144fd7d04a3c: link becomes ready
3
задан 14 November 2018 в 20:04

4 ответа

При записи вопроса я нашел источник ошибки в списке рассылки ядра. r8152 драйвер, который ответственен за управление моим r8153 адаптером, не может обработать usb, автоприостанавливают (сделанный по причинам экономии электроэнергии). Помещение в черный список устройства для usb автоприостанавливает, решает разъединения и сделан как так:

Узнайте идентификатор usb своего устройства (0bda:8153 в моем случае) при помощи lsusb, который дает мне:

Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp.

Теперь Вы открываете/etc/default/tlp и ищете USB_BLACKLIST и добавляете запись для Вашего устройства:

USB_BLACKLIST="0bda:8153"

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

6
ответ дан 1 December 2019 в 15:21

Я наткнулся на эту проблему также, но для меня проблема состояла в том, что дефектная способность драйвера r1852 LAN автоприостановить была преступником для моих случайных замораживаний.

Я решил его с помощью powertop, который хорош, потому что Вы не должны узнавать идентификатор usb устройства.

0
ответ дан 1 December 2019 в 15:21

Можно также сделать это ядро использования udev правила. Я создал правила udev и выключить usb, автоприостанавливают за устройство и также выключают Турбо Режим ЦП (который может помочь также):

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", TEST=="power/control", ATTR{power/control}="on"
KERNEL=="cpu",RUN+="/bin/sh -c 'echo -n 1 > /sys/devices/system/cpu/intel_pstate/no_turbo'"

Поместите вышеупомянутое в файл:/etc/udev/rules.d/50-cpu-custom.rules

0
ответ дан 1 December 2019 в 15:21

Я немного запутался, но подумал, что эта информация может помочь. В связанном вопросе я спросил о похожей проблеме, которая не была решена приведенными здесь решениями.Хотя я исправил это вскоре после этого и после заказа другого адаптера, изменив конфигурацию в /etc/networking/interfaces, только что был опубликован ответ, указывающий, что в моем dmesg используются два одинаковых номера. Кстати, используйте dmesg -T для удобочитаемых временных меток!

Таким образом, адаптер сообщает как usb 3-4: найдено новое USB-устройство, idVendor=0bda, idProduct=8153, но затем драйвер r8152(?) r8152 3-4:1.0 eth0 : v1.09.9 использовал его. Так какой номер использовать в черном списке 8153 или 8152? Я предполагаю, что это будет 8153, потому что это номер устройства, занесенного в черный список. Но просто помните о двух одинаковых числах при устранении неполадок.

0
ответ дан 1 June 2020 в 16:51

Другие вопросы по тегам:

Похожие вопросы: