[lkml]   [2000]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

> 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 W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail:, PGP key available +

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.107 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site