head	1.2;
access;
symbols;
locks
	fsmp:1.2; strict;
comment	@# @;


1.2
date	97.04.30.23.57.26;	author fsmp;	state Exp;
branches;
next	1.1;

1.1
date	97.04.29.02.04.25;	author fsmp;	state Exp;
branches;
next	;


desc
@original
@


1.2
log
@update
@
text
@<TITLE>Bugs</TITLE>

<hr><hr>
<h2 align = center>Kernel Problems</h2>


<p><hr>
<img src="../Images/redball.gif">
static (ROM based) MP tables and PCI bridge cards.

<p>
Some(most?) BIOS have a hard-coded MP table in ROM, meaning that bridged
PCI cards and other complex PCI setups will NOT be properly described
in the MP table.  As such, insufficient info exists in the table to properly
setup the APIC for these cards.

<p>
<img src="../Images/greenball.gif">Solution:
<p>
See the page on <a href="pcibridge.html">bridged PCI cards</a> for details
of a workaround.  The long term solution will be a pass where we build a
MP table incore based on information received from the PCI sub-system, ie,
we will toss certain sections of the motherboard provided MP table!

<p><hr>
<img src="../Images/redball.gif">
"sysctl kern.smp_active=x" ignores value of 'x'.

<p>
Initial startup of APs via "sysctl kern.smp_active=x" ignores
the actual value of 'x' and starts all the APs.
Not really a problem as much as it is just unexpected behaviour.

<p>
<img src="../Images/greenball.gif">Solution:
<p>
When we get the auto-start code working this section of code goes away...


<p><hr>
<img src="../Images/redball.gif">
Setting smp_active to '0' after starting other CPUs crashes system.

<p>
When smp_active == 0 all the lock code is ignored.  If you start the
additional CPU(s) via sysctl, they attempt to stop by setting smp_active
to '0' (instead of the proper value of '1') multiple CPUs enter the kernel
at the same time, causing random corruption and crashes.

<p>
<img src="../Images/greenball.gif">Solution:
<p>
Don't do that!  A better fix would be???

<p><hr>
<img src="../Images/redball.gif">
INT 13 sometimes attached to npx0.

<p>
Certains motherboards (Neptune/EISA based) randomly report INT 13 as used
by the FPU during the npx0 probe code.  This seems to be benign behaviour
in most cases, but still needs to be fixed.  It is sometimes exhibited
as "stray irq13" messages.

<p>
<img src="../Images/greenball.gif">Solution:
<p>
Since external FPUs are NOT allowed by the MP spec, I propose putting
a huge #ifdef SMP/#endif wrapper around the npx0 probe code so that for
the case of SMP it never decides to use INT 13.  In other words, the npx0
probe shouls always report "npx0: INT 16 interface" for the SMP kernel.
Volunteers?

<p><hr>
<img src="../Images/redball.gif">
PnP board failure

<p>
PnP boards can cause problems as I have not yet implimented code to "undirect"
PCI INTs when sent to the APIC.  Since an upper ( >15 ) INT is registered
in place of the original ( <=15 ) the original may be assigned later by
a PnP card.  BUT the lower INT line is NOT un-redirected.
This means both the PCI hardware (via the redirect hardware) AND the PnP
card are yanking on the same lower INT line, causing random problems.

<p>
<img src="../Images/greenball.gif">Solution:
<ul>
<li>Short term: disable the PnP aspects of a board, use the BIOS "legacy ISA"
settings.
<li>Long term: impliment the "undirect" code for the ISA redirection register.
</ul>


<p>
<hr><hr>
<h2 align = center>UserLand Code Problems</h2>

<p><hr>
<img src="../Images/blueball.gif">
dset probably fails, isa_device.h:irq_d(?) size: u_int vs. u_short.

<p><hr>
<img src="../Images/blueball.gif">
biosboot probably fails: cpufunc.h, ipl.h, spl.h: opt_smp.h issues.


<p>
<hr><hr>
<h2 align = center>Hardware Setup Problems</h2>

<p><hr>
<img src="../Images/yellowball.gif">
BIOS needs MP spec 1.4 setting

<p>
We have discoverd that some BIOS have a setting for which version of the MP
spec to use: 1.1 or 1.4.  When such a setting is available 1.4 should be used.

<p>
<img src="../Images/greenball.gif">Solution:
<p>
Set BIOS to MP spec 1.4 when available.


<p><hr>
<img src="../Images/yellowball.gif">
motherboard MP table declares 8254 timer to be connected to the IO APIC,
but it actually isn't, causing a kernel lockup.

<p>
On some motherboards the 8254 timer ouput is not connected to the IO APIC.
If the MP table correctly shows this fact by lack of an INT entry for
the 8254 timer the kernel will enable "mixed-mode" programming, 
getting around the problem.  However not all MP tables do so.  Instead they
declare that the 8254 timer is connected, usually to INT2.  This prevents
the kernel from taking corrective action, and a kernel lockup results.

<p>
<img src="../Images/greenball.gif">Solution:
<p>
A kernel option to override the offending MP table entry is available, see
<a href="timernc.html">this page</a> for details.


<p>
<hr><hr>
<a href="oldbugs.html">Old bugs </a> and resolutions.
@


1.1
log
@Initial revision
@
text
@a26 39
Systems with > 1 PCI bus may fail.

<p>
The MP spec appendix D.2 specifies that when MORE than 1 PCI bus exists
the PCI busses should be assigned IDs first, using actual PCI bus
numbers.  Then ids are assigned to other busses using whatever numbers are
free.

<p>
BIOS with ONLY ONE PCI bus on the MOTHERBOARD often list
the ISA/EISA bus first, thus makeing the one and only PCI bus have ID 1.
When a PCI bridge card exists in the system another PCI bus then exists,
causing the PCI bus numbering (ie ID #s) to be incorrect.  Even when
no such card exists, having the ISA bus first causes the PCI bus id to
NOT match the actual PCI bus #.  This makes identifying PCI bus:device:int
info from the MP table INTs section difficult (prone to error).
To work around this problem the current code ignores the bus ID when
identifying PCI INT associations, causing possible errors with multiple PCI
bus systems.

<p>
<img src="../Images/greenball.gif">Solution:

<ul>
<li>reorder the bus ids and the bus id entries in the INT section of the
   MP table to reflect true PCI bus semantics.
<li>start using the bus id fields in the lookups.
</ul>

<p>
This will require additional code in sys/i386/i386/mp_machdep.c and
possibly some sys/pci modules.

<p>
See MP spec v1.4, D.2 & D.3 for details on required format.


<p><hr>
<img src="../Images/redball.gif">
@
