My wish list for 6.1

1 view
Skip to first unread message

Scott Long

unread,
Dec 16, 2005, 2:42:51 AM12/16/05
to
Guys,

With code freeze for 6.1 about 6 weeks away, I'd like to put out my
'wish list' for it:

1. working kbdmux. We need this for the growing number of systems that
assume that USB is the primary keyboard. Current status appears to be
that the kbdmux driver breaks very easily. We need this working well
enough where it can be enabled by default, and all attached keyboards
Just Work.

2. SMP kernels for install. Right now we only install a UP kernel, for
performance reasons. We should be able to package both a UP and SMP
kernel into the release bits, and have sysinstall install both. It
should also select the correct one for the target system and make that
the default on boot. The easiest way to do this would be to have
sysinstall boot an SMP kernel and then look at the hw.ncpu sysctl. The
only problem is being able to have sysinstall fall back to booting a UP
kernel for itself if the SMP one fails. This can probably be 'faked' by
setting one of the SMP-disabling variables in the loader. But in any
case, the point is to make the process Just Work for the user, without
the user needing to know arcane loader/sysctl knobs. SMP laptops are
right around the corner, and we should be ready to support SMP
out-of-the-box.

3. Full review and update of the install docs, handbook, FAQ, etc.
There are sections that are embarrassingly out of date (one section of
the handbook apparently states that we only support a single brand of
wifi cards). A co-worker of mine tried to install 6.0 using just the
handbook install guide, and discovered that it really doesn't match
reality anymore, in both big and small ways. Contact me directly if
you would like his list of comments.

Thanks!

Scott
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

Alexander Leidinger

unread,
Dec 16, 2005, 5:05:24 AM12/16/05
to
Scott Long <sco...@samsco.org> wrote:

> Guys,
>
> With code freeze for 6.1 about 6 weeks away, I'd like to put out my
> 'wish list' for it:

What about putting 1. and 3. on the new ideas page (marked as important and
including a deadline)? At least for 3. more eyes would be beneficial.

> 1. working kbdmux. We need this for the growing number of systems that
> assume that USB is the primary keyboard. Current status appears to be
> that the kbdmux driver breaks very easily. We need this working well
> enough where it can be enabled by default, and all attached keyboards
> Just Work.

> 3. Full review and update of the install docs, handbook, FAQ, etc.

> There are sections that are embarrassingly out of date (one section of
> the handbook apparently states that we only support a single brand of
> wifi cards). A co-worker of mine tried to install 6.0 using just the
> handbook install guide, and discovered that it really doesn't match
> reality anymore, in both big and small ways. Contact me directly if
> you would like his list of comments.

Bye,
Alexander.

--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
BOFH excuse #130:

new management

Martin Cracauer

unread,
Dec 16, 2005, 10:40:22 AM12/16/05
to
Scott Long wrote on Fri, Dec 16, 2005 at 12:42:51AM -0700:
>
> 2. SMP kernels for install. Right now we only install a UP kernel, for
> performance reasons. We should be able to package both a UP and SMP
> kernel into the release bits, and have sysinstall install both. It
> should also select the correct one for the target system and make that
> the default on boot.

If people are concerned about performance, I benchmarked a 6-beta
kernel SMP versus UP on a socket 939 Opteron.

The performance characteristic for the parallel tests with CPU-eaters
and plain http streams in the background is different.

But there certainly is no slowdown that would make us look bad when
people use a SMP kernel on a one-processor machine.

CPU time results:
http://www.cons.org/cracauer/crabench/smpkernel.user.html

Wall clock time results:
http://www.cons.org/cracauer/crabench/smpkernel.wall.html

General benchmark homepage (lots of AMD64 and memory benchmarking there):
http://cracauer-forum.cons.org/forum/crabench.html

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/

Xin LI

unread,
Dec 16, 2005, 1:22:36 PM12/16/05
to
Hi, Scott,

On 12/16/05, Scott Long <sco...@samsco.org> wrote:
> Guys,
>
> With code freeze for 6.1 about 6 weeks away, I'd like to put out my
> 'wish list' for it:

More-or-less OT question: Shall we switch ULE as the default scheduler
on -HEAD to encourage more testing against it?

Cheers,
--
Xin LI <del...@delphij.net> http://www.delphij.net

Scott Long

unread,
Dec 16, 2005, 1:24:58 PM12/16/05
to
Xin LI wrote:

