From: Matt Turner <mattst88@gmail.com>
To: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
Alexandre Oliva <lxoliva@fsfla.org>, Tom Li <tomli@tomli.me>,
James Hogan <jhogan@kernel.org>,
Jiaxun Yang <jiaxun.yang@flygoat.com>,
Huacai Chen <chenhc@lemote.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers
Date: Wed, 22 Jan 2020 16:20:26 -0800 [thread overview]
Message-ID: <CAEdQ38E4_eSm9VnHHJuV=qvQVWrGNOMvn0s8KEKaJT65vO77pQ@mail.gmail.com> (raw)
In-Reply-To: <20190612192412.GF26504@darkstar.musicnaut.iki.fi>
On Wed, Jun 12, 2019 at 12:25 PM Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>
> Hi,
>
> On Wed, Jun 12, 2019 at 06:55:28AM +0100, Maciej W. Rozycki wrote:
> > On Tue, 11 Jun 2019, Aaro Koskinen wrote:
> >
> > > However, with your patch the "nobody cared" is never reached so all is
> > > good. I tried 10 boots with the patch and all were successful. Without
> > > the patch 8 out of 10 failed with the "nobody cared" warning.
> >
> > I wouldn't call it "good", just less obvious or painful. This is still
> > causing wasted CPU cycles that are used for taking the phantom interrupts.
> >
> > There is clearly a completion barrier missing somewhere that causes the
> > interrupt request to linger beyond the point interrupts are reenabled at
> > the CPU.
> >
> > One way to attempt to narrow it down might be taking a backtrace from
> > where IRQ 14 is found to be spurious. This would indicate the offending
> > interrupt unmask action. E.g. I see no explicit completion barrier
>
> The first spurious IRQ is right after the driver registers:
>
> [ 4.732000] [<ffffffff8020efac>] show_stack+0x90/0x140
> [ 4.732000] [<ffffffff8052850c>] ata_bmdma_interrupt+0x2b4/0x39c
> [ 4.732000] [<ffffffff80260368>] __handle_irq_event_percpu+0xb0/0x178
> [ 4.732000] [<ffffffff80260464>] handle_irq_event_percpu+0x34/0x9c
> [ 4.732000] [<ffffffff80260508>] handle_irq_event+0x3c/0x74
> [ 4.732000] [<ffffffff80264d28>] handle_level_irq+0x118/0x154
> [ 4.732000] [<ffffffff8025f978>] generic_handle_irq+0x34/0x50
> [ 4.732000] [<ffffffff806b9600>] do_IRQ+0x18/0x24
> [ 4.732000] [<ffffffff80208ce4>] handle_int+0x17c/0x188
> [ 4.732000] [<ffffffff806b30c8>] arch_local_irq_restore+0x18/0x30
> [ 4.732000] [<ffffffff802621f0>] __setup_irq+0x660/0x7a0
> [ 4.732000] [<ffffffff80262798>] request_threaded_irq+0x114/0x19c
> [ 4.732000] [<ffffffff80265d7c>] devm_request_threaded_irq+0xa0/0x10c
> [ 4.732000] [<ffffffff80527f00>] ata_pci_sff_activate_host+0x1c0/0x274
> [ 4.732000] [<ffffffff80528a30>] ata_pci_init_one+0x170/0x1c4
> [ 4.732000] [<ffffffff8052a288>] cs5536_init_one+0x94/0xb8
>
> and the following ones do not seem to provide much info as I can only
> see the IRQ stack:
>
> [ 4.736000] [<ffffffff8020efac>] show_stack+0x90/0x140
> [ 4.736000] [<ffffffff8052850c>] ata_bmdma_interrupt+0x2b4/0x39c
> [ 4.736000] [<ffffffff80260368>] __handle_irq_event_percpu+0xb0/0x178
> [ 4.736000] [<ffffffff80260464>] handle_irq_event_percpu+0x34/0x9c
> [ 4.736000] [<ffffffff80260508>] handle_irq_event+0x3c/0x74
> [ 4.736000] [<ffffffff80264d28>] handle_level_irq+0x118/0x154
> [ 4.736000] [<ffffffff8025f978>] generic_handle_irq+0x34/0x50
> [ 4.736000] [<ffffffff806b9600>] do_IRQ+0x18/0x24
> [ 4.736000] [<ffffffff80208ce4>] handle_int+0x17c/0x188
> [ 4.736000] [<ffffffff8022f330>] irq_exit+0x68/0xcc
>
> > between the final `outb' in `mask_and_ack_8259A' and the following call to
> > `raw_spin_unlock_irqrestore', which are obviously otherwise unordered WRT
> > each other (because `outb' is I/O or MMIO and `raw_spin_unlock_irqrestore'
> > is contained within the CPU on UP). I can see provisions however for
> > issuing an architecture-specific barrier in `do_raw_spin_unlock', which is
> > the workhorse for `raw_spin_unlock_irqrestore', so maybe this is the place
> > to look into?
> >
> > Also how's IRQ 14 registered as indicated by /proc/interrupts?
>
> Not sure what you mean but here's the output:
>
> $ cat /proc/interrupts
> CPU0
> 2: 0 XT-PIC 2 cascade
> 3: 20 XT-PIC 3 ttyS0
> 5: 543358 XT-PIC 5 timer
> 11: 0 XT-PIC 11 ehci_hcd:usb1, ohci_hcd:usb2
> 14: 100000 XT-PIC 14 pata_cs5536
> 18: 0 MIPS 2 cascade
> 22: 0 MIPS 6 cascade
> 36: 3052 bonito_irq eth0
> ERR: 0
>
> A.
Has any more progress been made?
Thanks,
Matt
next prev parent reply other threads:[~2020-01-23 0:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-08 8:30 [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers Tom Li
2019-02-08 20:08 ` Paul Burton
2019-02-09 10:11 ` Tom Li
2019-02-09 19:38 ` Paul Burton
2019-02-11 12:13 ` Alexandre Oliva
2019-02-11 12:55 ` Tom Li
2019-02-11 22:38 ` Alexandre Oliva
2019-02-11 23:06 ` Aaro Koskinen
2019-02-12 4:39 ` tomli
2019-02-16 23:39 ` Alexandre Oliva
2019-02-17 4:59 ` Alexandre Oliva
2019-02-17 23:59 ` Aaro Koskinen
2019-02-18 1:37 ` Alexandre Oliva
2019-02-18 2:41 ` Maciej W. Rozycki
2019-03-07 6:41 ` Alexandre Oliva
2019-03-07 17:59 ` Maciej W. Rozycki
2019-03-08 0:46 ` Alexandre Oliva
2019-03-08 23:56 ` Maciej W. Rozycki
2019-05-26 9:19 ` Alexandre Oliva
2019-06-10 21:49 ` Aaro Koskinen
2019-06-12 5:55 ` Maciej W. Rozycki
2019-06-12 19:24 ` Aaro Koskinen
2020-01-23 0:20 ` Matt Turner [this message]
2020-01-24 18:58 ` Aaro Koskinen
2019-03-07 20:21 ` Aaro Koskinen
2019-03-07 21:22 ` Alexandre Oliva
2019-02-17 4:41 ` Alexandre Oliva
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='CAEdQ38E4_eSm9VnHHJuV=qvQVWrGNOMvn0s8KEKaJT65vO77pQ@mail.gmail.com' \
--to=mattst88@gmail.com \
--cc=aaro.koskinen@iki.fi \
--cc=chenhc@lemote.com \
--cc=jhogan@kernel.org \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=lxoliva@fsfla.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=tomli@tomli.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).