kernel Call Trace_кому посылать

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

kernel Call Trace_кому посылать

Galina Anikina
Подскажите пожалуйста - кому посылать  о сбое в системе - одновременно
отключились клавиатура и мышь

в /var/log/kernel и в messages вот такое (там больше, с указанием имя
материнки и далее вот это, только подлинее)

Mar 10 17:15:22 mikintel kernel: [ 1683.579247] Call Trace:
Mar 10 17:15:22 mikintel kernel: [ 1683.579253]  <IRQ>
Mar 10 17:15:22 mikintel kernel: [ 1683.579264]  dump_stack+0x5c/0x85
Mar 10 17:15:22 mikintel kernel: [ 1683.579270]  __report_bad_irq+0x33/0xc0
Mar 10 17:15:22 mikintel kernel: [ 1683.579275]  note_interrupt+0x244/0x290
Mar 10 17:15:22 mikintel kernel: [ 1683.579280]
handle_irq_event_percpu+0x54/0x80
Mar 10 17:15:22 mikintel kernel: [ 1683.579284]  handle_irq_event+0x3c/0x60
Mar 10 17:15:22 mikintel kernel: [ 1683.579287]
handle_fasteoi_irq+0x8c/0x160
Mar 10 17:15:22 mikintel kernel: [ 1683.579292]  handle_irq+0x1f/0x30
Mar 10 17:15:22 mikintel kernel: [ 1683.579296]  do_IRQ+0x41/0xc0
Mar 10 17:15:22 mikintel kernel: [ 1683.579300]  common_interrupt+0x98/0x98
Mar 10 17:15:22 mikintel kernel: [ 1683.579303]  </IRQ>
Mar 10 17:15:22 mikintel kernel: [ 1683.579307] RIP: 0033:0x7efc4ba7de50
Mar 10 17:15:22 mikintel kernel: [ 1683.579309] RSP:
002b:00007ffee0a33158 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd9
Mar 10 17:15:22 mikintel kernel: [ 1683.579313] RAX: 0000000000000000
RBX: 0000557941c24390 RCX: 0000000000000000
Mar 10 17:15:22 mikintel kernel: [ 1683.579315] RDX: 00007efc4bfee100
RSI: 00007efc4c081322 RDI: 00007efc4c2ed910
Mar 10 17:15:22 mikintel kernel: [ 1683.579316] RBP: 00007efc38045600
R08: 0000000000100000 R09: 0000000000000000
Mar 10 17:15:22 mikintel kernel: [ 1683.579318] R10: 0000000000000000
R11: 0000000000000000 R12: 00007efc4bfee100
Mar 10 17:15:22 mikintel kernel: [ 1683.579319] R13: 00007efc4c077245
R14: 00007efc4c081322 R15: 0000557941c0da40
Mar 10 17:15:22 mikintel kernel: [ 1683.579322] handlers:
Mar 10 17:15:22 mikintel kernel: [ 1683.579347] [<000000009c4192f6>]
usb_hcd_irq [usbcore]
Mar 10 17:15:22 mikintel kernel: [ 1683.579351] Disabling IRQ #23


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

Отключила их оттуда и подключила непосредственно в USB-гнёзда, стоящие
на материнке. Пока вроде не отключается :-)))

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому посылать

Иван Лох-3
On Sun, Mar 11, 2018 at 12:43:31PM +0300, Gali Anikina wrote:
> Методом проб и ошибок пришла к вероятной проблеме - они были подключены на
> отдельную выносную планку USB, а она через шлейфы подключается
> непосредственно к материнке.

Можно попробовать протереть контакты спиртом)

> Отключила их оттуда и подключила непосредственно в USB-гнёзда, стоящие на
> материнке. Пока вроде не отключается :-)))
>

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому посылать

Artem Chuprina-4
In reply to this post by Galina Anikina
Gali Anikina -> [hidden email]  @ Sun, 11 Mar 2018 12:43:31 +0300:

 > Подскажите пожалуйста - кому посылать  о сбое в системе - одновременно
 > отключились клавиатура и мышь

 > Методом проб и ошибок пришла к вероятной проблеме - они были подключены на
 > отдельную выносную планку USB, а она через шлейфы подключается непосредственно
 > к материнке.

 > Отключила их оттуда и подключила непосредственно в USB-гнёзда, стоящие на
 > материнке. Пока вроде не отключается :-)))

Боюсь, что производителю шлейфа...

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому посылать

Galina Anikina
In reply to this post by Иван Лох-3


11.03.2018 12:57, Иван Лох пишет:

> On Sun, Mar 11, 2018 at 12:43:31PM +0300, Gali Anikina wrote:
>> Методом проб и ошибок пришла к вероятной проблеме - они были подключены на
>> отдельную выносную планку USB, а она через шлейфы подключается
>> непосредственно к материнке.
>
> Можно попробовать протереть контакты спиртом)
>
>> Отключила их оттуда и подключила непосредственно в USB-гнёзда, стоящие на
>> материнке. Пока вроде не отключается :-)))
>>

Самые очевидные ответы я не рассматривала. Помню-помню в своё время,
когда приносили сдавать в магазин неработающую видеокарту (в которой
время от времени происходи неявный сбой), то первое, что рекомендовали в
сервис центре или в ремонтной мастерской - протереть спиртом контакты.
Поэтому, с тех древних пор, я это вызубрила, как алфавит, поэтому такой
вариант даже не рассматривался, так как помещение - это не склад и тд.
То есть математическая вероятность наступления данного события -
загрязнение контактов, стремится к нулю. Ну может быть 0,000001%. При
условии надлежащей эксплуатации (не склад).
:-)))

Я предположила, что это может заинтересовать разработчиков ядра
kernel.org или Debian разработчиков, которые делают патчи к ядру.

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому посылать

Galina Anikina
In reply to this post by Artem Chuprina-4


11.03.2018 13:06, Artem Chuprina пишет:

> Gali Anikina -> [hidden email]  @ Sun, 11 Mar 2018 12:43:31 +0300:
>
>   > Подскажите пожалуйста - кому посылать  о сбое в системе - одновременно
>   > отключились клавиатура и мышь
>
>   > Методом проб и ошибок пришла к вероятной проблеме - они были подключены на
>   > отдельную выносную планку USB, а она через шлейфы подключается непосредственно
>   > к материнке.
>
>   > Отключила их оттуда и подключила непосредственно в USB-гнёзда, стоящие на
>   > материнке. Пока вроде не отключается :-)))
>
> Боюсь, что производителю шлейфа...
>
>



Ну да, я посмотрю, понаблюдаю - будет ли теперь происходить сбой, и если
нет - то демонтирую планку (хоnя ранее она работала нормально и шла в
комлекте с материнской платой ASUS - лет 5 и даже более того   :-))))
Сейчас вроде производители почти не прикладывают доп.шлейфов и планок к
аппаратным устройствам, продаваемым в магазинах - оптимизация
себестоимости, повышение маржи :-)))

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому ��осылать

yuri.nefedov
In reply to this post by Galina Anikina
On Sun, 11 Mar 2018, Gali Anikina wrote:

...
> в /var/log/kernel и в messages вот такое (там больше, с указанием имя
> материнки и далее вот это, только подлинее)
>
...
> Mar 10 17:15:22 mikintel kernel: [ 1683.579351] Disabling IRQ #23
>
>
> Методом проб и ошибок пришла к вероятной проблеме - они были подключены на
> отдельную выносную планку USB, а она через шлейфы подключается
> непосредственно к материнке.
...

  Можно посмотреть чему соответствует IRQ #23
  (man 5 proc)
  > cat /proc/interrupts

  23:    ....  IO-APIC-fasteoi   ehci_hcd:usb1


  У меня это подсистема USB1.
  Для USB1 ограничение в длине кабеля 3м (18ns max delay).
  Плюс, на выносной планке на конекторах набегает еще задержка.

  Правда, мне непонятно почему call trace вызывается.
  Вполне штатная ситуация, протокол рукопожатия не прошел
  и устройство игнорируется. Ну, видимо, игнорируется
  маскировкой соответствующего IRQ, а при этом идет штатная
  печать, что собственно и наблюдается в логах.