> Hi, Scott,
>
> On 12/16/05, Scott Long <sco...@samsco.org> wrote:
>
>>Guys,
>>
>>With code freeze for 6.1 about 6 weeks away, I'd like to put out my
>>'wish list' for it:
>
>
> More-or-less OT question: Shall we switch ULE as the default scheduler
> on -HEAD to encourage more testing against it?
>
> Cheers,

Only if there is someone committed to tracking and fixing bugs. Last
time we tried this, we wasted a lot of time and energy.

Eric Anderson

unread,
Dec 16, 2005, 2:55:22 PM12/16/05
to
Scott Long wrote:

> Guys,
>
> With code freeze for 6.1 about 6 weeks away, I'd like to put out my
> 'wish list' for it:
>
> 1. working kbdmux. We need this for the growing number of systems that
> assume that USB is the primary keyboard. Current status appears to be
> that the kbdmux driver breaks very easily. We need this working well
> enough where it can be enabled by default, and all attached keyboards
> Just Work.


FWIW, I've been using this for months, on a box that I've rolled from 5,
to 6 (when I started using it), and now 7 (although outdated now). It's
been running perfectly, and until now I forgot I was using it. I'm
using it so my machine has a ps/2 keyboard on boot for BIOS and loader
screens, but then has my usb keyboard normally. I just leave the ps/2
kb on top of the system, since it doesn't reboot much.

Maksim, thanks for the hard work on it so far!

Eric


--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------

Kris Kennaway

unread,
Dec 16, 2005, 3:02:38 PM12/16/05
to
On Sat, Dec 17, 2005 at 02:22:36AM +0800, Xin LI wrote:
> Hi, Scott,
>
> On 12/16/05, Scott Long <sco...@samsco.org> wrote:
> > Guys,
> >
> > With code freeze for 6.1 about 6 weeks away, I'd like to put out my
> > 'wish list' for it:
>
> More-or-less OT question: Shall we switch ULE as the default scheduler
> on -HEAD to encourage more testing against it?

No, it's already known to have stability problems (on large SMP
machines) and performance problems under load (about 10-20% slower
than 4BSD), so until someone fixes those there's no point.

Kris

Avleen Vig

unread,
Dec 17, 2005, 1:34:09 AM12/17/05
to
On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote:
> > 2. SMP kernels for install. Right now we only install a UP kernel, for
> > performance reasons. We should be able to package both a UP and SMP
> > kernel into the release bits, and have sysinstall install both. It
> > should also select the correct one for the target system and make that
> > the default on boot.
>
> If people are concerned about performance, I benchmarked a 6-beta
> kernel SMP versus UP on a socket 939 Opteron.

If those results are accurate, there's no real reason not to just use an
SMP kernel on default install?

Kris Kennaway

unread,
Dec 17, 2005, 3:01:09 AM12/17/05
to
On Fri, Dec 16, 2005 at 10:34:09PM -0800, Avleen Vig wrote:
> On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote:
> > > 2. SMP kernels for install. Right now we only install a UP kernel, for
> > > performance reasons. We should be able to package both a UP and SMP
> > > kernel into the release bits, and have sysinstall install both. It
> > > should also select the correct one for the target system and make that
> > > the default on boot.
> >
> > If people are concerned about performance, I benchmarked a 6-beta
> > kernel SMP versus UP on a socket 939 Opteron.
>
> If those results are accurate, there's no real reason not to just use an
> SMP kernel on default install?

Just because it didn't manifest on this workload, doesn't mean it
doesn't on others. I think this is the point :)

Kris

Allen

unread,
Dec 17, 2005, 3:55:00 AM12/17/05
to
On 12/17/2005 01:34:09 AM, Avleen Vig wrote:
> On Fri, Dec 16, 2005 at 10:40:22AM -0500, Martin Cracauer wrote:
> > > 2. SMP kernels for install. Right now we only install a UP
> kernel, for
> > > performance reasons. We should be able to package both a UP and
> SMP
> > > kernel into the release bits, and have sysinstall install both.
> It
> > > should also select the correct one for the target system and make
> that
> > > the default on boot.
> >
> > If people are concerned about performance, I benchmarked a 6-beta
> > kernel SMP versus UP on a socket 939 Opteron.

