Date: Fri, 24 Dec 1999 12:47:50 -0800 From: Mike Smith <msmith@freebsd.org> To: NOKUBI Hirotaka <hnokubi@yyy.or.jp> Cc: freebsd-smp@freebsd.org Subject: Re: IRQ and APIC pin mapping question Message-ID: <199912242047.MAA11237@mass.cdrom.com> In-Reply-To: Your message of "Sun, 12 Dec 1999 20:11:45 %2B0900." <19991212111015.2B2CF150CD@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I've been trying SMP kernel on NEC PC9821RvII which is not PC-AT
> compatible, FreeBSD PC98 port works fine on it with UP kernel.
>
> I made it possible to access MPCT at the top of the physical memory,
Neat. Looking at the MPCT parsing code as it stands, it should probably
be integrated with our other BIOS signature search code. How do you find
the MPCP at the top of memory?
> SMP kernel works fine on it. But there is a problem around interrupt.
> Would you advice me about that?
>
> Almost all MPCT I've seen has same source IRQ# and destination
> APIC PIN#, like IRQ4 is connected to APIC PIN4. But PC9821RvII's
> MPCT shows some IRQ# is connected to different APIC PIN#, like
> IRQ8 is connected to APIC PIN7 (please see mptable output).
>
> My question is the meaning of int_to_apicintpin[].
>
> Interrupt is managed with IRQ#, so it needs to know that which IRQ#
> corresponds to which APIC PIN#. Although I think that is the reason
> int_to_apicintpin[] is provided, initialization of it confused me.
>
> Function setup_apic_irq_mapping() initialize int_to_apicintpin[] using
> assign_apic_irq() with same value as argument `intpin' and `irq'
> (please see patch). It works fine on the machine which has same
> IRQ# and APIC PIN#. But on my PC9821RvII, it is impossible for kernel
> to get correct APIC PIN# corresponds to IRQ# to handle. For example,
> kernel wants to disable IRQ10, APIC PIN9 should be disabled,
> but without patch, kernel disables APIC PIN10.
That's all basically correct, yes.
> How can I fix this problem without affecting PC-AT compatible?
I can't claim to be any sort of expert regarding this code, but since
nobody else seems to be responding to your query, and since I've been
looking at it a bit over the last few days...
What appears to be needed is the ability to search for an intpin given
some or all of a source bus, interrupt type and bus IRQ number.
> Index: i386/i386/mp_machdep.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
> retrieving revision 1.111
> diff -u -u -r1.111 mp_machdep.c
> --- mp_machdep.c 1999/10/15 21:38:15 1.111
> +++ mp_machdep.c 1999/12/12 10:59:25
> @@ -966,7 +966,7 @@
> int x;
>
> if (int_to_apicintpin[irq].ioapic != -1)
> - panic("assign_apic_irq: inconsistent table");
> + return;
>
> int_to_apicintpin[irq].ioapic = apic;
> int_to_apicintpin[irq].int_pin = intpin;
This isn't good because it causes us to lose all of the other mappings
between the supplied IRQ and interrupt pins. We probably need to chain
these structures. (That's how the Linux folks do it, if I understand
their code correctly).
> @@ -1070,7 +1070,7 @@
> io_apic_ints[x].int_type == 3)) {
> assign_apic_irq(0,
> io_apic_ints[x].dst_apic_int,
> - io_apic_ints[x].dst_apic_int);
> + io_apic_ints[x].src_bus_irq);
> }
> }
> int_vector = 0;
This seems right on the surface, but falls down because of the assumption
that the 'irq' argument to assign_apic_irq must always be unique.
I'm not entirely sure what the right approach to take here is.
Suggestions, anyone?
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org
\\ and he'll hate you for a lifetime. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912242047.MAA11237>