Jordan K. Hubbard writes:
So you guys (core) choose -- do you want 4.x to reap the benefits of
further SMP development or not?
I've read all the feedback on this thread and now feel that it would
be worthwhile to simply bring the SMP changes in on Wednesday. As others
Are there any 3rd party NIC klds yet?
NTMK.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
so every vendor that has ever tried to use them has been bitten by the
fact that they have to maintain N version for each branch of FreeBSD???
Can you list some specific examples? I'm not trying to be a wise-ass,
On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
That is also partly why you are also lacking the respect and support of a
wider audience. If you act like FreeBSD is just a "developer's sandbox",
that's what it will be. If you want it to be something greater than
On Mon, 24 Apr 2000, you wrote:
On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
That is also partly why you are also lacking the respect and support of
a wider audience. If you act like FreeBSD is just a "developer's
sandbox", that's what it will be. If you want it
On Mon, Apr 24, 2000 at 02:14:50PM -0700, Rodney W. Grimes wrote:
Developers and early adopters are the ones tracking -STABLE. Users are
installing binary snapshots and releases.
Some users do install snapshots and/or releases. Snap shots occur on a
regular basis and are affected by
{First one bounced by hub with ``out of memory'' error... second attempt}
Are there any 3rd party NIC klds yet?
NTMK.
It's not quite a kld, but ET Inc's modules are distributed as a .o.
Also I know of work underway to support some of the fancier SDL WanNic
cards that would have to be kld's
The network stack is equally easy to make MP-safe. In this case we
have a shared lock to lookup sockets for host/port combinations and
then fine-grained exclusive locks within those sockets. Route table
and other high level operations could in fact remain BGL'd without
On Mon, 24 Apr 2000, Bill Fumerola wrote:
The entire point is that somewhere the user has decided to upgrade
their system, and they need to know what the consequences are before
taking the plunge. If they upgrade their system half-ass (kernel, but
not modules) they are digging their own
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
I believe that it depends on what changes were made since the last
recompile, although it is good practice to at least recompile the modules
when the kernel is recompiled.
In my opinion the best way to handle things like this is to add a
modules
On Tue, 25 Apr 2000, Daniel C. Sobral wrote:
Because if we do not provide a STABLE ABI, we WON'T get third-party
(binary only) kernel modules.
I'm very divided in this issue. 4.x has just started, and would be
seriously impaired if no further improvements to it's SMP get in. On
the other hand
modules. A quick grep -l spl * | wc
Given that this is a change in the splxxx() implementation, it breaks
zero modules.
splxxx() was changed from an inline function to an ordinary function
when SMP development started, to give the same ABI for the SMP case as
for the non-SMP case. This gives the same
from an inline function to an ordinary function
when SMP development started, to give the same ABI for the SMP case as
for the non-SMP case. This gives the same ABI for different SMP
implementations as a side effect.
simple_lock* functions has breakage too. They defined as macros
for non
Personally, I don't think that's a bad idea, I never had trouble going to
/usr/src/sys/modules and doing a make depend then make then make install,
but I guess it'd be nicer if everything just compiled when I built my
kernel, and better yet, it would be nice to have it make the
"modules.old"
On Sun, 23 Apr 2000, Matthew Dillon wrote:
:In that case I have a strong objection to the SMP patchset being
:merged to 4.0. I have kernel modules in object format only that
:are working now, which this would break :-(.
:
:Rod Grimes - KD7CAX @ CN85sl - (RWG25)
: [EMAIL
we've
ever had, and I am confident that the 4.x series of releases will be
the best in FreeBSD's history probably until 5.1 or 5.2.
It's all in the name. I don't disagree with your assesment of the code bases.
However, I consider your SMP changes VERY destablizing; they BREAK
lots of modules
: There's another good reason to MFC the linux patch on wednesday...
: that is, to do it at the same time the SMP cleanup is MFC'd, and that
: is because both patch sets require the linux kernel module to be
: recompiled and I'd rather not force people to do that twice
firmly
behind the concept of treating it like any other release.
I'm sure that something can be done for the kld compatibility issues
so that you can have your SMP cake and eat it too. Just give it a bit
more thought. :)
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
:
:: There's another good reason to MFC the linux patch on wednesday...
:: that is, to do it at the same time the SMP cleanup is MFC'd, and that
:: is because both patch sets require the linux kernel module to be
:: recompiled and I'd rather not force people to do that twice
:
: There's another good reason to MFC the linux patch on wednesday...
: that is, to do it at the same time the SMP cleanup is MFC'd, and that
: is because both patch sets require the linux kernel module to be
: recompiled and I'd rather not force people to do that twice
PROTECTED]
To: Richard Wackerbarth [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: SMP changes and breaking kld object module compatibility
:
:On Sun, 23 Apr 2000, Matthew Dillon wrote:
:
: :In that case I have a strong objection to the SMP patchset being
: :merged to 4.0. I have
On Mon, Apr 24, 2000 at 12:36:45AM -0400, Alok K. Dhir wrote:
Totally off topic question that I've wondered for some time now - what
does MFC stand for?
Merge From CURRENT.
--
Will Andrews [EMAIL PROTECTED]
GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w---
?O M+ V-- PS+
On Mon, 24 Apr 2000, Alok K. Dhir wrote:
Totally off topic question that I've wondered for some time now - what
does MFC stand for?
According to the FAQ section located on the web @
http://www.freebsd.org/FAQ/misc.html#AEN3908
Q: What does 'MFC' mean?
A: MFC is an acronym for 'Merged From
On 07-Apr-00 Nick Hibma wrote:
What does it say before this info? Shared interrupt?
I have the same problem.. The USB controller in on IRQ 10.
(Its the PIIX4 one)
USB does work on SMP (or at least in some cases).
Not me :) Works under UP nicely.
uhci0: Intel 82371AB/EB (PIIX4) USB
Hello,
At Fri, 07 Apr 2000 21:29:26 +0900,
Kazutaka YOKOTA [EMAIL PROTECTED] wrote:
I am currently having trouble with Gigabyte GA-6BXD, dual Pentium III
motherboard. If I boot a UP kernel (5.0-CURRENT), the PIIX4 USB
controller works fine.
I use same mainboard GA-6BXD with dual
errupt and try
again?
I know. It works on my another SMP box running 4.0-STABLE ;-
There is no difference between 5.0 nd 4.0 that could create this
problem, so it must be a difference in hardware.
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
To Do list for the USB project:
[...]
- USB base stack and general items.
I am currently having trouble with Gigabyte GA-6BXD, dual Pentium III
motherboard. If I boot a UP kernel (5.0-CURRENT), the PIIX4 USB
controller works fine.
If I boot a SMP kernel (the only difference from the UP kernel
What does it say before this info? Shared interrupt?
USB does work on SMP (or at least in some cases).
uhci_timeout: ii=0xc0a601c0
uhci_timeout: ii=0xc0a601c0
uhci_timeout: ii=0xc0a601c0
usbd_new_device: addr=2, getting first desc failed
uhub_explore: usb_new_device failed, error=TIMEOUT
a USB keyboard, I got the messages in my previous
mail below.
Shared interrupt?
No shared interrupt. Both IDE channels are disabled by BIOS, thus,
irq 15 is free. After all, The USB drivers work if I run a UP kernel
on the same machine.
USB does work on SMP (or at least in some cases).
I know
bus sizes (anyone for a 386SX SMP box?).
Larger bus sizes are also problematical - they may require some form
of RMW sequence to update an object smaller than the bus. If more
than one writer is allowed to the bus-word containing the object, some
form of locking will probably be necessary anyway
In message [EMAIL PROTECTED], Matthew Dillon writes:
The general problem with the timecounter is that not only is the hardware
indeterminant, but the timecounter structure itself is *NOT* MP safe,
at least not by my read of it.
Well, read again then :-)
I've had a paper in the
On Thu, 30 Mar 2000, Matthew D. Fuller wrote:
Does softupdates provide faster performance than async/noatime? I keep
/usr/src and /usr/obj as such, would it be faster with softupdates? And
if so, why?
Async is theoretically faster if it is implemented properly. It is poorly
implemented in
In message [EMAIL PROTECTED], Jesper Skriver writes:
On the box below, a relative new dual PIII box, with a Intel
motherboard, does it use the i8254 or the PIIX timecounter ?
[...]
Timecounter "PIIX" frequency 3579545 Hz
You're using the PIIX.
--
Poul-Henning Kamp FreeBSD
At 5:44 PM -0600 2000/3/30, Matthew D. Fuller wrote:
Does softupdates provide faster performance than async/noatime? I keep
/usr/src and /usr/obj as such, would it be faster with softupdates? And
if so, why?
Of course, once you ask this question, the next logical one that
On Fri, Mar 31, 2000 at 12:24:27PM +0200, a little birdie told me
that Brad Knowles remarked
At 5:44 PM -0600 2000/3/30, Matthew D. Fuller wrote:
Does softupdates provide faster performance than async/noatime? I keep
/usr/src and /usr/obj as such, would it be faster with softupdates?
At 9:45 PM -0500 2000/3/29, Chuck Robey wrote:
Difference: 19 minutes, or a 21% improvement. Bob Bishop got 7% with an
earlier patch (hopefully his system is no longer locking up and he can
repeat his test with the current stuff).
Goddamn. That's significant! Congratulations, Matt.
At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
So softupdates improves buildworld times by a significant margin.
Uh, I think we've known this for a while now. ;-)
Still, I'm looking forward to finding out what the new timings
are for SMP builds with the new code
Alfred Perlstein [EMAIL PROTECTED] writes:
I'm aware of this, the problem is that tz may move in either
direction.
Why not just ignore the timezone argument? That hasn't been relevant
for a long time. The timezone information is kept in user-space.
From gettimeofday(2):
Note: timezone
and parallel accesses to the timecounter. What
should we be using for an interrupt-disabling spinlock?
Nothing. Accesses to the timecounter struct are already MP safe and fast.
Only the i8254 timecounter hardware currently needs interrupt-disabling,
but it is hopefully never used on SMP machines.
Bruce
,
but it is hopefully never used on SMP machines.
Worse. It is used by default on SMP machines which don't sport the
PIIX timecounter.
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will t
:At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
:
: So softupdates improves buildworld times by a significant margin.
:
: Uh, I think we've known this for a while now. ;-)
:
: Still, I'm looking forward to finding out what the new timings
:are for SMP builds with the new
Oops.. some of us are using i8254 on SMP machines. This motherboard is a
Intel PR440FX.
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #5: Mon Mar 27 20:39:24
-disabling,
:but it is hopefully never used on SMP machines.
:
:Worse. It is used by default on SMP machines which don't sport the
:PIIX timecounter.
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED] "Real hackers run -current on their laptop."
In message [EMAIL PROTECTED] Matthew Dillon writes:
: The general problem with the timecounter is that not only is the hardware
: indeterminant, but the timecounter structure itself is *NOT* MP safe,
: at least not by my read of it.
:
: It also doesn't appear to be interrupt
. What
should we be using for an interrupt-disabling spinlock?
Nothing. Accesses to the timecounter struct are already MP safe and fast.
Only the i8254 timecounter hardware currently needs interrupt-disabling,
but it is hopefully never used on SMP machines.
Worse. It is used by default
,
but it is hopefully never used on SMP machines.
Worse. It is used by default on SMP machines which don't sport the
PIIX timecounter.
ie. anything using the PIIX3 or older (think 440FX dual P6 systems, etc.)
On the box below, a relative new dual PIII box, with a Intel
motherboard, does it use the i8254
Only the i8254 timecounter hardware currently needs interrupt-disabling,
but it is hopefully never used on SMP machines.
Worse. It is used by default on SMP machines which don't sport the
PIIX timecounter.
ie. anything using the PIIX3 or older (think 440FX dual P6 systems
On Wed, Mar 29, 2000 at 10:04:17PM -0800, a little birdie told me
that Matthew Dillon remarked
Ha! I found it. Kirk gets the credit --- softupdates was turned on
in one of the machine's /usr/obj's and off on the other machine's.
So softupdates improves buildworld times by a
On Thu, Mar 30, 2000 at 05:44:53PM -0600, Matthew D. Fuller wrote:
Does softupdates provide faster performance than async/noatime?
In general it depends. Softupdates is faster on creating a file and then
deleteing it before both hit the disk. Softupdates nulifies out the
creation. Async
On Thu, Mar 30, 2000 at 04:00:43PM -0800, a little birdie told me
that David O'Brien remarked
On Thu, Mar 30, 2000 at 05:44:53PM -0600, Matthew D. Fuller wrote:
Does softupdates provide faster performance than async/noatime?
In general it depends. Softupdates is faster on creating a file
In message [EMAIL PROTECTED] "Matthew D. Fuller" writes:
: The question at task is, is buildworld one of them? I don't think that
: situation comes up a lot in buildworld, but I'm not exactly an authority
: on it...
About 6 months ago, softupdates made things about 5% faster than async
for
:At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
[...]
6 minutes 20 seconds (about 7%).
I'm seeing the same order of improvement still.
--
Bob Bishop (0118) 977 4017 international code +44 118
[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK
To
:In message [EMAIL PROTECTED] "Matthew D. Fuller" writes:
:: The question at task is, is buildworld one of them? I don't think that
:: situation comes up a lot in buildworld, but I'm not exactly an authority
:: on it...
:
:About 6 months ago, softupdates made things about 5% faster than async
::At 10:04 PM -0800 2000/3/29, Matthew Dillon wrote:
:[...]
:6 minutes 20 seconds (about 7%).
:
:I'm seeing the same order of improvement still.
:
:--
:Bob Bishop (0118) 977 4017 international code +44 118
:[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK
In message [EMAIL PROTECTED] Matthew Dillon writes:
: Async should not be used unless you really like restoring crashed
: filesystems from tape :-). Oh, and perhaps when one is doing an
: initial OS install from CDRom :-). Async itself will not cause a crash,
: but if your
(I'll have to run the build a couple of times).
Of course, this includes whatever other changes have gone into 5.x that
haven't gone into 4.x, but I'm pretty sure the SMP patches are the major
benefit to the timings.
I also did some syscall timing tests between 4.0 and 5.0. Using getpid(),
which
For the single-process (1-fork) case, syscall overhead improved
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock inward somewhat (even for syscalls that aren't MP safe),
the
:
:You should be able to remove the splhigh() from sigprocmask and run it
:MPSAFE. At least, I can't find a reason not to (and it works here, yes).
:
:\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
:
Tentitively it looks like we will indeed be able to make sigprocmask()
For the single-process (1-fork) case, syscall overhead improved
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock inward somewhat (even for syscalls that aren't MP safe),
On Wed, 29 Mar 2000, Matthew Dillon wrote:
time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
4696.987u 1502.278s
On Wed, 29 Mar 2000, Matthew Dillon wrote:
time make -j 20 buildworldbuild FreeBSD-current using 4.0 kernel
4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615pf+0w
time make -j 20 buildworldbuild FreeBSD-current using 5.0 kernel
4696.987u 1502.278s
* Mike Smith [EMAIL PROTECTED] [000329 17:03] wrote:
For the single-process (1-fork) case, syscall overhead improved
moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
improvement in the competing-cpu's case is due to the movement of the
MP lock
On Wed, 29 Mar 2000 19:25:29 -0800, Alfred Perlstein [EMAIL PROTECTED] said:
What do you guys think about that? Am I totally missing something
that makes the Linux way right/ok? (no locking on a 64bit struct)
Generally, it's better to design an optimistic or non-blocking
algorithm rather
fred Perlstein
Sent: Wednesday, March 29, 2000 10:25 PM
To: Mike Smith
Cc: Matthew Dillon; [EMAIL PROTECTED]
Subject: Using packed structs to gain cheap SMP primatives
* Mike Smith [EMAIL PROTECTED] [000329 17:03] wrote:
For the single-process (1-fork) case, syscall overhead improved
To: Alfred Perlstein; Mike Smith
Cc: Matthew Dillon; [EMAIL PROTECTED]
Subject: RE: Using packed structs to gain cheap SMP primatives
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB"
* Allen Pulsifer [EMAIL PROTECTED] [000329 21:05] wrote:
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
order that nothing has changed. For example, to read a
structure
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
* Allen Pulsifer [EMAIL PROTECTED] [000329 21:05] wrote:
Here's another alternative for reading structures like time
that always change monotonically: read the values in
"MSB" to "LSB" order, then go back and check in reverse
* Jonathan Lemon [EMAIL PROTECTED] [000329 21:52] wrote:
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
I'm aware of this, the problem is that tz may move in either
direction. Hence my question about using sizes that are machine
atomic for read/write. :)
I've got
I get to still claim credit,
but it will have been due to the sequential write heuristic instead of
the SMP stuff :-)
-Matt
Matthew Dillon
[EMAIL PROTECTED
: 4696.987u 1502.278s 1:10:34.17 146.4% 1359+1641k 10889+4270io 1779pf+0w
:
:Can I ask why is there a huge difference in the number of io (251k vs 4k)?
:What is so different between 4.0 and 5.0 that causes this?
:
:--
:
:Andy Farkas
Ha! I found it. Kirk gets the credit ---
Matthew Dillon wrote:
: time make -j 20 buildworld build FreeBSD-current using 4.0 kernel
:
: 4745.607u 1673.646s 1:29:07.45 120.0% 1323+1599k 8237+251565io 1615p
f+0w
:
: time make -j 20 buildworld build FreeBSD-current using 5.0 kernel
:
: 4696.987u 1502.278s
Yesterday I was looking at how Linux handles the gettimeofday stuff
without locking thier sys_tz variable, well it seems they don't care
or I'm missing something important.
They just don't lock it, not that settimeofday will be called all that
often but it leaves me wondering what we can
In message [EMAIL PROTECTED], Mike Smith writes:
Yesterday I was looking at how Linux handles the gettimeofday stuff
without locking thier sys_tz variable, well it seems they don't care
or I'm missing something important.
They just don't lock it, not that settimeofday will be called all
. astpending is now undefined (/usr/src/sys/kern/kern_sig.c:1168)
. some calls to get_mplock and rel_mplock are made without #define SMP
conditionnal compile in following modules:
kern_exec
kern_exit
kern_sig
kern_sync
mfs_vfsops
mem
trap
To Unsubscribe: send mail
:. astpending is now undefined (/usr/src/sys/kern/kern_sig.c:1168)
:
:. some calls to get_mplock and rel_mplock are made without #define SMP
: conditionnal compile in following modules:
:
: kern_exec
: kern_exit
: kern_sig
: kern_sync
: mfs_vfsops
: mem
: trap
Hoya!... ok, I'll
Hi,
Appears to boot OK, but then won't answer to network or console, not even
CtlAltEsc to DDB. Screen saver kicks in OK though.
--
Bob Bishop (0118) 977 4017 international code +44 118
[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK
To Unsubscribe:
:Hi,
:
:Appears to boot OK, but then won't answer to network or console, not even
:CtlAltEsc to DDB. Screen saver kicks in OK though.
:
:--
:Bob Bishop (0118) 977 4017 international code +44 118
:[EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK
Make sure
:. astpending is now undefined (/usr/src/sys/kern/kern_sig.c:1168)
:
:. some calls to get_mplock and rel_mplock are made without #define SMP
: conditionnal compile in following modules:
:
: kern_exec
: kern_exit
: kern_sig
: kern_sync
: mfs_vfsops
: mem
: trap
Ok, should be fixed
At 09:52 -0800 28/3/00, Matthew Dillon wrote:
Make sure you haven't confused it between the patch set and the
commit I made last night. Do a cvs update and then a cvs diff to
make sure things haven't gotten confused.
Just blew /sys away and checked it out afresh. Same result I'm
:At 09:52 -0800 28/3/00, Matthew Dillon wrote:
:Make sure you haven't confused it between the patch set and the
:commit I made last night. Do a cvs update and then a cvs diff to
:make sure things haven't gotten confused.
:
:Just blew /sys away and checked it out afresh. Same result
I just noticed something with a new kernel with a Fresh world as of 1
hour ago. I'm running 2 setiathome's one for each CPU (Pentium pro)
and the machine has suddenly turned into a slug
It's worse than a 286 machine I used to own.
It's amazing !!!
It worked with this setup before the changes
The SMP patch (#7) will be going into -current tonight with Jordan's
approval. After I make minor corrections to the patch (which is actually
based off of 4.x).
I'm pretty comfortable with it in -current and think in a week or two
we can MFC it into 4.x, which will allow
On Fri, 24 Mar 2000, Matthew Dillon wrote:
Patch 04 is ready.
http://www.backplane.com/FreeBSD4/
http://www.backplane.com/FreeBSD4/smp-patch-04.diff
Contains lots of cleanup of stale SMP code. There are still a few places
where get_mplock is being called
:Otherwise right now your guess is as good as mine.
:
:As a side note, it seems silly that we do this:
:
:MPLOCKED incl _cnt+V_SYSCALL
:SYSCALL_LOCK
:call_syscall
:
:I think per-cpu statistics would be an interesting optimization,
:since you're testing all of this,
smp-patch-06 is now ready.
http://www.backplane.com/FreeBSD4/
http://www.backplane.com/FreeBSD4/smp-patch-06.diff
Bruce, I'd appreciate a quick review of my solution to the AST issue.
Search for 'syscall_ast_exit' in i386/i386/exception.s after patching.
I
A preliminary BGL patch is now on my site, relative to RELENG_4.
http://www.backplane.com/FreeBSD4/
It is the smp-patch-03.diff item at the end of the first section.
My test box successfully built the world. I know I'm probably missing
something, but so far I can't
Umm... ok, some people seem to be enthusiastic but I really recommend
that ONLY experts mess around with this patch until they sign off on
its properness (or suggest fixes for improperness).
This is not a 'normal Matt patch' that 'just works'. Ok, it seems to
just work, but
At 10:01 AM -0800 3/24/00, Matthew Dillon wrote:
This is not a 'normal Matt patch' that 'just works'. Ok, it seems to
just work, but it's not a normal Matt patch. If there were a
designation before 'early alpha' this patch would get it.
"Rough-draft proposal for early alpha
* Matthew Dillon [EMAIL PROTECTED] [000324 10:23] wrote:
A preliminary BGL patch is now on my site, relative to RELENG_4.
http://www.backplane.com/FreeBSD4/
It is the smp-patch-03.diff item at the end of the first section.
My test box successfully built the world. I
At 2:57 PM -0500 2000/3/24, Garance A Drosihn wrote:
At 10:01 AM -0800 3/24/00, Matthew Dillon wrote:
This is not a 'normal Matt patch' that 'just works'. Ok, it seems to
just work, but it's not a normal Matt patch. If there were a
designation before 'early alpha' this patch
readable and the doreti picture is becoming much
clearer. I think, at worst, I may be missing an AST check there.
I have created a document outlining a 'new' SMP mechanism proposal,
with emphasis on the interrupt handling (keep in mind that most
interrupts will be synchronously
Patch 04 is ready.
http://www.backplane.com/FreeBSD4/
http://www.backplane.com/FreeBSD4/smp-patch-04.diff
Contains lots of cleanup of stale SMP code. There are still a few places
where get_mplock is being called with interrupts disabled which I haven't
found, so I put
sometimes knows what he is doing)?
-current comes with all the usual `not for production use' caveats,
and (without any slur on Doug Rabson, who's doing the work), you'd
be very game taking FreeBSD's first cut at Alpha/SMP and putting it
into production.
On the other hand, a uniprocessor
Hello!
Will the -current version of FreeBSD run on a multi-CPU axp machine and
use all of the CPUs? Would that be a reliable box (assuming the admin
sometimes knows what he is doing)? Do I want to make a "production"
server out of an axp box at all in the near future? Thanks!
comes with all the usual `not for production use' caveats,
and (without any slur on Doug Rabson, who's doing the work), you'd
be very game taking FreeBSD's first cut at Alpha/SMP and putting it
into production.
Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cu
Hi,
I'm using a FreeBSD-current snapshot from 3rd January 2000. It seems
that in order to enable APICs (option APIC_IO in kernel configuration file),
one needs to also compile the kernel with SMP support (option SMP in kernel
configuration file). While enabling the APIC is desirable even
Hi there,
... I have an SMP-box (dual PPro, Natoma, mptable output attached) running
-current (with src/sys/dev/sym/sym_hipd.c,v 1.4 2000/01/08 19:58:17)
from around 2000/01/22.
The machine was running a 'ca. mid 1999' -current/SMP happily
for the last few months. I did the upgrade
I've had reports that a machine having USB compiled into an SMP kernel
panics. Could someone try the current version of the kernel and see what
that brings. Don't plug in any device, that will panic your system for
sure (I am working on that one).
If init of the OHCI driver fails it should now
I have a Dell PowerEdge 1300 with dual Pentium II / 400mhz processors
installed. However, upon installing today's snapshot of 4.0, the dmesg
output doesn't seem to detect the second processor. I wonder if there
is a problem here, or if I might have a hardware issue.
Thx.
To Unsubscribe:
might have a hardware issue.
|
Did you config/install a custom kernel? I don't think SMP is on by default.
-
Mike Heffner [EMAIL PROTECTED]
Fredericksburg, VA
ICQ# 882073
Date: 23-Jan-2000 Time: 23:39:58
-
To Unsubscribe: send
701 - 800 of 933 matches
Mail list logo