Ю.
Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому посылать

Tim Sattarov
In reply to this post by Galina Anikina
On 03/11/18 05:43, Gali Anikina wrote:

> Подскажите пожалуйста - кому посылать  о сбое в системе - одновременно отключились клавиатура и мышь
>
> в /var/log/kernel и в messages вот такое (там больше, с указанием имя материнки и далее вот это,
> только подлинее)
>
> Mar 10 17:15:22 mikintel kernel: [ 1683.579247] Call Trace:
> Mar 10 17:15:22 mikintel kernel: [ 1683.579253]  <IRQ>
> Mar 10 17:15:22 mikintel kernel: [ 1683.579264]  dump_stack+0x5c/0x85
> Mar 10 17:15:22 mikintel kernel: [ 1683.579270]  __report_bad_irq+0x33/0xc0
> Mar 10 17:15:22 mikintel kernel: [ 1683.579275]  note_interrupt+0x244/0x290
> Mar 10 17:15:22 mikintel kernel: [ 1683.579280] handle_irq_event_percpu+0x54/0x80
> Mar 10 17:15:22 mikintel kernel: [ 1683.579284]  handle_irq_event+0x3c/0x60
> Mar 10 17:15:22 mikintel kernel: [ 1683.579287] handle_fasteoi_irq+0x8c/0x160
> Mar 10 17:15:22 mikintel kernel: [ 1683.579292]  handle_irq+0x1f/0x30
> Mar 10 17:15:22 mikintel kernel: [ 1683.579296]  do_IRQ+0x41/0xc0
> Mar 10 17:15:22 mikintel kernel: [ 1683.579300]  common_interrupt+0x98/0x98
> Mar 10 17:15:22 mikintel kernel: [ 1683.579303]  </IRQ>
> Mar 10 17:15:22 mikintel kernel: [ 1683.579307] RIP: 0033:0x7efc4ba7de50
> Mar 10 17:15:22 mikintel kernel: [ 1683.579309] RSP: 002b:00007ffee0a33158 EFLAGS: 00000246
> ORIG_RAX: ffffffffffffffd9
> Mar 10 17:15:22 mikintel kernel: [ 1683.579313] RAX: 0000000000000000 RBX: 0000557941c24390 RCX:
> 0000000000000000
> Mar 10 17:15:22 mikintel kernel: [ 1683.579315] RDX: 00007efc4bfee100 RSI: 00007efc4c081322 RDI:
> 00007efc4c2ed910
> Mar 10 17:15:22 mikintel kernel: [ 1683.579316] RBP: 00007efc38045600 R08: 0000000000100000 R09:
> 0000000000000000
> Mar 10 17:15:22 mikintel kernel: [ 1683.579318] R10: 0000000000000000 R11: 0000000000000000 R12:
> 00007efc4bfee100
> Mar 10 17:15:22 mikintel kernel: [ 1683.579319] R13: 00007efc4c077245 R14: 00007efc4c081322 R15:
> 0000557941c0da40
> Mar 10 17:15:22 mikintel kernel: [ 1683.579322] handlers:
> Mar 10 17:15:22 mikintel kernel: [ 1683.579347] [<000000009c4192f6>] usb_hcd_irq [usbcore]
> Mar 10 17:15:22 mikintel kernel: [ 1683.579351] Disabling IRQ #23
>
>
> Методом проб и ошибок пришла к вероятной проблеме - они были подключены на отдельную выносную
> планку USB, а она через шлейфы подключается непосредственно к материнке.
>
> Отключила их оттуда и подключила непосредственно в USB-гнёзда, стоящие на материнке. Пока вроде не
> отключается :-)))
>
я отсылаю вот этим


