Re: bash2 or devfs problem?
In message <[EMAIL PROTECTED]>, "Simon 'portlint ' Schubert" writes: >> These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2, >>and so on, refer to files accessible through file descriptors. If file >>descriptor n is open, these two system calls have the same effect: >>fd = open("/dev/fd/n",mode); >>fd = dup(n); > >i read that only concerning *open* fds. (you can't dup a closed >[non-existant] fd). > >furthermore i think there was a patch floating around addressing exactly >this issue. perhaps it was even committed (i'm too lazy to search for >it). solution was to test in configure for additional fds accessible >from /dev/fd/* and build without that feature if not. Well, as far as I know we don't need a patch, we just need to mount fdescfs then. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic at soreceive()?
Hello, Starting pppd(8) on yesterday -current produces a panic: miss# gdb kernel.84 -k vmcore.84 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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 "i386-undermydesk-freebsd"... panic: KSE not on run queue panic messages: --- panic: receive: m == 0 so->so_rcv.sb_cc == 192 sys/kern/uipc_socket.c, line 856 syncing disks, buffers remaining... 902 902 900 900 900 900 900 panic: KSE not on run queue Uptime: 21m58s Dumping 63 MB ata0: resetting devices .. done [CTRL-C to abort] 16 32 48 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc01b19bf in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc01b1bb4 in poweroff_wait (junk=0xc02dd2bb, howto=-1054260288) at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc01bf118 in sched_rem (ke=0xc02dd2bb) at /usr/src/sys/kern/sched_4bsd.c:593 #4 0xc01b5288 in adjustrunqueue (td=0xc12943c0, newpri=180) at /usr/src/sys/kern/kern_switch.c:305 #5 0xc01bef90 in sched_prio (td=0x0, prio=0 '\0') at /usr/src/sys/kern/sched_4bsd.c:505 #6 0xc01becb4 in schedcpu (arg=0x0) at /usr/src/sys/kern/sched_4bsd.c:337 #7 0xc01bc579 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:195 #8 0xc01a3200 in ithread_loop (arg=0xc0a01200) at /usr/src/sys/kern/kern_intr.c:536 #9 0xc01a2694 in fork_exit (callout=0xc01a30e0 , arg=0xc0a01200, frame=0xc5ecad48) at /usr/src/sys/kern/kern_fork.c:871 (kgdb) quit -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -O2 breaks GCC 3.2.1-compiled code (seems OS specific)
On 11 Mar 2003 03:52:18 +0200 Dan Naumov <[EMAIL PROTECTED]> wrote: > Hello list. > > Since my issues are related to 5.0, I though I'd rather ask here. I've > noticed an interesting problem: I am using FreeBSD 5.0-p4 and GCC 3.2.1 > and if I use "CPUTYPE=athlon-tbird" and "CFLAGS= -O2 -mmmx -m3dnow > -fomit-frame-pointer -pipe", ezm3 refuses to compile AT ALL and even > though AbiWord 1.0.4 does compile, it will always coredump on exit, > preventing saving of any changes done to the Preferences. However, going > down from -O2 to -O solved both problems. > > This makes me wonder what exactly is wrong, since I've used exactly the > same CPUTYPE and CFLAGS under Gentoo Linux with GCC 3.2.1 for a long > time and everything compiled absolutely fine. This leads me to believe > that there are not only arch-specific, but also OS-specific GCC issues. > Can anyone else confirm this ? need to add -fno-schedule-insns2 to your CFLAGS to get ezm3 to compile with -O2... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE test code?
On Mon, Mar 10, 2003 at 11:53:40AM -0800, Julian Elischer wrote: > cd /usr/lib/libpthreads > make > make install > This installs a libkse which, when we are happy with it will become > libpthreads, but until then it has this special name.. > > get some test threads programs and link with -lkse > remember to disable -pthreads > > see what happens. > There is a fix for ^Z being committed in the next day or so.. > Hi, I tried to compile the test under libpthread but ended up waiting for it to finish with : Test static library: -- Test c_user c_system c_total chng passed/FAILEDh_user h_system h_total % chng -- hello_d 0.00 0.000.00 passed -- hello_s 0.00 0.010.01 passed -- join_leak_d 0.15 0.090.24 *** FAILED *** -- mutex_d Anything I've missed? Jiawei -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-O2 breaks GCC 3.2.1-compiled code (seems OS specific)
Hello list. Since my issues are related to 5.0, I though I'd rather ask here. I've noticed an interesting problem: I am using FreeBSD 5.0-p4 and GCC 3.2.1 and if I use "CPUTYPE=athlon-tbird" and "CFLAGS= -O2 -mmmx -m3dnow -fomit-frame-pointer -pipe", ezm3 refuses to compile AT ALL and even though AbiWord 1.0.4 does compile, it will always coredump on exit, preventing saving of any changes done to the Preferences. However, going down from -O2 to -O solved both problems. This makes me wonder what exactly is wrong, since I've used exactly the same CPUTYPE and CFLAGS under Gentoo Linux with GCC 3.2.1 for a long time and everything compiled absolutely fine. This leads me to believe that there are not only arch-specific, but also OS-specific GCC issues. Can anyone else confirm this ? Sincerely, -- Dan Naumov <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Anadolu' nun 7 harikasý seçiliyor ... HLZXGPGRVU
Sizi anadolunun 7 harikası seçimine katılmaya çağırıyoruz. 7 harika seçiminde halen aday belirleme sürecindeyiz. Seçime katılmasını istediğiniz adaylarınızı http://www.7woa.com adresinden bizlere iletebilirsiniz. Saygılarımızla www.7woa.com Not : Bu mail size tek bir defalık 7 wonders of Anatolia Projesini bildirmek için gönderilmiştir. Düzenli olarak haber bültenimizin şahsınıza ulaşmasını isterseniz. http://www.7woa.com adresinden mail listemize kayıt olmanız gerekmektedir. İstenmeyen sebepler ile mail mesajı birden fazla tarafınıza ulaştı ise özür dileriz. HLZXGPGRVUONRJGDYCYDPOJJEPWISVXRGRZTUU -- Virus taramasi Vexira AV programi kullanilarak Is Net tarafindan yapilmistir. This e-mail is checked by Is Net against all known types of viruses using Vexira AV. Is Net'in en ucuz saatlik kullanim paketi Teneffus.Net'i ve en ucuz sinirsiz erisim paketi Taksitli Ekonet'i duymus muydunuz? http://www.isnet.net.tr/teneffusnet/ http://www.isnet.net.tr/taksitliekonet/
Re: bash2 or devfs problem?
Lately Larry Rosenman told: > --On Tuesday, March 11, 2003 00:38:08 +0100 Poul-Henning Kamp > <[EMAIL PROTECTED]> wrote: > > In message <[EMAIL PROTECTED]>, Conrad Sabatier > > writes: > >> Apparently, the nodes for the named pipes are not being created as they > >> should. > >> > >> Is this a bash problem, or something in devfs not working as expected? > > That's a good question... > > > > Has anybody found out what the standards conformant thing is for /dev/fd ? > > > > presently we do only 0,1 & 2, with the std{in,out,err} symlinks. > > > > If we are required to do all filedescriptors, we should do so with > > fdescfs by default. > It is supposed to (based on MY reading of the fd(4) man page on a UnixWare > (SysVr5) system) > be ALL filedescriptors. > > this paragraph seems to be the cogent part: > > These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2, >and so on, refer to files accessible through file descriptors. If file >descriptor n is open, these two system calls have the same effect: >fd = open("/dev/fd/n",mode); >fd = dup(n); i read that only concerning *open* fds. (you can't dup a closed [non-existant] fd). furthermore i think there was a patch floating around addressing exactly this issue. perhaps it was even committed (i'm too lazy to search for it). solution was to test in configure for additional fds accessible from /dev/fd/* and build without that feature if not. cheers simon -- /"\ http://corecode.ath.cx/#donate \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News pgp0.pgp Description: PGP signature
Re: bash2 or devfs problem?
--On Tuesday, March 11, 2003 00:38:08 +0100 Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: In message <[EMAIL PROTECTED]>, Conrad Sabatier writes: I've noticed that bash's process substitution fails under -CURRENT. For (an admittedly stupid, trivial) example: diff <(cat file1) <(cat file2) errors out with: diff: /dev/fd/63: No such file or directory diff: /dev/fd/62: No such file or directory Apparently, the nodes for the named pipes are not being created as they should. Is this a bash problem, or something in devfs not working as expected? That's a good question... Has anybody found out what the standards conformant thing is for /dev/fd ? presently we do only 0,1 & 2, with the std{in,out,err} symlinks. If we are required to do all filedescriptors, we should do so with fdescfs by default. It is supposed to (based on MY reading of the fd(4) man page on a UnixWare (SysVr5) system) be ALL filedescriptors. this paragraph seems to be the cogent part: These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2, and so on, refer to files accessible through file descriptors. If file descriptor n is open, these two system calls have the same effect: fd = open("/dev/fd/n",mode); fd = dup(n); The full manpage is visible at: http://www.lerctr.org:8458/en/man/html.4/fd.4.html LER -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-ports" in the body of the message -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash2 or devfs problem?
< There is no standard, other than Tenth Edition and Plan 9. Most > programs which use it expect it to behave like one or the other. s/one or the other/that/ -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash2 or devfs problem?
< said: > Has anybody found out what the standards conformant thing is for /dev/fd ? There is no standard, other than Tenth Edition and Plan 9. Most programs which use it expect it to behave like one or the other. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash2 or devfs problem?
In message <[EMAIL PROTECTED]>, Conrad Sabatier writes: >I've noticed that bash's process substitution fails under -CURRENT. > >For (an admittedly stupid, trivial) example: > >diff <(cat file1) <(cat file2) > >errors out with: > >diff: /dev/fd/63: No such file or directory >diff: /dev/fd/62: No such file or directory > >Apparently, the nodes for the named pipes are not being created as they should. > >Is this a bash problem, or something in devfs not working as expected? That's a good question... Has anybody found out what the standards conformant thing is for /dev/fd ? presently we do only 0,1 & 2, with the std{in,out,err} symlinks. If we are required to do all filedescriptors, we should do so with fdescfs by default. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NULL pointer problem in pid selection ?
On Tue, 2003/03/11 at 08:43:46 +1100, Tim Robbins wrote: > On Mon, Mar 10, 2003 at 01:00:15PM -0500, John Baldwin wrote: > > > On 08-Mar-2003 Kris Kennaway wrote: > > > On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote: > > >> > > >> Just got this crash on -current, and I belive I have seen similar > > >> before. addr2line(1) reports the faulting address to be > > >> ../../../kern/kern_fork.c:395 > > >> which is in the inner loop of pid collision avoidance. > > > > > > I've been running this patch from Alfred for the past month or so on > > > bento, which has fixed a similar panic I was seeing regularly. > > > > Using just a shared lock instead of an xlock should be ok there. You > > aren't modifying the process tree, just looking at it. OTOH, the > > proc lock is supposed to protect p_grp and p_session, so they shouldn't > > be NULL. :( > > I have a suspiscion that the bug is actually in wait1(): > > sx_xlock(&proctree_lock); > [...] > /* >* Remove other references to this process to ensure >* we have an exclusive reference. >*/ > leavepgrp(p); > > sx_xlock(&allproc_lock); > LIST_REMOVE(p, p_list); /* off zombproc */ > sx_xunlock(&allproc_lock); > > LIST_REMOVE(p, p_sibling); > sx_xunlock(&proctree_lock); > > > Shouldn't we be removing the process from zombproc before setting > p_pgrp to NULL via leavepgrp()? Does this even matter at all when both > fork1() and wait1() are still protected by Giant? Hmmm, I think you're right; if allproc_lock happens to be contested in fork1() (which can happen because it it is locked without Giant held in some places, and because sleeping with an sx lock is allowed), we'll go to sleep there, dropping Giant. This opens up a race, since wait1() can now proceed until after the leavepgrp() before blocking; when allproc_lock is released, fork1() will be the first to pick it up, and this panic will happen. Seems that I relied on Giant too much when I first took a look into that code :) - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NULL pointer problem in pid selection ?
On 10-Mar-2003 Tim Robbins wrote: > On Mon, Mar 10, 2003 at 01:00:15PM -0500, John Baldwin wrote: > >> On 08-Mar-2003 Kris Kennaway wrote: >> > On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote: >> >> >> >> Just got this crash on -current, and I belive I have seen similar >> >> before. addr2line(1) reports the faulting address to be >> >> ../../../kern/kern_fork.c:395 >> >> which is in the inner loop of pid collision avoidance. >> > >> > I've been running this patch from Alfred for the past month or so on >> > bento, which has fixed a similar panic I was seeing regularly. >> >> Using just a shared lock instead of an xlock should be ok there. You >> aren't modifying the process tree, just looking at it. OTOH, the >> proc lock is supposed to protect p_grp and p_session, so they shouldn't >> be NULL. :( > > I have a suspiscion that the bug is actually in wait1(): > > sx_xlock(&proctree_lock); > [...] > /* >* Remove other references to this process to ensure >* we have an exclusive reference. >*/ > leavepgrp(p); > > sx_xlock(&allproc_lock); > LIST_REMOVE(p, p_list); /* off zombproc */ > sx_xunlock(&allproc_lock); > > LIST_REMOVE(p, p_sibling); > sx_xunlock(&proctree_lock); > > > Shouldn't we be removing the process from zombproc before setting > p_pgrp to NULL via leavepgrp()? Does this even matter at all when both > fork1() and wait1() are still protected by Giant? Giant doesn't help you with sleeps. However, removing the process from zombproc before destroying it's other linkages might be more correct, yes. > Tim -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: softupdates && write cache && ata tags topic
Hi, > > Write cacheing is automatically enabled if tagged queueing is enabled > and supported by the disk, so I doubt you're seeing any improvement at > all. I must admit: My statements are based on experience with SCSI Tagged Queuing and SCSI Write Cache. I hope I'm correct if I assume that the ATA features have not only the same name but the same functionality. I wasn't aware, that they are coupled by the driver code... Thanks for your commment/correction - Matthias To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bash2 or devfs problem?
I've noticed that bash's process substitution fails under -CURRENT. For (an admittedly stupid, trivial) example: diff <(cat file1) <(cat file2) errors out with: diff: /dev/fd/63: No such file or directory diff: /dev/fd/62: No such file or directory Apparently, the nodes for the named pipes are not being created as they should. Is this a bash problem, or something in devfs not working as expected? -- Conrad Sabatier <[EMAIL PROTECTED]> - "In Unix veritas" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NULL pointer problem in pid selection ?
On Mon, Mar 10, 2003 at 01:00:15PM -0500, John Baldwin wrote: > On 08-Mar-2003 Kris Kennaway wrote: > > On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote: > >> > >> Just got this crash on -current, and I belive I have seen similar > >> before. addr2line(1) reports the faulting address to be > >> ../../../kern/kern_fork.c:395 > >> which is in the inner loop of pid collision avoidance. > > > > I've been running this patch from Alfred for the past month or so on > > bento, which has fixed a similar panic I was seeing regularly. > > Using just a shared lock instead of an xlock should be ok there. You > aren't modifying the process tree, just looking at it. OTOH, the > proc lock is supposed to protect p_grp and p_session, so they shouldn't > be NULL. :( I have a suspiscion that the bug is actually in wait1(): sx_xlock(&proctree_lock); [...] /* * Remove other references to this process to ensure * we have an exclusive reference. */ leavepgrp(p); sx_xlock(&allproc_lock); LIST_REMOVE(p, p_list); /* off zombproc */ sx_xunlock(&allproc_lock); LIST_REMOVE(p, p_sibling); sx_xunlock(&proctree_lock); Shouldn't we be removing the process from zombproc before setting p_pgrp to NULL via leavepgrp()? Does this even matter at all when both fork1() and wait1() are still protected by Giant? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: current-digest V5 #848
unsubscribe freebsd-current-digest To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE test code?
On Mon, 10 Mar 2003, David Schultz wrote: > Thus spake Ivan Voras <[EMAIL PROTECTED]>: > > Is there any example code available that just tests (a "proof of > > concept"-like) the KSE system on FreeBSD 5-current? > > See src/tools/KSE/ksetest. also the library is mostly working so: cd /usr/lib/libpthreads make make install This installs a libkse which, when we are happy with it will become libpthreads, but until then it has this special name.. get some test threads programs and link with -lkse remember to disable -pthreads see what happens. There is a fix for ^Z being committed in the next day or so.. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE test code?
Thus spake Ivan Voras <[EMAIL PROTECTED]>: > Is there any example code available that just tests (a "proof of > concept"-like) the KSE system on FreeBSD 5-current? See src/tools/KSE/ksetest. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sendmail and backups
On Mon, 10 Mar 2003 09:01:55 -0800 Gregory Neil Shapiro <[EMAIL PROTECTED]> wrote: > cfowler> Is there a way to configure sendmail on my 4.7 system to keep a backup > cfowler> of all mail going out? > > http://www.sendmail.org/faq/section4.html#4.20 What about http://www.geocities.com/sbmilbur/sendmail/ (overlooking the fact that there's one character which has to get deleted and one character to get added to have a working sendmail 8.1[12].x)? I used it on request of a client (yes, he consulted a lawyer first and did all the necessary legal work) just last week, and it seems to work just fine. Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NULL pointer problem in pid selection ?
On 08-Mar-2003 Kris Kennaway wrote: > On Sat, Mar 08, 2003 at 11:46:34AM +0100, Poul-Henning Kamp wrote: >> >> Just got this crash on -current, and I belive I have seen similar >> before. addr2line(1) reports the faulting address to be >> ../../../kern/kern_fork.c:395 >> which is in the inner loop of pid collision avoidance. > > I've been running this patch from Alfred for the past month or so on > bento, which has fixed a similar panic I was seeing regularly. Using just a shared lock instead of an xlock should be ok there. You aren't modifying the process tree, just looking at it. OTOH, the proc lock is supposed to protect p_grp and p_session, so they shouldn't be NULL. :( > Kris > > Index: kern/kern_fork.c > === > RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v > retrieving revision 1.186 > diff -u -r1.186 kern_fork.c > --- kern/kern_fork.c 27 Feb 2003 02:05:17 - 1.186 > +++ kern/kern_fork.c 4 Mar 2003 00:28:09 - > @@ -325,6 +325,7 @@ >* exceed the limit. The variable nprocs is the current number of >* processes, maxproc is the limit. >*/ > + sx_xlock(&proctree_lock); > sx_xlock(&allproc_lock); > uid = td->td_ucred->cr_ruid; > if ((nprocs >= maxproc - 10 && uid != 0) || nprocs >= maxproc) { > @@ -432,6 +433,7 @@ > LIST_INSERT_HEAD(&allproc, p2, p_list); > LIST_INSERT_HEAD(PIDHASH(p2->p_pid), p2, p_hash); > sx_xunlock(&allproc_lock); > + sx_xunlock(&proctree_lock); > > /* >* Malloc things while we don't hold any locks. > @@ -757,6 +759,7 @@ > return (0); > fail: > sx_xunlock(&allproc_lock); > + sx_xunlock(&proctree_lock); > uma_zfree(proc_zone, newproc); > if (p1->p_flag & P_THREADED) { > PROC_LOCK(p1); > > >> >> Poul-Henning >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; lapic.id = >> fault virtual address = 0x14 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc01c3eec >> stack pointer = 0x10:0xe74e3c74 >> frame pointer = 0x10:0xe74e3cbc >> code segment= base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags= interrupt enabled, resume, IOPL = 0 >> current process = 99777 (sh) >> trap number = 12 >> panic: page fault >> cpuid = 0; lapic.id = >> Stack backtrace: >> backtrace(c032ff8e,0,c03394ce,e74e3b68,1) at 0xc01d86a7 = backtrace+0x17 >> panic(c03394ce,c0342131,cfe5496c,1,1) at 0xc01d87ba = panic+0x10a >> trap_fatal(e74e3c34,14,c03422ba,2e3,cfe4fa50) at 0xc02fa672 = trap_fatal+0x322 >> trap_pfault(e74e3c34,0,14,c035a038,14) at 0xc02fa322 = trap_pfault+0x1c2 >> trap(18,10,10,cf19c3f8,cf76b9ec) at 0xc02f9e9d = trap+0x3cd >> calltrap() at 0xc02e2cd8 = calltrap+0x5 >> --- trap 0xc, eip = 0xc01c3eec, esp = 0xe74e3c74, ebp = 0xe74e3cbc --- >> fork1(cfe4fa50,14,0,e74e3cd4,cfe54858) at 0xc01c3eec = fork1+0x3fc >> fork(cfe4fa50,e74e3d10,c03422ba,404,0) at 0xc01c3852 = fork+0x52 >> syscall(2f,2f,2f,0,80ff000) at 0xc02fa98e = syscall+0x26e >> Xint0x80_syscall() at 0xc02e2d2d = Xint0x80_syscall+0x1d >> --- syscall (2), eip = 0x807ba9f, esp = 0xbfbff6bc, ebp = 0xbfbff6e8 --- >> boot() called on cpu#0 >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> [EMAIL PROTECTED] | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] >> with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: /usr/src5/sys/kern/kern_lock.c:243: could sleep with "buf qu
On 09-Mar-2003 Willem Jan Withagen wrote: > I'n not shure if this is still the place to drop these??? > I haven't seen may off these lately on the list... > > Found in my dmesg of yesterday, system is now 5 days up: > > /usr/src5/sys/kern/kern_lock.c:243: could sleep with "buf queue lock" locked from > /usr/src5/sys/kern/vfs_bio.c:2104 > > freebee# uname -a > FreeBSD freebee.digiware.nl 5.0-CURRENT FreeBSD 5.0-CURRENT #4: Sat Mar 1 17:50:16 > CET 2003 > [EMAIL PROTECTED]:/mnt2/obj/usr/src5/sys/GENERIC i386 > > I'll install yesterdays kernel and run that to see if it reoccurs. This was fixed Friday. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sendmail and backups
cfowler> Is there a way to configure sendmail on my 4.7 system to keep a backup cfowler> of all mail going out? http://www.sendmail.org/faq/section4.html#4.20 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
Garrett Wollman wrote: > `#if __GNUC__' wouldn't help matters; every preprocessor has to read > and interpret every preprocessor directive (so that `#else' and > `#endif' can be recognized). I thought that the other discussion had concluded that: #if 0 ... #else Or: #if 0 ... #endif Should ignore everything *except* "#else" or "#elif" or "#endif"? I remember when GCC used to start "nethack" any time you used a "#pragma" in an unprotected block, but not otherwise... ;^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: #warning must be protected by #if __GNUC__ in headers?
Craig Rodrigues wrote: > In , I see: > > #if __GNUC__ > #warning "No user-serviceable parts inside." > #endif > > Does the use of #warning need to be protected by > #if __GNUC__ in FreeBSD header files? Yes. It is a preprocessor directive specific the GCC preprocessor. This was discussed in great detail about a month ago, when the people trying to get TenDRA to compile FreeBSD discovered to their horror that TenDRA's preprocessor incorrectly assigns meaning to code that's #if'ed out, and blew chunks on the #warning, when it should have ignored it. > Some other header files check for __GNUC__ before using #warning, > such as , but does not. is wrong. Please see the original discussion for more details. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sendmail and backups
Hello, Is there a way to configure sendmail on my 4.7 system to keep a backup of all mail going out? Thanks, Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sendmail_enable="NONE" doesn't appear in rc.conf
Nuno Teixeira wrote: > sendmail_enable="NONE" doesn't appear in /etc/defaults/rc.conf. Can > anyone update this file to include "NONE" option? Do you mean you want it to default to "NONE", or do you mean that you want the option documented in this file? If the former, then it's not going to happen; by default, there has to be an MSA for /bin/mail to work, for things like daily, weekly, and mothly security scripts to email their results to root. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
Andrey A. Chernov <[EMAIL PROTECTED]> writes: > Many programs (from ports too) defines _ISOC99_SOURCE to get C99 > functions, but we don't sense this define currently. Here is the fix for > review: Cool. I didn't realize there was an existing precedence, or I would have used it. > --- cdefs.h.bak Wed Oct 23 05:04:06 2002 > +++ cdefs.h Mon Mar 10 09:11:01 2003 > @@ -360,6 +360,9 @@ > #define __POSIX_VISIBLE 198808 > #define __ISO_C_VISIBLE 0 > #endif /* _POSIX_C_SOURCE */ > +#ifdef _ISOC99_SOURCE > +#define __ISO_C_VISIBLE 1999 > +#endif This part isn't needed... > #else > /*- > * Deal with _ANSI_SOURCE: > @@ -378,7 +381,7 @@ > #define __XSI_VISIBLE 0 > #define __BSD_VISIBLE 0 > #define __ISO_C_VISIBLE 1990 > -#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */ > +#elif defined(_ISOC99_SOURCE)/* Strict C99 env. */ > #define __POSIX_VISIBLE 0 > #define __XSI_VISIBLE 0 > #define __BSD_VISIBLE 0 ...since the next line here is: #define __ISO_C_VISIBLE 1999 Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: softupdates && write cache && ata tags topic
Nuno Teixeira wrote: > I understand the basic concept of the folowing techs: softupdates, disk > write cache and ata tags. > > My question is: > > It is safe to use softupdates + write cache + ata tags (IBM disk)? > > I read someware that it not safe to use softupdate + write cache > (without ata tags) and if it is not safe why FreeBSD 5.0 ships with them > enabled? See the discussion of 3 weeks ago with one of the engineers from Maxtor, on this list. The short answer is that the drive does not honor tags on a commit to stable storage, before returning the request as satisfied, and that's because on a write, ATA doesn't support disconnect with tagged commands. As to why write caching is on be default, there's a lot of going back and forth on that, and it's flipped state maybe 4-5 times, so far. The short answer is that ATA drives are pig-slow with write caching disabled, and users find that unacceptable. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
KSE test code?
Is there any example code available that just tests (a "proof of concept"-like) the KSE system on FreeBSD 5-current? -- Ashes to ashes, DOS to DOS ivoras @ fer.hr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FBSD 5.0 diskless environment does not work!
Hello. For a long time with FreeBSD 4.X we ran and still run a bunch of diskless stations, X11 Terminals, some special workstations and now a growing system with several nodes for usage as PVM. Now I want to switch to FreeBSD 5.0 and run into massive problems. I searched for similar problems in the archive and groups.google, but I did not find any appropriate. Hope someone can help. The environment is really simple. All diskless machines uses PXE to bootstrap. In FreeBSD 4.7 this environment works perfect (and ist is still working), but in FreeBSD 5.0 I get into trouble. I want first to describe the environment. Each class of machines has its own full FreeBSD-4/5 installation. Within ist root-path, there is a populated /etc and a populated /conf. /conf has three main entries: /conf/base, /conf/default and /conf/IP.SPECIFIC.ENTRY. As I understand the diskless boot process in FreeBSD 4.X, at first a memory disc is created, then the stuff in /etc/ is copied to that RAM disc, executed and then the process does a kind of hierarchy overlay by unifying /etc with /conf/base with /conf/default and at last with /conf/IP.SPECIFIC.ENTRY and executes then the on top remaining config files (sorry about my English). That means: the most specific system configs are in /conf/IP.SPECIFIC.ENTRY and get executed. This seems to have changed in 5.0 as there is only the /conf/default and /conf/IP.SPECIFIC.ENTRY left. /conf/base has gone. But nevertheless, this should work, but does not! When booting a FBSD 5.0 client without a populated /etc directory but with a well populated /conf/defaults/etc directory, it fails. It also fails when populating /etc and delete those files which are in /conf/default/etc. Putting all the stuff in /etc forces the client to do things it should do, but this is not the way it should be and its not the way as it is decribed (rarely) in the docs I found and as I expect this in FreeBSD 4.7 (where this scheme works like a charme). This seems to be the first problem I can not figure out. What is the hierarchy of /etc and /conf/defaults/etc in FBSD 5.0 now? How can I keep my config files in sync without copying all the stuff again from /conf/default/etc to /etc (which breaks the config scheme, I think)? When the kernel has been bootstraped and started , the first thing is it moans about a non writeable root partition. This also does not change when exporting the root partition as read/writeable on the server (doing a killall -HUP mountd ...). I also use the rc_ng="YES"-scheme. The kernel has options NFS_ROOT and MD_ROOT and also options md for the memory disc compiled in. The only problem is that in the clients /dev directory is no appropriate md0* node, I can not create it via MAKEDEV all in this directory and I wonder whether this is needed. Can anyone help? Has someone a runnng diskless FBSD 5.0-R/5-CURRENT environment? Thanks in advance, Oliver -- MfG O. Hartmann [EMAIL PROTECTED] -- Systemadministration des Institutes fuer Physik der Atmosphaere (IPA) -- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinenraum) Tel: +496131/3924144 (Buero) FAX: +496131/3923532 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Headless Server
Hi, I have a 2U Rackmount system that I have inherited. This box has a standard Intel RC440BX Desktop Motherboard in it. The actual chassis covers the whole board so that none off the expansion slots or on board connectors are visible. There is a network connector on the back off the chassis that has been rigged internally to a network. The front panel has three LED's (Power, HDD, and Network) and two buttons (Power and Function). On investigating the Function button is connected to two pins on the Serial Com 2 connector. I was wondering if there is anything in FreeBSD Current or older that will allow me to use this function button to shutdown the system as the power button results in instant off. I'd also like to know what others might use this for bearing in mind that the only connector exposed is the network connector and hence if the system loses its network connection then the only way to diagnose issues is to open the case. Regards, Suneel. ** A disclaimer applies to all email sent from Inter-Computer Technology Limited. For the full text, see http://home.inctech.com/Content/Legal/EmailDisclaimer.htm ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GDB kernel debug new command
On Monday 10 March 2003 17:28, Dag-Erling Smorgrav wrote: > Jun Su <[EMAIL PROTECTED]> writes: > > To help myself more easily check the kernel dump, I added two new > > command. One is ps, the other is kldstat. I know we can print the kernel > > data manually to get the same information. I still think this is useful. > > This can help the newbies to get the information without many knowledge > > about the kernel. This also can help the experienced user to get the data > > more quickly. > > > > Here is the new file. Just put it in /usr/src/gnu/usr.bin/binutils/gdb. > > And add the file to Makefile. Please give me some comments if this is > > garbage. :) > > This is pointless as it won't work unless gdb is in synch with the > kernel (since it depends on knowing the layout of struct proc and > struct linker_file). Both of these commands can be implemented as > macros, which will not depend on gdb being in synch with the kernel. > > Greg Lehey wrote this ps macro: > > define ps > set $nproc = nprocs > set $aproc = allproc.lh_first > set $proc = allproc.lh_first > printf " pidprocaddr uid ppid pgrp flag stat comm > wchan\n" while (--$nproc >= 0) > set $pptr = $proc.p_pptr > if ($pptr == 0) >set $pptr = $proc > end > if ($proc.p_stat) > printf "%5d %08x %08x %4d %5d %5d %06x %d %-10s ", \ >$proc.p_pid, $aproc, \ >$proc.p_addr, $proc.p_cred->p_ruid, $pptr->p_pid, \ >$proc.p_pgrp->pg_id, $proc.p_flag, $proc.p_stat, \ >&$proc.p_comm[0] > if ($proc.p_wchan) > if ($proc.p_wmesg) > printf "%s ", $proc.p_wmesg > end > printf "%x", $proc.p_wchan > end > printf "\n" > end > set $aproc = $proc.p_list.le_next > if ($aproc == 0 && $nproc > 0) > set $aproc = zombproc > end > set $proc = $aproc > end > end > > document ps > "ps" -- when kernel debugging, type out a ps-like listing of active > processes. end > > and I've written two variants of kldstat myself, plus a kldload: > > end > > document kldstat > Lists the modules that were loaded when the kernel crashed. > end > > define kldstat-v > set $kld = linker_files.tqh_first > printf "Id Refs AddressSize Name\n" > while ($kld != 0) > printf "%2d %4d 0x%08x %-8x %s\n", \ > $kld->id, $kld->refs, $kld->address, $kld->size, $kld->filename > printf "Contains modules:\n" > printf "Id Name\n" > set $module = $kld->modules.tqh_first > while ($module != 0) > printf "%2d %s\n", $module->id, $module->name > set $module = $module->link.tqe_next > end > set $kld = $kld->link.tqe_next > end > end > > document kldstat-v > Lists modules with full information. > end > > define kldload > set $kld = linker_files.tqh_first > set $done = 0 > while ($kld != 0 && $done == 0) > if ($kld->filename == $arg0) > set $done = 1 > else > set $kld = $kld->link.tqe_next > end > end > if ($done == 1) > shell /usr/bin/objdump -h $arg0 | \ > awk '/ .text/ { print "set \$offset = 0x" $6 }' > .kgdb.temp > source .kgdb.temp > add-symbol-file $arg0 $kld->address + $offset > end > end > > document kldload > Loads a module. Arguments are module name and offset of text section. > end > > Note that for kldload to work, you need to know the offset of the text > section for the module you wish to load (objdump -h will tell you) > > Note also that I haven't used any of these macros in a long time, so > there may be some issues related to KSE or whatnot. > > DES You are so cool. Your macro is better than my code. Thanks. I think the kernel structure is not changed often. These type of macro can help most newbies such as me to enter the freebsd debug easily. It is worth to maintain a copy somewhere. (In source tree, it may be great.) I used windbg for a long time. it provides many commands to help developer debug. This is a good pratice I think. :) Jun Su To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 5.0R panic: bwrite: buffer is not busy???
Hello, > Here the messages that appears in console: The panic appears randomly > after the boot , it can be an hour as can be 3 or more hours . Could you please try to upgrade to -CURRENT? --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- ===> lib/libpam/modules/pam_opieaccess cc1: warnings being treated as errors /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c: In function `pam_sm_authenticate': /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:70: warning: passing arg 2 of `opielookup' discards qualifiers from pointer target type /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c:80: warning: passing arg 1 of `opieaccessfile' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules/pam_opieaccess. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam/modules. *** Error code 1 Stop in /tinderbox/sparc64/src/lib/libpam. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: softupdates && write cache && ata tags topic
Matthias Schuendehuette <[EMAIL PROTECTED]> writes: > I consider it unnecessary to use WriteCache if TaggedQueuing is enabled > and working. > (The performace gain of WriteCache and TaggedQueuing is more or less the > same, the combination of both adds less than 10% of performance and you > shouldn't use Soft Updates any more) Write cacheing is automatically enabled if tagged queueing is enabled and supported by the disk, so I doubt you're seeing any improvement at all. /* enable write caching if allowed and not default on device */ if (ata_wc || (ata_tags && ad_tagsupported(adp))) { if (ata_command(atadev, ATA_C_SETFEATURES, 0, 0, ATA_C_F_ENAB_WCACHE, ATA_WAIT_INTR)) ata_prtdev(atadev, "enabling write cache failed\n"); } DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GDB kernel debug new command
Jun Su <[EMAIL PROTECTED]> writes: > To help myself more easily check the kernel dump, I added two new command. One > is ps, the other is kldstat. I know we can print the kernel data manually to > get the same information. I still think this is useful. This can help the > newbies to get the information without many knowledge about the kernel. This > also can help the experienced user to get the data more quickly. > > Here is the new file. Just put it in /usr/src/gnu/usr.bin/binutils/gdb. And > add the file to Makefile. Please give me some comments if this is garbage. :) This is pointless as it won't work unless gdb is in synch with the kernel (since it depends on knowing the layout of struct proc and struct linker_file). Both of these commands can be implemented as macros, which will not depend on gdb being in synch with the kernel. Greg Lehey wrote this ps macro: define ps set $nproc = nprocs set $aproc = allproc.lh_first set $proc = allproc.lh_first printf " pidprocaddr uid ppid pgrp flag stat comm wchan\n" while (--$nproc >= 0) set $pptr = $proc.p_pptr if ($pptr == 0) set $pptr = $proc end if ($proc.p_stat) printf "%5d %08x %08x %4d %5d %5d %06x %d %-10s ", \ $proc.p_pid, $aproc, \ $proc.p_addr, $proc.p_cred->p_ruid, $pptr->p_pid, \ $proc.p_pgrp->pg_id, $proc.p_flag, $proc.p_stat, \ &$proc.p_comm[0] if ($proc.p_wchan) if ($proc.p_wmesg) printf "%s ", $proc.p_wmesg end printf "%x", $proc.p_wchan end printf "\n" end set $aproc = $proc.p_list.le_next if ($aproc == 0 && $nproc > 0) set $aproc = zombproc end set $proc = $aproc end end document ps "ps" -- when kernel debugging, type out a ps-like listing of active processes. end and I've written two variants of kldstat myself, plus a kldload: end document kldstat Lists the modules that were loaded when the kernel crashed. end define kldstat-v set $kld = linker_files.tqh_first printf "Id Refs AddressSize Name\n" while ($kld != 0) printf "%2d %4d 0x%08x %-8x %s\n", \ $kld->id, $kld->refs, $kld->address, $kld->size, $kld->filename printf "Contains modules:\n" printf "Id Name\n" set $module = $kld->modules.tqh_first while ($module != 0) printf "%2d %s\n", $module->id, $module->name set $module = $module->link.tqe_next end set $kld = $kld->link.tqe_next end end document kldstat-v Lists modules with full information. end define kldload set $kld = linker_files.tqh_first set $done = 0 while ($kld != 0 && $done == 0) if ($kld->filename == $arg0) set $done = 1 else set $kld = $kld->link.tqe_next end end if ($done == 1) shell /usr/bin/objdump -h $arg0 | \ awk '/ .text/ { print "set \$offset = 0x" $6 }' > .kgdb.temp source .kgdb.temp add-symbol-file $arg0 $kld->address + $offset end end document kldload Loads a module. Arguments are module name and offset of text section. end Note that for kldload to work, you need to know the offset of the text section for the module you wish to load (objdump -h will tell you) Note also that I haven't used any of these macros in a long time, so there may be some issues related to KSE or whatnot. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message