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: missing words, lots of them
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.
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.
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.
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.
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
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.
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?
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.
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.
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?
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
: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 ?
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.
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 ?
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 ?
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
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
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?
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?
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
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
