Re: 3x read to write ratio on dump/restore
Hi Warner, On Friday 09 January 2009 17:50:27 M. Warner Losh wrote: > I just copied a disk using dump + restore. I noticed something > through the whole run of this 500GB operation: > > L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name > 3231231 147549.5 0 00.0 97.5| da1s1a > 0 39 0 00.0 39 4982 10.0 38.7| da2s1a > > The read kBps was 3x the write kBps. While the dump is going through > the raw device, and the restore is going through the file system, I > can't imagine why we'd have such a huge difference that would be utter > consistent for the whole 15 hour run. > > Any ideas what gives? I observed this with 16MB cache and with 32MB > cache, fwiw. I've noticed this too. Last week I upgraded a laptop harddisk and used dump + restore to copy files from the original harddisk (attached to the laptop using a USB bracket). During the entire copy process I also saw about a 3x difference. -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
support for i45 (ich10) chipsets
I just got a i45 based motherboard and everything works except for the following pci: no...@pci0:1:0:0: class=0x02 card=0x83671043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet does -current support it or should I stay with 7.1-RELEASE ? (i386) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
On Thu, Jan 08, 2009 at 09:50:47PM -0800, per...@pluto.rain.com wrote: > > In principle, everything that would be successfully created if > open(2)'ed. It doesn't necessarily need to actually create them, > but the results from readdir(2) should be as if they had been > created. The whole point of things like ls(1) and readdir(2) is > to find out what-all is available to be opened, without having to > already know the answer. That's not how devfs works. It's actually a feature that devfs doesn't list everything ever possible (things looked terrible back in the old MAKEDEV days with all those polluted names). I'd rather be able to list to see things that are in use, although at first glance I didn't like devfs hidden nodes. Otherwise you'd be stuck printing tunXXX through infinity instead of this: % ls /dev/tun* /dev/tun0 /dev/tun115 /dev/tun194 Maybe you could argue that dsp should work differently, but some sound cards and configurations would give you infinite (within reason) device nodes, IIRC. > > This is a FAQ really. > > It may be an FAQ, but it is also a bug, granted one that may not be > easy to fix. This is not a bug, it is designed behavior. It was intentionally written to dynamically create device nodes when needed. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/dsp* & /dev/audio* devices not present
On Thu, 08.01.2009 at 21:50:47 -0800, per...@pluto.rain.com wrote:
> Ulrich Spoerlein wrote:
Ummm, out of curiosity, are your receiving your mail via UUCP? :)
> > Please run
> > % cat /dev/sndstat
> > % ls -l /dev/dsp0 /dev/dsp0.0
> >
> > The reason you are not seeing them with 'ls /dev/dsp*' is because
> > devfs is creating the nodes when they are open(2)'ed. Using shell
> > globbing will search the output of readdir(2) for matches to dsp*
> > where devfs has no way of dynamically creating nodes (which ones
> > should it create anyway?)
>
> In principle, everything that would be successfully created if
> open(2)'ed. It doesn't necessarily need to actually create them,
> but the results from readdir(2) should be as if they had been
> created. The whole point of things like ls(1) and readdir(2) is
> to find out what-all is available to be opened, without having to
> already know the answer.
Not according to my understanding, which may be flawed of course.
devfs(4) would have to create all devices, which may be open(2)ed up
front, for dsp that would have to be 32 instances (for my system):
% ll /dev/dsp0.{0,9,11,21,31}
crw-rw-rw- 1 root wheel0, 142 Jan 9 20:57 /dev/dsp0.0
crw-rw-rw- 1 root wheel0, 153 Jan 9 20:20 /dev/dsp0.11
crw-rw-rw- 1 root wheel0, 154 Jan 9 20:20 /dev/dsp0.21
crw-rw-rw- 1 root wheel0, 151 Jan 9 20:20 /dev/dsp0.31
crw-rw-rw- 1 root wheel0, 152 Jan 9 20:20 /dev/dsp0.9
It would also cloud the information about devices in-use.
> > This is a FAQ really.
>
> It may be an FAQ, but it is also a bug, granted one that may not be
> easy to fix.
You really want all cloneable instances to show up with a readdir, which
would mean that they would have to created upon device attachment? I
really don't think so ... For /dev/dsp0 the semantics are pretty clear:
try to open /dev/dsp0, if it succeeds fine, if not, there is no vchan
available and you're SOL. No need to play the guess-a-free-dsp-device
game.
Cheers,
Ulrich Spoerlein
--
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Fri, Jan 09, 2009 at 07:42:32PM +0200, Kostik Belousov wrote: > On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote: > > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: > > > Brian Fundakowski Feldman wrote: > > >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: > > >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > > >>> > > It appears that the post-fork hooks for malloc(3) are somewhat broken > > such that > > when a threaded program forks, and then its child attempts to go > > threaded, it > > deadlocks because it already appears to have locks held. I am not > > familiar > > enough with the current libthr/libc/rtld-elf interaction that I've > > been able > > to fix it myself, unfortunately. > > >>> There's really nothing to fix - according to POSIX you are only > > >>> allowed to call async-signal-safe functions in the child forked > > >>> from a threaded process. If you are trying to do anything other > > >>> than that, it may or may not work on FreeBSD, but it is not > > >>> guaranteed and is not portable. > > >>> > > >>> The rationale is that what is the point of forking and creating > > >>> more threads, when you can just as easily create more threads in > > >>> the parent without forking? The only reason to fork from a threaded > > >>> process is to call one of the exec() functions. > > >> > > >> Well, it worked until the last major set of changes to malloc. For me, > > >> the point > > >> was that I was able to have transparent background worker threads in any > > >> program > > >> regardless of its architecture, using the standard pthread fork hooks. > > >> Could you > > >> point me to the POSIX section covering fork and threads? If it's really > > >> not > > >> supposed to work then that's fine, but there's an awful lot of code > > >> there dedicated > > >> to support going threaded again after a fork. > > >> > > > > > > Practically, you can't go threaded again after a fork > > > (by which I mean creating new threads or use things > > > like mutexes etc.) in any posix system I know of. > > > > > > It would require that: > > > The forking thread stop until: > > > Every other thread has released every resource it owns > > > and reports itself to be in a "safe quiescent state", > > > or at least report every resource it owns, especially > > > locks, > > > and > > > After the fork: > > > The child, post fork, to take ownership of all > > > of them, and free them. > > > > > > You might be able to do that in a simple > > > threaded program, but consider then that the libraries may have > > > threads running in them of which you are unaware, and that > > > some of the resources may interract with resources owned by the > > > forking thread. > > > > > > Add to this that there may be a signal thrown into this mix as well > > > > > > (signals are the bane of thread developement) > > > > Well, I wouldn't mind showing all of you what I can of what I had been doing > > with the background threads -- it works pretty well modulo this particular > > malloc lock bug. Due to it being inappropriate to share library resources > > between a child and parent for an open socket connection, I always > > considered > > the only "safe" behavior to be going single-threaded for the duration of > > the fork > > processes in both the parent and child, and the pthread_atfork(3) hooks > > have been > > sufficient to do so. > > > In fact, try recent HEAD, it contains the fixed for deadlocks caused by > fork calls in mt processes. Also, see r185456, that may be directly > relevant to your problem. > > The MFC to the stable/7 is doable, but depends on the MFC of some stuff > committed by David Xu, that would take me some time to look into. Ah, thank you for the pointer. Seems this is an opportunity for me to catch up with our switch to SVN, then. I'll take a further look at this this weekend. For reference, these platforms passed the particular regression test I posted: Linux 2.6.18-92.1.17.el5 SunOS 5.10 Generic_137138-09 Darwin macintosh.green.homeunix.org 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008;root:xnu-1228.9.59~1/RELEASE_I386 i386 FreeBSD 7.0-RELEASE -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> gr...@freebsd.org \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Having a problem of kernel panic
Kamlesh Patel wrote: Hi all, I am having a problem of kernel panic in FreeBSD 7.0: In sys/boot/forth/beastie.4th variable rebootkey variable mykey (added line) After building and installing the kernel, when i reboot the system it gives me the following error: --- " panic: free: guard1 fail @ 0x6e104 from /usr/src/sys/boot/i386/loader/../../common/module.c:959 --> Press a key on the console to reboot <-- " How do i recover the system from this error. I can't reload the loader.old Could anyone please help me? it's the loader that is crashing, not the kernel. (at least that is what it looks like to me) maybe reinstall loader from cd? actually you should be able to bypass the loader using the bootblocks.. teh sysntax is arcane but you get a chance to enter something in the bootblocks before the loader. (hit space) replace /boot/loader with /boot/kernel/kernel in teh string (I think... it's been a long time since I tried this.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Having a problem of kernel panic
Hi all, I am having a problem of kernel panic in FreeBSD 7.0: In sys/boot/forth/beastie.4th variable rebootkey variable mykey (added line) After building and installing the kernel, when i reboot the system it gives me the following error: --- " panic: free: guard1 fail @ 0x6e104 from /usr/src/sys/boot/i386/loader/../../common/module.c:959 --> Press a key on the console to reboot <-- " How do i recover the system from this error. I can't reload the loader.old Could anyone please help me? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Fri, Jan 09, 2009 at 11:34:26AM -0500, Brian Fundakowski Feldman wrote: > On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: > > Brian Fundakowski Feldman wrote: > >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: > >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: > >>> > It appears that the post-fork hooks for malloc(3) are somewhat broken > such that > when a threaded program forks, and then its child attempts to go > threaded, it > deadlocks because it already appears to have locks held. I am not > familiar > enough with the current libthr/libc/rtld-elf interaction that I've been > able > to fix it myself, unfortunately. > >>> There's really nothing to fix - according to POSIX you are only > >>> allowed to call async-signal-safe functions in the child forked > >>> from a threaded process. If you are trying to do anything other > >>> than that, it may or may not work on FreeBSD, but it is not > >>> guaranteed and is not portable. > >>> > >>> The rationale is that what is the point of forking and creating > >>> more threads, when you can just as easily create more threads in > >>> the parent without forking? The only reason to fork from a threaded > >>> process is to call one of the exec() functions. > >> > >> Well, it worked until the last major set of changes to malloc. For me, > >> the point > >> was that I was able to have transparent background worker threads in any > >> program > >> regardless of its architecture, using the standard pthread fork hooks. > >> Could you > >> point me to the POSIX section covering fork and threads? If it's really > >> not > >> supposed to work then that's fine, but there's an awful lot of code there > >> dedicated > >> to support going threaded again after a fork. > >> > > > > Practically, you can't go threaded again after a fork > > (by which I mean creating new threads or use things > > like mutexes etc.) in any posix system I know of. > > > > It would require that: > > The forking thread stop until: > > Every other thread has released every resource it owns > > and reports itself to be in a "safe quiescent state", > > or at least report every resource it owns, especially > > locks, > > and > > After the fork: > > The child, post fork, to take ownership of all > > of them, and free them. > > > > You might be able to do that in a simple > > threaded program, but consider then that the libraries may have > > threads running in them of which you are unaware, and that > > some of the resources may interract with resources owned by the > > forking thread. > > > > Add to this that there may be a signal thrown into this mix as well > > > > (signals are the bane of thread developement) > > Well, I wouldn't mind showing all of you what I can of what I had been doing > with the background threads -- it works pretty well modulo this particular > malloc lock bug. Due to it being inappropriate to share library resources > between a child and parent for an open socket connection, I always considered > the only "safe" behavior to be going single-threaded for the duration of the > fork > processes in both the parent and child, and the pthread_atfork(3) hooks have > been > sufficient to do so. > In fact, try recent HEAD, it contains the fixed for deadlocks caused by fork calls in mt processes. Also, see r185456, that may be directly relevant to your problem. The MFC to the stable/7 is doable, but depends on the MFC of some stuff committed by David Xu, that would take me some time to look into. pgpzFbJ3BCzH2.pgp Description: PGP signature
Re: threaded, forked, rethreaded processes will deadlock
Brian Fundakowski Feldman wrote: On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: Brian Fundakowski Feldman wrote: On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: It appears that the post-fork hooks for malloc(3) are somewhat broken such that when a threaded program forks, and then its child attempts to go threaded, it deadlocks because it already appears to have locks held. I am not familiar enough with the current libthr/libc/rtld-elf interaction that I've been able to fix it myself, unfortunately. There's really nothing to fix - according to POSIX you are only allowed to call async-signal-safe functions in the child forked from a threaded process. If you are trying to do anything other than that, it may or may not work on FreeBSD, but it is not guaranteed and is not portable. The rationale is that what is the point of forking and creating more threads, when you can just as easily create more threads in the parent without forking? The only reason to fork from a threaded process is to call one of the exec() functions. Well, it worked until the last major set of changes to malloc. For me, the point was that I was able to have transparent background worker threads in any program regardless of its architecture, using the standard pthread fork hooks. Could you point me to the POSIX section covering fork and threads? If it's really not supposed to work then that's fine, but there's an awful lot of code there dedicated to support going threaded again after a fork. Practically, you can't go threaded again after a fork (by which I mean creating new threads or use things like mutexes etc.) in any posix system I know of. It would require that: The forking thread stop until: Every other thread has released every resource it owns and reports itself to be in a "safe quiescent state", or at least report every resource it owns, especially locks, and After the fork: The child, post fork, to take ownership of all of them, and free them. You might be able to do that in a simple threaded program, but consider then that the libraries may have threads running in them of which you are unaware, and that some of the resources may interract with resources owned by the forking thread. Add to this that there may be a signal thrown into this mix as well (signals are the bane of thread developement) Well, I wouldn't mind showing all of you what I can of what I had been doing with the background threads -- it works pretty well modulo this particular malloc lock bug. Due to it being inappropriate to share library resources between a child and parent for an open socket connection, I always considered the only "safe" behavior to be going single-threaded for the duration of the fork processes in both the parent and child, and the pthread_atfork(3) hooks have been sufficient to do so. a well going single threaded for the duration of the fork, changes everything! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kernel dump with 7.1-RELEASE
Hi, I am having kernel dump with FreeBSD 7.1: Here is crashinfo output of it (Actually i don't know the state of crashinfo in Fbsd 7.1) 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 r...@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 panic: semexit - semid not allocated GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Physical memory: 8173 MB Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38 22 6 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:195 #1 0x0004 in ?? () #2 0x804b4ce9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x804b50f2 in panic (fmt=0x104 ) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x804f846d in semexit_myhook (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/sysv_sem.c:1328 #5 0x80490dbc in exit1 (td=0xff000995f370, rv=0) at /usr/src/sys/kern/kern_exit.c:244 #6 0x8049239e in sys_exit (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:109 #7 0x8078a7c7 in syscall (frame=0xb0d4ac80) at /usr/src/sys/amd64/amd64/trap.c:907 #8 0x8077088b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #9 0x000800a2a30c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
3x read to write ratio on dump/restore
I just copied a disk using dump + restore. I noticed something through the whole run of this 500GB operation: L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 3231231 147549.5 0 00.0 97.5| da1s1a 0 39 0 00.0 39 4982 10.0 38.7| da2s1a The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. Any ideas what gives? I observed this with 16MB cache and with 32MB cache, fwiw. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: > Brian Fundakowski Feldman wrote: >> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that when a threaded program forks, and then its child attempts to go threaded, it deadlocks because it already appears to have locks held. I am not familiar enough with the current libthr/libc/rtld-elf interaction that I've been able to fix it myself, unfortunately. >>> There's really nothing to fix - according to POSIX you are only >>> allowed to call async-signal-safe functions in the child forked >>> from a threaded process. If you are trying to do anything other >>> than that, it may or may not work on FreeBSD, but it is not >>> guaranteed and is not portable. >>> >>> The rationale is that what is the point of forking and creating >>> more threads, when you can just as easily create more threads in >>> the parent without forking? The only reason to fork from a threaded >>> process is to call one of the exec() functions. >> >> Well, it worked until the last major set of changes to malloc. For me, the >> point >> was that I was able to have transparent background worker threads in any >> program >> regardless of its architecture, using the standard pthread fork hooks. >> Could you >> point me to the POSIX section covering fork and threads? If it's really not >> supposed to work then that's fine, but there's an awful lot of code there >> dedicated >> to support going threaded again after a fork. >> > > Practically, you can't go threaded again after a fork > (by which I mean creating new threads or use things > like mutexes etc.) in any posix system I know of. > > It would require that: > The forking thread stop until: > Every other thread has released every resource it owns > and reports itself to be in a "safe quiescent state", > or at least report every resource it owns, especially > locks, > and > After the fork: > The child, post fork, to take ownership of all > of them, and free them. > > You might be able to do that in a simple > threaded program, but consider then that the libraries may have > threads running in them of which you are unaware, and that > some of the resources may interract with resources owned by the > forking thread. > > Add to this that there may be a signal thrown into this mix as well > > (signals are the bane of thread developement) Well, I wouldn't mind showing all of you what I can of what I had been doing with the background threads -- it works pretty well modulo this particular malloc lock bug. Due to it being inappropriate to share library resources between a child and parent for an open socket connection, I always considered the only "safe" behavior to be going single-threaded for the duration of the fork processes in both the parent and child, and the pthread_atfork(3) hooks have been sufficient to do so. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> gr...@freebsd.org \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: threaded, forked, rethreaded processes will deadlock
On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote: On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: It appears that the post-fork hooks for malloc(3) are somewhat broken such that when a threaded program forks, and then its child attempts to go threaded, it deadlocks because it already appears to have locks held. I am not familiar enough with the current libthr/libc/rtld-elf interaction that I've been able to fix it myself, unfortunately. There's really nothing to fix - according to POSIX you are only allowed to call async-signal-safe functions in the child forked from a threaded process. If you are trying to do anything other than that, it may or may not work on FreeBSD, but it is not guaranteed and is not portable. The rationale is that what is the point of forking and creating more threads, when you can just as easily create more threads in the parent without forking? The only reason to fork from a threaded process is to call one of the exec() functions. Well, it worked until the last major set of changes to malloc. For me, the point was that I was able to have transparent background worker threads in any program regardless of its architecture, using the standard pthread fork hooks. Could you point me to the POSIX section covering fork and threads? If it's really not supposed to work then that's fine, but there's an awful lot of code there dedicated to support going threaded again after a fork. I don't know if this link will work for you, but you can start here: http://www.opengroup.org/onlinepubs/009695399/nframe.html "It is suggested that programs that use fork() call an exec function very soon afterwards in the child process, thus resetting all states. In the meantime, only a short list of async-signal-safe library routines are promised to be available." -- DE -- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Small change to 'ps'
On Wed, 7 Jan 2009 09:27:24 -0800 "Sheldon Givens" wrote: > And I guess I just feel like running a second command to do what should be > possible to do with the first command (and is, on many platforms. ps > --no-headers on linux for example) is a problem and presents opportunity for > continued refinement of the utility. I agree. However, I think we might want to look at a broader scope, in that the same argument applies to pretty much every command that outputs headers - if you're feeding the output to a program, you probably don't want the headers, and copying all the output through another process for the sole purpose of removing them seems wasteful. That we already have commands in the base system that implement this functionality would imply that others agree with this. So `--no-headers' is ok. However, `-n' has lots of different meanings in different commands. How about borrowing from existing commands that already implement this functionality (zfs and zpool) and using `-H', which is relatively rarely used elsewhere? http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Threads and SMP kernel scheduling
Hi, Thank you very much again Ulf. I found this http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library and it describes 1:1 correspondence of Linux threads. So, you were right and thank you very much again. Regards, Mehmet On Thu, Jan 8, 2009 at 4:59 PM, Ulf Lilleengen wrote: > On tor, jan 08, 2009 at 09:16:26am -0500, Mehmet Ali Aksoy TÜYSÜZ wrote: > > Hi, > > > > Thank you very much for your response Ulf. It is a very clear answer. > Thanks > > again. > > > > By the way, any information for the Linux case? > > > I think this applies to Linux as well, since it's NPTL(Native Posix > Threading > Library) uses a 1:1 mapping also. I'm not 100% sure, so you might want to > ask > on a linux mailing list. > > -- > Ulf Lilleengen > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
kernel panic
Hi there, I changed the following file of FreeBSD 7.0: sys/boot/forth/beastie.4th variable rebootkey variable mykey (added line) I built and installed kernel, then i reboot the system, it gives me the following error: --- " panic: free: guard1 fail @ 0x6e104 from /usr/src/sys/boot/i386/loader/../../common/module.c:959 --> Press a key on the console to reboot <-- " How do i recover the system from this error. I can't reload the loader.old Could anyone please help me? Kamlesh MS CS, CSUS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
