From: Arnd Bergmann <arnd@kernel.org>
To: Nikolai Zhubr <zhubr.2@gmail.com>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Heiner Kallweit <hkallweit1@gmail.com>,
netdev <netdev@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: Realtek 8139 problem on 486.
Date: Tue, 22 Jun 2021 15:22:55 +0200 [thread overview]
Message-ID: <CAK8P3a1XaTUgxM3YBa=iHGrLX_Wn66NhTTEXtV=vaNre7K3GOA@mail.gmail.com> (raw)
In-Reply-To: <60D1DAC1.9060200@gmail.com>
On Tue, Jun 22, 2021 at 2:32 PM Nikolai Zhubr <zhubr.2@gmail.com> wrote:
>
> 21.06.2021 14:22, Arnd Bergmann:
> [...]
> > I looked some more through the git history and found at least one time
> > that the per-chipset ELCR fixup came up for discussion[1], and this
> > appears to have resulted in generalizing an ALI specific fixup into
> > common code into common code[2], so we should already be doing
> > exactly this in many cases. If Nikolai can boot the system with debugging
> > enabled for arch/x86/pci/irq.c, we should be able to see exactly
> > which code path is his in his case, and why it doesn't go through
> > setting that register at the moment.
>
> Here is my dmesg with debugging (hopefully) added to irq.c:
>
> https://pastebin.com/tnC2rRDM
Ok, so it's getting roughly through the right code path:
dev_dbg(&dev->dev, "PCI INT %c -> PIRQ %02x, mask %04x, excl %04x",
'A' + pin - 1, pirq, mask, pirq_table->exclusive_irqs);
...
dev_dbg(&dev->dev, "PCI INT %c -> newirq %d", 'A' + pin - 1, newirq);
/* Check if it is hardcoded */
if ((pirq & 0xf0) == 0xf0) {
irq = pirq & 0xf;
msg = "hardcoded";
} else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq)) && \
((!(pci_probe & PCI_USE_PIRQ_MASK)) || ((1 << irq) & mask))) {
msg = "found";
elcr_set_level_irq(irq);
} else if (newirq && r->set &&
(dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
if (r->set(pirq_router_dev, dev, pirq, newirq)) {
elcr_set_level_irq(newirq);
msg = "assigned";
irq = newirq;
}
}
if (!irq) {
if (newirq && mask == (1 << newirq)) {
msg = "guessed";
irq = newirq;
} else {
dev_dbg(&dev->dev, "can't route interrupt\n");
return 0;
}
}
dev_info(&dev->dev, "%s PCI INT %c -> IRQ %d\n", msg, 'A' +
pin - 1, irq);
with the corresponding output from that one being
[ 0.761546] 8139too 0000:00:0d.0: runtime IRQ mapping not provided by arch
[ 0.761546] 8139too: 8139too Fast Ethernet driver 0.9.28
[ 0.761546] 8139too 0000:00:0d.0: PCI INT A -> PIRQ 02, mask 1eb8, excl 0001
[ 0.765817] 8139too 0000:00:0d.0: PCI INT A -> newirq 9
[ 0.765817] 8139too 0000:00:0d.0: can't route interrupt
[ 0.777546] 8139too 0000:00:0d.0 eth0: RealTek RTL8139 at
0xc4804000, 00:11:6b:32:85:74, IRQ 9
From what I can tell, this means that there is no chipset specific
get/set function,
the irq is not hardcoded but the 'mask' value in the irq_info table (0x1eb8)
lists a number of options.
In this case, the function gives up with the "can't route interrupt\n"
output and does not call elcr_set_level_irq(newirq). Adding the call
to elcr_set_level_irq() in that code path as well probably makes it
set the irq to level mode:
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -984,6 +984,7 @@ static int pcibios_lookup_irq(struct pci_dev *dev,
int assign)
irq = newirq;
} else {
dev_dbg(&dev->dev, "can't route interrupt\n");
+ elcr_set_level_irq(newirq);
return 0;
}
}
No idea if doing this is a good idea though, in particular I have no clue
about whether this is a common scenario or not.
Arnd
next prev parent reply other threads:[~2021-06-22 13:25 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 14:08 Realtek 8139 problem on 486 Nikolai Zhubr
2021-05-29 18:42 ` Heiner Kallweit
2021-05-29 21:44 ` tedheadster
2021-05-30 0:49 ` Nikolai Zhubr
2021-05-30 10:36 ` Nikolai Zhubr
2021-05-30 17:27 ` Nikolai Zhubr
2021-05-30 20:54 ` Arnd Bergmann
2021-05-30 23:17 ` Nikolai Zhubr
2021-05-31 16:53 ` Nikolai Zhubr
2021-05-31 18:39 ` Arnd Bergmann
2021-05-31 22:18 ` Nikolai Zhubr
2021-05-31 22:30 ` Heiner Kallweit
2021-06-01 7:20 ` Arnd Bergmann
2021-06-01 10:53 ` Nikolai Zhubr
2021-06-01 11:42 ` Heiner Kallweit
2021-06-01 16:09 ` Nikolai Zhubr
2021-06-01 21:48 ` Heiner Kallweit
2021-06-01 23:37 ` Nikolai Zhubr
2021-06-02 9:12 ` Arnd Bergmann
2021-06-07 23:07 ` Nikolai Zhubr
2021-06-08 7:44 ` Arnd Bergmann
2021-06-08 20:32 ` Nikolai Zhubr
2021-06-08 20:45 ` Arnd Bergmann
2021-06-08 22:07 ` Nikolai Zhubr
2021-06-09 7:09 ` Arnd Bergmann
2021-06-12 17:40 ` Nikolai Zhubr
2021-06-12 22:41 ` Arnd Bergmann
2021-06-13 14:10 ` Nikolai Zhubr
2021-06-13 21:52 ` Arnd Bergmann
2021-06-03 18:32 ` Maciej W. Rozycki
2021-06-04 7:36 ` Arnd Bergmann
2021-06-20 0:34 ` Thomas Gleixner
2021-06-20 10:19 ` Arnd Bergmann
2021-06-21 4:10 ` Maciej W. Rozycki
2021-06-21 11:22 ` Arnd Bergmann
2021-06-21 14:42 ` Maciej W. Rozycki
2021-06-21 15:20 ` Arnd Bergmann
2021-06-22 11:12 ` David Laight
2021-06-22 12:42 ` Nikolai Zhubr
2021-06-22 13:22 ` Arnd Bergmann [this message]
2021-06-22 18:42 ` Nikolai Zhubr
2021-06-22 19:26 ` Arnd Bergmann
2021-06-23 1:04 ` Maciej W. Rozycki
2021-06-24 17:56 ` Nikolai Zhubr
2021-06-24 18:25 ` Maciej W. Rozycki
2021-07-14 23:32 ` Maciej W. Rozycki
2021-07-15 7:32 ` Nikolai Zhubr
2021-07-16 23:48 ` Maciej W. Rozycki
2021-06-23 16:31 ` Nikolai Zhubr
2021-06-23 23:39 ` Maciej W. Rozycki
2021-06-24 8:28 ` Arnd Bergmann
2021-07-02 19:02 ` Nikolai Zhubr
2021-07-03 9:10 ` Arnd Bergmann
2021-07-08 19:21 ` Nikolai Zhubr
2021-07-09 7:31 ` Arnd Bergmann
2021-07-09 12:43 ` David Laight
2021-06-01 17:44 ` Maciej W. Rozycki
2021-06-02 15:14 ` Nikolai Zhubr
2021-06-02 15:28 ` Arnd Bergmann
2021-05-31 19:05 ` Heiner Kallweit
2021-05-31 18:29 ` Denis Kirjanov
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='CAK8P3a1XaTUgxM3YBa=iHGrLX_Wn66NhTTEXtV=vaNre7K3GOA@mail.gmail.com' \
--to=arnd@kernel.org \
--cc=bp@alien8.de \
--cc=hkallweit1@gmail.com \
--cc=hpa@zytor.com \
--cc=macro@orcam.me.uk \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=zhubr.2@gmail.com \
/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.