headers
Tim Rightnour | 1 Nov 2007 18:35
Gravatar

RE: CVS commit: src/sys/arch/sandpoint/stand/netboot


On 30-Oct-2007 Tohru Nishimura wrote:
> major PCI rework to make possible NIC autoconf.  now bootloader
> can have multiple network interface device drivers and choose one
> by PCI_ID_REG matching.

I think these standalone PCI drivers are a really great thing to have in the
system, for those machines that have really crappy boot ROMs and whatnot and
can't do anything useful on thier own.

Is this something that can possibly be moved down into libsa at some point,
once you get the drivers working and are happy with them?  (I see that cobalt
has already adopted some of this code)

Please understand, I don't want this to be a big, super-complex architecture
with bus_space and whatnot, just a simple system like you are doing now, where
presumably the ports will have to provide thier own inb/outb stuff to make it
go.

Also, in the CVS attic for prep and bebox, there should be a standalone floppy
driver, if you ever intend to do bio drivers.

---
Tim Rightnour <root <at> garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/
Permalink | Reply | 1 comment |
headers
Vincent | 1 Nov 2007 21:14
Picon
Favicon

Package Gnash 0.8.1

Hi there,
to whom it may concern, this a (maybe not entirely correct) pkgsrc 
version of the release 0.8.1 of the Gnash flash player.

Please test it, it should work.

Vincent
Attachment (gnash081.tgz): application/octet-stream, 3369 bytes
Permalink | Reply | 0 comments |
headers
Andrew Doran | 2 Nov 2007 00:10
Picon

vmlocking branch in need of testing

Hi all,

The two core goals for this branch are:

- Make VM system / trap handling MP safe.
- Make file system framework MP safe.

What that means is for many I/O operations, page faults and so on, the
global kernel_lock is no longer taken. The code isn't tuned yet although a
quick test I did a while ago on a 4 CPU system showed something like a 40%
reduction in _system_ time while building a kernel.

It's approaching stability and I'd like to invite anyone who is interested
to test. There are known problems, the major ones are:

- Only amd64, i386 and pmax have the necessary code at the moment.
  Other architectures need still need updating.
- ext2fs and lfs are busted. 
- Layered file systems need testing and probably need some work.
- Running nfsd is currently inadvisable due to a locking issue.
  The NFS client should work fine.

If you'd like to test it, the steps are:

- Grab a recent copy of src/common from -current.
- Check out src/sys from anoncvs with the 'vmlocking' tag.
- Build a kernel, install, and with luck it all works OK. :-)

Thanks,
Andrew
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Thorpe | 2 Nov 2007 00:55

Re: vmlocking branch in need of testing


On Nov 1, 2007, at 4:10 PM, Andrew Doran wrote:

> - Only amd64, i386 and pmax have the necessary code at the moment.
>  Other architectures need still need updating.

Please describe what needs to be done to a port to make it work.

Thanks!

-- thorpej
Permalink | Reply | 0 comments |
headers
Andrew Doran | 2 Nov 2007 01:42
Picon

Re: vmlocking branch in need of testing

On Thu, Nov 01, 2007 at 04:55:10PM -0700, Jason Thorpe wrote:
> 
> On Nov 1, 2007, at 4:10 PM, Andrew Doran wrote:
> 
> >- Only amd64, i386 and pmax have the necessary code at the moment.
> > Other architectures need still need updating.
> 
> 
> Please describe what needs to be done to a port to make it work.

The odd bit of useful information is missing but this is it:

	http://www.netbsd.org/~ad/smp/vmlocking.txt

Andrew
Permalink | Reply | 0 comments |
headers
Toru Nishimura | 2 Nov 2007 02:29

Re: CVS commit: src/sys/arch/sandpoint/stand/netboot

Tim Rightnour said;

> I think these standalone PCI drivers are a really great thing to have in the
> system, for those machines that have really crappy boot ROMs and whatnot and
> can't do anything useful on thier own.
> 
> Is this something that can possibly be moved down into libsa at some point,
> once you get the drivers working and are happy with them?

Yes, that is my plan.

> Please understand, I don't want this to be a big, super-complex architecture
> with bus_space and whatnot, just a simple system like you are doing now, where
> presumably the ports will have to provide thier own inb/outb stuff to make it
> go.