Package: kerneloops
Version: 0.12+git20140509-6
Installed-Size: 57
Maintainer: Balint Reczey <[hidden email]>
Architecture: amd64
Replaces: kerneloops-daemon (<< 0.12+git20140509-2)
Depends: libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), libdbus-1-3 (>= 1.9.14), libdbus-glib-1-2 (>=
0.78), libglib2.0-0 (>= 2.14.0), init-system-helpers (>= 1.18~), lsb-base
Recommends: kerneloops-applet
Breaks: kerneloops-daemon (<< 0.12+git20140509-2)
Description-en: kernel oops tracker
 kerneloops is a daemon that collects kernel crash information and then
 submits the extracted signature to the oops.kernel.org website for
 statistical analysis and presentation to the Linux kernel developers.
Description-md5: 0b84aab675babc14431af9c96039cf87
Homepage: http://oops.kernel.org/
Tag: role::shared-lib
Section: oldlibs
Priority: optional
Filename: pool/main/k/kerneloops/kerneloops_0.12+git20140509-6_amd64.deb
Size: 16314
MD5sum: e8c202c85d0d420d337bec02131f09db
SHA256: 1715a9c9966ae8be726f297d61582b844b56dcea00275dca0b304078b943d7d4

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_кому посылать

Tim Sattarov


On 03/11/18 23:57, Gali Anikina wrote:

>
>
> 12.03.2018 02:56, Tim Sattarov пишет: я отсылаю вот этим
>>
>>
>> Package: kerneloops
>> Version: 0.12+git20140509-6
>
>
> Там нужно составить по английски сообщение о том, что произошло, правильно? И они попросят
> дополнительную информацию?
>
>
>
Программа сама собирает данные и отправляет, это такой сборщик oops'ов по миру

Не нужно мне напрямую отвечать, лучше в рассылку.

Reply | Threaded
Open this post in threaded view
|

Re: kernel Call Trace_________ ________________

Alexander Gerasiov-2
In reply to this post by yuri.nefedov
Hello [hidden email],

On Sun, 11 Mar 2018 21:33:18 +0800 (CST)
[hidden email] wrote:

> On Sun, 11 Mar 2018, Gali Anikina wrote:
>
> ...
> > в /var/log/kernel и в messages вот такое (там больше, с указанием
> > имя материнки и далее вот это, только подлинее)
> >  
> ...
> > Mar 10 17:15:22 mikintel kernel: [ 1683.579351] Disabling IRQ #23
> >
> >
> > Методом проб и ошибок пришла к вероятной проблеме - они были
> > подключены на отдельную выносную планку USB, а она через шлейфы
> > подключается непосредственно к материнке.  
> ...
>
>   Можно посмотреть чему соответствует IRQ #23
>   (man 5 proc)
>   > cat /proc/interrupts  
>
>   23:    ....  IO-APIC-fasteoi   ehci_hcd:usb1
>
>
>   У меня это подсистема USB1.
>   Для USB1 ограничение в длине кабеля 3м (18ns max delay).
>   Плюс, на выносной планке на конекторах набегает еще задержка.
>
>   Правда, мне непонятно почему call trace вызывается.
>   Вполне штатная ситуация, протокол рукопожатия не прошел
>   и устройство игнорируется. Ну, видимо, игнорируется
>   маскировкой соответствующего IRQ, а при этом идет штатная
>   печать, что собственно и наблюдается в логах.

Произошло прерывание, но на момент проверки состояния аппаратуры из
irq handler'а железка стала сообщаться о себе уже что-то совсем не то
(явно решил, что это не его прерывание), получилось, "ничейное
прерывание". Похоже, что это аппаратная проблема контроллера в некоторых
экзотических случаях. Не факт, что ее реально кто-то будет пытаться
чинить. Хотя, возможно, это драйвер неправильно проверят факт
прерывания на устройстве.

Можно попытаться написать в http://www.linux-usb.org/mailing.html

--
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: [hidden email]  WWW: http://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1