Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 1997 13:40:12 -0700
From:      Steve Passe <smp@csn.net>
To:        smp@freebsd.org
Subject:   Re: Adaptec 3940UW and SMP 
Message-ID:  <199701162040.NAA12419@clem.systemsix.com>

next in thread | raw e-mail | index | archive | help
Hi,

Summary:

  We appear to have fixed this problem for 1 system, but not the other.
The difference is the way the MP tables declare the 3940 INTerrupts.  The
working system is more 'definitive', however there *may* be enough info
in the non-working system to get around its incomplete MP table info
with some coding effort.  This assummes that they are redirecting the 3940
irqs properly in hardware on the motherboard.

Another part to the solution appears to be insuring that the 3940 doesn't
attempt to share INTs with other hardware.  This shouldn't be a problem, but...

I will not be able to get to this for 3-4 weeks at the earliest.  Anyone
else wanting to attempt it, feel free.

I placed the MP tables for these machines in the database as entries 22,23,24.
Thanx to  Keith Mitchell and Kenneth Merry for running all the tests, and
everyone else for their input.

---
I had no idea this was a problem till the other day.  Perhaps we should make
a definitive list of what doesn't work at the present while there is a lull
in the development effort.  Please send reports of any failings to the list,
(hopefully someone will have time to collect and collate, then I will put up
on the web page.)

Here's several items for the list:

--
From: smp@csn.net

-
bridged PCI cards don't work in all motherboards (lest we forget!)

-
every few boots I get:

starting system daemons: syslogd.
syslogd: cannot create /var/run/log: Address already in use
syslogd: child pid 69 exited with return code 1

once this happens it happens every time till I remove /var/run/log &
/var/run/syslog.pid.  I suspect its something to do with the fact that
we are NOT shutting down the 2nd CPU properly during halt.  The '/var/run/log'
file it complains about is a socket left lying around from the previous run.
A quick fix would probably be an "rm -f /var/run/log" preceeding the
syslogd creation in /etc/rc (is that where this happens?)

--
From: dave adkins <adkin003@gold.tc.umn.edu>

>I've noticed that with INVLTLB the 1pg and 2pg invalidates call invlpg which
>calls smp_invalidate as well as calling smp_invalidate explicitly. I've
>removed the explicit calls to smp_invalidate in the 1pg and 2pg routines
>and reduced the number of ipi int27's with no effect on the system's
>stability. It reduces the number of sio overflows.

--
Steve Passe	| powered by
smp@csn.net	|            FreeBSD




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701162040.NAA12419>