.
have you recompiled the kernel to enable SMP? the GENERIC kernel does not
support SMP AFAIK.
damon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[Not network-related; moved to -current.]
On Sat, 8 Jan 2000 10:02:25 -0600 (CST), Mohit Aron [EMAIL PROTECTED] said:
Good Lord! This is the second time now. I even SAID in my last two mails that
there is only ONE processor. Theortically then, FreeBSD configured with/without
SMP support
Yes it should. SMP support enables inter-processor locking code which
does not exist in non-SMP kernels. Ergo, non-SMP kernels run
uniprocessor tasks faster.
Well, some difference is to be expected. But 22%
- Mohit
To Unsubscribe: send mail to [EMAIL PROTECTED
On Sat, 8 Jan 2000 12:34:24 -0600 (CST), Mohit Aron [EMAIL PROTECTED] said:
Well, some difference is to be expected. But 22%
Flaws in the Intel SMP design make it more expensive than it ought to
be. Things like atomic RMW cycles are very, very expensive. (We had
a discussion about six
Hi,
I'm using FreeBSD-current (snapshot from Jan 3rd) which is configured
with both SMP and APIC_IO support. This version panics upon calling
acquire_timer0() (to modify the interrupt frequency of the 8254). On the other
hand, if the kernel is not configured as an SMP, then it works fine
hello,
You may want to upgrade to a more recent source tree :
I've cvsupped from a 4.0-19991229-CURRENT snapshot to the sources around
01/05 21h00 GMT and SMP works fine on my machine (I have seen strange
things with the snapshot : cvs did not want to check out the source tree
! not a pleasant
On Sat, 8 Jan 2000, Mohit Aron wrote:
Hi,
I'm using FreeBSD-current (snapshot from Jan 3rd) which is configured
with both SMP and APIC_IO support. This version panics upon calling
acquire_timer0() (to modify the interrupt frequency of the 8254). On the other
hand, if the kernel
Hi,
I am using the FreeBSD-4.0 snapshot from 3rd January 2000. This version
used to panic when configured as an SMP but with less CPUs than there are
actually in the machine (I had 4 processors but only wanted to use 1). Someone
mailed me patches for fixing this problem (attached below
On Tue, Dec 21, 1999 at 12:50:24PM +, George Cox wrote:
Right. Get yourself cvsup-bin-16.0 from a FreeBSD ftp site (it's in the
cvsup directory). Install that and read the manpages, just to get a
flavour of how it works.
Next, look at the files in /usr/share/examples/cvsup --
Emre wrote:
Hi people,
I went to
ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/4.0-19991218-CURRENT/README.TXT
and read that document.
Most hardware that I need to use is supported on that list, but I have a question:
is SMP enabled in the GENERIC kernel in FreeBSD 4.0-current
Hi people,
I went to
ftp://current.freebsd.org/pub/FreeBSD/snapshots/i386/4.0-19991218-CURRENT/README.TXT
and read that document.
Most hardware that I need to use is supported on that list, but I have a question: is
SMP enabled in the GENERIC kernel in FreeBSD 4.0-current? we have a server
(Forwarded to -current, due to lack of audience in -smp. Sorry for
bothering you).
-- Forwarded message --
From: Remy Nonnenmacher [EMAIL PROTECTED]
Subject: Idle loop in SMP.
Date: Wed, 1 Dec 1999 18:43:40 +0100 (CET)
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED
Just a followup question on my question from a week ago or so ther was
indeed a stack overflow I'd guess- I check the code path more carefully
and there was a 2KB stack buffer there (oof)- and removing it seemed to
make the problem go awaySo the question here is "Shouldn't this have
Just a followup question on my question from a week ago or so ther was
indeed a stack overflow I'd guess- I check the code path more carefully
and there was a 2KB stack buffer there (oof)- and removing it seemed to
make the problem go awaySo the question here is "Shouldn't this have
been
I just ran across this:
Debugger("isp_attach")
Stopped at Debugger+0x37: movl$0,in_Debugger
db cont
whoa, other_cpus: 0x0002, stopped_cpus: 0x
panic: stop_cpus() failed
mp_lock = 0002; cpuid = 0; lapic.id =
Automatic reboot in 15 seconds - press a key on the
I just ran across this:
Debugger("isp_attach")
Stopped at Debugger+0x37: movl$0,in_Debugger
db cont
whoa, other_cpus: 0x0002, stopped_cpus: 0x
panic: stop_cpus() failed
mp_lock = 0002; cpuid = 0; lapic.id =
Automatic reboot in 15 seconds - press a
Just to let everyone know, Greg's going to be out-of-town for a little
while and won't be able to continue debugging. I'm taking a crack at it
again.
So far, it seems to be a combination of softupdates+vinum+raid5 that
triggers the bug, whatever it is. If I turn off softupdates the raid5
On Monday, 30 August 1999 at 7:53:12 +0200, Bernd Walter wrote:
On Sun, Aug 29, 1999 at 04:48:32PM -0700, Matthew Dillon wrote:
:
:How similar? The trap above is extremely bad; it looks like a return
:on a corrupted stack or a jump through a null function vector.
:
:Make very sure that
Hi,
With a kernel built from -current cvsup'd at Sun Aug 22 04:03:19 BST 1999,
I got the following panic doing make -j8 world with /usr/src via NFS and
/usr/obj local:
Panic: free vnode isn't
mp_lock = 0001; cpuid = 0; lapic.id =
backtrace (hand-transcribed):
panic
getnewvnode()
On Mon, Aug 30, 1999 at 09:14:11AM +0200, Bernd Walter wrote:
On Mon, Aug 30, 1999 at 03:58:16PM +0930, Greg Lehey wrote:
Yes, this is the same thing. Until Parag came along, I was beginning
to think it was a problem with your hardware :-(
Yes - I would have done tests with a host at
process = 376 (cpio)
interrupt mask = bio - SMP: XXX
kernel: type 12 trap, code=0
Stopped at 0:
[...]
This looks similar to the panics I got since some days.
I was not able to dump too, but was successfull with remote kgdb
My system is single CPU with vinum
, IOPL = 0
current process = 376 (cpio)
interrupt mask = bio - SMP: XXX
kernel: type 12 trap, code=0
Stopped at 0:
[...]
This looks similar to the panics I got since some days.
How similar? The trap above is extremely bad; it looks like a return
on a corrupted stack
On Sunday, 29 August 1999 at 18:08:33 -0700, Parag Patel wrote:
On Sun, 29 Aug 1999 16:48:32 PDT, Matthew Dillon wrote:
This looks like an indirect call through a NULL function pointer.
Wow - I'm impressed! You really know your kernel debugging! :) It is a
null-pointer dereference
:(kgdb) target remote /dev/cuaa2
:Remote debugging using /dev/cuaa2
:0x0 in ?? ()
:(kgdb) bt
:#0 0x0 in ?? ()
:#1 0xc017228f in biodone (bp=0xc09ebd80) at ../../kern/vfs_bio.c:2580
:#2 0xc0123db6 in dadone (periph=0xc0882c80, done_ccb=0xc09bd200) at
:../../cam/scsi/scsi_da.c:1294
:#3
:Greg's debugging this on the machine here at the moment, which is
:crashing the same way in what appears to be the same place.
:
:If anyone else wants to take a crack it, the magic vinum debug number
:needed is 328 and not 324.
:
:So far Greg's discovered that the field is correctly set a little
On Sunday, 29 August 1999 at 23:15:47 -0700, Matthew Dillon wrote:
Greg's debugging this on the machine here at the moment, which is
crashing the same way in what appears to be the same place.
If anyone else wants to take a crack it, the magic vinum debug number
needed is 328 and not 324.
On Monday, 30 August 1999 at 7:53:12 +0200, Bernd Walter wrote:
On Sun, Aug 29, 1999 at 04:48:32PM -0700, Matthew Dillon wrote:
:
:How similar? The trap above is extremely bad; it looks like a return
:on a corrupted stack or a jump through a null function vector.
:
:Make very sure that
On Sunday, 29 August 1999 at 22:59:22 -0700, Matthew Dillon wrote:
(kgdb) target remote /dev/cuaa2
Remote debugging using /dev/cuaa2
0x0 in ?? ()
(kgdb) bt
#0 0x0 in ?? ()
#1 0xc017228f in biodone (bp=0xc09ebd80) at ../../kern/vfs_bio.c:2580
#2 0xc0123db6 in dadone (periph=0xc0882c80,
: },
: b_vnbufs = {
: ...
: (kgdb)
:
: This is definitely a pbuf.
:
:What's a pbuf?
Sorry, it isn't a pbuf. Hmm. You are allocating and initializing
a struct buf yourself? That could cause long term problems but is
neither here nor there at the moment, we'll deal with it
On Sunday, 29 August 1999 at 23:36:24 -0700, Matthew Dillon wrote:
},
b_vnbufs = {
...
(kgdb)
This is definitely a pbuf.
What's a pbuf?
Sorry, it isn't a pbuf.
OK. But what is a pbuf? I've never heard that term before.
Hmm. You are allocating and initializing a
On Monday, 30 August 1999 at 8:06:03 +0200, Bernd Walter wrote:
On Sun, Aug 29, 1999 at 10:59:22PM -0700, Matthew Dillon wrote:
This is definitely a pbuf. Did you apply the patches Greg emailed?
Not yet.
I will do it today.
Wait a while. I'll send you another couple as well.
Greg
:
: What's a pbuf?
:
: Sorry, it isn't a pbuf.
:
:OK. But what is a pbuf? I've never heard that term before.
A pbuf is a 'physical buffer'. Specifically, it is a struct buf
structure used by low level device drivers to issue their own I/O.
pbuf's are used by a number of
Dual-Proc GigaByte 6BXDS-MB with 2x350Mhz PII and 256MB-RAM.
For further information I have added the Config-File and dmesg-output.
This is a known bug in the generic BIOS code on SMP systems; I have a
patch in hand and will be committing it soon.
--
\\ The mind's the standard \\
= 0x10:0xc02bde80
code= base 0xc00f, limit 0x, type 0x1b
= DPL 0, pres 1, def32 1, gran 0
proc flags = intr enabled, resume, iopl=0
current proc= idle
interrupt mask = -
On Saturday, 21 August 1999 at 22:30:54 -0400, Luoqi Chen wrote:
I'm generating a core dump. Please note that as tara is my test machine, I use
"INVARIANT" "INVARIANT_SUPPORT". Should I remove them ?
It seems that from my reading of the code, the panic would not had happened
without
According to Greg Lehey:
In all likelihood, these options didn't "cause" the panic, they just
made another bug more visible. That's what they're there for.
That's what I'm thinking but compiling NFS into the kernel "fixed" my
panic. The weird part is that I'm still using INVARIANT. I don't
On Sun, Aug 22, 1999 at 10:24:33PM +0200, Ollivier Robert wrote:
That's what I'm thinking but compiling NFS into the kernel "fixed" my
panic. The weird part is that I'm still using INVARIANT. I don't see why the
condition is not met when compiling all these together and is when using the
kld.
Hello,
I just got a panic when trying to play with NFSv3. The system is a dual
PentiumPro system, running CURRENT/SMP. I use NFS as a kld.
The FS on keltia is exported as:
/z -alldirs -maproot=0 tara
And mounted on tara with
keltia:/z /spare rw,nfsv30 0
I tried making
:Hello,
:
:I just got a panic when trying to play with NFSv3. The system is a dual
:PentiumPro system, running CURRENT/SMP. I use NFS as a kld.
The very first thing I would do is compile NFS into the kernel and not
use it as a kld. Then see if you can repeat the problem
I'm generating a core dump. Please note that as tara is my test machine, I use
"INVARIANT" "INVARIANT_SUPPORT". Should I remove them ?
It seems that from my reading of the code, the panic would not had happened
without INVARIANT.
It is these options that caused the panic, you either
"David E. Cross" [EMAIL PROTECTED] wrote:
I have a threaded appilcation that is only running on one processor.
I remember there was discussion about this in the past, and there was a
solution, I think it involved a patch.
Any pointers?
http://lt.tar.com
Tony.
--
f.a.n.finch[EMAIL
|"David E. Cross" [EMAIL PROTECTED] wrote:
|I have a threaded appilcation that is only running on one processor.
|I remember there was discussion about this in the past, and there was a
|solution, I think it involved a patch.
|
|Any pointers?
|
|http://lt.tar.com
And don't be turned off by
I have a threaded appilcation that is only running on one processor.
I remember there was discussion about this in the past, and there was a
solution, I think it involved a patch.
Any pointers?
--
David Cross | email: [EMAIL PROTECTED]
Systems
test3:/usr/src/sys/compile/ALPHA# make
cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-g -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf
:Hi there,
:
: I recently had a crash on my SMP system. Actually, I have had a
:number of crashes over the past six months, but have just recently had
:time to configure the system to get the crash dumps. Like a good
:citizen, I filed a problem report (kern/12127). I have now gotten
:another
On Tue, 20 Jul 1999, Matthew Dillon wrote:
How old is your -CURRENT source tree ?Fixes to the pipe code
have been made, though they are not 100% complete.
If your -CURRENT source tree is more then a few days old I recommend
updating it. A number of significant
It seems Matthew Dillon wrote:
Here's some more info. If the dd is stuck and systat -vm 1 is showing
no interrupts occuring on, for example, ahc2 (irq17), and I then do
something that causes an interrupt to occur on mux (irq19), which I
guess is ahc1, ahc2 then starts
Hi there,
I recently had a crash on my SMP system. Actually, I have had a
number of crashes over the past six months, but have just recently had
time to configure the system to get the crash dumps. Like a good
citizen, I filed a problem report (kern/12127). I have now gotten
another crash. I
On Wed, 09 Jun 1999, Luoqi Chen wrote:
I've been trying to install 19990604-CURRENT on a couple of SC450NX
boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's
falls over very quickly (I think while it's setting up the APIC
stuff, or very shortly after - the messages about
I have added more debugging messages, and the crash appears to be inside
mp_start(). I don't have a log because this is too early in the boot
to get the messages saved anywhere, and they go by too quickly to
write it down. The evidence that this is an SMP problem is simple -
with 2 cpu's
On Thu, 10 Jun 1999, Luoqi Chen wrote:
Could you narrow down the crash further inside mp_start()? I'd like to
know whether the crash occurred inside start_all_aps(). One or two lines of
debug messages would be really helpful, you don't have to write down the exact
words. Do you have options
Hi,
I've been trying to install 19990604-CURRENT on a couple of SC450NX
boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's
falls over very quickly (I think while it's setting up the APIC
stuff, or very shortly after - the messages about APIC bus ids appear
on the screen very
Hi,
I've been trying to install 19990604-CURRENT on a couple of SC450NX
boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's
falls over very quickly (I think while it's setting up the APIC
stuff, or very shortly after - the messages about APIC bus ids appear
on the screen
In reply:
Hi,
I've been trying to install 19990604-CURRENT on a couple of SC450NX
boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's
falls over very quickly (I think while it's setting up the APIC
stuff, or very shortly after - the messages about APIC bus ids appear
Do you mean messages like these?
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000
cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000
io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0
By the time
interesting. then why the delay in bringing up the AP? Note in the
dmesg output below, that the AP only comes up during th SCSI delay. I
have also added other comments to the following output.
The APs need the giant kernel lock when initializing the
local APIC and printing the launched
In article local.mail.freebsd-current/199906092225.saa01...@par28.ma.ikos.com
you write:
Also in trying to figure this out I looked at the DRAM probing
code in /usr/src/sys/i386/i386/machdep.c:getmemsize(), and it looks
as though it's not safe for 2GB (e.g. comparisons of byte addresses
against
In reply:
interesting. then why the delay in bringing up the AP? Note in the
dmesg output below, that the AP only comes up during th SCSI delay. I
have also added other comments to the following output.
The APs need the giant kernel lock when initializing the
local APIC and printing
are there any known problems with the Tyan Thunder2 [1696DLUA] and
Thunder100 [1836DLUA] motherboards?
I am finishing up putting together the thunder-2 system with dual
333's, and am starting to obtain the parts for the Thunder100.
jim
--
All opinions expressed are mine, if you| I will
I run a -STABLE system on a S1836DLUAN, it seems to do just fine.
If you need more info contact me.
-Ira
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Thu, Jun 03, 1999 at 08:37:56AM -0500, Jim Bryant jbry...@unix.tfs.net
wrote:
are there any known problems with the Tyan Thunder2 [1696DLUA] and
Thunder100 [1836DLUA] motherboards?
The Thunder100 DLUAN I have works very well with two PII-400 and
-current FreeBSD. For Thunder2 don't
On Fri, 14 May 1999 19:34:43 CDT, Anthony Kimball wrote:
If anyone has applied reasonable stress to a recent MP kernel,
preferrably with X, VESA, VM86, and found it stable, do please report
on your last cvs update time: I, for one, would very much like to
isolate a fairly stable post-newbus
If anyone has applied reasonable stress to a recent MP kernel,
preferrably with X, VESA, VM86, and found it stable, do please report
on your last cvs update time: I, for one, would very much like to
isolate a fairly stable post-newbus world. Presumably this would be
helpful to other readers as
Hi,
Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :)
Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems
to return normal values though.
I've attached a sample output from APM, dmesg and my kernel config.
I get a trap 12: page fault
Hi,
Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :)
Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems
to return normal values though.
I've attached a sample output from APM, dmesg and my kernel config.
I get a trap 12: page fault
On 05-May-99 Luoqi Chen wrote:
Also, nm kernel.debug | sort shows that 0xc0208a4c is in Xbpt
Are you sure it's in Xbpt? Xbpt has only 6 lines of code and none of them is
likely to generate a page fault. What's the address of symbol Xbpt?
Yeah, well, it didn't look likely to me either but..
Yeah, well, it didn't look likely to me either but.. :-/
Here is part of nm kernel.debug | sort
...
c0208a30 T Xnmi
c0208a3c T Xbpt
c0208a50 T Xofl
...
Did you actually boot from kernel.debug? If not, use the kernel you booted
from, the symbols should still be there.
I'll give it
Hi,
Has anyone tried having APM and SMP in the same kernel? It panic()'s mine :)
Basically the machine panics a few seconds after I do 'apmconf -e'. apm seems
to return normal values though.
I've attached a sample output from APM, dmesg and my kernel config.
I get a trap 12: page fault
Insufficient content. Please add more and try again.
An alert: VESA/SMP seems to be problematic again. For example, this
sequence reliably brings me down to the bios:
startx
ctl-alt-bksp
vidcontrol 132x42
startx
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe
gdb.
I wonder if there are problems running the APM requests on an AP?
Daniel, are you running with the most recent MTRR/SMP fixes?
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ m...@smith.net.au
\\ The race is long, and in the \\ msm
(XF86_S3V), with
options SMP
options APIC_IO
options NCPU=2
options NBUS=4
options NAPIC=1
options NINTR=24
options VESA
options VM86
I'm going to be crashing the system later today anyhow, so I'll try
DDB to get an backtrace at that time
got a PR440FX dual running current (99.05.03) with an S3V
(Trio64) and XFree96 3.3.something (XF86_S3V), with
options SMP
options APIC_IO
options NCPU=2
options NBUS=4
options NAPIC=1
options NINTR=24
On 05-May-99 Luoqi Chen wrote:
My SMP vm sharing commit broke APM. Please try out this patch,
That patch seems to have fixed it! Great stuff :)
---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so
An alert: VESA/SMP seems to be problematic again. For example, this
sequence reliably brings me down to the bios:
startx
ctl-alt-bksp
vidcontrol 132x42
startx
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
In message 199904272349.taa28...@lor.watermarkgroup.com, Luoqi Chen writes:
I'm about to commit the SMP vmspace sharing patch (the %fs approach). All
kernel modules will need to be recompiled. Recompilation is not neccessary
for user land applications including ps, libkvm and friends
In message 199904281625.maa05...@lor.watermarkgroup.com, Luoqi Chen writes:
In this %fs approach, per-processor private pages are no longer mapped at
identical virtual address for each cpu, instead a new segment descriptor
(%fs)
is setup to access per-cpu global variables like curproc.
On Wed, 28 Apr 1999, Poul-Henning Kamp wrote:
In message 199904281625.maa05...@lor.watermarkgroup.com, Luoqi Chen writes:
In this %fs approach, per-processor private pages are no longer mapped at
identical virtual address for each cpu, instead a new segment descriptor
(%fs)
is setup
I know this is a little late ... but I don't suppose there might be a
way to lock a TLB entry in place? That would solve the problem too.
Baring that, %fs is the way to go.
I am happily compiling up a new SMP kernel as we speak :-).
-Matt
On Wed, Apr 28, 1999 at 11:19:17AM -0700, Matthew Dillon wrote:
I know this is a little late ... but I don't suppose there might be a
way to lock a TLB entry in place? That would solve the problem too.
Baring that, %fs is the way to go.
Unfortunately, on the x86, the answer is
:On Wed, Apr 28, 1999 at 11:19:17AM -0700, Matthew Dillon wrote:
: I know this is a little late ... but I don't suppose there might be a
: way to lock a TLB entry in place? That would solve the problem too.
: Baring that, %fs is the way to go.
:
:
:Unfortunately, on the x86, the
On Wed, Apr 28, 1999 at 02:48:56PM -0700, Matthew Dillon wrote:
...
There might be less confusion with %fs if we simply use it as a
'cpu number' index and then make all the cpu-dependant variables
standard arrays. i.e. instead if 'struct proc *curproc' we would
have
more readable then trying to 'hide' the
fact that curproc ( and other variables ) are actually segmented. We
have to keep in mind the fact that SMP is only just now gaining momentum,
and I think a considerable amount of additional data and structure is
going to be added to the per
I'm about to commit the SMP vmspace sharing patch (the %fs approach). All
kernel modules will need to be recompiled. Recompilation is not neccessary
for user land applications including ps, libkvm and friends.
In this %fs approach, per-processor private pages are no longer mapped at
identical
In message 199904272349.taa28...@lor.watermarkgroup.com, Luoqi Chen writes:
I'm about to commit the SMP vmspace sharing patch (the %fs approach). All
kernel modules will need to be recompiled. Recompilation is not neccessary
for user land applications including ps, libkvm and friends.
In this %fs
I have one problem, though. During the kernel boot:
isa_dmainit(2, 1024) failed
And, of course, any access to something that needs isa
dma (e.g. floppy) panics. It's a large-memory machine (1G).
I was under the impression that this was supposed to be fixed
in the
I have one problem, though. During the kernel boot:
isa_dmainit(2, 1024) failed
And, of course, any access to something that needs isa
dma (e.g. floppy) panics. It's a large-memory machine (1G).
I was under the impression that this was supposed to be fixed
in
Hi,
It seems to be fixed now with v 1.97 from
/usr/src/sys/i386/i386/mp_machdep.c
thanks !
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
But it's not related to that caused by the NMI,
and it appears suddenly after probing soerens
ATAPI drivers. hmm - SMP: AP CPU #1 Launched!
does not appear ... what this ever means.
the previos kernel as of yesterday had:
IP Filter: initialized. Default = pass all, Logging = disabled
SMP: AP
aeh - forgot to say ... it is reproducable - it can't boot
And the kernel-gdbtrace isn't very useful :(
Martin
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
I haven't been able to get a working SMP kernel out of -CURRENT recently.
I don't know exactly when it broke, because I usually rebuild on a weekly
basis. The kernel hangs after:
APIC_IO: Testing 8254 interrupt delivery
and doesn't ever come back (panic or otherwise).
The one thing that I
I haven't been able to get a working SMP kernel out of -CURRENT recently.
I don't know exactly when it broke, because I usually rebuild on a weekly
basis. The kernel hangs after:
APIC_IO: Testing 8254 interrupt delivery
and doesn't ever come back (panic or otherwise).
The one thing that I
That fixes it, thanks.
At 04:13 4/13/99 +0200, tor.e...@fast.no wrote:
I haven't been able to get a working SMP kernel out of -CURRENT recently.
I don't know exactly when it broke, because I usually rebuild on a weekly
basis. The kernel hangs after:
APIC_IO: Testing 8254 interrupt delivery
John S. Dyson dy...@iquest.net writes:
I just wanted to chime in and say that the new patches are based
on a really good concept, and is much cleaner than the previous
method. Also, many RISC architectures can utilize this
method due to the availability of lots of general registers.
(One
per-processor registers that one could use (but loading a
general register with that per processor register would be
needed for access.) Also, since the PPC has lots of registers,
one could? permanently reserve one of the general registers (r13?).
I really don't like the idea of
On Sun, 4 Apr 1999, Matthew Dillon wrote:
:(and what would be the equivalent ALPHA patch?)
:I can imagine the original PDE trick working on the alpha but
:they don't have a spare register sitting around..
do they?
:
:julian
I'd like to see this too. I will soon have two SMP boxes
: :julian
:
:I'd like to see this too. I will soon have two SMP boxes of my own to
play
:with for my own personal use and for an upcoming project, and at least one
:will be available for SMP life-testing purposes for several months.
:I really want to see two things: (1
will soon have two SMP boxes of my own to play
with for my own personal use and for an upcoming project, and at least one
will be available for SMP life-testing purposes for several months.
I really want to see two things: (1) Actual sharing of the physical pmap
between rfork(RFMEM
? permanently reserve one of the general registers (r13?).
All in all, this change has the potential for better context
switching time (and less memory/better performance for multi-threaded
processes.) This is a serious, non-trivial movement in the *right*
direction!!! :-). SMP users should
-trivial movement in the *right*
direction!!! :-). SMP users should be pleased with this movement (I
certainly am!!!)
The alpha palcode supports a per-thread unique value which can be used by
any threading system (user or kernel).
--
Doug Rabson Mail: d
/sys/i386/i386/swtch.s,v
retrieving revision 1.78
diff -c -r1.78 swtch.s
*** swtch.s 1999/04/02 17:59:39 1.78
--- swtch.s 1999/04/02 18:37:29
***
*** 466,472
#else
xorl%eax, %eax
#endif /* SMP */
! btrl%eax, VM_PMAP+PM_ACTIVE(%edx
801 - 900 of 933 matches
Mail list logo
