Date: Mon, 13 Jan 1997 10:54:26 -0700 From: Steve Passe <smp@csn.net> To: Ade Barkah <mbarkah@hemi.com> Cc: freebsd-smp@FreeBSD.org Subject: Re: Data point, and questions... Message-ID: <199701131754.KAA20622@clem.systemsix.com> In-Reply-To: Your message of "Mon, 13 Jan 1997 02:15:06 MST." <199701130915.CAA22677@hemi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, --- >* 1st try: compiled the kernel without the APIC_IO support as >mptable suggests. I just updated the web page with the latest version, 2.0.5: http://www.freebsd.org/~fsmp/SMP/mptable/mptable.c.gz This makes APIC_IO the default (now highly recommended, USE IT), as well as adding: options SMP_INVLTLB # this is also highly recommended (ie USE IT) --- >| npx0: INT 16 interface >| stray irq 13 >| Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 10, 11, 13, imen: 0x00ffd221 > >Hmm... reading npx.c says the FPU doesn't work in smp yet, so >maybe the stray irq is ok. > >Now, sometimes (after a warm reboot, perhaps), the "13," doesn't >show up, and the machine hangs. not "OK", but a "feature" of the Neptune chipset! not possessing one I haven't been able to track this down. you are the 1st to report it actually hanging the machine. --- >With this APIC_IO support, the machine appeared to be a little more >stable, but after awhile it dies with random core dumps as well. > >** 3rd try: I had an Adaptec 1542CF w/64mb + bounce buffer support. >So, that might be part of the problem. this might work with the above mentioned SMP_INVLTLB option in effect. --- >However... I can't tell if it's actually using two cpus! The >"make -j 4" times using the smp w/apic and the uni-processor >kernel yield almost identical times (about 14 minutes to >compile an smp kernel, slow due to the disabled cache.) > >| % sysctl kern | grep smp >| >| kern.smp_active: 2 >| kern.smp_cpus: 2 this is strange, it looks like both are truly running. I wonder if lack of cache is causing this? --- 1) On ps aux, all the STARTED times show "31Dec69". known problem. --- >2) The sio driver now regularly reports sio overflows. A modem > is connected at 57.6k there. INTerrupt latency sucks right now because of our "giant lock" model. This is being thought over,,, it will be a big change to fix! I suspect that fixing your cache might help here also. --- >3) Is there support for multi-threaded programs ? (I mean, do > the threads run on multiple processors ?) I wrote a simple > pthread program, and it doesn't look like the threads run > in parallel. they DON'T, no kernel threading yet, libc_r time-shares a single process... -- 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?199701131754.KAA20622>