Re: passwd.1
On Sun, 17 Sep 2000 00:48:27 EST, "Peter Avalos" wrote: > I don't know who to contact about this, so I'm hoping some people subscribed > to this list have commit access. I found some spelling errors in passwd(1) > manpage. I have RELENG_4 installed. Here's the output of diff -u: Thanks. Your delta has been committed as rev 1.19 of passwd.1 and has been merged onto the RELENG_4 branch. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
}In message <[EMAIL PROTECTED]>you write: }}Danny Braniss ([EMAIL PROTECTED]) wrote: }}> BTW, is someone working in passing all this stuff via dhcp? im trying to co }m }}e}}> up with an almost zero admin diskless ws solution. }} }}Yes, this has been done in current for a while and was back ported to }}-stable yesterday. }} }will tryout asap. } if by -stable you mean whatever i get when i do a 'cvs co -rRELENG_4' src/sys then there are some things missing. i386/i386/autoconf.c does not have the stuff for pxe. if i compile a kernel with the BOOTP_ stuff, then i can mount nfsroot, but [mount_]mfs is broken, i get 'bad address' when trying to mount_mfs ... /conf/etc. if i see (or think i see :-) a bug in the diskless stuff who do i inform? danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: > I recently ran into revelant problem with /dev/stdout, while > working on some software under linux that expected /dev/stdout as an > argument instead of using stdout. > > Using the device file breaks, if the process is suid to a non-root > user. This is because it cannot open /dev/stdout, which is owned by your > UID and not the EUID of the process to which the device was passed. My > solution was to add the "-" hack and use the existing open descriptor. Um, open on fdesc devices doesn't check either uid. It just checks the access mode. Perhaps the software expected /dev/stdout to for read-write like a tty would be. Then opening /dev/stdout would fail for normal shell output redirection which only opens for writing. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: diskless workstation
> > if by -stable you mean whatever i get when i do a 'cvs co > -rRELENG_4' src/sys > then there are some things missing. > i386/i386/autoconf.c does not have the stuff for pxe. > if i compile a kernel with the BOOTP_ stuff, then i can mount > nfsroot, but > [mount_]mfs is broken, i get 'bad address' when trying to > mount_mfs ... /conf/etc. > > if i see (or think i see :-) a bug in the diskless stuff who > do i inform? > I think the "bad address" messages indicate that your kernel and your "world" are out of sync. Do a make world and install a freshly compiled kernel. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
4.1 make world and cvsup release field
Hello, I don't wish to jump all the way forward to -CURRENT, but would like to bring my 3.3 system up to 4.1 (would like to go beyond 4.0 for kqueue() and fxp PEX support). I would like to do this via cvsup and `make world'. My understanding is that `make world' is just buildworld followed by installworld, each a single monolithic step. Hhmm.. it seems to me that some build stages will not work without some other elements being installed. For example, my current modified 4.1 kernel will not build on a 3.3 system due to the old binutils (2.9.1 vs. 2.10). So how can a `make world' work in a monolithic build then install sequence? How do I specify 4.1 in the release field of my supfile? (The man page isn't too enlightening. Says "The supfile is as described in sup(1)". `man sup` turns up nothing. An additional blurb on the release=releasename keyword talks about traditional sup and recommends using releasename=cvs.) thanks -Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif wrote: > > What is the FreeBSD naming convention for devices of disk slices and > labels? Considering my system is installed on the first partition of > /dev/wd0 (non-dedicated), these are the block-device interfaces I > have to my disk: > > wd0 wd0cwd0fwd0s1 wd0s1cwd0s1fwd0s2 > wd0awd0dwd0gwd0s1awd0s1dwd0s1gwd0s3 > wd0bwd0ewd0hwd0s1bwd0s1ewd0s1hwd0s4 That's for up to 3.x. From 4.x, the device name is ad. > Questions: > 1. What are wd0[a-h] used for? 1) Dangerously Dedicated Disks (no slices). 2) Compatibility mode (an ugly hack) alias for the first FreeBSD slice on that disk. > 2. If wd0s1 is my first slice, why isn't it named wd0s0? Because a slice is what DOS calls a "partition table". They are numbered from 1 on, so we decided to keep the numbering to make things less confusing (which, if you think of it, is pretty silly with the partition/slice confusion). > 3. If I format wd0s2 as any type (Xenix for example), >will /dev now contain wd0s2[a-h]? No. 1. /dev is not a "magical" directory. It contains only what you put in there. 2. If you happened to have devfs, which _is_ "magical", partitions still require that a partition table exists in the slice. > Assuming /dev/wd0s2 contains a few blocks, ie /dev/wd0s1 > doesn't span to the end of disk: > 4. If I want to use /dev/wd0s2 as a raw slice for reading >and writing, what are the steps to follow? None. You just use it. > 4a. Do I need to format the partition as any type? If so > is there a recommended type (perhaps one which won't > be recognised by the bootloader would be preferable)? No, you don't need to format it, nor do you need to worry about it's type. Just make sure the slice does exist. > 4b. Should I then be using /dev/rwd0s2 or /dev/rwd0s2a > for reading and writing (of course, this is assuming > block i/o of multiples of 512 bytes)? Nope, using raw devices is almost always wrong, and we even got rid of raw device in latter versions of FreeBSD. A "raw" device is an _unbuffered_ device. It has nothing to do with formats or types. Anyway, you should be using /dev/wd0s2. Unless you partition the slice, and want to use the "a" partition. > Lastly, where else could I have found this information other > than asking on the FreeBSD mailing list? Beats me, but it _should_ be in the handbook. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "I demand that my picture show a handsome face, even if it doesn't look like me." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
Danny Braniss ([EMAIL PROTECTED]) wrote: > if by -stable you mean whatever i get when i do a 'cvs co -rRELENG_4' src/sys > then there are some things missing. > i386/i386/autoconf.c does not have the stuff for pxe. > if i compile a kernel with the BOOTP_ stuff, then i can mount nfsroot, but > [mount_]mfs is broken, i get 'bad address' when trying to > mount_mfs ... /conf/etc. That means your kernel and userland are out of sync. -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif wrote: > > If I understand correctly, wd0[a-h] will be the same as wd0s3[a-h] in a > situation where DOS is on first slice, Linux on second and FreeBSD on > third, right? But what if the fourth slice is also FreeBSD? In such a Right. > case, I'll assume you meant "booted slice" instead of "first slice", where > the slice selected when booting will be referred to by the OS as wd0[a-h] > which would translate to "current slice". Confirmation of my assumption > would be appreciated. Nope, he means "first slice", not "booted slice". I think, at some point, it might have changed to "active partition". But the fact is that the wd0[a-h] hack is very gross. Stay away from it, and always use full device specification. > > > 2. If wd0s1 is my first slice, why isn't it named wd0s0? > > wd0s0 == wd0 > > wd0s0a == wd0a > > > I somehow doubt that. Considering wd0s* goes from 1 to 4 inclusively, I > would tend to believe the first slice is wd0s1. The above is incorrect, he misunderstood your question. > > > 4. If I want to use /dev/wd0s2 as a raw slice for reading > > >and writing, what are the steps to follow? > > You can't write several blocks near /dev/wd0s2 beginning. > > Use /dev/wd0 with proper address > > > That is rather risky. Wouldn't it be safer to have a device name I could > dedicate to some purpose. In such a case, I could chown the device to an > appropriate username and group. Furthermore, I could avoid the unfortunate > mistake of overwriting my current FreeBSD fs in case I get the addresses > wrong. He is incorrect. You can use /dev/wd0s2 any way you want, as long as you have nothing of value there. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "I demand that my picture show a handsome face, even if it doesn't look like me." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Bug: NATD Problems
Hi all, CCd to freebsd-bugs (I think it exists, doesn't it?!) In every FreeBSD Snapshot I tested (2214, 2521, 2905) I always got problems regarding Natd. I have a very simple /etc/rc.firewall: /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via isp0 /sbin/ipfw add pass all from any to any And in my Kernel I have enabled IP_DIVERT and IP_FIREWALL_DEFAULT_TO_ACCEPT or however this option is called. Now my Problem: Sometimes, when I activate natd, it won't let me through. But sometimes everything works fine, sometimes it just stopps letting me through at a certain point of time... Very randomized. I think it's a very hard BUG, and it's really taking my last nerv. Are there any similar programs to natd, which I can use instead? I just want to have a working firewall MTIA -- Best Regards, Freddy = Frederik Meerwaldt ICQ: 83045387 Homepage: http://www.freddym.org Bavaria/Germany OpenVMS and Unix Howtos and much more FREEBSD, NETBSD, OPENBSD, TRU64, OPENVMS, ULTRIX, BEOS, LINUX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Weird locking issue with makemap, sendmail on a 4.1-R SMP.
Hello: I'm resending this mail here as nobody in -questions seems to have a clue about what is going on. Any ideas? Thanks for your time. - Forwarded message from Fernando Schapachnik - Subject: Weird locking issue with makemap, sendmail on a 4.1-R SMP. To: [EMAIL PROTECTED] Date: Fri, 15 Sep 2000 15:07:11 -0300 (ART) Hello: I'm having a weird problem with my SMP 4.1-RELEASE mail server: CPU: Pentium III/Pentium III Xeon/Celeron (731.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383fbff real memory = 536854528 (524272K bytes) First thing I noticed was that newaliases was getting hung. Further investigation showed the problem was ~majordom/aliases.majordom.db Running makemap hash ~majordom/aliases.majordom < ~majordom/aliases.majordom hunged also. A fstat showed only sendmail has this file open, and for reading only. A ktrace shows: [...] 87185 makemap CALL open(0xbfbff658,0x622,0x1a4) 87185 makemap NAMI "aliases.majordomo.db" [a lot of time... sent kill] 87185 makemap PSIG SIGINT SIG_DFL aliases.majordom.db ends with 0 bytes. Removing the file solves the problem. Sometimes same thing happens with virtusertable and similar aliases-related files. Today the same happened with access.db. Lsof showed sendmail 52975 root 7rR VREG 109,196608 0 35980 /etc/mail/access.db which means sendmail has the whole file locked for reading. Doing a ps -axl shows lockfs state and a sleeping process (waiting for a lock, I guess). Any ideas? Thanks in advance! - End of forwarded message from Fernando Schapachnik - Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. [EMAIL PROTECTED] (54-11) 4323- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 make world and cvsup release field
On Mon, 18 Sep 2000, Christopher Stein wrote: > > Hello, I don't wish to jump all the way forward to -CURRENT, but would > like to bring my 3.3 system up to 4.1 (would like to go beyond 4.0 > for kqueue() and fxp PEX support). > > How do I specify 4.1 in the release field of my supfile? > If you want 4.1-STABLE you need this: *default release=cvs tag=RELENG_4 On another note, this type of thing would better be suited for freebsd-questions. Peter Avalos TheShell.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 make world and cvsup release field
On Mon, 18 Sep 2000, Christopher Stein wrote: > I would like to do this via cvsup and `make world'. > My understanding is that `make world' is just buildworld followed > by installworld, each a single monolithic step. Hhmm.. it seems > to me that some build stages will not work without > some other elements being installed. For example, my current modified > 4.1 kernel will not build on a 3.3 system due to the old binutils (2.9.1 > vs. 2.10). So how can a `make world' work in a monolithic build then > install sequence? See the /usr/src/UPDATING file after updating your source and be sure to follow the directions precisely. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
On Tue 2000-09-19 (00:54), Daniel C. Sobral wrote: > > Lastly, where else could I have found this information other > > than asking on the FreeBSD mailing list? > > Beats me, but it _should_ be in the handbook. A basic device naming overview, as well as some simple disk layout information, is available in http://www.FreeBSD.org/handbook/disks.html Of course, noone reads documentation, so I don't know why I bother. (: Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to time a system call
A friend asks me what will happen if more than one process trying to read the stdin at the same time. There is no way to guarantee that any particular keyboard input will be accepted by a particular process. Since a system call is atomic, this makes me wonder how long it takes to do a system call, like read(), on a 500Mhz PC? How to time it? I later write a program that forks. So that two processes tries to read the stdin at the same time. I use read() to read one character at a time. Each process read 1000 characters and write what they read to a file. I use I/O redirect to let them read from the same file instead of keyboard. I find out that one process always call 1000 read()s before the second has a chance to call read(). I hope someone can give me a clue on how this is happening. Maybe the scheduling quantum (100ms?) is just enough for doing 1000 read() system calls. Is there any easy way to time a system call (perhaps with minor modifications of the kernel)? Any help is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
[ snip ] > > Assuming /dev/wd0s2 contains a few blocks, ie /dev/wd0s1 > > doesn't span to the end of disk: > > 4. If I want to use /dev/wd0s2 as a raw slice for reading > >and writing, what are the steps to follow? > > None. You just use it. > This is what I have in fdisk (from /stand/sysinstall): Offset SizeEnd Name PType Desc Subtype Flags 0 63 62- 6 unused0 6319375651937627wd0s1 3freebsd 165 C 1937628 1912682128895- 6 unused0 At this point, the second slice does not exist yet so I can't use it. For problems in defining a slice, see next question. > > 4a. Do I need to format the partition as any type? If so > > is there a recommended type (perhaps one which won't > > be recognised by the bootloader would be preferable)? > > No, you don't need to format it, nor do you need to worry about it's > type. Just make sure the slice does exist. > When I define a slice, I need to specify what fdisk (from sysinstall) calls a "partition type". In the case of my FreeBSD slice, I selected "165". In the case of a slice I will use for raw io, is there any reason I should use one partition type rather than another? > > 4b. Should I then be using /dev/rwd0s2 or /dev/rwd0s2a > > for reading and writing (of course, this is assuming > > block i/o of multiples of 512 bytes)? > > Nope, using raw devices is almost always wrong, and we even got rid of > raw device in latter versions of FreeBSD. A "raw" device is an > _unbuffered_ device. It has nothing to do with formats or types. > Got rid of raw devices in later versions of FreeBSD? What if I purposely want unbuffered io? There are instances, such as with databases, where the buffer cache is useless. I understand that in many cases, databases using the raw device practically reinvent the wheel by programming what is effectively another filesystem (which, by the way, is most likely slower than bsd's ffs). Even Oracle, which used to be one of the "you gotta use a raw partition if you want any speed at all" type, has moved into the "use a normal partitoin or regular file unless you do things like sharing a RAID between two hosts" camp. Yet, there are still isolated cases where raw io can be beneficial. What should I do for raw io in later versions of FreeBSD? > Anyway, you should be using /dev/wd0s2. Unless you partition the slice, > and want to use the "a" partition. > If I will be storing a few tables in /dev/wd0s2 of a predefined block aligned size, would it be advisable to use the 165 partition type for /dev/wd0s2 and create labels which will effectively become my tables? If this actually makes sense (fat chance), is there any reason I should be creating mount points? Or, if it would be better to define the labels as swap (assuming I already have a swap label in /dev/wd0s1), could FreeBSD inadvertently use those swap partitions and overwrite my data? Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PEACE - Portable Executable win32 API Compatible Environment.
In message <[EMAIL PROTECTED]> Takanori Watanabe writes: : I ported kernel part of PEACE from NetBSD.(That is in sys/compat/pecoff/*). Cool. Way Cool. : - It requires following changes to sys/imgact.h and kern/kern_exec.c to : be able to change size of memory area to hold dynamic linker argument : from executable image loader. Woof. I think this is reasonable, but will let others more qualified talk about it. I think that arch@ should likely review it if there aren't enough people doing so in emulation@. It looks good to me, but my knowledge in this area is limited and I think others with a better understanding might be able to give a better review. : - Merge the patch to precede .(Who should I ask about it?) Once the patch is reviewed, you should be able to commit the change yourself, since you have commit privs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 make world and cvsup release field
Every message I see in the archives on these points is very simple: "See /usr/src/UPDATING" Unfortunately, my system has no /usr/src/UPDATING. I have decided to go with a full net reinstall (rather than use cvsup) to take me from 3.3 to 4.1. I look forward to reading UPDATING when it lands on my system. Should make great bedtime reading. thanks -Chris On Mon, 18 Sep 2000, Kris Kennaway wrote: > On Mon, 18 Sep 2000, Christopher Stein wrote: > > > I would like to do this via cvsup and `make world'. > > My understanding is that `make world' is just buildworld followed > > by installworld, each a single monolithic step. Hhmm.. it seems > > to me that some build stages will not work without > > some other elements being installed. For example, my current modified > > 4.1 kernel will not build on a 3.3 system due to the old binutils (2.9.1 > > vs. 2.10). So how can a `make world' work in a monolithic build then > > install sequence? > > See the /usr/src/UPDATING file after updating your source and be sure to > follow the directions precisely. > > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe <[EMAIL PROTECTED]> > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- -Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ptrace help
I am experiencing problems with ptrace() under FreeBSD. I made a simple
example program to demonstrate. All it does is fork a child process to
execl() a simple "hello world" program and ptrace() it with PT_CONTINUE.
The first time around, everything is as it should be - the program is
executed and traced perfectly. However, when I attempt to repeat the whole
process, first by forking a completely new child to execute the helloworld
program again, I start getting ptrace() errors such as "Operation not
permitted" and "Device busy".
Now the weird thing is, after the first trace, the program terminates
normally, and I print out the pid of the child process which should no
longer be running at this point. ptrace(PT_KILL) verifies this by
returning "No such process". However, during the pause between the first
and second ptrace, if I do a ps and search for the pid, it shows up in
memory as running in the background, although ptrace(PT_KILL) claims it
does not exist. Then my sample program attempts to trace the same
helloworld program again, and gets "Operation not permitted" - even though
an entirely new child is fork()'d with an entirely new pid - so it should
have absolutely no connection at all to the first trace. Does anyone know
why I can't ptrace() the same helloworld program a second time?
I have attached my sample ptrace() program to this message. Thanks in
advance for any help
Patrick Alken
/*
* To run this, make a prog.c which contains:
* int main() { printf("hello world\n"); }
* and compile it into the file "prog".
*
* Then, simply: gcc -o myptrace myptrace.c
* and ./myptrace
*/
#include
#include
#include
#include
#include
#include
#include
#include
/*
DoTrace() - begin to trace a process
*/
int
DoTrace()
{
int pid; /* child pid */
int waitval;
struct reg regs;
pid = fork();
switch (pid)
{
case -1:
{
perror("fork");
break;
}
/*
* Child
*/
case 0:
{
/*
* Allow parent to trace this child process
*/
ptrace(PT_TRACE_ME, 0, 0, 0);
/*
* Execute program to be debugged and cause child to
* send a signal to parent
*/
execl("./prog", "prog", NULL);
exit(0);
}
/*
* Parent
*/
default:
{
int pret;
/*
* Wait for child to stop (execl)
*/
wait(&waitval);
printf("waitval = %d\n", waitval);
/*
* Continue exection of process
*/
pret = ptrace(PT_CONTINUE, pid, (caddr_t) 1, 0);
if (pret != 0)
{
/*
* This is where it fails the second time with an
* errno of 1 (EPERM), even though we are tracing
* a completely new pid.
*/
perror("ptrace");
}
wait(&waitval);
pret = ptrace(PT_KILL, pid, 0, 0);
if (pret == 0)
{
printf("Kill successful\n");
wait(&waitval);
}
else
printf("Kill unsuccessful, errno = %s\n",
strerror(errno));
}
}
return (pid);
} /* DoTrace() */
int
main()
{
int pid;
char buf[512];
/*
* Trace through the process
*/
pid = DoTrace();
printf("Pid1 = %d\n", pid);
fgets(buf, 512, stdin);
/*
* Trace through again (this is where it fails)
*/
pid = DoTrace();
printf("Pid2 = %d\n", pid);
return 0;
}
Re: device naming convention
On Mon 2000-09-18 (14:42), Marc Tardif wrote: > > > 4b. Should I then be using /dev/rwd0s2 or /dev/rwd0s2a > > > for reading and writing (of course, this is assuming > > > block i/o of multiples of 512 bytes)? > > > > Nope, using raw devices is almost always wrong, and we even got rid of > > raw device in latter versions of FreeBSD. A "raw" device is an > > _unbuffered_ device. It has nothing to do with formats or types. > > > Got rid of raw devices in later versions of FreeBSD? What if I purposely > want unbuffered io? There are instances, such as with databases, where the > buffer cache is useless. > > I understand that in many cases, databases using the raw device > practically reinvent the wheel by programming what is effectively another > filesystem (which, by the way, is most likely slower than bsd's ffs). Even > Oracle, which used to be one of the "you gotta use a raw partition if you > want any speed at all" type, has moved into the "use a normal partitoin or > regular file unless you do things like sharing a RAID between two hosts" > camp. > > Yet, there are still isolated cases where raw io can be beneficial. What > should I do for raw io in later versions of FreeBSD? We didn't get rid of raw devices. We got rid of block devices, and kept character devices. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif wrote:
>
> This is what I have in fdisk (from /stand/sysinstall):
> Offset SizeEnd Name PType Desc Subtype Flags
> 0 63 62- 6 unused0
> 6319375651937627wd0s1 3freebsd 165 C
> 1937628 1912682128895- 6 unused0
>
> At this point, the second slice does not exist yet so I can't use it. For
> problems in defining a slice, see next question.
Really? I wouldn't expect FreeBSD to worry about the type being
"unused".
> When I define a slice, I need to specify what fdisk (from sysinstall)
> calls a "partition type". In the case of my FreeBSD slice, I selected
> "165". In the case of a slice I will use for raw io, is there any reason I
> should use one partition type rather than another?
A type serves to, well, check the type. :-) If you don't care about the
type, nothing else will... in theory. I certainly can't see
open("/dev/ad0s2", flags) checking the type for anything. Perhaps, it
will, indeed, fail for "unused". But nothing more than that.
Other things do worry about type, of course. boot0 will identify slices
to be booted by their type. loader will list a slice's type, and try to
find the disklabel for FreeBSD slices.
> Got rid of raw devices in later versions of FreeBSD? What if I purposely
> want unbuffered io? There are instances, such as with databases, where the
> buffer cache is useless.
Oh, sorry, I got things confused. You should verify the hour at which a
message is replied for reliability... ;-)
Anyway, raw devices are character devices, unbuffered. Then, there were
the "block" devices, which were buffered. We got rid of the _block_
devices, not the raw devices. But, as we no longer have two types, we no
longer prefix them with "r".
> I understand that in many cases, databases using the raw device
> practically reinvent the wheel by programming what is effectively another
> filesystem (which, by the way, is most likely slower than bsd's ffs). Even
> Oracle, which used to be one of the "you gotta use a raw partition if you
> want any speed at all" type, has moved into the "use a normal partitoin or
> regular file unless you do things like sharing a RAID between two hosts"
> camp.
>
> Yet, there are still isolated cases where raw io can be beneficial. What
> should I do for raw io in later versions of FreeBSD?
Actually, there is little benefit in buffered device access. Buffering
is better handled elsewhere and by other means.
> > Anyway, you should be using /dev/wd0s2. Unless you partition the slice,
> > and want to use the "a" partition.
> >
> If I will be storing a few tables in /dev/wd0s2 of a predefined block
> aligned size, would it be advisable to use the 165 partition type for
> /dev/wd0s2 and create labels which will effectively become my tables? If
> this actually makes sense (fat chance), is there any reason I should be
> creating mount points? Or, if it would be better to define the labels as
> swap (assuming I already have a swap label in /dev/wd0s1), could FreeBSD
> inadvertently use those swap partitions and overwrite my data?
Well, you could, indeed, use slice type 165, and partition it. We are
limited, though, to 6 partitions. c must always be the whole slice
(minus the disklabel :), and d is better left unused for historical
reasons.
OTOH, using a partition (try to avoid using c -- if you want the whole
slice, create a partition with the same data as c) would be cleaner,
from the point of view of various utilities, than using a slice. You do
lose a few sectors.
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"I demand that my picture show a handsome face, even if it doesn't look
like me."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PnP & 4.1 Release
> > Is it possible to stop any PnP operation (checking, seting) during > > boot? > > > > Can I ask specifically what problems you're having or what you are > trying to accomplish? I want install 4.1 RELEASE on my old 486's, with ISA bus only and without bios PnP support. First has SMC EliteULTRA 8416 software selectable PnP operation - ethernet Second has Emerging Technology ET-25 (not PnP) - synchronous interface Problems (with 4.1 only, 2.2.7 works perfectly): Ad. 1 - SMC's are "unknown" for 4.1 Setting PnP "on" or "off" has no visible effect. All my card eeprom settings (port,int,mem,etc) are changed after start-up. Ad. 2 - The system hangs on start-up. May be because during PnP scanning, something was written to register. I think that If I could stop PnP scanning and setting, my problems will be solved. Best Regards, Piotr Sroczynski To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
Mike Smith wrote: > > > ok, once i compiled a kernel with options BOOTP things got better ;-) > > it worked several times, but now it boots ok, (pxe->dhcp->tftpboot->nfs) > > but after it re-configures the ethernet, the ethernet stops working! > > > > ponters anyone? > > You can't run dhclient (DHCP in any of the ifconfig lines in /etc/ > rc.conf) if you have mounted / via NFS. > > If you're running -current or a very recent -stable, remove the 'BOOTP' > options. The loader now passes all the DHCP information into the kernel. > Then leave the interface configuration alone... Has this actually been merged to -stable yet? I can't find anything that actually reads the boot.nfsroot.* loader variables. Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Tue, 19 Sep 2000, Bruce Evans wrote: > On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote: > > > I recently ran into revelant problem with /dev/stdout, while > > working on some software under linux that expected /dev/stdout as an > > argument instead of using stdout. > > > > Using the device file breaks, if the process is suid to a non-root > > user. This is because it cannot open /dev/stdout, which is owned by your > > UID and not the EUID of the process to which the device was passed. My > > solution was to add the "-" hack and use the existing open descriptor. > > Um, open on fdesc devices doesn't check either uid. It just checks > the access mode. > > Perhaps the software expected /dev/stdout to for read-write like a > tty would be. Then opening /dev/stdout would fail for normal shell > output redirection which only opens for writing. No, it wasn't a RW/W issue. I dug a little deeper. It looks like the BSD implmentation of /dev/stdout is smarter than the linux version. Linux's is a symlink into /proc and the device ownership is determined by the UID of the invoking user. I guess I wouldn't have have had a problem under BSD. no suprise here. Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
In message <[EMAIL PROTECTED]>you write: }Mike Smith wrote: }> }> > ok, once i compiled a kernel with options BOOTP things got better ;-) }> > it worked several times, but now it boots ok, (pxe->dhcp->tftpboot->nfs) }> > but after it re-configures the ethernet, the ethernet stops working! }> > }> > ponters anyone? }> }> You can't run dhclient (DHCP in any of the ifconfig lines in /etc/ }> rc.conf) if you have mounted / via NFS. }> }> If you're running -current or a very recent -stable, remove the 'BOOTP' }> options. The loader now passes all the DHCP information into the kernel. }> Then leave the interface configuration alone... } }Has this actually been merged to -stable yet? I can't find anything that }actually reads the boot.nfsroot.* loader variables. } no, last time i checked it's in SNPNG or something, but not stable. i tried some retrofitting (made the changes to autoconfig.c) got past mountroot but got stopped at 'nfs send error 65' :-( danny }Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
> > This is what I have in fdisk (from /stand/sysinstall): > > Offset SizeEnd Name PType Desc Subtype Flags > > 0 63 62- 6 unused0 > > 6319375651937627wd0s1 3freebsd 165 C > > 1937628 1912682128895- 6 unused0 > > > > At this point, the second slice does not exist yet so I can't use it. For > > problems in defining a slice, see next question. > > Really? I wouldn't expect FreeBSD to worry about the type being > "unused". > If I try the following command as root, nothing is output: # hd /dev/rwd0s2 | head Also, I tried writing a little c program to mmap(2) and, if that fails, read(2) the device. Unfortunately, that didn't work either. It seems I do actually need to define the slice as some type. The reason is maybe to define the limits of the device. Therefore, the actual type is of little importance but knowing where the device starts and stops could be important for some reason. To make the system happy, I then defined the slice as "partition type" 0, but fdisk still displayed "unused". Maybe some obscur type which doesn't appear in the bootloader would be preferable, if I find one... If this kind of information is relevant to the mailing list, I'll post what I find. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PEACE - Portable Executable win32 API Compatible Environment.
Takanori Watanabe <[EMAIL PROTECTED]> writes: > PEACE is Win32 API Compatible environment for (Originally) NetBSD. > It consist of three parts: > Kernel part to load PE format executable onto process memory space. > Dynamic Linker to link with PE format DLL. > Libraries to translate Win32 API call to NetBSD native system call. What is the difference between PEACE and WINE? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Trouble with dynamic loading of C++ libs in PHP v4.02 on FreeBSD 4.1
In article <[EMAIL PROTECTED]>, Max Khon <[EMAIL PROTECTED]> wrote: > hi, there! > > On Fri, 15 Sep 2000, John Polstra wrote: > > > Here is another possibility: we could call _thread_init() from > > crt1.o. The patch (untested) is below. It calls _thread_init() if > > and only if that symbol is defined -- i.e., libc_r is linked in. > > What do you think about this solution? > > seems ok to me but can we do this from `do_ctors' or `_init' -- they are > located in common/ That's a good point. But I would rather not do it from crtbegin since there is a good chance that we'll eventually be using the GCC version of that. However, I have some plans to unify the versions of crt1.c so that it can be moved into "common". The alpha and sparc versions are identical, and they are not very much different from the i386 version. I think a couple of platform-specific #defines or inline functions could handle all of the architecture dependencies. Note, I _don't_ want to do it using "#ifdef __i386__", etc., because that doesn't scale well for a lot of platforms and it makes the code hard to read. Instead I would prefer to #include a small platform-specific header file which defines macros and inline functions appropriately. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PEACE - Portable Executable win32 API Compatible Environment.
Dag-Erling Smorgrav wrote: > Takanori Watanabe <[EMAIL PROTECTED]> writes: > > PEACE is Win32 API Compatible environment for (Originally) NetBSD. > > It consist of three parts: > > Kernel part to load PE format executable onto process memory space. > > Dynamic Linker to link with PE format DLL. > > Libraries to translate Win32 API call to NetBSD native system call. > > What is the difference between PEACE and WINE? > Wine is actually trying to completely replace MS windows (include win3.1, win95, win98, and winnt). SO, wine includes code for the old 16 bit API(s) and it is trying to replace all on the MS dll's with built-in dll. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif writes: > > > This is what I have in fdisk (from /stand/sysinstall): > > > Offset SizeEnd Name PType Desc Subtype Flags > > > 0 63 62- 6 unused0 > > > 6319375651937627wd0s1 3freebsd 165 C > > > 1937628 1912682128895- 6 unused0 > > > > > > At this point, the second slice does not exist yet so I can't use it. For > > > problems in defining a slice, see next question. > > > > Really? I wouldn't expect FreeBSD to worry about the type being > > "unused". > > > If I try the following command as root, nothing is output: > # hd /dev/rwd0s2 | head > > Also, I tried writing a little c program to mmap(2) and, if that fails, > read(2) the device. Unfortunately, that didn't work either. It seems I do > actually need to define the slice as some type. The reason is maybe to > define the limits of the device. Therefore, the actual type is of little > importance but knowing where the device starts and stops could be > important for some reason. To make the system happy, I then defined the > slice as "partition type" 0, but fdisk still displayed "unused". Maybe > some obscur type which doesn't appear in the bootloader would be > preferable, if I find one... If this kind of information is relevant to > the mailing list, I'll post what I find. Use fdisk. See at begin and size of slices - nothing else affect until you boot or have another OS on your computer. in sysinstal last string mean that entryes for wd0s2, wd0s3 and wd0s4 are all size 0. So you can read EOF only. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 make world and cvsup release field
On Mon, 18 Sep 2000, Christopher Stein wrote: > Every message I see in the archives on these points is very simple: > > "See /usr/src/UPDATING" > > Unfortunately, my system has no /usr/src/UPDATING. Reread what I said: > See the /usr/src/UPDATING file after updating your source and be sure to > follow the directions precisely. ^^ > I have decided to go with a full net reinstall (rather than use cvsup) to > take me from 3.3 to 4.1. Cool. Probably easier all around. > I look forward to reading UPDATING when it lands on my system. Should make > great bedtime reading. :-) Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mergemaster RFC (long)
Brian Somers <[EMAIL PROTECTED]> wrote:
> > First, the things I am definitely going to do. Christian "naddy"
> > Weisgerber has taken on the task of porting mm to openbsd.
>
> I think it would be nice to aim to keep the two scripts exactly the
> same, using `uname` when it's really necessary.
If I have interpreted the noises Theo has made correctly, he wants
mergemaster in the base tree. I don't think he'll keep a "case
`uname` ..." in there.
Most of the diff deals with two simple differences:
- mergemaster uses "read -p " throughout. That fails for
OpenBSD's /bin/sh (pdksh), where "read -p" means something entirely
different.
- On OpenBSD, "install" is synonymous to "install -c". FreeBSD still
has the old behavior where plain "install" deletes the source file.
If we can get rid of those, the actual differences become more
visible.
Oh, and changing every instance of "FreeBSD" into "${OPSYS}" or
some such would remove another few diff lines.
> I think having
>
> IGNOREFILES="a b c"
>
> isn't necessary when it's as easy to have
>
> rm a b c
>
> in your start script. It seems like overkill to handle ignored files
> specifically.
Well, I don't know. Something like "IGNOREFILES=..." was the first
thing to come to my mind.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PnP & 4.1 Release
On Mon, 18 Sep 2000, Piotr Sroczynski wrote: > First has SMC EliteULTRA 8416 software selectable PnP operation > - ethernet The 'ed' driver doesn't support SMC cards in PnP mode. (Or rather it doesn't support SMC cards in non shared memory mode which is what they run in when configured via PnP.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
On 18-Sep-00 Marc Tardif wrote: >> > This is what I have in fdisk (from /stand/sysinstall): >> > Offset SizeEnd Name PType Desc Subtype Flags >> > 0 63 62- 6 unused0 >> > 6319375651937627wd0s1 3freebsd 165 C >> > 1937628 1912682128895- 6 unused0 >> > >> > At this point, the second slice does not exist yet so I can't use it. For >> > problems in defining a slice, see next question. >> >> Really? I wouldn't expect FreeBSD to worry about the type being >> "unused". >> > If I try the following command as root, nothing is output: ># hd /dev/rwd0s2 | head Look at your output you pasted above. There is no entry with the name 'wd0s2'. There is just an entry with wd0s1. Note that those unused areas are not allocated into any existing slice at the moment, and are thus not the same as a slice with a subtype of '0' indicating that the slice itself is unused. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.1 make world and cvsup release field
On Mon, Sep 18, 2000 at 02:45:06PM -0400, Christopher Stein wrote: > On Mon, 18 Sep 2000, Kris Kennaway wrote: > > See the /usr/src/UPDATING file after updating your source and be sure to > > follow the directions precisely. > > Every message I see in the archives on these points is very simple: > "See /usr/src/UPDATING" It's more like, "See /usr/src/UPDATING after updating your source." > Unfortunately, my system has no /usr/src/UPDATING. If you had updated your source, you would have /usr/src/UPDATING. - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
implementing idle-time networking
Hi, as part of my thesis research, I'm implementing something similar to the POSIX idle-time CPU scheduler for other resource types, one being network I/O. The basic idea is to substitute two-level queues for the standard ones. I'm seeing some unexpected things (explained below), but let me first outline what I'm doing exactly: 1. I extend the ifnet structure to contain a second ifqueue, for idle-time traffic; and also declare a new flag for mbufs, to indicate whether network idle-time processing should be done or not. 2. In sosend(), I check if the sending process is running at a POSIX idle-time priority. If so, I set the idle-time flag in the mbuf. 3. In ether_output_frame(), I check if the idle-time flag is set on an mbuf, and if so, enqueue it in the interface's idle-time queue (default queue otherwise.) 4. In xl_start() (my onboard chip happens to use the xl driver), I first check the default queue for any mbufs ready to send. If there are none, I try the idle-time queue. If an mbuf could be dequeued from either queue, I continue with normal outbound processing (have mbuf be picked up by NIC). Unfortunately, this scheme does not work. Some first experiments have shown that idle-time network performance is practically identical to regular-priority. I measured it going from a slower (10Mb/s) to a faster (100Mb/s) host through a private switch, so the NIC should be the bottleneck (the processors are both 800Mhz PIII). The new code is in fact executed, I have traced it heavily. Closer inspection revealed that both the ifnet ifqueues as well as the driver transmission chain are always empty upon enqueue/dequeue. Thus, even though my fancy queuing code is executed, it has no effect, since there never are any queues. Can someone shed some light on if this is expected behavior? Wouldn't that mean that as packets are being generated by the socket layer, they are handed down through the kernel to the driver one-by-one, incurring at interrupt for each packet? Or am I missing the obvious? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/University of Southern California S/MIME Cryptographic Signature
Re: 4.1 make world and cvsup release field
In message <[EMAIL PROTECTED]> Christopher Stein writes: : Unfortunately, my system has no /usr/src/UPDATING. Then you need to get newer sources. /usr/src here is the conventional code for "the path to where you keep your sources." Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Daniel C. Sobral writes: > Marc Tardif wrote: > > > > 4. If I want to use /dev/wd0s2 as a raw slice for reading > > > >and writing, what are the steps to follow? > > > You can't write several blocks near /dev/wd0s2 beginning. > > > Use /dev/wd0 with proper address > > > > > That is rather risky. Wouldn't it be safer to have a device name I could > > dedicate to some purpose. In such a case, I could chown the device to an > > appropriate username and group. Furthermore, I could avoid the unfortunate > > mistake of overwriting my current FreeBSD fs in case I get the addresses > > wrong. > He is incorrect. You can use /dev/wd0s2 any way you want, as long as you > have nothing of value there. It is English that I know bad. Labeling, partitioning so on I know MUCH better. So I take a time and dictionary and because of long letter I begin with conclusion. There is risky use any partition or slice with FreeBSD for arbitrary purposes. May be any file system except ffs can work improperly (msdos, ntfs, hpfs, 9660) Things are worst - ffs does not stable too, but this is far from subject of this letter. OK, lets verify. "cicuta/home/babolo(N)#" is prompt, number before is exit code. Look at test disk: 0cicuta/home/babolo(1)#fdisk wd0 *** Working on device /dev/rwd0 *** parameters extracted from in-core disklabel are: cylinders=1011 heads=15 sectors/track=44 (660 blks/cyl) parameters to be used for BIOS calculations are: cylinders=1011 heads=15 sectors/track=44 (660 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 50160 (24 Meg), flag 0 beg: cyl 0/ sector 1/ head 0; end: cyl 75/ sector 44/ head 14 The data for partition 2 is: sysid 0,(unused) start 50160, size 50160 (24 Meg), flag 0 beg: cyl 76/ sector 1/ head 0; end: cyl 151/ sector 44/ head 14 The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 100320, size 50160 (24 Meg), flag 0 beg: cyl 152/ sector 1/ head 0; end: cyl 227/ sector 44/ head 14 The data for partition 4 is: sysid 0,(unused) start 0, size 0 (0 Meg), flag 80 (active) beg: cyl 0/ sector 0/ head 0; end: cyl 0/ sector 0/ head 0 Now read slices: 0cicuta/home/babolo(2)#dd if=/dev/wd0s1 of=/dev/null bs=660b 76+0 records in 76+0 records out 25681920 bytes transferred in 17.175867 secs (1495233 bytes/sec) 0cicuta/home/babolo(3)#dd if=/dev/wd0s2 of=/dev/null bs=660b 1+1 records in 1+1 records out 368640 bytes transferred in 0.258831 secs (1424250 bytes/sec) 0cicuta/home/babolo(4)#dd if=/dev/wd0s3 of=/dev/null bs=660b 76+0 records in 76+0 records out 25681920 bytes transferred in 22.601690 secs (1136283 bytes/sec) 0cicuta/home/babolo(5)#dd if=/dev/wd0s4 of=/dev/null bs=660b 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) 3 equal slices, test if wd0s2 has some error in it: 0cicuta/home/babolo(6)#dd if=/dev/wd0 of=/dev/null bs=660b 1011+0 records in 1011+0 records out 341637120 bytes transferred in 283.316634 secs (1205849 bytes/sec) Whole disk read successfully. What the test system is? 0cicuta/home/babolo(7)#uname -a FreeBSD cicuta.babolo.ru 2.2.7-RELEASE FreeBSD 2.2.7-RELEASE #0: Tue Dec 29 04:10:35 MSK 1998 [EMAIL PROTECTED]:/usr/src/sys/compile/cicuta i386 0cicuta/home/babolo(8)#dmesg [skip] wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , 32-bit, multi-block-8 wd0: 325MB (667260 sectors), 1011 cyls, 15 heads, 44 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, accel, dma, iordis wcd0: 171/1367Kb/sec, 128Kb cache, audio play, 255 volume levels, ejectable tray wcd0: no disc inside, unlocked, lock protected [skip] wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice size wd0s2: start 50160, end 100319, size 50160 wd0s2c: start 50160, end 50879, size 720 wd0s3: cannot find label (no disk label) wd0s2: raw partition size != slice s
Re: PEACE - Portable Executable win32 API Compatible Environment.
In message <[EMAIL PROTECTED]>, Steve Kargl wrote: >Dag-Erling Smorgrav wrote: >> Takanori Watanabe <[EMAIL PROTECTED]> writes: >> > PEACE is Win32 API Compatible environment for (Originally) NetBSD. >> > It consist of three parts: >> > Kernel part to load PE format executable onto process memory space. >> > Dynamic Linker to link with PE format DLL. >> > Libraries to translate Win32 API call to NetBSD native system call. >> >> What is the difference between PEACE and WINE? >> > >Wine is actually trying to completely replace MS windows (include >win3.1, win95, win98, and winnt). SO, wine includes code for the >old 16 bit API(s) and it is trying to replace all on the MS >dll's with built-in dll. Yes ,but more essential difference is the way the executable binaries are treated. In FreeBSD Linux ABI support,executable binariies are treated as a executable text and kernel translate system calls so static Linux binaries can be run. ++ |Linux | | binary | |+ Lib | || +--^-+ | -v---KERNEL |Linux Syscall| |Entry| +-+ In Wine, Wine behaves as operation system that runs under FreeBSD and from FreeBSD, Windows executable is treated as data file. +Wine+ | ++ | | |Windows | | | |App.+lib| | | +^---+ | | | | +--v-| | Internal Lib | +^---+ | v--KERNEL (Native system entry) In PEACE,kernel execute PE executable (NE Win16 Binaries and DOS application is not supported) directry and prepare library imprementing win32 API by FreeBSD native system call and replace some win32 library by it. +--+ |Win32 Exec| |+some native |Lib. ++ | || +-+| |replaced lib +---^--+ | | --vKERNEL--- (Native sysent) That is my understanding. Takanori Watanabe http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html"> Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
semaphores inside kernel???
hi, i am implementing a pseudo-devicer, many instaces of this device may be active, all have to share a resource. all instances have to synchronize their access to the resource. trying to implement this, i ended up with a less powerful version of semaphores. since the resultant code became little complex, i want to replace that with the more generic semaphores. i checked the include files, but i couldn't find any semaphore functions(semget,semctl,semop) which are specific or meant for use inside kernel. does it mean they aren't available inside kernel?? if i am wrong, can someone suggest me how to use them?? thank you, mohan __ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
> 0cicuta/home/babolo(9)#dd of=/dev/wd0s2 if=/dev/zero bs=660b > 1cicuta/home/babolo(11)#od -b /dev/wd0s2 [ snip ] > Why I use 2.2.7 for test? > Because of my lovely 4.1-STABLE is extremly unstable with content of > ad0s2 (wd0s2) above and silently reboot after the first dd in the test above. > Assuming my wd0s2 is still unused and of size 0, 3.5-STABLE also crashes in the test above (no disk activity, ctrl-c doesn't work, alt-f# doesn't work either). Perhaps it eventually reboots, but I wasn't patient enough to wait that long. One solution to this problem is to specify the count blocks after which dd returns properly but still no bytes are copied. > What is slices content? > s1 - almost right FreeBSD label > s2 - not a right FreeBSD label but similar enough to label. > s3 - no label or similar at all. > How to do such a content that screw the system? > This is my way for this test: > - shorten s2 to 3 cilinder. > - disklabel -w -r wd0s2 fd360 > - restore s2 size. > I don't understand this last part, probably because I don't have much experience with labelling and partitioning. Please excuse my questions if they seem basic, but I am fairly new to disks: - how can s2 be "similar enough to label" if it is recognised as "sysid 0,(unused)" by fdisk? - how did you create s2 exactly, in order to make it "similar enough to label" yet remain unused? - how did you create s3 and s4 exactly? - why is s3 not similar at all if it is recognised as a FreeBSD slice by fdisk? - what do you mean by shortening s2 to 3 cylinders? Do you mean s2 should start at the third cylinder? - is there any reason you chose to label wd0s2 as fd360? - how should s2 size be restored? maybe: dd of=/dev/wd0s2 if=/dev/null bs=660b? > How can you guarantee that occasionally some > bits in slice do not fraud FreeBSD > if used for arbitrary bits? > Do not use slice begin at all. > I also didn't quite understand what is wrong with using the slice begin. Your octal dump showed how the first 017343 bytes were not nulls, but why? Is there a fixed number of bytes that should be skipped, or should this number be system dependent and tested manually? To avoid using the slice begin, could the first label be defined at a proper offset to skip the slice begin? Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: semaphores inside kernel???
On 19-Sep-00 Mohan Krishna P wrote: > hi, > > i am implementing a pseudo-devicer, many instaces of > this device may be > active, all have to share a resource. all instances > have to synchronize > their access to the resource. trying to implement > this, i ended up with a > less powerful version of semaphores. since the > resultant code became > little complex, i want to replace that with the more > generic semaphores. > > i checked the include files, but i couldn't find any > semaphore > functions(semget,semctl,semop) which are specific or > meant for use inside > kernel. does it mean they aren't available inside > kernel?? if i am wrong, > can someone suggest me how to use them?? In the most recent -current kernels, there is a new recursive mutex that you can use. See the mutex(9) manpage for details. > thank you, > mohan -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: implementing idle-time networking
Hi, i believe there are two things here that you need to consider before you can see any queue build up in ipq: 1. you should generate packets (way) faster than the card is able to handle them; 2. the network card itself might be able to queue multiple packets in the "transmit ring"; to check if #2 is true you should either look at the driver, or trace how fast ipq is drained (e.g. take timestamps) and see if it happens faster than the packet transmission time. re. #1, remember that on a 100Mbit net a full-sized packet goes out in some 100us, which is fast. Maybe you have already done this, but just in case, you should run your tests preferably with reasonably long (that might mean some 50-100 packets if there is queueing in the card) bursts full-sized UDP packets and on a 10Mbit/s link to see queues build up in ipq. cheers luigi > > as part of my thesis research, I'm implementing something similar to the > POSIX idle-time CPU scheduler for other resource types, one being network > I/O. The basic idea is to substitute two-level queues for the standard > ones. I'm seeing some unexpected things (explained below), but let me first > outline what I'm doing exactly: > > 1. I extend the ifnet structure to contain a second ifqueue, for idle-time > traffic; and also declare a new flag for mbufs, to indicate whether network > idle-time processing should be done or not. > > 2. In sosend(), I check if the sending process is running at a POSIX > idle-time priority. If so, I set the idle-time flag in the mbuf. > > 3. In ether_output_frame(), I check if the idle-time flag is set on an > mbuf, and if so, enqueue it in the interface's idle-time queue (default > queue otherwise.) > > 4. In xl_start() (my onboard chip happens to use the xl driver), I first > check the default queue for any mbufs ready to send. If there are none, I > try the idle-time queue. If an mbuf could be dequeued from either queue, I > continue with normal outbound processing (have mbuf be picked up by NIC). > > Unfortunately, this scheme does not work. Some first experiments have shown > that idle-time network performance is practically identical to > regular-priority. I measured it going from a slower (10Mb/s) to a faster > (100Mb/s) host through a private switch, so the NIC should be the > bottleneck (the processors are both 800Mhz PIII). The new code is in fact > executed, I have traced it heavily. > > Closer inspection revealed that both the ifnet ifqueues as well as the > driver transmission chain are always empty upon enqueue/dequeue. Thus, even > though my fancy queuing code is executed, it has no effect, since there > never are any queues. > > Can someone shed some light on if this is expected behavior? Wouldn't that > mean that as packets are being generated by the socket layer, they are > handed down through the kernel to the driver one-by-one, incurring at > interrupt for each packet? Or am I missing the obvious? > > Thanks, > Lars > -- > Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute > http://www.isi.edu/larse/University of Southern California Content-Description: S/MIME Cryptographic Signature [Attachment, skipping...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
