Re: useful addition to mergemaster (patch included)?
On Mon, 10 Jan 2000 22:21:32 MST, John and Jennifer Reynolds wrote: So, I made a quick hack to mergemaster so it would recognize a new "rc" variable called IGNORE_FILE. This file is a list of files mergemaster should ignore, or not compare. One filename per line. I've been meaning to do something like this for a while, because I also thought it'd be useful. Thanks! I've passed your patch on to the mergemaster maintainers. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
On Mon, Jan 10, 2000 at 03:36:23PM -0800, Matthew Dillon wrote: A better solution may be to shift to FreeBSD4.0 (when it's released - wait for it to become good and stable), and then use the native linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. The linuxthreads port is at least four times faster and, since it uses rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong there?). rfork (...RF_MEM) works under 3.X too on uni-processors. Its only SMP that you need 4.0 for. However, if you're going to use dynamic linking, there's a problem in ld-elf.so (its not thread safe) that has only been fixed recently. There are reported problems with both UP and SMP, but the problem is more evident with SMP. In theory the problem should exist for libc_r, but I don't know of any reports. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads)
On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote: I'm working on adding alternate entry points to libc now. Good. The naming approach I'm taking is: fwrite() -- Alternate entry point that is used externally unless another library overrides it. _libc_fwrite() -- `_libc_' prefix. Alternate entry point for internal library use. __fwrite() -- `__' prefix. Actual name. The reason for a prefix of `__' instead of `_' in the actual name case is that using only one underscore would be ambiguous at least in the cases of setjmp()/_setjmp() and longjmp()/_longjmp(). FYI, the actual name with a single '_' is already defined for syscalls via SYS.h. Aliasing '__sycall' to '_syscall' is ok, I assume. Or, are you planning on replacing the '_syscall's? Setjmp/_setjmp are libc calls but not syscalls. I'm under the impression that linux glibc uses both single and double underscore symbols, but I don't recall exactly what distinction they make between the two. One issue I'm not sure on is whether *every* libc interface should have alternate entry points added. Doing so would be more consistent, Agreed. but it probably isn't necessary, since POSIX very clearly defines the set of functions that may act as cancellation points. There end up being a few other functions that need wrapped by threads libraries as well. Of course, doing only the necessary ones is easier for me. =) Agreed its not necessary. I'm under the impression that linux glibc only does the "necessary" ones (at lease for the _libc_ prefix), but you'd have to check the code if you want to be sure, because I'm not. If only adding alternate entry points for the necessary libc interfaces, there's a good chance I can get this done for 4.0, which will mean compliant thread cancellation for both libc_r and linuxthreads. A genuine libpthread is just a hop, skip, and a jump from there. I'd say only do whats necessary, if thats the case. Someone really good with sed, or some other text processor, might be able to semi-automate the process, but I know I don't know how. This will be a big help. -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding alternate entry points to libc (was Re: Possible libc changes to support LinuxThreads)
On Tue, Jan 11, 2000 at 12:49:32PM -0600, Richard Seaman, Jr. wrote: On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote: The naming approach I'm taking is: fwrite() -- Alternate entry point that is used externally unless another library overrides it. _libc_fwrite() -- `_libc_' prefix. Alternate entry point for internal library use. __fwrite() -- `__' prefix. Actual name. The reason for a prefix of `__' instead of `_' in the actual name case is that using only one underscore would be ambiguous at least in the cases of setjmp()/_setjmp() and longjmp()/_longjmp(). FYI, the actual name with a single '_' is already defined for syscalls via SYS.h. Aliasing '__sycall' to '_syscall' is ok, I assume. Or, are you planning on replacing the '_syscall's? Setjmp/_setjmp are libc calls but not syscalls. I'm under the impression that linux glibc uses both single and double underscore symbols, but I don't recall exactly what distinction they make between the two. It would be more consistent to change to `__' for syscalls, but I was planning on leaving the syscalls with `_', and adding `__' aliases, for fear that changing it would violate some "law of libc". Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
devfs oddity bug
Recently I discovered a bug in DEVFS which I gonna try to fix. I have core dump which has been traced and analyzed, so that the place, where page fault occurs, and the way it came to death is known. And the only problem left: I have only few bits of information about DEVFS and VFS subsystems and looking for more details. -- /Voland Vadim Belman E-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
On Tue, Jan 11, 2000 at 13:31:23 -0600, Jonathan Lemon wrote: On Tue, Jan 11, 2000 at 01:22:49PM -0600, Jonathan Lemon wrote: We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a bit nervous because the 2400 uses a non-Intel server chipset made by a company called RCC Reliance. The chipset is called the "LE-64 ver 3.0". and I cannot seem to find any info about it. The most I've been able to turn up is somebody else looking for info. I was wondering if anybody was currently using a PowerEdge 2400 (or any other server products with this PCI chipset) with FreeBSD So -- does FreeBSD work with RCC chipsets? Is the chipset robust reliable? We've been badly burned a few times by buggy DEC PCI chipsets we're hoping to not repeat the experience with an x86 ;-) It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? This is with a RCC-186566-PO3. As for stability, I have another box running Linux with an RCC--PO2 that seems fairly stable. The RCC chips are supposed to allow better memory bandwidth @ 133Mhz. Anyone have a URL for RCC? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? Oops, you're right. That's probably the onboard Adaptec 7899. The RCC is probably this one: pci: unknown ATA vendor = 0x1166, device = 0x0211 I wonder why it flags it as a ATA device, I'm pretty sure this is the RCC chip -- the vendor id matches. (I checked this time.) -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
On Tue, Jan 11, 2000 at 13:49:59 -0600, Jonathan Lemon wrote: On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? Oops, you're right. That's probably the onboard Adaptec 7899. Yep, it is. I missed the 7899 ID when looking through the Adaptec driver. If you get the latest Adaptec driver in -current, you should be able to use that chip at Ultra2 speeds. The RCC is probably this one: pci: unknown ATA vendor = 0x1166, device = 0x0211 I wonder why it flags it as a ATA device, I'm pretty sure this is the RCC chip -- the vendor id matches. (I checked this time.) It's proably the chip class or something. That could well be an IDE chip, though. Intel's chipsets usually include an IDE controller. Does anyone have a URL for "RCC"? Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
Jonathan Lemon writes: On Tue, Jan 11, 2000 at 12:42:19PM -0700, Kenneth D. Merry wrote: It doesn't currently seem to boot with the RCC chipset. I get the following: pci unknown vendor = 0x9005, dev = 0x00cf That's an Adaptec vendor ID. (They've got 0x9004 and 0x9005.) I'm not sure what device that is, however. Justin might know. Are you sure that's the RCC chipset? Oops, you're right. That's probably the onboard Adaptec 7899. Damn. I was hoping that the Dell docs were something approaching correct. The claim is one 7890 one 7880 on-board. What is it really? a 7880 a 7899, or something else? Can you do me a huge favor run the lmbench bw_mem_cp benchmark from the lmbench or Hbench-OS benchmark suites please? How does it compare to: 2:54pmboil/gallatin:osf4.0-alpha./bw_mem_cp 20 8M libc aligned $Id: bw_mem_cp.c,v 1.7 1997/06/27 00:33:58 abrown Exp $ 299.3323 (This is a Compaq XP1000, alpha 21264). Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
A friend of mine pick one up for his home...fbsd 3.3 installed with minimal effort. He's now married to it, like it's his second wife...:) Andrew Gallatin wrote: We're thinking of purchasing some Dell PowerEdge 2400 servers. I'm a bit nervous because the 2400 uses a non-Intel server chipset made by a company called RCC Reliance. The chipset is called the "LE-64 ver 3.0". and I cannot seem to find any info about it. The most I've been able to turn up is somebody else looking for info. I was wondering if anybody was currently using a PowerEdge 2400 (or any other server products with this PCI chipset) with FreeBSD So -- does FreeBSD work with RCC chipsets? Is the chipset robust reliable? We've been badly burned a few times by buggy DEC PCI chipsets we're hoping to not repeat the experience with an x86 ;-) Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-smp" in the body of the message -- Cheers, Mikel +~+ | Optimized Computer Solutions, Inchttp://www.ocsny.com | 39 W14th Street, Suite 203 212 727 2238 x132 | New York, NY 10011 +~+ | Labor rates: Tech $125 hourly | Net Engineer $150 hourly | Phone Support $ 33 quarter hourly | Lost Password $ 45 per incedent +~+ | http://www.ocsny.com/~mikel +~+ begin:vcard n:King;Mikel x-mozilla-html:TRUE org:Optimized Computer Solutions version:2.1 email;internet:[EMAIL PROTECTED] title:Procurement Manager tel;fax:2124638402 tel;home:http://www.upan.org/vizkr tel;work:2127272100 adr;quoted-printable:;;39 W14th St.=0D=0ASte 203;New York;NY;10011;US x-mozilla-cpt:;0 fn:Mikel King end:vcard
Re: Dell PowerEdge 2400 RCC PCI chipset?
On Tue, Jan 11, 2000 at 02:56:51PM -0500, Andrew Gallatin wrote: Damn. I was hoping that the Dell docs were something approaching correct. The claim is one 7890 one 7880 on-board. What is it really? a 7880 a 7899, or something else? Uh, I didn't say that this was a PowerEdge 2400, just that it's a Dell box with a RCC chipset. Can you do me a huge favor run the lmbench bw_mem_cp benchmark from the lmbench or Hbench-OS benchmark suites please? How does it compare to: 2:54pmboil/gallatin:osf4.0-alpha./bw_mem_cp 20 8M libc aligned $Id: bw_mem_cp.c,v 1.7 1997/06/27 00:33:58 abrown Exp $ 299.3323 I can't seem to find that version. Here are some results: smp2-733[12:32pm](0)# ./bw_mem_cp 8M libc aligned $Id: bw_mem_cp.c,v 1.2 1995/03/11 02:19:56 lm Exp $ 8. 251.41 With the lmbench-2 suite, with the following ID: char *id = "$Id: s.bw_mem.c 1.5 98/06/29 22:37:23-07:00 [EMAIL PROTECTED] $" smp2-733[12:37pm](0)# ./bw_mem 8M rd 8.39 1033.33 smp2-733[12:37pm](0)# ./bw_mem 8M wr 8.39 281.68 smp2-733[12:37pm](0)# ./bw_mem 8M rdwr 8.39 307.67 smp2-733[12:37pm](0)# ./bw_mem 8M cp 8.39 243.47 smp2-733[12:38pm](0)# ./bw_mem 8M fwr 8.39 269.50 smp2-733[12:38pm](0)# ./bw_mem 8M frd 8.39 537.94 smp2-733[12:38pm](0)# ./bw_mem 8M fcp 8.39 231.97 smp2-733[12:38pm](0)# ./bw_mem 8M bzero 8.39 450.06 smp2-733[12:38pm](0)# ./bw_mem 8M bcopy 8.39 263.79 -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
Jonathan Lemon writes: Uh, I didn't say that this was a PowerEdge 2400, just that it's a Dell box with a RCC chipset. If you don't mind me asking, what is it? Can you do me a huge favor run the lmbench bw_mem_cp benchmark from the lmbench or Hbench-OS benchmark suites please? How does it compare to: 2:54pmboil/gallatin:osf4.0-alpha./bw_mem_cp 20 8M libc aligned $Id: bw_mem_cp.c,v 1.7 1997/06/27 00:33:58 abrown Exp $ 299.3323 I can't seem to find that version. Here are some results: smp2-733[12:32pm](0)# ./bw_mem_cp 8M libc aligned $Id: bw_mem_cp.c,v 1.2 1995/03/11 02:19:56 lm Exp $ 8. 251.41 Not too shabby! Thanks! Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
Matthew Dillon [EMAIL PROTECTED] wrote: A better solution may be to shift to FreeBSD4.0 (when it's released - wait for it to become good and stable), and then use the native linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. After a number of hours hacking around with linuxthreads under 3.3-stable and 3.4-stable, I'm wondering if this suggestion was a joke of some sort that I just didn't get? As far as I can tell, the linuxthreads source code contains no files newer than mid December 1997. That would predate FreeBSD3.x entirely, wouldn't it? No wonder I'm having such an awful time getting things compiled. Please please please tell me that I'm REALLY missing something, here. Is there newer code hidden somewhere? Later, scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
On Tue, Jan 11, 2000 at 03:23:13PM -0800, Scott Hess wrote: Matthew Dillon [EMAIL PROTECTED] wrote: A better solution may be to shift to FreeBSD4.0 (when it's released - wait for it to become good and stable), and then use the native linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD. After a number of hours hacking around with linuxthreads under 3.3-stable and 3.4-stable, I'm wondering if this suggestion was a joke of some sort that I just didn't get? As far as I can tell, the linuxthreads source code contains no files newer than mid December 1997. That would predate FreeBSD3.x entirely, wouldn't it? No wonder I'm having such an awful time getting things compiled. Please please please tell me that I'm REALLY missing something, here. Is there newer code hidden somewhere? The linuxthreads port switched to glibc-linuxthread-2.1.2 a couple of weeks ago. As mentioned by someone else (Alfred?), you *will* have problems with linuxthreads on -stable SMP, but it may work on -stable otherwise (I haven't tried it). It sounds like you need to do a cvsup. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dell PowerEdge 2400 RCC PCI chipset?
So -- does FreeBSD work with RCC chipsets? Is the chipset robust reliable? We've been badly burned a few times by buggy DEC PCI chipsets we're hoping to not repeat the experience with an x86 ;-) It doesn't currently seem to boot with the RCC chipset. I get the following: Can you be more specific than "it doesn't seem to boot:"? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
In article 1d5c01bf5c42$1409d990$[EMAIL PROTECTED] you wrote:
You've got that backwards - fork() and vfork() can easily be implemented in
terms of rfork() [in fact, I believe all three are implemented in terms of
fork1() in the kernel]. rfork(RFMEM) means that the processes share all
memory - current AND FUTURE. You could use minherit() before fork() to
share current memory, but not future memory.
BTW, concerning rfork(RFMEM). Could somebody explain me, why the
following simple program is coredumping:
#include stdio.h
#include unistd.h
volatile int data=0;
int
main()
{
volatile int pid=0;
int status;
pid=rfork(RFPROC|RFMEM|RFCFDG);
if(pid==-1) {
perror("rfork");
exit(-1);
}
if(pid!=0) {
wait(status);
printf("Data is %d\n",data);
} else
data=1;
}
---
The world is coming to an end. Please log off.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
: fork1() in the kernel]. rfork(RFMEM) means that the processes share all : memory - current AND FUTURE. You could use minherit() before fork() to : share current memory, but not future memory. : :BTW, concerning rfork(RFMEM). Could somebody explain me, why the :following simple program is coredumping: You cannot call rfork() with RFMEM directly from a C program. You have to use assembly (has anyone created a native clone() call yet to do all the hard work?). The reason is that rfork(RFMEM) does not give the new process a new stack, so both the old and new processes wind up on the same original stack and stomp all over each other. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rfork() [was: Concept check]
: : The reason is that rfork(RFMEM) does not give the new process a new : stack, so both the old and new processes wind up on the same original : stack and stomp all over each other. : :There is an implementation of clone() in the linuxthreads port, written by :Richard Seaman. : :Jason No manual page, tho :-( -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
