My wish list for 6.1
Scott Long
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
> 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
>
> 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
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
> 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
> 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
> 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
> > 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
> 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
> 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
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
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
> 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
> 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
> > 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
> 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
> 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
>
> > 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
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
> 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
> 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
> 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
> > 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
> > 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
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
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
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
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
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
>
> 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
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
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
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
>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
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
>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
Kris Kennaway, and lo! it spake thus:
>
> 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
>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
Kris Kennaway, and lo! it spake thus:
> >
> >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.
>
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
> 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...
>
Arne
Charles Sprickman
> 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
- 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
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
> 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
On Fri, 16 Dec 2005, 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?
This is an old thread that I'm just catching up on, but I figured I'd chime in
anyway: you have to be really careful benchmarking across CPU types and
configurations, as the performance characteristics of important insturctions
differ a lot across hardware variations. For example, the performance of
atomic operations, used to synchronize between CPUs, varies significantly by
CP, bus configuration, etc. On modern opteron hardware, the performance of
inter-CPU synchronization instructions is blindingly fast. On modern Xeon P4
hardware, it is incredibly slow. Software optimized for the Opteron will
often perform much slower on Xeon P4 hardware as a result. P3 hardware tends
to behave a lot more like Opteron in terms of speed of insturctions relating
to disabling interrupts, where on P4 Xeon they are proprtionally much slower.
The critical section optimizations made by John Baldwin, and the movement to
critical sections in UMA and kernel malloc that I made, made a big performance
difference on Xeon P4 hardware, but relatively little difference on Opteron.
All this seems to suggest that when comparing UP and SMP, it's useful to do it
on nice opteron hardware, but also on P4 Xeon to prevent making decisions
based on platform-specific properties.
Robert N M Watson
Martin Cracauer
>
> On Fri, 16 Dec 2005, 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?
>
> This is an old thread that I'm just catching up on, but I figured I'd chime in
> anyway: you have to be really careful benchmarking across CPU types and
> configurations, as the performance characteristics of important insturctions
> differ a lot across hardware variations. For example, the performance of
> atomic operations, used to synchronize between CPUs, varies significantly by
> CP, bus configuration, etc. On modern opteron hardware, the performance of
> inter-CPU synchronization instructions is blindingly fast. On modern Xeon P4
> hardware, it is incredibly slow.
Well, my runs included P4s and P4-based Xeons, and hyperthreading,
too.
The core of the problem here is that while my parallel benchmarks are
partly system-call exercising, I use apache over localhost and
zero-spaced files to get the disk and network out of the equitation.
I think I have a solid framework in place to run parallel benchmarks
and see the tradeoffs involved, but I need to fill it with activity
that exercises what we want to see.
Still, I bet that my measurements are good enough to label the SMP
kernel "defaultable" for FreeBSD installations, from a performance
standpoint. After all, I *do* test parallel activity, CPU-intensive
and systemcall-intensive and various mixes thereof.
Remember that those people who do a lot of parallel activity and hence
would suffer from the additional locks in the SMP kernel are very
likely to have a SMP system, dual-cores or at least hyperthreading in
first place. On the other hand, people who use very low-end hardware
to do demanding tasks are very likely to build their own kernel
anyway.
> Software optimized for the Opteron will
> often perform much slower on Xeon P4 hardware as a result. P3 hardware tends
> to behave a lot more like Opteron in terms of speed of insturctions relating
> to disabling interrupts, where on P4 Xeon they are proprtionally much slower.
> The critical section optimizations made by John Baldwin, and the movement to
> critical sections in UMA and kernel malloc that I made, made a big performance
> difference on Xeon P4 hardware, but relatively little difference on
> Opteron.
One thing I noticed is that anything P4-based is very sensitive to
spinlocks being placed on the same cache line as the data it protects.
Putting a lock into a struct without cache-line crossing padding means
doom for the P4-based/netburst CPUs (I'm sure it's not a good thing
for Opterons either but they don't seem to mind that much).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/