Date: Fri, 11 Dec 1998 11:47:21 -0700 From: Steve Passe <smp@csn.net> To: Roger Hardiman <roger@cs.strath.ac.uk> Cc: splite <splite@purdue.edu>, Nate Williams <nate@mt.sri.com>, mobile@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: SMP and PCMCIA card controllers give kernel panic Message-ID: <199812111847.LAA03619@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Fri, 11 Dec 1998 13:53:30 GMT." <367123D9.41C6@cs.strath.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> Hi,
>
> Well I did some kernel hacking and tracked down the problem to the
> IRQ probe code. The error is in build_freelist() in /sys/pccard/pcic.c
>
> It tries to ask the kernel which IRQs are free to be
> allocated to A) the PCMCIA controller board and B) the PCMCIA cards.
>
> This probe does not work correctly with SMP systems.
> It seems that on my hardware, the kernel Frees up some IRQs, giving
> these messages in my boot sequence.
> Freeing (NOT implemented) redirected ISA irq 11.
> Freeing (NOT implemented) redirected ISA irq 10.
> Freeing (NOT implemented) redirected ISA irq 9.
> Freeing (NOT implemented) redirected ISA irq 11.
>
> The IRQ probe scans IRQs from 1 to 15.
> When it gets to IRQ9 it causes a kernel panic, reporting a clash
> in the IRQ allocation. (I did not capture the exact error).
>
> Now IRQs 9,10 and 11 are what my BIOS assignes to my PCI cards and
> the SMP kernel does reasign these to IRQs 16 onwards in the magical
> APIC_IO way.
Need more detailed error messages from your failure. The line:
Freeing (NOT implemented) redirected ISA irq 9.
^^^^^^^^^^^^^^^
implies that the SMP kernel did direct IRQ9 thru the APIC. The "NOT
implimented" part is a reminder that the ISA section has not been
reprogrammed to allow use of IRQ 9 by cards on the ISA bus. (didn't)
have time to figure out how when I wrote that code...).
So the problem is in this code:
/* See if the IRQ is free. */
if (register_intr(irq, 0, 0, nullfunc, NULL, irq) == 0) {
/* Give it back, but add it to the mask */
INTRMASK(freemask, mask);
unregister_intr(irq, nullfunc);
}
Since the SMP kernel actually registered an INT from 16 up, but didn't
unhook IRQ9 from the bus, nor register it, it looks like its free, when it
really isn't. Its been a long time since I was in this code, so I'm not sure
of what the cure should be. Would be nice if someone could find time to
impliment the "freeing of ISA INT paths" for this situation, but I don't think
this would fix this problem. It appears (need the exact error message!)
that it is a programmed panic, based on some perceived allocation problem, but
I have no idea where without seeing the error message.
(note that I used an older SNAP for source to discuss this issue, could be the
panic is coming from the current version of this function, but that I am
not up to date.)
--
Steve Passe | powered by
smp@csn.net | Symmetric MultiProcessor FreeBSD
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812111847.LAA03619>