Memory Mapping -2
Hi, I am trying to write a PCI ethernet driver for FreeBSD 3.4 release. I have some questions 1. How can I convert physical address to virtual address . What I want is to read the physical address from the device register and to copy it to host memory. From my earlier post I found that I can use vtopys macro to convert virtual to physical address. Now I want to do the reverse. 2. What are things should I do if I want the driver to work on alpha platform also. Thanks -Pran To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Document about threads
Hey all, I have been trying to port some code to FreeBSD which currently runs under Linux (and to some degree, Solaris). Since I'm a longtime FreeBSD user, I'm pretty excited to get a chance to port to FreeBSD. The program I'm working on uses both POSIX threads and ISO C++ (including templates, exceptions, etc.), so I needed information about the current state of such things under FreeBSD. However, there wasn't any "one-stop" documentation I could find about the current state of everything. As a result, I ended up writing a brief text document which describes what I found out about threads (C++ and threads is only mentioned briefly). If anyone who knows about the state of the FreeBSD threads implementation could go through it and check it for factual errors, missing bits, etc. then that would be great. Included at the end of the document is a little bit about the planned implementation using scheduler activations for -CURRENT, but that section is almost totally just posts copied from the mailing list archives. I would be happy to contribute this information to the Documentation project if that would be preferable. The URL for the document is http://www.idiom.com/~bko/bsd/freebsd-threads.txt A few quick questions: 1. I had seen an email in the mailing list archives which asserted that C++ exceptions have been broken since August 1999 in the multithread case -- does anyone know what the status in 4.1-STABLE and -CURRENT are? I've managed to get the code to compile under FreeBSD, but it crashes quite rapidly after this, and I'm wondering if it's because of an exception being thrown. This is under 4.1-RELEASE. 2. Sometimes, the programs crash at startup, but not always. I seem to recall a recent discussion about the loader not being multi-thread safe -- was this fixed in time for 4.1-RELEASE ? Thanks, -- bryan k ogawa [EMAIL PROTECTED] http://www.primenet.com/~bkogawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
hi, there! On Fri, 25 Aug 2000, Bryan K. Ogawa wrote: 1. I had seen an email in the mailing list archives which asserted that C++ exceptions have been broken since August 1999 in the multithread case -- does anyone know what the status in 4.1-STABLE and -CURRENT are? I've managed to get the code to compile under FreeBSD, but it crashes quite rapidly after this, and I'm wondering if it's because of an exception being thrown. This is under 4.1-RELEASE. this issue is unrelated to threads. FreeBSD stock g++ 2.95.2 compiler uses -fsjlj-exceptions mechanism for exception handling which is broken (g++ sometimes generates incorrect code even without any optimization options given). It is not FreeBSD-specific behaviour. gcc GNATS has bug report with similar gcc behaviour under OS/390. uou can still use /usr/ports/lang/egcs -- this is the same 2.95.2 but it uses DWARF2 unwinding info for exception handling -- the same mechanism that is used by default under Linux and (IIRC) Solaris. I believe that FreeBSD g++ will switch to this scheme in near future. I have initial set of patches that adds support to FreeBSD CRT startups for loading info from .eh_frame ELF sections needed for DWARF2 unwinding info mechanism to work. David O'Brien has all the information. I think he can shed some light on this issue (he is gcc/binutils maintainer) but he seems to be busy with other tasks -- I still haven't got any replies from him except "go ahead, it would be nice to have this feature" :) 2. Sometimes, the programs crash at startup, but not always. I seem to recall a recent discussion about the loader not being multi-thread safe -- was this fixed in time for 4.1-RELEASE ? yes, I beleive /fjoe PS you will also have problems with shared libraries debugging (see PR/20373). I have solution for this problem too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
tape buffer size - scsi
Sorry, I posted this already in 'questions' but since it is very urgent to my tape read back withing the next couple of hours I'm posting my plea here also: I'm trying to read a DAT tape with important backup data. The device is a DEC TLZ04. sa0 at ncr0 bus 0 target 4 lun 0 sa0: DEC TLZ04 1989(C)DEC 1915 Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers When trying to read it (tar tvf /dev/rsa0) I'm getting a kernel message: (sa0:ncr0:0:4:0): 132497-byte tape record bigger than suplied buffer Any ideas? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory Mapping -2
* Pran Joseph [EMAIL PROTECTED] [000825 00:11] wrote: Hi, I am trying to write a PCI ethernet driver for FreeBSD 3.4 release. I have some questions 1. How can I convert physical address to virtual address . What I want is to read the physical address from the device register and to copy it to host memory. From my earlier post I found that I can use vtopys macro to convert virtual to physical address. Now I want to do the reverse. Um, I'm not sure what you mean here, a physical memory location can be mapped vitually anywhere :), you have to keep track of the virtual address somehow in your driver. 2. What are things should I do if I want the driver to work on alpha platform also. Don't use i386 assumptions? example: use PAGE_SIZE rather than hardcoding 4096, make sure you're using busdma rather than hardcoding all your stuff. Lastly buy and alpha. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
perlcc in current - xs_init and boot_DynaLoader
If i do a perlcc test.pl i get the folllowing , in CURRENT ? Must i define something beforehand, or is it broken ? -Wl,-E -lperl -lm -L/usr/libdata/perl/5.6.0/mach/CORE -lperl -lm -lc -lcrypt /usr/libdata/perl/5.6.0/mach/auto/IO/IO.so /usr/libdata/perl/5.6.0/mach/auto/Fcntl/Fcntl.so /tmp/ccJ97508.o: In function `xs_init': /tmp/ccJ97508.o(.text+0x33a4): undefined reference to `boot_DynaLoader' ERROR: In compiling code for test.pl.c ! -- Unix Software Developer/Engineer E-Mail: Johan Kruger [EMAIL PROTECTED] Date: 25-Aug-00 Time: 11:53:40 All good things come to those who ... runs FreeBSD -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Preventing zombies to occure
Hello,
I have some ideas to improve fork()-ing and getting rid of zombie processes.
This things mentioned here are proposed of a man that do not know very well
(author means 'the depths' of) BSD kernel source although he have some ex-
pirience with it (mainly in reading it :-).
By definition zombie is a process entry in proc table that wasn't released
by wait*() called form the parent's code. So all we need to do is to ensure
that parent will call wait*() as many times as it called fork(). This meth-
od have some advantages but it has some disadvantages too. First of all,
we
provide programmers all users with full out-of-zombies enviroment where
everything created will be destroyed in the right way. Second, proposed
me-
thod is easy to include in current source with minnor modifications.
What I exactly mean is:
1) Adding 'int childs' field in 'struct proc' in /usr/src/sys/sys/proc.h
That field will store current numbers of childs for the process entry. After
creation of process it is initialized to zero and incremented by one after
each fork(). The real incrementation may be done by *fork() or fork1() from
/usr/src/sys/kern/kern_fork.c - it doesn't matter. In this way we may keep
track of number of childs; how many times process fork()s; to limit number
of fork()s per process and etc.
2) Setting up an 'at-exit()' function that will call wait*() as many
ti-
mes as needed. It could probably look something like that:
void release_childs(p)
struct proc *p;
{
int rc;
while(p-childs != 0) /* Release all childs in a loop by
{ * wait()-ing each of them to exit
rc = wait(NULL);*/
if(rc == -1)
{
printf(" Can NOT release all childs \n");
/*
* Any other steps to proceed here
*/
return;
}
p-childs--; /* Decreasing the number of childs left*/
}
return;
}
And the code to call the above somewhere in fork1() (probably):
. . .
at_exit(release_childs());
. . .
3) Of course, any program may still use wait*() functions to ensure right
exiting of each childs, but the new wait*() functions should include some
bits
of code like this (probably the right place for it is /usr/src/sys/kern/kern_
exit.c -- wait1()):
. . .
q-childs--;
. . .
By doing this, the code will take care only for childs that wasn't wait()-
ed or
'forgotten' by the parent process due to programmer's mistake or bad algorithm.
This code probably may be improved a lot but for now it is still in 0.1
version
:-) so please excuse my "kernel-C". (All mentioned-bug comments are wellcome).
That's all by now. If you think there is something usefull in the ideas
menti-
oned above please drop me a letter to encourage me. I am unix new programmer
with little experience but I'd like to help anyone that develops BSD and
espe-
cially FreeBSD by introdusing ideas that I found worthable in my works.
Please
excuse my code if it isn't as tight as it should be but I am only 18-years-
old
high-school student with interests in OS development and almost any information
about it. (If you can, send me any kind of programming resources oriented
to BSD
and other Unices).
Thanks for reading this long borring letter.
Looking forward to hearing from you.
ix
[EMAIL PROTECTED]
Re: Preventing zombies to occure
[EMAIL PROTECTED] wrote: Hello, I have some ideas to improve fork()-ing and getting rid of zombie processes. This things mentioned here are proposed of a man that do not know very well (author means 'the depths' of) BSD kernel source although he have some ex- pirience with it (mainly in reading it :-). I'll betray some of my own ignorance here, but what about processes where the parent exits before the child? For example, when starting a server, it is customary for the foreground process to fork a background child to be the actual server process and then exit. You might be able to work around that problem and the one you are tackling by adding some smarts to exit(2) so that when a process exits, it checks to see if any of its children are zombies and clears them if so, and for a process to not become a zombie upon exit(2) unless it's parent is still around. -- 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: Preventing zombies to occure
* [EMAIL PROTECTED] [EMAIL PROTECTED] [000825 03:14] wrote: Hello, I have some ideas to improve fork()-ing and getting rid of zombie processes. This things mentioned here are proposed of a man that do not know very well (author means 'the depths' of) BSD kernel source although he have some ex- pirience with it (mainly in reading it :-). By definition zombie is a process entry in proc table that wasn't released by wait*() called form the parent's code. So all we need to do is to ensure that parent will call wait*() as many times as it called fork(). This meth- od have some advantages but it has some disadvantages too. First of all, we provide programmers all users with full out-of-zombies enviroment where everything created will be destroyed in the right way. Second, proposed me- thod is easy to include in current source with minnor modifications. [snip] If a parent that has zombie children exits the kernel will attach them to init (I haven't checked, but this is the common unix solution). init will be calling waitpid to clear zombies automagically. So this sorta already happens. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Merging ACPI related code is on the way.
Hi, I have committed orthognal part of ACPI driver. The rest part will be committed after a few days. I put the part at URL:http://people.freebsd.org/~takawata/sysdiff. This can be applied for HEAD. Please test and report about it if there is serious problem,such as breaking build. Thanks. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a 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
RE: Preventing zombies to occure
I have some ideas to improve fork()-ing and getting rid of
zombie processes.
This things mentioned here are proposed of a man that do
not know very well
(author means 'the depths' of) BSD kernel source although
he have some ex-
pirience with it (mainly in reading it :-).
By definition zombie is a process entry in proc table that
wasn't released
by wait*() called form the parent's code. So all we need to
do is to ensure
that parent will call wait*() as many times as it called
fork(). This meth-
od have some advantages but it has some disadvantages too.
First of all,
we
provide programmers all users with full out-of-zombies
enviroment where
everything created will be destroyed in the right way.
Second, proposed
me-
thod is easy to include in current source with minnor modifications.
[snip]
If a parent that has zombie children exits the kernel will attach them
to init (I haven't checked, but this is the common unix solution).
init will be calling waitpid to clear zombies automagically.
So this sorta already happens. :)
two ways:
first:
something like
SIGCHLD_handler(int)
{
while (waitpid(-1, NULL, 0))
;
}
you need to handle SIGCHLD, otherwise you will have zombies.
second:
use SA_NOCLDWAID flag in sigaction(2)
in this case ``init'' will be responsible for zombie process
thanks,
emax
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Preventing zombies to occure
* Yevmenkin, Maksim N, CSCIO [EMAIL PROTECTED] [000825 05:59] wrote:
[snip]
If a parent that has zombie children exits the kernel will attach them
to init (I haven't checked, but this is the common unix solution).
init will be calling waitpid to clear zombies automagically.
So this sorta already happens. :)
two ways:
first:
something like
SIGCHLD_handler(int)
{
while (waitpid(-1, NULL, 0))
;
}
This could be wrong if:
[EINTR]The call was interrupted by a caught signal, or the
signal did not have the SA_RESTART flag set.
more proper (paraniod) would be:
int
sigchld_handler(int)
{
while (waitpid(-1, NULL, 0) || errno == EINTR)
;
}
you need to handle SIGCHLD, otherwise you will have zombies.
second:
use SA_NOCLDWAID flag in sigaction(2)
in this case ``init'' will be responsible for zombie process
typo: should be 'SA_NOCLDWAIT'.
Sorry to pick, but one must be careful.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
this issue is unrelated to threads. FreeBSD stock g++ 2.95.2 compiler uses -fsjlj-exceptions mechanism for exception handling which is broken (g++ sometimes generates incorrect code even without any optimization options given). It is not FreeBSD-specific behaviour. gcc GNATS has bug report with similar gcc behaviour under OS/390. There was a bug in -fsjlj-exceptions code generation related to shared libraries and to best of my knowledge the correct fix has been imported into the official gcc CVS tree and was merged into FreeBSD some time ago. Are there any other errors you know about? If there are any simple code snippets which can demonstrate the problem, I am willing to investigate it further and see if it can be fixed. -fsjls-exceptions errors should be fixed regardless of whether FreeBSD is going to switch to DWARF scheme or not. 4.x-STABLE is here to stay for quite some time and I doubt that it will ever be changed to use DWARF unwinding. -- E-Mail: Alexander N. Kabaev [EMAIL PROTECTED] Date: 25-Aug-00 Time: 09:45:59 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tape buffer size - scsi
On Fri, Aug 25, 2000 at 10:52:49AM +0200, Christoph Kukulies wrote: Sorry, I posted this already in 'questions' but since it is very urgent to my tape read back withing the next couple of hours I'm posting my plea here also: Ooops. I must have been very nervous about getting my tape read back that I made so many typos. I finally solved it. The tape was written a bit weird at then. dd if=/dev/rsa0 ibs=256k | tar zxvf - solved the problem. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preventing zombies to occure
On Fri, Aug 25, 2000 at 02:19:28PM +, [EMAIL PROTECTED] wrote: Hello, Hi ix By definition zombie is a process entry in proc table that wasn't released by wait*() called form the parent's code. So all we need to do is to ensure A zombie can only occur with a *live* parent. If the parent exits, it's orphaned children are automatically inherited by init (Pid 1) which is a very well written program that will wait on any exiting child ( or even a bunch of zombies inherited from a dysfunctional parent ). So your solution is already there in the system. The solution (if one is even desired :) should be along these line: Instead of discarding SIGCHLD which is issued when the child exits, it should have a default handler which would check if indeed that is the case and wait on that child (in other words what a good programmer should do for himself :) Naief To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd and non-preemtive threads
* Robert Watson [EMAIL PROTECTED] [000821 18:01] wrote: For reference, my recollection is that peemption-aware userland thread libraries tend to make alot of timer syscalls, losing some of the advantage of being a userland thread library (low context switch cost, few transistions between user/kerneland). The AFS LWP code included a fasttime() mechanism that took advantage of the ability to mmap kernel memory under SunOS, allowing direct access to the timer variable in kernel, without a context switch. I do not believe that native ports to Linux/FreeBSD/et al have retained this capability, especially given its requirements for privilege. However, it would be easy to imagine a kernel module exporting a /dev/time, which had the singular ability of allowing the mmaping of a page containing only the kernel's timer variables, permitting syscall-free precise time access from userland using atomic memory access calls. I think phk and I discussed this about a year ago, our idea was to automatically map the segment in for each process (also allowing things like getpid and such to be accessable). It would be nice to see happen either way (mmap'able /dev/time or automatically) If it's a uni-processor machine, could you use the cycle counter register? I wrote a driver under FreeBSD 3.0 for the Datum bc635PCI which allowed a process to mmap() the device registers of this board. With two memory references, you'd get a timestamp with 100ns resolution, which was handy for a bunch of tasks. I don't know that a /dev/time would give you sufficient resolution, as convienient memory-based stuff would only be updated everytime hardclock() ran, at HZ times per second. The gettimeofday(), etc., routines do some other fiddling (like the TSC register, or reading other programmable timer devices). louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
From: "Bryan K. Ogawa" [EMAIL PROTECTED]
If anyone who knows about the state of the FreeBSD threads implementation
could go through it and check it for factual errors, missing bits, etc.
then that would be great.
in your section about common reentrant extensions, you mention the IPv6
apis. these are currently _not_ a viable alternative to the missing
traditional gethostby{name,addr}_r entrypoints due to a bug in KAME. they
are not threadsafe. your process will deadlock if multiple threads call
getipnodeby{addr,name}. see http://orange.kame.net/dev/query-pr.cgi?pr=277.
--
-greg
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Anyone try the new dual-head G-400 drivers?
Hello! I am a SysAdmin at GTE, 'er Verizon, and we are doing something simular. We tried using the freebie stuff with Xfree86 4.0.1 but found it to be extreamly buggy... both on Linux and FreeBSD. The solution we found works best is paying the 129 bucks and getting the drivers from AcceleratedX (I think it supports up to eight monitors). We are using the Matrox DUAL Head AGP card. It's been about three weeks and I have had no problems at all... in fact, I will defend to the death anyone that comes in and tries to take eight one of my two 21" monitors! I'm telling you, once you use it for a few hours you will never want to go back. ...no the task of talking the wife into a second 21" monitor for the house :) AcceleratedX has demo drivers, but be warned that they only work ten minutes before it dumps you back at the command prompt-- it doesn't care what you are doing. Hope this helps a bit. /tg thomas r stromberg wrote: We're looking at buying some workstations for our network admins here, and dual head is a plus. We were looking at buying them from hardware.bsdi.com, and then today on Slashdot I saw: - Matrox has released a beta driver for their G200/G400/G450 which includes support for DualHead and QuadHead (up to 4 monitors), Flat Panel and TV out. This driver is a beta. You can get it here and I mirrored it here. You'll need XFree 4.0.1 in order to use this driver. Please follow the readme file carefully! (the readme file from Matrox's FTP needs to be converted dos2unix). Note: you cannot use the 3D hardware acceleration on the 2nd monitor (yet). - And of course, I was instantly happy when I saw this.. Has anyone tried these drivers yet in FreeBSD? They look to be the OS-independant XFree86 4.0.1 modules (nothing funky like the NVIDIA ones). They come with some source code, but it appears to be wrappers around a missing HAL (?) library, though I could be wrong. Please forward any successes/failures to the list. -- thomas r. stromberg: [EMAIL PROTECTED] senior systems administrator : http://www.afterthought.org/ research triangle commerce, inc. :1.919.657.1317 -- --- Timothy Grzechowski[EMAIL PROTECTED] --- GTE Data Services AAIS Engineering, Sys. Admin. --- Office: 813/978-4327 Office FAX: 813/978-6812 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
hi, there!
On Fri, 25 Aug 2000, Alexander N. Kabaev wrote:
There was a bug in -fsjlj-exceptions code generation related to shared
libraries and to best of my knowledge the correct fix has been imported into
the official gcc CVS tree and was merged into FreeBSD some time ago. Are there
any other errors you know about? If there are any simple code snippets which can
demonstrate the problem, I am willing to investigate it further and see if
it can be fixed. -fsjls-exceptions errors should be fixed regardless of whether
FreeBSD is going to switch to DWARF scheme or not. 4.x-STABLE is here to stay
for quite some time and I doubt that it will ever be changed to use DWARF
unwinding.
this is definitely not the case with shared libraries -- I know about that
bug and the fix was merged to FreeBSD CVS source tree somewhere around
beginning of this year. unfortunately I have no simple code snippets and
have no time to investigate it further. but I have an application that
demonstrates this bug: Reactor_Exceptions_Test from ACE wrappers
(you can get ACE wrappers from http://www.cs.wustl.edu/~schmidt/).
the test itself is quite simple snippet but you will need to build ACE to
run it. please look at #413 and #258 in gcc GNATS.
all that I found is that emitted setjmp got optimized during flow analysis
stage in such way that when exception is raised execution continues
in try { } block (yes, again) instead of place where decision is taken in
which catch { } block the execution should be continued.
I do not know about any other 2.95.2 bugs.
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Memory Mapping -2
In message [EMAIL PROTECTED] Pran Joseph writes: : 1. How can I convert physical address to virtual address . What I want : is to read the physical address from the device register and to copy it : to host memory. From my earlier post I found that I can use vtopys : macro to convert virtual to physical address. Now I want to do the : reverse. : : 2. What are things should I do if I want the driver to work on alpha : platform also. Use the bus space macros. These will generally obviate the need to to the vtophys and ptovirt sorts of things. I don't think FreeBSD has a ptovirt these days. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preventing zombies to occure
'Alfred Perlstein' wrote:
int
sigchld_handler(int)
{
while (waitpid(-1, NULL, 0) || errno == EINTR)
;
}
Even more paranoid would be
int
sigchld_handler(int)
{
int e = errno;
while (waitpid(-1, NULL, 0) || errno == EINTR)
;
errno = e;
}
otherwise you could get bogus errors reported, I think.
if ((fp = fopen(foo, "r")) == NULL)
/* SIGCHLD arrives here */
warn("can't open foo");
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Preventing zombies to occure
* Ben Smithurst [EMAIL PROTECTED] [000825 10:15] wrote:
'Alfred Perlstein' wrote:
int
sigchld_handler(int)
{
while (waitpid(-1, NULL, 0) || errno == EINTR)
;
}
Even more paranoid would be
int
sigchld_handler(int)
{
int e = errno;
while (waitpid(-1, NULL, 0) || errno == EINTR)
;
errno = e;
}
otherwise you could get bogus errors reported, I think.
if ((fp = fopen(foo, "r")) == NULL)
/* SIGCHLD arrives here */
warn("can't open foo");
The code I presented is flawed as a result of an allnighter dealing
with postresql. I'll enjoy thinking about this over the weekend. :)
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Preventing zombies to occure
'Alfred Perlstein' wrote:
int
sigchld_handler(int)
{
while (waitpid(-1, NULL, 0) || errno == EINTR)
;
}
actually, shouldn't you use WNOHANG when calling waitpid() there? What
I normally do is
int e = errno;
while (waitpid(-1, NULL, WNOHANG) 0)
;
errno = e;
But I think I'm drifting from the original point.
--
Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tape buffer size - scsi
On Fri, Aug 25, 2000 at 10:52:49AM +0200, Christoph Kukulies wrote: Sorry, I posted this already in 'questions' but since it is very urgent to my tape read back withing the next couple of hours I'm posting my plea here also: I'm trying to read a DAT tape with important backup data. The device is a DEC TLZ04. sa0 at ncr0 bus 0 target 4 lun 0 sa0: DEC TLZ04 1989(C)DEC 1915 Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers When trying to read it (tar tvf /dev/rsa0) I'm getting a kernel message: (sa0:ncr0:0:4:0): 132497-byte tape record bigger than suplied buffer Any ideas? The tape has probably been written by a non-FreeBSD machine. Like an SGI or something like that. They can do much larger blocksizes. I think FreeBSD is limited to 64k (??). W/ -- Wilko Bulte [EMAIL PROTECTED] Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anyone try the new dual-head G-400 drivers?
On Fri, Aug 25, 2000 at 11:52:18AM -0400, Tim Grzechowski wrote: We tried using the freebie stuff with Xfree86 4.0.1 but found it to be extreamly buggy... both on Linux and FreeBSD. Could you describe `extremely buggy'? Did you open any problem reports with the XFree86 guys? I have been using the Matrox G400 Dual-Head AGP card with XFree86 4.0.1 + Matrox's Linux driver since August 18 with zero problems. Works perfectly. I was previously using a Matrox Millenium II AGP + Matrox Millenium II PCI since the XFree86 3.9 days. Like you, I will kill anyone who attempts to make off with one of my monitors :-) -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Merging ACPI related code is on the way.
I have committed orthognal part of ACPI driver. The rest part will be committed after a few days. I put the part at URL:http://people.freebsd.org/~takawata/sysdiff. This can be applied for HEAD. Please test and report about it if there is serious problem,such as breaking build. It seems OK for me. BTW, I've just added new file in CVS; sys/dev/acpi/acpi_powerres.c. You need to have the following line in sys/conf/files. dev/acpi/acpi_powerres.coptionalacpi Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perlcc in current - xs_init and boot_DynaLoader
If i do a perlcc test.pl i get the folllowing , in CURRENT ? Must i define something beforehand, or is it broken ? I'll take a look... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Auto DMA vs. Manual DMA Settings... FBSD 3.51
Reposted to -HACKERS Hiya... I am having an issue with the wd driver (from FBSD 3.51). Once a customer kernel (having the flags 0xa0ffa0ff for wd) is booted, I get screen-full's of this error message when there is any hard drive access: DMA failure, DMA status 5active I can "slow down" or degrade my DMA settings in the BIOS to avoid this message, but I'm sure I am taking a performance penalty in doing this. For more history, please refer to: http://www.freebsd.org/cgi/mid.cgi?db=mid[EMAIL PROTECTED] ... where this was covered back in December 1999 - I had hoped that this would have been resolved by now. System hardware - Maxtor UDMA66 drive, motherboard only supports UDMA33 however, so that's not really an issue. My question ... can I use the ad driver from 4.x with 3.51-RELEASE? This problem doesn't occur under 4.0 or 4.1-RELEASE/STABLE. If this is possible ... how? Thanks for any thoughts (or even solutions) :) Regards ... Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Moving FreeBSD towards glibc (or: FreeBSD and Hurd/Mach)
Hello, [please Cc: to me, since I'm not subscribed to this list. Thanks] are there plans to replace FreeBSD's libc with GNU glibc in the near or medium future? Linux moved also from it's own libc5 to glibc (=libc6) some time ago and it may be useful to do the same in FreeBSD too. The reason I'm asking this is to investigate further, wether the Hurd can be dropped into a FreeBSD system as an alternative to the current FreeBSD kernel. As you probably know, Keio University and NTT provide a RT-Mach/Lites package that can be installed into a FreeBSD 2.2.8 system and which, when booted, provides binary compatibility with the means of the system call redirection feature of Mach. Such a system feels like an original FreeBSD system and is a good development platform for Mach programming. The Lites server used by RT-Mach is a user-land single OS-Server that contains most of the 4.4 BSD-Lite code to emulate a *BSD kernel. It is still monolithic in the sense that it is a single task with multiple threads. As opposed to the single-OS Server Lites, the Hurd is a set of OS-Servers that run on top of Mach and that seek to replace Unix. They actually provide Unix API compatibility through the current version of glibc which translates Unix calls into (mainly) RPCs to the appropriate Hurd servers. The Hurd is still under development but is already working reasonably well for development purposes. Actually, people at Debian are trying to put up a debian-style distribution of GNU/Hurd, that will resemble Debian/Linux. Once such a systems is ready, Hurd-0.3 will be released. As FreeBSD user, I strongly dislike the debian style currently favorized but there is not much that can be done against it. What I'm trying to do, is to figure out how to add binary compatibility to the Hurd in the same way than is done with RT-Mach/Lites, so that ultimatly, the Hurd/Mach can be added as an alternative kernel to a current FreeBSD distribution. This is one way how the Hurd can be installed in a FreeBSD distribution: 1. Replace libc with glibc and create a glibc-based FreeBSD distribution. The Hurd/Glibc/Mach can now be compiled like a regular FreeBSD port and installed in a subdirectory somewhere (say: /usr/local/hurd). Rebooting the Mach kernel would load the Hurd servers first and would then invoke the regular FreeBSD rc scripts. Each FreeBSD binary that is linked against FreeBSD glibc would now be transparently relinked against the Hurd's glibc, which would call the servers and Mach in appropriate ways. Other libs [that don't contain traps] can be used unchanged. 2. Statically linked binaries and other binaries (like Linux etc...) would need more work to be supported. There, the syscall redirection mechanism of Mach would still be needed. Should this mechanism be implemented in the Hurd, providing binary compatibility to FreeBSD could be possible, even without having to move FreeBSD to glibc in the first place. An easier and probably faster way would be to provide specially compiled versions of those static programs that would be used instead of the FreeBSD ones while running the Hurd. Yet having the possibility to transparently link FreeBSD binaries against the Hurd's glibc instead of the hypothetical FreeBSD glibc would have the enormous advantage to reduce the syscall overhead that is induced by the syscall redirection facility. What would you suggest? -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving FreeBSD towards glibc (or: FreeBSD and Hurd/Mach)
On Sat, 26 Aug 2000, Farid Hajji wrote: Hello, [please Cc: to me, since I'm not subscribed to this list. Thanks] are there plans to replace FreeBSD's libc with GNU glibc in the near or medium future? I think I can safely say: "No." 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: Moving FreeBSD towards glibc (or: FreeBSD and Hurd/Mach)
[please Cc: to me, since I'm not subscribed to this list. Thanks] are there plans to replace FreeBSD's libc with GNU glibc in the near or medium future? Linux moved also from it's own libc5 to glibc (=libc6) some time ago and it may be useful to do the same in FreeBSD too. No, that is not going to happen. The reason I'm asking this is to investigate further, wether the Hurd can be dropped into a FreeBSD system as an alternative to the current FreeBSD kernel. Using a non-FreeBSD kernel with GNU libc would pretty much make it not FreeBSD anymore. FreeBSD is what it is; if you don't like most of it, then may I suggest that you use one of the alternatives that better suits your needs. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving FreeBSD towards glibc (or: FreeBSD and Hurd/Mach)
* Farid Hajji [EMAIL PROTECTED] [000825 21:03] wrote: Hello, [please Cc: to me, since I'm not subscribed to this list. Thanks] are there plans to replace FreeBSD's libc with GNU glibc in the near or medium future? Linux moved also from it's own libc5 to glibc (=libc6) some time ago and it may be useful to do the same in FreeBSD too. hahahaha no. The reason I'm asking this is to investigate further, wether the Hurd can be dropped into a FreeBSD system as an alternative to the current FreeBSD kernel. I'm going to have to cut you short here, what's them point of this? I read the rest of your message and basically what you seem to want to do is port the FreeBSD userland to Hurd, that's what you need to do. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving FreeBSD towards glibc (or: FreeBSD and Hurd/Mach)
Kris Kennaway wrote: On Sat, 26 Aug 2000, Farid Hajji wrote: Hello, [please Cc: to me, since I'm not subscribed to this list. Thanks] are there plans to replace FreeBSD's libc with GNU glibc in the near or medium future? I think I can safely say: "No." Not only "No" but "Hell No". Why would we want to replace our functional, proven libc code with the GPL virus? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving FreeBSD towards glibc (or: FreeBSD and Hurd/Mach)
On Saturday, August 26, 2000, Farid Hajji wrote: are there plans to replace FreeBSD's libc with GNU glibc in the near or medium future? Linux moved also from it's own libc5 to glibc (=libc6) some time ago and it may be useful to do the same in FreeBSD too. There are no such plans for that type of downgrade. If the software you need to use externally calls nonstandard C library functions consider porting the library and linking it manually, or fixing the software: cc -o my-hurd-program -nostdlib -lglibc ... or something along those lines. -- |Chris Costello [EMAIL PROTECTED] |You can't make a program without broken egos. `- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Auto DMA vs. Manual DMA Settings... FBSD 3.51
On Fri, 25 Aug 2000, Jamie Hermans wrote: I am having an issue with the wd driver (from FBSD 3.51). Once a customer kernel (having the flags 0xa0ffa0ff for wd) is booted, I get screen-full's of this error message when there is any hard drive access: DMA failure, DMA status 5active I can "slow down" or degrade my DMA settings in the BIOS to avoid this message, but I'm sure I am taking a performance penalty in doing this. It may be that: a) your cable is damaged; b) your system is too noisy; c) your disks proclaim UDMA capability but can't actually deliver it. http://www.freebsd.org/cgi/mid.cgi?db=mid[EMAIL PROTECTED] ... where this was covered back in December 1999 - I had hoped that this would have been resolved by now. System hardware - Maxtor UDMA66 drive, motherboard only supports UDMA33 however, so that's not really an issue. I'd suggest upgrading to a proper DMA66 cable and see if that helps. My question ... can I use the ad driver from 4.x with 3.51-RELEASE? This problem doesn't occur under 4.0 or 4.1-RELEASE/STABLE. If this is possible ... how? No, the ata driver is not available on 3.X. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sysctl from kernel
Thanks for your help ! If someone would be kind enough to answer them, I have a few other questions. I'm currently trying to modify sysctl_kern_proc() function in src/sys/kern/kern_proc.c But, to modify it, I must understand it first ;-) First, this sysctl is supposed to give the list of the running processes, but where this information is stored ? The function returns an int so it's probably not this :-) Second, what is an "oib" ? There are a lot of oib related stuff with sysctl and I can't understand what it is. Thanks for all future help. Maxime Henrion Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Maxime Henrion writes: Hi, I'm new to the FreeBSD kernel and I wanted to know what are the good methods to read a sysctl value from the kernel. Is it the same interface as in user-space ? Any help or links to some documentation would be greatly appreciated :) Look at the kernel_sysctl() function in src/sys/kern/kern_sysctl.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