Must be great having boxes like that ;) You know what I'd like to see
in the next Free BSD? A way to update security fixes without having to
play with any source, or having to touch make world. I know the speed
and so on makes some people like this, but I personally try getting
people who use Windows to switch to another OS or at least show them
something else exists, and it's hard to make someone want to use Free
BSD when installing patches can be such a timely manner.

I know about the port tool, but what I'd love to have is a tool you
could run from the CLI or the GUI that would check for updates, and
then ask which ones to install, similar to Swaret on Slackware. This
way people can do the usual updates if they want, and people like me
can show people BSD and how great it is.

> If those results are accurate, there's no real reason not to just use
> an
> SMP kernel on default install?
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers

> To unsubscribe, send any mail to "freebsd-hackers-
> unsub...@freebsd.org"

Christian Brueffer

unread,
Dec 17, 2005, 3:55:17 AM12/17/05
to

You probably haven't seen ports/security/freebsd-update yet.

See http://www.daemonology.net/freebsd-update/ for more information.

- Christian

--
Christian Brueffer ch...@unixpages.org brue...@FreeBSD.org
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D

Allen

unread,
Dec 17, 2005, 5:37:20 AM12/17/05
to

Actually, I've seen that and it does come close... But it didn't seem to like
updating the Kernel or anything similar to the base system in the time I
spent with it.

Free BSD has probably one of the best methods of installing new packages with
pkg_add, and pkg_add -r for grabbing them off the internet but for updates it
could use some work.

It won't stop me from buying Free BSD things, but it does make showing new
computer users the OS a but harder.
OT: If anyone wants a person to couge, the Free BSD boxers are VERY high
quality and, it must be said, a pair of boxers any BOFH would wear. They look
great with my Free BSD TeeShirt and Laptop covered in BSD stickers. :)


> - Christian
-Allen

David O'Brien

unread,
Dec 18, 2005, 4:08:41 AM12/18/05
to
On Fri, Dec 16, 2005 at 12:42:51AM -0700, Scott Long wrote:
> SMP laptops are
> right around the corner, and we should be ready to support SMP
> out-of-the-box.

Already here - Alienware Aurora m7700 Athlon X2 dual-core.
http://www.alienware.com/product_detail_pages/Aurora_m7700/aurora-m_features.aspx?SysCode=PC-LT-AURORA-M-7700&SubCode=SKU-DEFAULT

--
-- David (obr...@FreeBSD.org)

Dirk GOUDERS

unread,
Dec 19, 2005, 4:34:23 AM12/19/05
to

> 3. Full review and update of the install docs, handbook, FAQ, etc.
> There are sections that are embarrassingly out of date (one section of
> the handbook apparently states that we only support a single brand of
> wifi cards). A co-worker of mine tried to install 6.0 using just the
> handbook install guide, and discovered that it really doesn't match
> reality anymore, in both big and small ways. Contact me directly if
> you would like his list of comments.

I am wondering if it wouldn't be advantageous to have "versioned"
documents that just cover one specific release and not to cover all
realeases in single documents.

I could imagine that it is harder to cover everything in single
documents than to perhaps copy the existing documentation when a new
branch is created and edit it to match just the new release.

Maybe, I do not realize how much more work this would be but it would
probably enforce regular reviews of the documentation and the readers
would benefit from it.

Dirk

Allen

unread,
Dec 19, 2005, 5:58:12 AM12/19/05
to
On Monday 19 December 2005 04:34, Dirk GOUDERS wrote:
> > 3. Full review and update of the install docs, handbook, FAQ, etc.
> > There are sections that are embarrassingly out of date (one section of
> > the handbook apparently states that we only support a single brand of
> > wifi cards). A co-worker of mine tried to install 6.0 using just the
> > handbook install guide, and discovered that it really doesn't match
> > reality anymore, in both big and small ways. Contact me directly if
> > you would like his list of comments.


The install docs really could use some updating. However I've written this
little tutorial for AntiOnline on installing it, and I don't think anyone has
ever made it easier, and yes I am quite proud of it :)

http://www.antionline.com/showthread.php?s=&threadid=259335

You don't need to sign up to read this so check it out if you'd like. I've
posted this tutorial to the docs mailing list before and everyone loved it.
I'd have no problem doing a similar one for the 6X series so I should be able
to soon.

Written on a Linux box while wearing a Free BSD shirt with a monitor that has
Free BSD stickers ;) I use both and don't flame!

Dirk GOUDERS

unread,
Dec 19, 2005, 6:05:25 AM12/19/05
to

> On Monday 19 December 2005 04:34, Dirk GOUDERS wrote:

Well, I did not write the quoted text, but Scott Long did.

Dirk

Ceri Davies

unread,
Dec 20, 2005, 9:14:24 AM12/20/05
to
On Sat, Dec 17, 2005 at 05:37:20AM -0500, Allen wrote:
> On Saturday 17 December 2005 03:55, Christian Brueffer wrote:
> > On Sat, Dec 17, 2005 at 08:55:00AM +0000, Allen wrote:

> > > I know about the port tool, but what I'd love to have is a tool you
> > > could run from the CLI or the GUI that would check for updates, and
> > > then ask which ones to install, similar to Swaret on Slackware. This
> > > way people can do the usual updates if they want, and people like me
> > > can show people BSD and how great it is.
> >
> > You probably haven't seen ports/security/freebsd-update yet.
>
> Actually, I've seen that and it does come close... But it didn't seem to like
> updating the Kernel or anything similar to the base system in the time I
> spent with it.

Look harder; those are the *only* things it will update. This is not
portupgrade.

Ceri
--
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former. -- Einstein (attrib.)

Ceri Davies

unread,
Dec 20, 2005, 9:22:54 AM12/20/05
to
On Mon, Dec 19, 2005 at 10:34:23AM +0100, Dirk GOUDERS wrote:
>
> > 3. Full review and update of the install docs, handbook, FAQ, etc.
> > There are sections that are embarrassingly out of date (one section of
> > the handbook apparently states that we only support a single brand of
> > wifi cards). A co-worker of mine tried to install 6.0 using just the
> > handbook install guide, and discovered that it really doesn't match
> > reality anymore, in both big and small ways. Contact me directly if
> > you would like his list of comments.
>
> I am wondering if it wouldn't be advantageous to have "versioned"
> documents that just cover one specific release and not to cover all
> realeases in single documents.
>
> I could imagine that it is harder to cover everything in single
> documents than to perhaps copy the existing documentation when a new
> branch is created and edit it to match just the new release.
>
> Maybe, I do not realize how much more work this would be but it would
> probably enforce regular reviews of the documentation and the readers
> would benefit from it.

This is exactly the idea that I have been pimping to anyone who will
listen for the last three months or so. I also think that it is
advantageous for users who are using, say 4.2, to be able to find
documentation for 4.2 without having to interpret a nest of "if you have
4.x do this, if 5.0 through 5.3 do that, else do the other". I don't
think it's a lot of work to just branch the handbook (and FAQ
if we decide to keep it) - in fact, for me, it would be a definite win -
at release time, but it just doesn't seem to be what other people want
done.

I would encourage those interested to ask about it on doc@.

Joel Dahl

unread,
Dec 20, 2005, 9:46:53 AM12/20/05
to

Yep, I really like this. The current mess is impossible to maintain
(and also impossible to read). Yesterday I tried to update the kernel
configuration chapter to cover 6.0, but I gave up since there are "do
this for 4.X, do that for 5.X, and maybe this too for 6.X" everywhere.

--
Joel - joel at FreeBSD dot org

Dirk GOUDERS

unread,
Dec 20, 2005, 10:33:32 AM12/20/05
to

> This is exactly the idea that I have been pimping to anyone who will
> listen for the last three months or so. I also think that it is
> advantageous for users who are using, say 4.2, to be able to find
> documentation for 4.2 without having to interpret a nest of "if you have
> 4.x do this, if 5.0 through 5.3 do that, else do the other". I don't
> think it's a lot of work to just branch the handbook (and FAQ
> if we decide to keep it) - in fact, for me, it would be a definite win -
> at release time, but it just doesn't seem to be what other people want
> done.

I would like to add that I could imagine that it would be easier for
authors to just change/add some documentation that matches the target
release and not to have to think about "if version=something else ..."
constructs.

Also, sometimes it is good to be able to just throw away things that
are out-of-date.

> I would encourage those interested to ask about it on doc@.

Well, I would be surprised if that hasn't already been discussed.
Have to search the archives...

Dirk

Dirk GOUDERS

unread,
Dec 20, 2005, 10:51:09 AM12/20/05
to

