Re: Spurious EHCI interrupts with 5.2 and later on shutdown / init 6 reboot .

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/3/20 10:15 AM, Alan Stern wrote:
On Tue, 3 Mar 2020, John Donnelly wrote:

Let's try to be a little more precise.  You said this happens "every
time a server is rebooted".  At first I thought you meant it happened
during the boot process.  But the timestamps on these log messages
indicate the unwanted IRQ happened 836 seconds _after_ boot, possibly
also 336 seconds after.

So when exactly do you see this?

       On shutdown - init 6

Started Show Plymouth Reboot Screen.
[  OK  ] Unmounted RPC Pipe File System.
[  OK  ] Stopped Logout off all iSCSI sessions on shutdown.
          Stopping Open-iSCSI...
[  OK  ] Stopped Open-iSCSI.
[  OK  ] Unmounted /home.
[  OK  ] Stopped Dynamic System Tuning Daemon.
[  OK  ] Stopped Login Service.
[  OK  ] Stopped target User and Group Name Lookups.
          Stopping System Security Services Daemon...
[  OK  ] Stopped System Security Services Daemon.
[  OK  ] Stopped VDO volume services.
[  OK  ] Stopped System Logging Service.
[  OK  ] Stopped target Network is Online.
[  OK  ] Stopped target Network.
          Stopping Network Manager...
          Stopping Network Name Resolution...
[  OK  ] Stopped Network Name Resolution.
[  OK  ] Stopped Network Manager.
          Stopping D-Bus System Message Bus...
[  OK  ] Stopped Rollback uncommitted netcf network config change transactions.
[  OK  ] Stoppe[ 1523.374186] irq 18: nobody cared (try booting with the "irqpoll" option)
d D-Bus System M[ 1523.470444] handlers:
[ 1523.514197] [<0000000024f18691>] usb_hcd_irq
[ 1523.565284] [<0000000024f18691>] usb_hcd_irq
[ 1523.675772] Disabling IRQ #18
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped Forward Password Requests to Plymouth Directory Watch.
[  OK  ] Stopped target Sockets.
[  OK  ] Closed Avahi mDNS/DNS-SD Stack Activation Socket.
[  OK  ] Closed Activation socket for spice guest agent daemon.
[  OK  ] Closed Open-iSCSI iscsiuio Socket.
[  OK  ] Closed CUPS Scheduler.
[  OK  ] Closed Virtual machine log manager socket.
[  OK  ] Closed Virtual machine lock manager socket.
[  OK  ] Closed Open-iSCSI iscsid Socket.
[  OK  ] Closed PC/SC Smart Card Daemon Activation Socket.
[  OK  ] Closed SSSD Kerberos Cache Manager responder socket.
[  OK  ] Stopped target Paths.
[  OK  ] Stopped CUPS Scheduler.
[  OK  ] Stopped target Slices.
[  OK  ] Removed slice Virtual Machine and Container Slice.
[  OK  ] Removed slice User and Session Slice.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Stopped target System Initialization.
[  OK  ] Stopped target Swap.
    [ 1524.987084] reboot: Restarting system

All right.  You never made this clear.

    Removing the modules BEFORE I do a shutdown does not produce the error - which is kind of surprising .

What exactly does this mean?  Do you mean that the error does not occur
at the time the module is removed?

     Yes

No!  You mean that the error does not occur at the time when the system
is shut down following module removal.  Right?

  Or do you mean that if you remove
the module and then reboot, the error does not occur during the reboot?

  Yes

Again, no.

yes -- If I remove the module(s) ehci_pci and/or ehci_hcd prior to rebooting - the error does not occur


Or do you mean that if you remove the module and reboot, the error does
not occur until the system is booted yet again?


    Yes

And no.  I can't help if you don't give full and unambiguous answers.
>>> Or do you mean that if you remove the module and reboot, the error does
>>> not occur

 Yes


   It appears the modules are actually loaded by the ramdisk too  - prior to getting to the single user mode when I built them as loadable module .. because I renamed them  so modprobe/udev  would not find them after systemd starts.

This depends on the contents of your initramfs.  Most likely you
rebuilt that along with the kernel, so if the kernel uses modules for
the EHCI drivers then so does the initramfs.

     Yes .  I needed to make them modules so I could test the removal using rmmod.



  I have determined the event goes all the back to 5.0-rc1, then  4.18.rc8 ;  and Kernel 4.18.0-147.3.1.el8_1.x86_64, which is the current RH 8.1 kernel . I was mistaken it was solely  a 5.4 issue.

Good work.  Keep on going; what about 4.19 and 4.20?  And various
release candidates in between, and so on...

Alan Stern



--
Thank You,
John



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux