Messages in this thread | | | From | Matt Turner <> | Date | Wed, 22 Jan 2020 16:20:26 -0800 | Subject | Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers |
| |
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
| |