> Yep, I really like this. The current mess is impossible to maintain
> (and also impossible to read). Yesterday I tried to update the kernel
> configuration chapter to cover 6.0, but I gave up since there are "do
> this for 4.X, do that for 5.X, and maybe this too for 6.X" everywhere.

Seems as if my imagination was correct ;-)

By the way, I tried to search the archive (doc@) for a possible
earlier discussion of this subject but have a hard time to find proper
words to search for...

Dirk

Ceri Davies

unread,
Dec 20, 2005, 11:01:24 AM12/20/05
to
On Tue, Dec 20, 2005 at 03:46:53PM +0100, Joel Dahl wrote:
> On Tue, 2005-12-20 at 14:22 +0000, Ceri Davies wrote:

> > This is exactly the idea that I have been pimping to anyone who will
> > listen for the last three months or so. I also think that it is
> > advantageous for users who are using, say 4.2, to be able to find
> > documentation for 4.2 without having to interpret a nest of "if you have
> > 4.x do this, if 5.0 through 5.3 do that, else do the other". I don't
> > think it's a lot of work to just branch the handbook (and FAQ
> > if we decide to keep it) - in fact, for me, it would be a definite win -
> > at release time, but it just doesn't seem to be what other people want
> > done.
>
> Yep, I really like this. The current mess is impossible to maintain
> (and also impossible to read). Yesterday I tried to update the kernel
> configuration chapter to cover 6.0, but I gave up since there are "do
> this for 4.X, do that for 5.X, and maybe this too for 6.X" everywhere.

Yes, that's my major concern. I find working on the current documents
too difficult.

Joel Dahl

unread,
Dec 21, 2005, 6:44:37 AM12/21/05
to
On Tue, 2005-12-20 at 16:51 +0100, Dirk GOUDERS wrote:
> > Yep, I really like this. The current mess is impossible to maintain
> > (and also impossible to read). Yesterday I tried to update the kernel
> > configuration chapter to cover 6.0, but I gave up since there are "do
> > this for 4.X, do that for 5.X, and maybe this too for 6.X" everywhere.
>
> Seems as if my imagination was correct ;-)
>
> By the way, I tried to search the archive (doc@) for a possible
> earlier discussion of this subject but have a hard time to find proper
> words to search for...

http://lists.freebsd.org/pipermail/freebsd-doc/2005-October/009027.html

:-)

--
Joel - joel at FreeBSD dot org

_______________________________________________

Dirk GOUDERS

unread,
Dec 21, 2005, 8:08:15 AM12/21/05
to

> > By the way, I tried to search the archive (doc@) for a possible
> > earlier discussion of this subject but have a hard time to find proper
> > words to search for...
>
> http://lists.freebsd.org/pipermail/freebsd-doc/2005-October/009027.html

Thanks! Well, seems as if some people's heads are already working on this
subject...

Dirk

Juhana Tahvanainen

unread,
Dec 21, 2005, 11:01:37 AM12/21/05
to

how about:

FreeBSD-Handbook-General (guaranteed to work with all FreeBSD systems,
doesn't include stuff in FreeBSD-Handbook-BRANCH.x)

FreeBSD-Handbook-4.x (guaranteed to work with 4.x branch, doesn't include
stuff in FreeBSD-Handbook-General)

FreeBSD-Handbook-5.x (guaranteed to work with 5.x branch, doesn't include
stuff in FreeBSD-Handbook-General)

FreeBSD-Handbook-6.x (guaranteed to work with 6.x branch, doesn't include
stuff in FreeBSD-Handbook-General)

...

this way layered information is minimalized and there is clear path to
find something out.

FreeBSD-Handbook-General is rather fixed once ready, only maintenance
needed is when some future release doesnt support something anymore, that
is removed and moved to FreeBSD-Handbook-BRANCH.x.

FreeBSD-Handbook-BRANCH.x deals with branch in case from installation to
use, having links to FreeBSD-Handbook-General when needed.
FreeBSD-Handbook-BRANCH.x can also have real-life examples and comments,
so need for FAQ should be covered.

dunno if that is any more clear but what there is out there now, is a
mess.


---J

Matthew D. Fuller

unread,
Dec 21, 2005, 8:47:40 PM12/21/05
to
On Wed, Dec 21, 2005 at 06:01:37PM +0200 I heard the voice of
Juhana Tahvanainen, and lo! it spake thus:
>
> how about:

>
> FreeBSD-Handbook-General is rather fixed once ready, only
> maintenance needed is when some future release doesnt support
> something anymore, that is removed and moved to
> FreeBSD-Handbook-BRANCH.x.

Difficult to manage. You have to remember or know which branches to
backport stuff to, and you can't then say "OK, we won't bother with
3.x anymore, but Handbook-3.x will remain around not needing further
work for people using it", as future changes might not get pushed
back.

It would probably be easier using something like marked sections in a
single handbook to separate out version-specific stuff from more
general stuff; that way, at least it's all in one place, and you could
just generate handbooks for any given branch off one source. Of
course, it can get ugly to look at, too..


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

Juhana Tahvanainen

unread,
Dec 22, 2005, 7:31:29 AM12/22/05
to

i think you got this one wrong.

what FreeBSD-Handbook-General should include:

everything that spans through all FreeBSD releases i.e.

# rm -rf /

(that is guaranteed to work in all FreeBSD systems)

but if some future release stops supporting this, then its removed from
FreeBSD-Handbook-General and moved to FreeBSD-Handbook-BRANCH.x (to all
branches that supports this).


---J

Martin Cracauer

unread,
Dec 22, 2005, 5:33:08 PM12/22/05
to

I tried to model different worklods. The parallel part of my
benchmark suite has CPU-heavy processes, short plain http, php, long
plain http and mixtures thereof.

None of these showed the SMP kernel to be an overall disadvantage on a
one-processor system.

However, the tradeoffs are different. The SMP kernel further
increases the tendency that FreeBSD had all along to give CPU eaters
more resources, disk and network I/O less, compared to Linux.

Whether this is good or bad is open for discussion. From a traffic
control standpoint you can both argue that it is better to get the CPU
demands out of the way instead of getting more I/O done only to have
the I/Oing processes then pile up in the already overcrowded
CPU-demanding corner - and you can argue that you should get I/O done
ASAP so that the I/O-initiating process doesn't hang around
neccessaryily long.

This is for both schedulers. I don't think this tendency is directly
caused by the scheduler, it is probably the I/O subsystems coercing
the scheduler, not the other way round.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/

Ceri Davies

unread,
Dec 23, 2005, 10:41:42 AM12/23/05
to

On 21 Dec 2005, at 16:01, Juhana Tahvanainen wrote:

>
> how about:
>
> FreeBSD-Handbook-General (guaranteed to work with all FreeBSD
> systems, doesn't include stuff in FreeBSD-Handbook-BRANCH.x)
>
> FreeBSD-Handbook-4.x (guaranteed to work with 4.x branch, doesn't
> include stuff in FreeBSD-Handbook-General)
>
> FreeBSD-Handbook-5.x (guaranteed to work with 5.x branch, doesn't
> include stuff in FreeBSD-Handbook-General)
>
> FreeBSD-Handbook-6.x (guaranteed to work with 6.x branch, doesn't
> include stuff in FreeBSD-Handbook-General)

FreeBSD-Handbook-General is basically what we have now, and it sucks
to maintain.

Seriously though, all the interested people are on doc@; this
discussion should be moved there.

Ceri

Kris Kennaway

unread,
Dec 23, 2005, 9:05:47 PM12/23/05
to
Martin Cracauer wrote:

>
> I tried to model different worklods. The parallel part of my
> benchmark suite has CPU-heavy processes, short plain http, php, long
> plain http and mixtures thereof.
>
> None of these showed the SMP kernel to be an overall disadvantage on a
> one-processor system.

What you want is to find a real-world workload that exercises a lot of
mutexes. These exist, and they'll see the most pessimization from
running SMP kernel on UP.

Kris

Sergey Babkin

unread,
Dec 25, 2005, 9:18:18 AM12/25/05
to

Hm, how about this (similar to what Linuxes do):

Use an SMP kernel for the installation boot, so that the install
scripts can discover the SMP machines.

Have two GENERIC kernels built and packaged, UP and SMP.

The install scripts then install the kernel matching the absent
or present SMP (like Linux distros do). Probably with an option of
a manual override through a menu. Maybe better yet, install both
(or allow to install both) and allow to choose the one booted
through a sysinstall menu.

-SB

Charles Sprickman

unread,
Dec 25, 2005, 1:46:15 PM12/25/05
to
I'm missing the start of the thread, so perhaps I can just cut in here.

I'm to the point at home and work where I've got more USB keyboards than
PS2. It seems like even my old boxes support getting into the BIOS and
everything via USB keyboards... You all know where I'm going... Whenever
I want to install FBSD, I have to dig up a clunky old PS2 keyboard. Not
the case with Winderz, NetBSD, OpenBSD, Linux, etc. In fact, I'm pretty
sure 4.11 can be installed with a USB keyboard. I may be imagining that
though...

Back to lurking,

C

Matthew D. Fuller

unread,
Dec 25, 2005, 5:04:47 PM12/25/05
to
On Sun, Dec 25, 2005 at 01:46:15PM -0500 I heard the voice of
Charles Sprickman, and lo! it spake thus:

>
> In fact, I'm pretty sure 4.11 can be installed with a USB keyboard.
> I may be imagining that though...

Well, I'm pretty sure I didn't imagine installing 6.0 last month with
a USB keyboard. Of course, the loader didn't grok it, but...


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

Kris Kennaway

unread,
Dec 25, 2005, 10:45:52 PM12/25/05
to
Matthew D. Fuller wrote:

>On Sun, Dec 25, 2005 at 01:46:15PM -0500 I heard the voice of
>Charles Sprickman, and lo! it spake thus:
>
>
>>In fact, I'm pretty sure 4.11 can be installed with a USB keyboard.
>>I may be imagining that though...
>>
>>
>
>Well, I'm pretty sure I didn't imagine installing 6.0 last month with
>a USB keyboard. Of course, the loader didn't grok it, but...
>
>

The loader groks it just fine when you choose the 'boot with USB
keyboard' boot menu option ;-)

Kris

Matthew D. Fuller

unread,
Dec 26, 2005, 4:22:01 AM12/26/05
to
On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of
Kris Kennaway, and lo! it spake thus:

>
> The loader groks it just fine when you choose the 'boot with USB
> keyboard' boot menu option ;-)

How can I choose a menu option in the loader when the keyboard doesn't
work in the loader? :p


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

Kris Kennaway

unread,
Dec 26, 2005, 9:27:58 AM12/26/05
to
Matthew D. Fuller wrote:

>On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of
>Kris Kennaway, and lo! it spake thus:
>
>
>>The loader groks it just fine when you choose the 'boot with USB
>>keyboard' boot menu option ;-)
>>
>>
>
>How can I choose a menu option in the loader when the keyboard doesn't
>work in the loader? :p
>
>

Perhaps a BIOS option. I've never encountered a system with USB
keyboard that did not work in the loader.

Kris

Matthew D. Fuller

unread,
Dec 26, 2005, 9:36:45 AM12/26/05
to
On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of

Kris Kennaway, and lo! it spake thus:
>
> Perhaps a BIOS option. I've never encountered a system with USB
> keyboard that did not work in the loader.

The "emulation" or whatever it was was set in the BIOS. And it worked
in the BIOS. Worked when the OS got up to sysinstall, too. Just
wouldn't work for the loader. Luckily, I didn't need to do anything
but wait for it to boot, but I figured the BIOS was laughing at me
behind my back...


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

Kris Kennaway

unread,
Dec 26, 2005, 9:58:23 AM12/26/05
to
Matthew D. Fuller wrote:

>On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of
>Kris Kennaway, and lo! it spake thus:
>
>
>>Perhaps a BIOS option. I've never encountered a system with USB
>>keyboard that did not work in the loader.
>>
>>
>
>The "emulation" or whatever it was was set in the BIOS. And it worked
>in the BIOS. Worked when the OS got up to sysinstall, too. Just
>wouldn't work for the loader. Luckily, I didn't need to do anything
>but wait for it to boot, but I figured the BIOS was laughing at me
>behind my back...
>
>

What happens if you turn it off?

Kris

Matthew D. Fuller

unread,
Dec 26, 2005, 10:06:37 AM12/26/05
to
On Tue, Dec 27, 2005 at 01:28:23AM +1030 I heard the voice of

Kris Kennaway, and lo! it spake thus:
> Matthew D. Fuller wrote:
> >
> >The "emulation" or whatever it was was set in the BIOS. And it
> >worked in the BIOS. Worked when the OS got up to sysinstall, too.
> >Just wouldn't work for the loader.
>
> What happens if you turn it off?

Then it still didn't work in the loader, and wouldn't work for the
BIOS either (so I had to plugin a PS/2 keyboard to turn it back on).
I don't think I let it boot long enough to see if the keyboard worked
in sysinstall in that case; I presume it would. And the system's in
production now, so I can't really fiddle with it anymore.

It's got a Biostar (blech!) Socket A motherboard.

ACPI APIC Table: <VKT400 AWRDACPI>
<http://www.biostar.com.tw/products/mainboard/board.php?name=M7VIG%20400%20(7.x)>


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

Arne Schwabe

unread,
Dec 27, 2005, 7:15:00 AM12/27/05
to
Matthew D. Fuller wrote:
> On Tue, Dec 27, 2005 at 12:57:58AM +1030 I heard the voice of
> Kris Kennaway, and lo! it spake thus:
>
>> Perhaps a BIOS option. I've never encountered a system with USB
>> keyboard that did not work in the loader.
>>
>
> The "emulation" or whatever it was was set in the BIOS. And it worked
> in the BIOS. Worked when the OS got up to sysinstall, too. Just
> wouldn't work for the loader. Luckily, I didn't need to do anything
> but wait for it to boot, but I figured the BIOS was laughing at me
> behind my back...
>
Same here with an ASUS A8V Deluxe.

Arne

Charles Sprickman

unread,
Dec 27, 2005, 1:17:31 PM12/27/05
to
On Tue, 27 Dec 2005, Kris Kennaway wrote:

> Matthew D. Fuller wrote:
>
>> On Mon, Dec 26, 2005 at 02:15:52PM +1030 I heard the voice of
>> Kris Kennaway, and lo! it spake thus:
>>
>>> The loader groks it just fine when you choose the 'boot with USB
>>> keyboard' boot menu option ;-)
>>>
>>
>> How can I choose a menu option in the loader when the keyboard doesn't
>> work in the loader? :p
>>
> Perhaps a BIOS option. I've never encountered a system with USB keyboard
> that did not work in the loader.

I'm going to be putting a few more workstations together in the next few
days, likely using PCBSD. I will twiddle every option and report back.

Charles

Ray Mihm

unread,
Dec 27, 2005, 2:36:08 PM12/27/05
to
My wishes are:
- Get MIPS arch working (plenty of MIPS based SoC in the market)
- NUMA support (see what Solaris did or is doing),
- Fold IMUNES changes in to the FreeBSD tree,
- rwlocks (has this been done already?),
- DDB MP support
- Make ULE default. Extend ULE to support per Jail CPU time slices
(Solaris does this already with zones - way too cool).
- native PCI-E support with QoS
- 802.11 support for VAP and Mesh Networks (already available?)
- make base (off-the-box) performance the best among all OSs.

Wish everyone a great 2006.

Ray.

Robert Huff

unread,
Dec 28, 2005, 9:06:21 AM12/28/05
to

Arne Schwabe writes:

> > The "emulation" or whatever it was was set in the BIOS. And it worked
> > in the BIOS. Worked when the OS got up to sysinstall, too. Just
> > wouldn't work for the loader. Luckily, I didn't need to do anything
> > but wait for it to boot, but I figured the BIOS was laughing at me
> > behind my back...
>
> Same here with an ASUS A8V Deluxe.

I have a similar problem with an ASUS P4<something> and possibly
a P3. However, I have been told (it's in the archives) this may be
a known problem with the BIOS/ASUS firmware,


Robert Huff

Martin Cracauer

unread,
Dec 28, 2005, 7:47:27 PM12/28/05
to
Kris Kennaway wrote on Sat, Dec 24, 2005 at 12:35:47PM +1030:
> Martin Cracauer wrote:
>
> >
> > I tried to model different worklods. The parallel part of my
> > benchmark suite has CPU-heavy processes, short plain http, php, long
> > plain http and mixtures thereof.
> >
> > None of these showed the SMP kernel to be an overall disadvantage on a
> > one-processor system.
>
> What you want is to find a real-world workload that exercises a lot of
> mutexes. These exist, and they'll see the most pessimization from
> running SMP kernel on UP.

Well, I would be thankful for some ideas.

I'd like to develop my benchmark suite from a pure hardware testing
platform into one which can be used to measure improvements in SMP
kernels.

However, I am fully aware that what I am doing now (CPU loaders, and
small and big http over localhost, make -j <x>) doesn't cut it.

If you want to keep hardware out of the loop, things become hairy.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/

Robert Watson

unread,
Dec 31, 2005, 2:12:23 AM12/31/05