lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1011271011230.23611-100000@netrider.rowland.org>
Date:	Sat, 27 Nov 2010 10:16:47 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Alexander E. Patrakov" <patrakov@...il.com>
cc:	linux-kernel@...r.kernel.org, <linux-usb@...r.kernel.org>
Subject: Re: Nobody cared about IRQs at shutdown

On Sat, 27 Nov 2010, Alexander E. Patrakov wrote:

> 26.11.2010 01:25, Alan Stern wrote:
> > On Thu, 25 Nov 2010, Alexander E. Patrakov wrote:
> >
> >> 25.11.2010 21:06, Alan Stern wrote:
> >>> On Thu, 25 Nov 2010, Alexander E. Patrakov wrote:
> >>>
> >>>> Hello.
> >>>>
> >>>> After switching my Gentoo desktop from sysvinit + openrc to systemd, I
> >>>> started getting "nobody cared" messages about IRQs 16 and 19 (common
> >>>> thing: they are assigned to the USB controllers, that's why CC:
> >>> According to your listing, they are used by uhci-hcd.  Do the messages
> >>> go away if you unload uhci-hcd before shutting down?
> >> It is not a module here, so I have to recompile the kernel in order to
> >> try this. Will do that tomorrow.
> >>
> >>> You may need to debug the uhci-hcd driver. Look into
> >>> drivers/usb/host/uhci-hcd.c; the uhci_shutdown() routine ought to be
> >>> called and it ought to call uhci_hc_died(), which in turn calls
> >>> uhci_reset_hc() in pci-quirks.c, which is supposed to prevent the
> >>> controller from generating any IRQs.
> >> OK, tomorrow I will add some printks there.
> 
> Sorry, I didn't add them due to being busy with a different (non-kernel) 
> bug. What do you want to know - just the fact that these functions are 
> called before or after reporting the bad IRQ?

They should be called before the bad IRQ is reported.  That's what I 
want to verify.

> > Even without rebuilding the kernel, you can unbind the uhci-hcd driver
> > from the hardware by going to the /sys/bus/pci/drivers/uhci_hcd
> > directory and doing:
> >
> > 	echo -n device-name>unbind
> >
> > where "device-name" is the name of one of the symlinks in that
> > directory.
> 
> Thanks for the tip. Below are the updated test results, including the 
> ones posted in my first mail, for completeness.
> 
> 1. No irqpoll, no unbind: the system reports that nobody cared for IRQs, 
> then waits, displays SATA errors, waits again, shuts down.
> 
> 2. irqpoll, no unbind: the system shuts down without any delays.
> 
> 3. No irqpoll, unbind uhci-hcd from everything it controls: the system 
> reports bad IRQ 19 (consumed by firewire-ohci), waits, displays SATA 
> errors, waits again, shuts down.

This suggests that the problem comes from the firewire controller, not 
the UHCI controller.

Are you sure that you ever got "nobody cared" reports for IRQ 16?  Your 
listing showed that uhci-hcd used both 16 and 19 whereas firewire-ohci 
used only 19.

> 4. No irqpoll, unbind both uhci-hcd and firewire-ohci from everything: 
> the system does not report any bad IRQs, waits, displays SATA errors, 
> waits again, shuts down.

And this tends to confirm it.  The SATA errors are probably a separate
issue.

What happens if you unbind firewire-ohci but not uhci-hcd?

> 5. irqpoll, unbind both uhci-hcd and firewire-ohci from everything: same 
> as (4).
> 
> I have no firewire devices.

Apparently that doesn't stop the controller from misbehaving.  But you 
need to do more tests to be sure of this.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