It's my standpoint, too.  Tired of debugging etherboot/grub/uboot code to
run and having strong confidence "this should be far small and simple," I  started
writng them in rush.  And yes, I want to keep LIBSA loosely coupled with the
rest of NetBSD kernel structure (or -ism API) and include files (it started its life
when NetBSD did not exist on this planet, didn't it?)  The aim is the ease of code
re-usability, or "retargetting," out of NetBSD context.  I used LIBSA derivative
code for non NetBSD OS several times and got paid in fact.

Toru Nishimura / ALKYL Technology
Permalink | Reply | 0 comments |
headers
Vincent | 2 Nov 2007 08:50
Picon
Favicon

Re: vmlocking branch in need of testing

Andrew,

there is a slight incompatibilty between the vmlocking branch code and 
the last drm code update. See below:

#   compile  PRESARIO/ati_pcigart.o
cc -march=pentium4m -msse2 -mfpmath=sse -ffreestanding 
-fno-zero-initialized-in-bss -march=pentium4m -O2 -Werror -Wall 
-Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes 
-Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings 
-Wno-sign-compare -Wno-pointer-sign -Wno-attributes -Wextra 
-Wno-unused-parameter -fno-strict-aliasing -Di386 -I. 
-I../../../../contrib/dev/ath/netbsd -I../../../../../common/include 
-I../../../../arch -I../../../.. -nostdinc -DDFLDSIZ=805306368 -DLKM 
-DMAXUSERS=32 -D_KERNEL -D_KERNEL_OPT 
-I../../../../lib/libkern/../../../common/lib/libc/quad 
-I../../../../lib/libkern/../../../common/lib/libc/string 
-I../../../../lib/libkern/../../../common/lib/libc/arch/i386/string 
-I../../../../dist/ipf -c ../../../../dev/pci/drm/ati_pcigart.c
In file included from ../../../../dev/pci/drm/ati_pcigart.c:37:
../../../../dev/drm/drmP.h:229: error: expected identifier or '(' before 
'<<' token
In file included from ../../../../dev/pci/drm/ati_pcigart.c:37:
../../../../dev/drm/drmP.h:238:1: error: "DRM_SPINTYPE" redefined
../../../../dev/drm/drmP.h:230:1: error: this is the location of the 
previous definition
../../../../dev/drm/drmP.h:239:1: error: "DRM_SPININIT" redefined
../../../../dev/drm/drmP.h:231:1: error: this is the location of the 
previous definition
../../../../dev/drm/drmP.h:240:1: error: "DRM_SPINUNINIT" redefined
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joerg Sonnenberger | 3 Nov 2007 13:55
Picon

Re: recent amd64 slowless caused by x86pmap merge

On Wed, Oct 31, 2007 at 02:50:51PM +0900, YAMAMOTO Takashi wrote:
> i failed to reproduce.  can you give me more details?

One test case which could be related is starting Firefox from cache
(e.g. starting it, closing it and restarting). Sometimes it is instantly
there, at other times it needs over 30s here.

This is on AMD64 with a UP kernel.

Joerg
Permalink | Reply | 2 comments |
headers
Bill Stouder-Studenmund | 3 Nov 2007 21:50
Picon

multi-core router

At the last San Diego BSD users group meeting we had an interesting 
discussion about which would be a better pf platform: FreeBSD or OpenBSD. 
The choices were OpenBSD 4.2 with the updated pf (supposedly lots of 
performance improvements) or FreeBSD 5.3 I think it was. The perceived 
disadvantage of FreeBSD was a slightly older pf (shouldn't be hard to fix) 
and the advantage would be the ability to use more than one core. You 
can't really buy UP Intel chips anymore (well, you can buy Celerons, but 
why not just get a Core 2 Duo), and Core 2 Quad isn't that much more.

The target setup involves three NICs. One to the outside, one to the 
inside, and one to the failover box.

So that leads me to two questions for these lists.

1) How would you design a router to make use of multiple cores. We've 
talked about different multi-core setups for running the TCP stack on one 
core and IP on another and so on to sustain 10 GigE TCP connections. But 
this case is different in that all we're doing is NAT and forwarding.

2) How well do we think existing code (FreeBSD, so I can tell the folks 
next month, and NetBSD) will do in this case?

Take care,

Bill
Permalink | Reply | 18 comments |
headers
De Zeurkous | 3 Nov 2007 22:19

RE: multi-core router

Haai,

On Sat, November 3, 2007 20:50, Bill Stouder-Studenmund wrote:
>[snip]
>
> 1) How would you design a router to make use of multiple cores. We've
> talked about different multi-core setups for running the TCP stack on one
> core and IP on another and so on to sustain 10 GigE TCP connections. But
> this case is different in that all we're doing is NAT and forwarding.
>

Split both stacks and the NATd into if-dependent and if-independent parts,
and run them concurrently -- one instance of the if-independent 'core' to
arbitrate and route and numif instances of the if-dependent part. Then
introduce a tuning option to allocate sockets to threads, like nfsd -n.
Perhaps spin off all software checksumming into seperate threads?

Baai,

De Zeurkous
-----------

Friggin' Machines!

>[snip]
>
> Take care,
>
> Bill
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane