LINUX.ORG.RU

ноут, usb 8087:07E6, виснет pm-suspend

 , , ,


0

1

Проверено на ядрах 4.9 (из debian strectch) и 4.19 (из debian buster).

При вызове pm-suspend ноут зависает (экран не успевает погаснуть).

Иногда (довольно редко) на старте системы пишется ошибка

[ 3.957398] ehci-pci 0000:00:1d.0: port 1 reset error -110

В таких сеансах (от запуска системы с этой ошибкой до ребута) pm-suspend работает. Так же обнаружил, что в таких сеансах из lsusb пропадает устройство:

Bus 003 Device 002: ID 8087:07e6 Intel Corp.

Из вывода lsusb -v кажется что это хаб, но драйвера к нему видимо нет. При попытке записать ему 0 в /sys/bus/usb/devices/3-1/authorized или 1 в /sys/bus/usb/devices/3-1/remove система тоже виснет. Поиск в инете никаких жалоб на это устройство не нашёл. Зато нашёл рандомные жалобы на виснущий suspend но без внятной диагностики.

В логах suspend’а ничего полезного не видно (подозреваю что после зависания он уже ничего не диск не может записать).

Что ещё можно предпринять (кроме исследования исходников ядра)?

★★★★★

Последнее исправление: firkax (всего исправлений: 1)

Ответ на: комментарий от anonymous

Там точно не про конкретно эту проблему. И кажется даже не про связанную, вот кто-то для обхода их проблемы советует делать suspend после запуска: https://bugzilla.kernel.org/show_bug.cgi?id=109051#c327 то есть у них он работает.

firkax ★★★★★
() автор топика
Ответ на: комментарий от anonymous

И я всё же думаю что это не баг проца а проблема с тем непонятным usb-устройством. Потому как когда устройство не подхватилось ядром - suspend работает.

firkax ★★★★★
() автор топика
Ответ на: комментарий от NiTr0

lsusb -t

/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M

    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

lsusb

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 002: ID 8087:07e6 Intel Corp.

firkax ★★★★★
() автор топика
Ответ на: комментарий от NiTr0

нет не блютус, блютус там другим устройством

Bus 002 Device 005: ID 0cf3:3004 Qualcomm Atheros Communications AR3012 Bluetooth 4.0

если их только не два зачем-то

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

хм, странно.

по гуглу по device id - прилично подобных граблей, мож какой солюшн их них поможет…

NiTr0 ★★★★★
()
Ответ на: комментарий от firkax

Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
Bus 003 Device 002: ID 8087:07e6 Intel Corp.

Насколько знает lkddb для «usb 8087 ....» есть драйвера только для bluetooth и wimax. Но у тебя устанавливается «hub/4p». То есть либо lkddb что-то не знает, либо не те драйвера грузятся.

Возможное решение - запретить устойство «8087:07e6», так как все равно не работает.

Не спрашивай как запретить устройство. Знаю, что можно через правила udev, но конкретного решения не знаю. Что-то вроде:

$ cat /etc/udev/rules.d/disable-usb-8087-07e6.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="8087", ATTRS{idProduct}=="07e6", <тут должно быть то что запрещает устройство>

anonymous
()

предлагаю проверить на ядре 5.3 (просто загрузиться с ubuntu19.10 например)
кстати, запрещать можно не только устройство, но и сам модуля ядра к нему, прямо из grub'a

anonymous
()
Ответ на: комментарий от NiTr0

Вполне возможно. Значит ядро их не «фильтрует» по ID, и поэтому не попали в базу данных.

Скорее всего, проблемный хаб нерабочий, нераcпаяный. А криворукие писатели биоса забыли его запретить в acpi-таблицах. Что обычное дело в ноутах, особенно со всякими энергоэффективными чипами-на-плате, системами-на-чипе и тп.

anonymous
()
Ответ на: комментарий от anonymous

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

NiTr0 ★★★★★
()
Ответ на: комментарий от anonymous

Ну запретить это был бы хороший вариант, но udev это ж user-space демон, а надо чтобы ядро это устройство с самого начала не пыталось трогать. Попытка его отключить через sysfs приводит к зависанию как я уже писал, и вряд ли udev может сделать какое-то другое отключение.

firkax ★★★★★
() автор топика
Ответ на: комментарий от anonymous

На 5.4 всё то же самое.

Модуль нельзя запрещать, там и другой хаб есть который нужен. А запретить в ядре по device id нельзя?

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

Driver=ehci-pci

Кстати, почему используется именно ehci?

Есть еще xhci и uhci (этот именно для каких-то intel’овских).

Ядро самосборное или что за дистр?

anonymous
()
Ответ на: комментарий от anonymous

Дистр debian stretch, ядра из stretch (4.9), buster (4.19), buster-backports (5.4) - везде виснет. Никаких настроек касательно usb не делалось.

Хотя где-то в инете читал что там usb 3.0 (xhci), по дефолту поддерживающее эмуляцию usb 2.0 (ehci), которую в итоге ядро и видит. Как это изменить не знаю, в биосе настроек нет. И не уверен что это связано с проблемой.

firkax ★★★★★
() автор топика
Ответ на: комментарий от anonymous

/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/8p, 480M

тут нет ни 1 порта но есть то непонятное устройство

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 5000M

тут есть один порт usb3

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 480M

тут есть два порта usb2 + внутренняя периферия ноута (не глючащая)

а ну наверно можно ehci-pci в блеклист засунуть, попробую сейчас

но ещё стало интересно зачем вообще третья шина тогда нужна если на ней ничего внятного нет?

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

но ещё стало интересно зачем вообще третья шина тогда нужна если на ней ничего внятного нет?

У тебя скорее всего какой-то SoC-процессор (система на чипе), в котором как бы встроен ущербный усб-контроллер (и много чего еще другого хлама), который не используется, так как есть отдельный усб на плате. В биосе его забыли отключить, вот он и торчит. Если умеешь изменять acpi-таблицы, то это «легко» делается.

anonymous
()
Ответ на: комментарий от firkax

Внёс ehci_pci ehci_hcd в blacklist в /etc/modprobe.d/ - он всё равно грузится почему-то. Убрал файлы ehci-pci.ko и ehci-hcd.ko, modinfo теперь не может их найти но в lsmod они всё равно загружены (откуда - непонятно).

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

firkax ★★★★★
() автор топика
Ответ на: комментарий от firkax

https://wiki.archlinux.org/index.php/Kernel_module секция Using kernel command line

а вообще, перед тем как блэклистить, посмотри, какие зависимости есть у твоих модулей и можно ли их (модули) выкосить с помощью sudo modprobe -vr foo

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

anonymous
()
Ответ на: комментарий от firkax

Внёс ehci_pci ehci_hcd в blacklist в /etc/modprobe.d/ - он всё равно грузится почему-то.

Он у тебя из initramfs грузится. Пересобери его. Я не знаю, как это делается в дебиан. Быстрый поиск по интернетам выдал такую ссылку: https://wiki.debian.org/KernelModuleBlacklisting

anonymous
()
Ответ на: комментарий от anonymous

И правда оттуда, как же я про него забыл.

Сделал через командную строку ядра в grub как выше посоветовали, всё получилось, и так и правда удобнее чем пересобирать, спасибо.

firkax ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.