RE: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Mike Meyer

[Context recovered from top posting.]

Nicpon, John [EMAIL PROTECTED] types:
  From: Mike Meyer [mailto:[EMAIL PROTECTED]]
  Nicpon, John [EMAIL PROTECTED] types:
   I've been having the same problem listed below and was wondering if
   anyone had a fix?
  There wasn't a fix when I asked last week, and I've not been able to
  get technical specs out of SiS. If you get one, I'd appreciate hearing
  about it.
 I have attached a file from the ecsusa.com for reprogramming the MAC
 address. Perhaps the data file included could provide the necessary
 information for updating the SIS900 driver. Please advise.

Could you provide a pointer to where you found it? An explanation of
why users need to reprogram their MAC's - which is rather unusual -
would help quite a bit.

mike
--
Mike Meyer [EMAIL PROTECTED]  http://www.mired.org/home/mwm/
Q: How do you make the gods laugh?  A: Tell them your plans.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: missing words, lots of them

2001-11-08 Thread Joseph Jacobson


 These words, 830 of them, were obtained by intersecting the words
 in a number of lexicons and then subtracting the words in
 /usr/share/dict/web2. This all done with words that contain only
 lowercase letters.
 
 You'll find those words at the end of this message. Should you
 take even a cursory look at this list, I expect you'll be appalled
 at the words that are not in the lexicon.
 
 The point is *not* that these words should be added. The point is
 that a cursory, in-my-sleep check of the word list shows glaring
 deficiencies. A serious audit of the list will find way many more
 missing words (I did a preliminary -- think ~50,000-100,000
 missing words if it is supposed to approximate the contents of an
 unabridged dictionary.)
 
 Anyway, I'm willing to create a replacement list, if it's likely
 to actually get used.

Wondering if anything became of this  It would be nice to have a
relatively complete word list.

http://www.puzzlers.org/secure/wordlists/dictinfo.html contains a good
summary of publically available word lists.   IMHO, the ENABLE list
mentioned there (http://www.puzzlers.org/secure/wordlists/enable_readme.txt)
seems like a good candidate for a drop-in replacement

Joe


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



RE: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Nicpon, John

It was a small link on the bottom of this page for users who did a bad
bios flash.
I thought there might be some information as far as card parameters that
would assist in updating the drivers.

http://www.ecsusa.com/ecsusa/www.ecs.com.tw/download/k7s5a.htm

-Original Message-
From: Mike Meyer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 08, 2001 3:02 PM
To: Nicpon, John
Cc: Jonathan Lemon; Kent Stewart; [EMAIL PROTECTED]
Subject: RE: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.


[Context recovered from top posting.]

Nicpon, John [EMAIL PROTECTED] types:
  From: Mike Meyer [mailto:[EMAIL PROTECTED]]
  Nicpon, John [EMAIL PROTECTED] types:
   I've been having the same problem listed below and was wondering
if
   anyone had a fix?
  There wasn't a fix when I asked last week, and I've not been able to
  get technical specs out of SiS. If you get one, I'd appreciate
hearing
  about it.
 I have attached a file from the ecsusa.com for reprogramming the MAC
 address. Perhaps the data file included could provide the necessary
 information for updating the SIS900 driver. Please advise.

Could you provide a pointer to where you found it? An explanation of
why users need to reprogram their MAC's - which is rather unusual -
would help quite a bit.

mike
--
Mike Meyer [EMAIL PROTECTED]
http://www.mired.org/home/mwm/
Q: How do you make the gods laugh?  A: Tell them your plans.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Wilko Bulte

On Thu, Nov 08, 2001 at 03:02:15PM -0600, Mike Meyer wrote:
 [Context recovered from top posting.]
 
 Nicpon, John [EMAIL PROTECTED] types:
   From: Mike Meyer [mailto:[EMAIL PROTECTED]]
   Nicpon, John [EMAIL PROTECTED] types:
I've been having the same problem listed below and was wondering if
anyone had a fix?
   There wasn't a fix when I asked last week, and I've not been able to
   get technical specs out of SiS. If you get one, I'd appreciate hearing
   about it.
  I have attached a file from the ecsusa.com for reprogramming the MAC
  address. Perhaps the data file included could provide the necessary
  information for updating the SIS900 driver. Please advise.
 
 Could you provide a pointer to where you found it? An explanation of
 why users need to reprogram their MAC's - which is rather unusual -
 would help quite a bit.

Things like DECnet used to do it. And I think some server clustering 
solutions might still do it.

-- 
|   / o / /_  _ email:  [EMAIL PROTECTED]
|/|/ / / /(  (_)  Bulte Arnhem, The Netherlands 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Leo Bicknell

On Thu, Nov 08, 2001 at 03:02:15PM -0600, Mike Meyer wrote:
 Could you provide a pointer to where you found it? An explanation of
 why users need to reprogram their MAC's - which is rather unusual -
 would help quite a bit.

There are several possibilities:

* Users wish to replace a card but have it use the same MAC
  address due to filters, static arp entries, caches that take too
  long to expire, bootp entries that are based on MAC address, etc.
  For years cards had the MAC in a separate ROM to make this possible
  with a chip swap too.

* Some protocols (mostly all obsolete) required specific MAC
  addresses.

* Some clustering software switches MAC's from one machine to 
  another to make the switch transparent at layer 2.

Older cards could only answer a single MAC, a small multicast MAC
list, and the broadcast MAC.  I think most newer designs unify this
into a single list of things I want, which could allow a card to
be multiple unicast MAC's at once.


-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Warner Losh

In message [EMAIL PROTECTED] Wilko Bulte writes:
: Things like DECnet used to do it. And I think some server clustering 
: solutions might still do it.

Some clustering solutions do do it to this day.  They provide for
completely trasnparent IP failover, and experience has shown that the
easiest way to do that is for the MAC to be taken over.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: mmap/madvise

2001-11-08 Thread Terry Lambert

Jason Mawdsley wrote:
 
  Jason Mawdsley [EMAIL PROTECTED] asks:
 
 I am looking for a way to reserve memory, without actually
 allocating the swap space.
 
  Alfred Perlstein answers:
 
Just proceed normally, freebsd does overcommit such that you really
don't need to do anything special to get the results you desire.
 
  I assume Jason is writting a userland application, but I cannot tell
  how he was using the allocated memory. Alfred is correct in that
  allocated memory is not even physical until needed and only paged back
  if modified AND space becomes low.
 
  Without information of what he was doing, I was trying to read between
  the lines of his message and wonder if he needs the memory physically
  there and wired (using mprotect) to prevent the memory from being
 released.
 
 I am creating a virtual memory manager.
 
 Currently I am doing a
 mmap(...PROT_NONE, MAP_ANON ) to reserve the memory.
 then when committing the memory I am using mprotect( ...PROT_READ |
 PROT_WRITE )


Up front, given your company web pages, I suspect that you are
trying to port Windows code to Linux, but that the Linux community
has been less than helpful, so you are turning to us.  Hopefully,
if we a re helpful, you will seriously consider supporting FreeBSD
as a platform for your product.

---

First, you aren't doing what you think you are doing, even under
Windows, since the function you are using doesn't really work
completely like you think it works.  However inefficient it is,
though, you can at least get work done with it, so whatever.

Here is the nasty function:

LPVOID VirtualAlloc(
  LPVOID lpAddress,// region to reserve or commit
  SIZE_T dwSize,   // size of region
  DWORD flAllocationType,  // type of allocation
  DWORD flProtect  // type of access protection
);

---

I started to write a glue function that looked like VirtualAlloc,
but when I got about 3/4 of the way done, I realized that the
performance penalty would be large enough that it would be a
really (, really, really) bad idea.

Instead, you will want to relook at the problem you are attempting
to solve a bit, and come up with a better solution.  Right now,
you are having to look at the code that calls VirtualAlloc in your
product, so you are on the right track for doing that, so it is no
more hairy to (mostly) do the right thing than to write a glue
function.

Since I don't know how you are _precisely_ using VirtualAlloc, I'm
going to cover the UNIX bases for you...

---

The manual pages you want to look at are:

mmapFor reservation of memory; you should
mmap the fd for /dev/zero, with MAP_ANON
to grab pages initially.

munmap  Needed for PAGE_NO_ACCESS; implicated in
PAGE_GUARD and MEM_WRITE_WATCH (see below).

msync   For MEM_COMMIT.  The Windows documentation
is actually misleading, since a MEM_COMMIT
of previously allocated memory does not
result in it being zeroed, like it will be
if you use MEM_COMMIT on a region that has
not been previous MEM_RESERVE or MEM_PHYSICAL
flagged.

Note:   Unfortunately FreeBSD msync() will
write more data than it needs to,
since the dirty pages in mapped
regions are not tracked to the
granualrity necessary to be able to
write only them, without an expensive
reverse page table lookup.  So this
will generally be mor expensive than
it should be.

madvise Use to get MEM_RESET functionality; also used
to change the protections.  Changing the
protections _DOES NOT COMMIT_ dirty blocks,
as you appear to be assuming.

Other caveats:

o   The round down will be to the next 4k, not the next
64k boundary; FreeBSD doesn't have to deal with
segments, like Windows 98/ME, so there is no real
efficiency reason for doing the rounding, as in
Windows.  If you depend on this, you will need to
manually take care of this (note: dwSize will need
to go up if you make the address go down, so be
prepared).

o   FreeBSD does not support AWE, so if you are trying to
use this to get more than 4G of physical memory, you
aren't going to be able to do it.

o   The MEM_TOP_DOWN (NT/2000/XP specific) flag can only
be simulated by putting logic into your allocation,

Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Terry Lambert

Wilko Bulte wrote:
  An explanation of
  why users need to reprogram their MAC's - which is rather unusual -
  would help quite a bit.
 
 Things like DECnet used to do it. And I think some server clustering
 solutions might still do it.

DECNet reprogrammed the MACs with the DEC ethernet allocation
block, and the last part was the DECNet Node ID.

VRRP uses a similar approach for MAC reprogramming for IP
address takeover.  It does this because not using real MAC
addresses for VRRP confuses the hell out of switches (most
particularly, L2 switches like those from Extreme, which
don't have the ability to cache multiple MAC addresses per
port).

Using the multicast mask approach (like the FXP version of
VRRP for Linux) is a bad idea, since VRRP requires the use
of multicast anyway.

FreeBSD needs some basic changes for multiple MAC s to be
useful, though.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



How to profiling a KLD?

2001-11-08 Thread Zhihui Zhang


I am trying to profile a KLD.  It seems to me that adding the following
line in its make file does not help:

COPTS+= -pg -DGPROF

The kernel was configured with config -p and I used kgmon -b, kgmon -h,
kgmon -p, and gprof /kernel gmon.out  gprof.out to collect the data. But
none of my routines in the KLD show up in gprof.out.  I must be missing
something.  Any help is appreciated.

-Zhihui


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Leo Bicknell

On Thu, Nov 08, 2001 at 02:50:44PM -0800, Terry Lambert wrote:
 FreeBSD needs some basic changes for multiple MAC s to be
 useful, though.

I have more than once wished to assign a separate MAC to each
virtual IP address on an interface.  I have no idea how complex
that would be, but it would be handy in a few odd situations.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Terry Lambert

Leo Bicknell wrote:
 
 On Thu, Nov 08, 2001 at 02:50:44PM -0800, Terry Lambert wrote:
  FreeBSD needs some basic changes for multiple MAC s to be
  useful, though.
 
 I have more than once wished to assign a separate MAC to each
 virtual IP address on an interface.  I have no idea how complex
 that would be, but it would be handy in a few odd situations.

Yes, this is exactly the change I was talking about.

Specifically, IP packets need to come out a specific MAC; to
do this, you have to treat it as multiple physical interfaces
on a single card (one per MAC address), and send them that
way.

The Tigon II can do 1 extra MAC the Tigon III 4, and the Intel
can do 16 extra MACs.  You could get more on the Tigons by
rewriting the firmware, but in their infinite wisdome, the
Tigon III firmware is no where nearly as accessible as the
Tigon II, which was published on their web site.

The FreeBSD gratuitous ARP code is also broken; and there
needs to be a third state between up and down called
passive that prevents ARP responses, but leaves the
interface up.

The Tigon II firmware download on each IP address change also
really throws a monkeywrench into things.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Framebuffer device under FreeBSD?

2001-11-08 Thread Vladimir Kushnir

Hi all,

A couple of questions here.
i. Is it feasible to port Linux fbdev modules to FreeBSD (as a modules,
again)? They work quite nice under Linux for multimedia apps, and it's a
pity we haven't got anything of this kind (TNT2 based v/cards with HW
accelleration, for one). Did anybody try to do that? If so, I would
happily join this project (no money for XFree86-supported card like Matrox
or Radeon :-)

ii. If not, is there any chance to port Linux's vm86 - based video module
(see MPlayer CVS version, VESA video-out) to our i386_vm86? It alse work
nice under Linux (no HW accelleration but very low overhead instead).

Any hints would be greatly appreciated.

TIA,
Vladimir

-- 
Vladimir Kushnir - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: mmap/madvise

2001-11-08 Thread Matthew Dillon


:I am creating a virtual memory manager.
:
:Currently I am doing a
:mmap(...PROT_NONE, MAP_ANON ) to reserve the memory.
:then when committing the memory I am using mprotect( ...PROT_READ |
:PROT_WRITE )
:
:HTH
:
:Jason Mawdsley ~ [EMAIL PROTECTED]
:m_ a c a d a m i a nt e c h n o l o g i e s
:
:Software developers for the world's leading technology companies.
:http://www.macadamian.com

Hmm.  Well, the memory is already virtual.  mprotect() can be
used to force a SIGBUS if the process tries to access the
protected memory in a manner you do not allow, but it will
have no effect on how FreeBSD manages the memory on the backend.

mmap() w/ MAP_ANON will reserve memory but not allocate it 
until you access it (read or write), on a page by page basis.

munmap() will free memory immediately and cause any further
references to the unmapped address space in question to generate
a SIGSEGV signal.  However, it is not recommend that you use
munmap() to manage freeing memory on a page-by-page basis due
to its overhead.  If you don't need a hard signal on access failures
then madvise(...MADV_FREE...) is the better way.

mprotect() can be used to prevent reading and/or reading 
writing to the address space in question without destroying
any of the data (i.e. you can mprotect() a piece of memory
so it is not accessible, and then mprotect() again later
to make it accessible with the original contents undisturbed).
Accesses to mprotect()ed memory in a manner not allowed by
the mprotect() will result in a SIGBUS signal.

mprotect() has rather serious overhead.  If you don't need
to handle hard-signals on access failures you should use
madvise(...MADV_FREE) to 'free' (uncommit) memory.

madvise() can be used in a number of ways, but the most common
way is to use MADV_WILLNEED and MADV_FREE.  MADV_WILLNEED does
*NOT* commit or reserve physical memory in any way, it simply
advises FreeBSD that you will need the memory soon and FreeBSD
will try to make sure (but will not guarentee) that any swapped-out
pages are swapped in.  MADV_FREE is a soft version of munmap() - 
it 'decommits' the memory, allowing FreeBSD to throw it away at any
time until the next access (on a page-by-page basis), but it doesn't
do it instantly like mmap().  Instead the memory is only thrown away
if FreeBSD hits a memory shortage, and the memory is left
mapped so you can simply access it (read or write) to re-commit
the memory (but when you do so you are not guarenteed that the
contents as of the time of the MADV_FREE were kept intact,
only that whatever contents is there remains intact after you
access it again).

msync() has no effect on anonymous (MAP_ANON) memory.  It only
effects file-backed memory.

Committing physical or swap space to back anonymous memory
(you don't have any control over which FreeBSD uses) is
simple:  You simply access (read or write) the memory in
question (this occurs on a page-by-page basis).

Generally speaking you have very little control over when 
FreeBSD pages allocated memory in and out of swap, and
generally you shouldn't have to worry about it because FreeBSD
does a very good job figuring out what it should and should
not page out.

mincore() can be used to determine whether pages of virtual
memory are actually assigned physical pages or whether they
have been paged out to swap.

mlock() and munlock() can be used to lock virtual memory into
physical store, but only root can call these functions and they
are considered to be rather dangerous.

FreeBSD's manual pages are fairly complete in describing what these
functions do, you should look at them:

http://www.FreeBSD.org/cgi/man.cgi?manpath=FreeBSD+4.4-stable

e.g. type in 'madvise' and submit.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



processor recommendations for multi-user freeBSD system ?

2001-11-08 Thread Joesh Juphland


I am planning on building a true multi-user system (as opposed to a NFS 
server, or a web server, or a mail server) - many people with many shells 
will be doing many things.

Two things have been decided:

- it will run freeBSD
- it will be dual processor

-

So what two processors should I use ?  Coming from a Sun hardware 
background, I originally thought to use PIII Xeons .. since they have a lot 
of cache, and fast cache.  I was thinking 512meg cache p3 xeons running at 
550mhz.

But what about a modern athlon MP processor ?  Much less cache, but it runs 
at 266mhz, and it is much faster ... 1700mhz or so.

One specific question might be, at what bus speed and mhz speed do the 
advantages of a good processor like a xeon start to not matter ?

Any advice, comments appreciated.

--joesh

_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: SIS 900 Onboard NIC /w SIS 735 Chipset Motherboard.

2001-11-08 Thread Mike Meyer

Leo Bicknell [EMAIL PROTECTED] types:
 On Thu, Nov 08, 2001 at 03:02:15PM -0600, Mike Meyer wrote:
  Could you provide a pointer to where you found it? An explanation of
  why users need to reprogram their MAC's - which is rather unusual -
  would help quite a bit.
 There are several possibilities:

None of which apply in this case. The posted instructions told the
reader how to put the original MAC address back after it turned up all
zeros, not how to change it to an arbitrary value.  This was basically
a bit of code to work around a bug in the firmware that caused the
hardware to lose the MAC address.

All of which has little to do with the real problem - getting the SiS
900 in the SiS 735 chipset working with FreeBSD, so I can put the fxp
card and the PCI slot it's in to better use. The SiS is recognized,
but you get the following at boot:

sis0: SiS 900 10/100BaseTX port 0xd000-0xd0ff mem 0xcffdd000-0xcffddfff irq 14 at 
device 3.0 on pci0
sis0: Ethernet address: 00:00:00:00:00:00
sis0: MII without any PHY!
device_probe_and_attach: sis0 attach returned 6

Apparently the PHY part of this chipset is either unsupported or
unrecognized.

mike
--
Mike Meyer [EMAIL PROTECTED]  http://www.mired.org/home/mwm/
Q: How do you make the gods laugh?  A: Tell them your plans.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: processor recommendations for multi-user freeBSD system ?

2001-11-08 Thread Mike Meyer

Joesh Juphland [EMAIL PROTECTED] types:
 I am planning on building a true multi-user system (as opposed to a NFS 
 server, or a web server, or a mail server) - many people with many shells 
 will be doing many things.
 
 Two things have been decided:
 
 - it will run freeBSD
 - it will be dual processor

Why the dual processor requirement? There are lockups in the SMP
kernel that don't exist in the UP kernel. A number of people have
reported reliable reproduction of them, but nobody has fixed them. I
don't know if there is a PR on it or not.

 So what two processors should I use ?  Coming from a Sun hardware 
 background, I originally thought to use PIII Xeons .. since they have a lot 
 of cache, and fast cache.  I was thinking 512meg cache p3 xeons running at 
 550mhz.
 
 But what about a modern athlon MP processor ?  Much less cache, but it runs 
 at 266mhz, and it is much faster ... 1700mhz or so.

I just traded - due to hardware failure - a dual PII/Xeon system for a
1GHz Athlon UP system. The Xeons had a 100MHz FSB with 256 meg of
ram. The Athlon has a 266MHz FSB with 256 meg of ram. The actual box
had 450MHz/2MB Xeons. I also moved the system disks from the onboard
7890 to a 2940 on the PCI bus. Some things are noticably faster, some
are noticably slower.

I have timings on make -j N world from an earlier incarnation of the
system. It used 400MHz/512MB cache Xeons in it. I did similar tests
with the Athlon. The numbers are:

-j  Athlon  Dual Xeon

1   01:12:2002:05:15
2   00:49:1401:16:01
4   00:44:1201:04:47
8   00:43:3701:01:05
16  00:43:4601:00:40
32  00:44:0201:00:36

While the hardware is essentially identical except as noted, the Dual
Xeons are running on FreeBSD 4-STABLE as of mid February, and the
Athlon on 4-STABLE as of October, with file systems dumped and
restored to take advantage of the dirpref code. Make of it them what
you will.

The real kicker is that the Athlon board - complete with CPU and
256Meg of 266MHz memory - has about the same street price as the two
Xeons it replaced, or an empty dual Xeon motherboard. Dual CPU
motherboards seem to have the same price no matter what CPU they
support, so there's a significant bang/buck advantage to the Athlon
cpus. I'd say that, unless you know the cache on the Xeons is going to
be a win - and don't forget that cache misses are still twice as fast
as cache misses on the Xeon, and roughly half the speed of cache
*hits* on the Xeon - go with the Athlon.

 One specific question might be, at what bus speed and mhz speed do the 
 advantages of a good processor like a xeon start to not matter ?

It depoends on what advantages you're looking for. If your code and
data fit in a megabyte, a 450MHz PII/Xeon with 2MB of cache will
probably outperform most Athelons on the task at hand, as pretty much
everything will run at 450MHz, instead of some of it running at 266MHz
and some at 1.7GHz. But that's not your application.

mike
--
Mike Meyer [EMAIL PROTECTED]  http://www.mired.org/home/mwm/
Q: How do you make the gods laugh?  A: Tell them your plans.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: processor recommendations for multi-user freeBSD system ?

2001-11-08 Thread Leo Bicknell

On Thu, Nov 08, 2001 at 06:36:18PM -0700, Joesh Juphland wrote:
 So what two processors should I use ?  Coming from a Sun hardware 
 background, I originally thought to use PIII Xeons .. since they have a lot 
 of cache, and fast cache.  I was thinking 512meg cache p3 xeons running at 
 550mhz.

Does it matter?  90% of the shell systems I see have poor
performance because they are out of memory and swapping like a dog.
Another 9.99% have enough memory, but because there aren't enough
disks / fast enough disks everything is blocked waiting on io.
Only 0.01% of them have I ever seen be CPU bound (100 tintin++'s
can do that to you :-).

Unless it's a compiler farm, or you have lots of users running
specialized apps (mathematica, staroffice) I bet pouring your money
into memory and io bandwidth will make the system more 'responsive'
to the end users.

-- 
   Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Report on FreeBSD 4.4 pthread implementation verses boehm-gc

2001-11-08 Thread Loren James Rittle

Hello all,

I have ported the most recent version of boehm-gc (6.1-alpha) to
FreeBSD/i386 under the auspice of the gcc project (it will be in Hans'
6.1 release and it is on the gcc mainline).  I got one notable thing
fully configured beyond what is in the ports tree (which is based on
6.0): threaded GC is now supported.  However, this work has uncovered
either a rare race condition in the 4.X pthread implementation (also
seen on a current 5.0 system) or a bad assumption in the GC signal
code (abstracted below).  Either way, the result seen is an undetected
deadlock.  With the following new assertion, I can at least force the
condition to be detectable in many cases where it would have locked up.

Two questions come to mind: Is there any condition under which my new
assumption should not be true?  Is there any obvious mistake that a
threaded application can make (perhaps related to its signal use) that
could cause the new assumption to ever be violated?

Index: uthread/uthread_exit.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_exit.c,v
retrieving revision 1.16.2.3
diff -c -r1.16.2.3 uthread_exit.c
*** uthread/uthread_exit.c  12 Jul 2001 21:03:38 -  1.16.2.3
--- uthread/uthread_exit.c  7 Nov 2001 04:18:51 -
***
*** 217,222 
--- 217,224 
pthread-suspended = SUSP_NO;
break;
case SUSP_NO:
+   PTHREAD_ASSERT ((pthread-state == PS_JOIN),
+   Target of join has wrong state);
/* Make the joining thread runnable: */
PTHREAD_NEW_STATE(pthread, PS_RUNNING);
break;

I have also seen what I thought was a less important issue, but I now
see that it is probably related.  After reviewing the FreeBSD uthread
source code, the issue appears to be a race between the pthread_exit()
code running in one thread and the pthread_join() code running in
another thread in conjunction with a sigsuspend() call occurring on a
signal handler of that second thread.  Under some conditions, an
errant EINTR would be returned to the pthread_join() caller instead of
the exit code from the terminated thread.  Under other timing
conditions, you get the deadlock spotted with the above new assertion.

This test program displays the problem (I only know how to make the
deadlock/assertion failure reproducible not the errant return code):

/* This code is an abstraction of that which is found in both
   _Programming with POSIX Threads_ and boehm-gc (taken from 6.1-alpha
   but other versions appear similar). */
#include unistd.h
#include pthread.h
#include signal.h

void handler1 (int s)
{
  sigset_t mask;

  /* boehm-gc code uses a sem_post() and nominally blocks SIGUSR2
 inside this handler instead of the luck method, but that detail
 is not required to see the primary issue at hand. */

  sigfillset (mask);
  sigdelset (mask, SIGUSR2);
  sigsuspend (mask);
}

void handler2 (int s)
{
  /* Do nothing.  Must exist to allow sigsuspend() to work properly. */
}

void* worker (void* arg)
{
  pthread_kill (*(pthread_t*)arg, SIGUSR1);
  sleep (1);
  pthread_kill (*(pthread_t*)arg, SIGUSR2);
}

int
main (void)
{
  pthread_t w1;
  pthread_t w2;
  pthread_t m = pthread_self ();

  signal (SIGUSR1, handler1);
  signal (SIGUSR2, handler2);

  pthread_create (w2, NULL, worker, m);

  return pthread_join (w2, NULL);
}

Comments?  Workaround for the GC code (other than switching to the _np
interface points to stop/start threads which was the whole point of
the signal tomfoolery)?  Best case: Anyone see how to better support
this test case in the 4.X uthread implementation?

Regards,
Loren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: Report on FreeBSD 4.4 pthread implementation verses boehm-gc

2001-11-08 Thread Warner Losh

In message [EMAIL PROTECTED] Loren James Rittle 
writes:
: void* worker (void* arg)
: {
:   pthread_kill (*(pthread_t*)arg, SIGUSR1);
:   sleep (1);
:   pthread_kill (*(pthread_t*)arg, SIGUSR2);
: }

We've seen the same thing with: 

pthread_kill (*(pthread_t*)arg, SIGUSR1);
pthread_kill (*(pthread_t*)arg, SIGUSR1);

At this point, the signal handler repeatedly gets called.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: Framebuffer device under FreeBSD?

2001-11-08 Thread Craig R

I'm going to have to agree with your idea in general, however there are 
parts that I disagree with. First, taking all of the code from Linux may not 
be good for the FreeBSD project. That would steer FreeBSD into being more 
like yet another Linux distro instead of an independent project. Just 
picture having tons of GPL code and changing the name to FreeGPL and how 
much that would suck. What I think we should do is create a framebuffer 
system as you suggested, but do it separately with FreeBSD's own developed 
code and build it straight into the base OS. A linux compatability layer 
could be made (similar idea as the existing binary support) so that more 
applications would run, but the system itself would be independant. The idea 
of framebuffers in general is good, as the XFree86 project appears to be 
going very slowly with little improvement in performance.

If this were to take off, I think it would help FreeBSD a great deal. Seeing 
the existing OS and how well it performs makes me drool over how well it 
could run as a desktop with it's own builtin windowing system. As mentioned, 
I also think that being Linux distro #8000 is not a good idea. FreeBSD and 
Linux are independant projects and should remain as such.

-- Craig


From: Vladimir Kushnir [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Framebuffer device under FreeBSD?


Hi all,

A couple of questions here.
i. Is it feasible to port Linux fbdev modules to FreeBSD (as a modules,
again)? They work quite nice under Linux for multimedia apps, and it's a
pity we haven't got anything of this kind (TNT2 based v/cards with HW
accelleration, for one). Did anybody try to do that? If so, I would
happily join this project (no money for XFree86-supported card like Matrox
or Radeon :-)

ii. If not, is there any chance to port Linux's vm86 - based video module
(see MPlayer CVS version, VESA video-out) to our i386_vm86? It alse work
nice under Linux (no HW accelleration but very low overhead instead).

Any hints would be greatly appreciated.

TIA,
Vladimir

--
Vladimir Kushnir - [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message


_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



Re: Framebuffer device under FreeBSD?

2001-11-08 Thread Daniel O'Connor


On 09-Nov-2001 Craig R wrote:
  code and build it straight into the base OS. A linux compatability layer 
  could be made (similar idea as the existing binary support) so that more 
  applications would run, but the system itself would be independant. The idea

Why write yet another interface?
Is there anything inherently wrong with the Linux API?
If not, just Use It.

Ask the author of the code if he is prepared to dual license it to save time
writing it again (unless it's trivial code).

  of framebuffers in general is good, as the XFree86 project appears to be 
  going very slowly with little improvement in performance.

Hmm.. I have to disagree here.. The Xv extension is very nice. The DRI is
looking good etc..

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message



IPFW module

2001-11-08 Thread Dimitar Peikov


This morning I've cvsuped to STABLE and put 'options IPFIREWALL' into my 
kernel configuration file. After installing all I try to 'kldload ipfw' which 
complains that ipfw module is already in kernel, but kldstat reports that 
module is being loaded! Then I've decided to kldunload it Kernel panic 
 reboot!

It is regular to kernel crash if ipfw is loaded as module, but why when it was 
build into kernel? In that case it would be good kldload/kldunload to exit! 
Why kldload loads module in case that it is compiled in kernel?

-- 
Dimitar Peikov
Programmer Analyst
Globalization Group
We Build e-Business  

RILA Solutions  
27 Building, Acad.G.Bonchev Str.  
1113 Sofia, Bulgaria  

phone: (+359 2) 9797320 
phone: (+359 2) 9797300 
fax:   (+359 2) 9733355  
http://www.rila.com 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message