All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: Nobody cared about IRQs at shutdown
Date: Wed, 01 Dec 2010 22:29:15 +0500	[thread overview]
Message-ID: <4CF685EB.4020007@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1012010948270.1629-100000@iolanthe.rowland.org>

01.12.2010 19:59, Alan Stern пишет:
> On Wed, 1 Dec 2010, Alexander E. Patrakov wrote:
>
>> Alan Stern wrote:
>>> On Tue, 30 Nov 2010, Alexander E. Patrakov wrote:
>>>
>>>> In fact, I think that there is something bad, not specific to USB,
>>>> FireWire or SATA. Without systemd, all those subsystems function
>>>> properly at shutdown. With systemd, it looks like there are many
>>>> mishandled interrupts (all of USB, FireWire and SATA) at shutdown.
>>>> What    could be this common thing? ACPI?
>>> I don't know -- what is systemd?
>> Systemd is a new init developed by Lennart Poettering. You can learn more at http://freedesktop.org/wiki/Software/systemd
>>
>> It employs high concurrency in starting and stopping services, starts many things on demand and thus boots faster than the traditional SysV init. And also exposes this bug :(
> All right.
>
> One last test.  What happens if you unbind the firewire driver and all
> the UHCI controllers except the one attached to IRQ 16?

As I was not sure if you mean 16 or 19, I did two tests. In both cases, 
the firewire driver and all UHCI controllers except one were unbound. In 
both cases, the system printed the line I added to uhci_hc_died(), 
reported a bad IRQ (16 and 19, respectively), waited, displayed SATA 
errors, waited again, and powered itself off. I.e., the screenshot is 
nearly identical to what I sent earlier.


> Possible explanations: IRQs are being misrouted, so the system thinks
> it gets IRQ 16 when in fact a different interrupt line was activated
> (this is related to ACPI, but I don't see any connection to systemd).
> Or the interrupt layer is malfunctioning and it thinks IRQs are
> arriving when they aren't.

I forgot to mention that only shutdown is problematic, reboots are OK.

-- 
Alexander E. Patrakov

  reply	other threads:[~2010-12-01 17:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 15:51 Nobody cared about IRQs at shutdown Alexander E. Patrakov
2010-11-25 16:06 ` Alan Stern
2010-11-25 16:14   ` Alexander E. Patrakov
2010-11-25 20:25     ` Alan Stern
2010-11-27  7:12       ` Alexander E. Patrakov
2010-11-27 15:16         ` Alan Stern
2010-11-30 18:08           ` Alexander E. Patrakov
2010-11-30 18:57             ` Alan Stern
2010-11-30 19:15               ` Alexander E. Patrakov
2010-12-01 14:59                 ` Alan Stern
2010-12-01 17:29                   ` Alexander E. Patrakov [this message]
2010-12-01 18:26                     ` Alan Stern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CF685EB.4020007@gmail.com \
    --to=patrakov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.