Messages in this thread |  | | Date | Fri, 8 Sep 2000 20:21:36 +0200 (MET DST) | From | "Maciej W. Rozycki" <> | Subject | Re: [PATCH] panic when booting Intel XXPRESS SMP boards |
| |
On Fri, 8 Sep 2000, Linus Torvalds wrote:
> I'm doing an alternative patch that just igores unknown buses, because > paniccing is definitely the wrong answer for anything but some early > debugging ("did I catch all the relevant cases?").
I think we must panic() for an unknown bus that has an I/O APIC interrupt routed from that is marked as "conforming to the bus spec" in the MP table. Trying to assume any defaults is unsafe and is not any better -- we may guess them upon the first interested user reports such a problem. This should trigger on a small amount of unusual system if any at all.
For any other case we may try to handle interrupts according to information provided in the MP table.
> It looks like the simplest solution is to just make bus number 0 be > "unknown", and leave it at that (and start ISA etc from 1). Wouldn't you > agree?
We cannot asume any bus is of any type -- it may be ISA or PCI or whatever. Jean-Marc actually reported:
Bus #0 is PCI Bus #1 is PCI Bus #18 is XPRESS Bus #19 is EISA
a few days ago (I admit I should have replied by then but this week was completely crazy for me so I just marked it for later reference). So this will not help him either.
We may add an "unknown" entry to our bus list and only choke upon I/O IRQ parsing under conditions I've outlined above. We may print the bus name to the log for user pleasure anyway, as it's stored as ASCII in the MP table.
> I'd love to have somebody (yes, you) look at the actual MP table and see > if there is something special with the XXPRESS bus, but in the end even if > we don't know a bus we're better off always just mentioning the fact > ("Unknown bus XXXX") and going on with our life. Maybe the system won't > work simply becasue we won't find any critical devices off the bus, but if > we panic we _know_ that it won't work, so..
The system may be unusable due to an IRQ flood for example (just like when I set my 8254 IRQ as level-triggered in the I/O APIC when simulating an MCA configuration).
Jean-Marc: feel free to send me the output of `dmesg -s 32768' as I outlined in the previous mail -- I'll study it after the next week (or immediately, if you somehow manage it to be delivered in a few minutes ;-) ).
Maciej
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |