Re: fstab weirdness / UPDATING
Hello, On Wed, Apr 04, 2001 at 10:49:22PM -0700, Alfred Perlstein wrote: I've had that problem on one box also -- when the boot occurs, my /var partition is not fsck'd. It's the second pass-two file system, which means that it *should* be checked :-). I suspect a nit in the recent fsck cleanup, so I'm CC'ing phk, whose mailbox is obviously too empty. I think I'm seeing the same thins... At boot I see a kernel printf "warning: /var was not properly dismounted" then /var mounts. If I unmount it and fsck it it's dirty. I saw something similar too, but did not get around to posting yet because I wanted to understand what's going on. On boot, I see only two of my partitions being reported as clean, and not the others. After this, all of them are mounted allright. (They happen to be ad0s1a and ad0s1f don't know why...) I don't know if it causes filesystem corruption, because it is my policy to always 'boot -s' upon unclean shutdown and fsck all partitions manually. (In fact I just did it again because X has a tendency to freeze the machine off and on for unknown reasons... maybe related?) If this is an fsck problem, then I figured there was no big problem if your previous shutdown was clean... am I right? Or maybe there is a problem with shutdown too that fsck simply doesn't notice? Brrr...:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic I got: mutex sx backing lock recursed at ../../kern/kern_condvar.c:198
I'm running -CURRENT on a dual PII/400 box with 128M of RAM. The kernel
I'm running was built from sources current as of last night (i.e. around
9PM CDT Apr 3). Just now, while listening to streaming audio with xmms,
the machine crashed. It's done that a couple times before, with recent-ish
kernels while doing streaming audio with xmms, but the other times didn't give
core dumps with usable backtraces. *This* time I got a decent backtrace.
If I'm reading this backtrace right, the thread handling the sound
hardware called selwakeup() (frame #19). This called pfind() (frame
#18), which tries to lock allproc. Somewhere in doing this,
witness_sleep() (frame #15) decides it wants to printf() a message. printf()
calls down into the tty code, which goes into ptsstart() (frame #9) and the
pty code (I'm not entirely sure why). This code then tries to do a selwakeup()
of its own (frame #7) which calls pfind() which tries (again) to lock allproc,
leading to the "mutex recursed" panic.
GDB output and (if it matters) kernel config file below.
Script started on Thu Apr 5 01:12:28 2001
ichotolot# cd /usr/src/sys/compile/ICHOTOLOTSMP
ichotolot# gdb -k kernel.debug /var/crash/vmcore.7
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd"...
IdlePTD 6356992
initial pcb at 513860
panicstr: mutex sx backing lock recursed at ../../kern/kern_condvar.c:198
panic messages:
---
panic: mutex sx backing lock recursed at ../../kern/kern_condvar.c:198
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16
1: dev:da0s2e, flags:21021024, blkno:11469104, lblkno:11469104
2: dev:da0s2e, flags:21021024, blkno:11468864, lblkno:11468864
3: dev:da0s2e, flags:2124, blkno:2048, lblkno:2048
4: dev:da0s2e, flags:21021024, blkno:2752848, lblkno:2752848
5: dev:da0s2e, flags:21021024, blkno:2752736, lblkno:2752736
6: dev:da0s2e, flags:21021024, blkno:11468976, lblkno:11468976
7: dev:da0s2a, flags:21021024, blkno:131152, lblkno:131152
8: dev:da0s2e, flags:21021024, blkno:2294176, lblkno:2294176
9: dev:da0s2e, flags:21021024, blkno:2425120, lblkno:2425120
10: dev:da0s2a, flags:21021024, blkno:131184, lblkno:131184
11: dev:da0s2e, flags:2124, blkno:16, lblkno:16
12: dev:da0s2e, flags:21021024, blkno:2294160, lblkno:2294160
13: dev:da0s2e, flags:21021024, blkno:14221440, lblkno:14221440
14: dev:da0s2e, flags:21021024, blkno:2294192, lblkno:2294192
15: dev:da0s2e, flags:01011024, blkno:11474186, lblkno:0
16: dev:da0s2e, flags:0124, blkno:11468848, lblkno:11468848
giving up on 16 buffers
Uptime: 23h3m37s
dumping to dev da0s2b, offset 270336
dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83
82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54
53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:478
478 if (dumping++) {
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc0251547 in boot (howto=256) at ../../kern/kern_shutdown.c:321
#2 0xc0251a09 in panic (fmt=0xc0464a44 "mutex %s recursed at %s:%d")
at ../../kern/kern_shutdown.c:592
#3 0xc024aec3 in _mtx_assert (m=0xc054765c, what=9,
file=0xc0462932 "../../kern/kern_condvar.c", line=198)
at ../../kern/kern_mutex.c:602
#4 0xc02369a2 in cv_wait (cvp=0xc0547698, mp=0xc054765c)
at ../../kern/kern_condvar.c:198
#5 0xc0258caa in _sx_slock (sx=0xc0547640,
file=0xc0464e23 "../../kern/kern_proc.c", line=143)
at ../../kern/kern_sx.c:117
#6 0xc024bf48 in pfind (pid=606) at ../../kern/kern_proc.c:143
#7 0xc026ffe1 in selwakeup (sip=0xc10eea04) at ../../kern/sys_generic.c:1061
#8 0xc027accf in ptcwakeup (tp=0xc10eea20, flag=1) at ../../kern/tty_pty.c:318
#9 0xc027acaa in ptsstart (tp=0xc10eea20) at ../../kern/tty_pty.c:307
#10 0xc0278170 in ttstart (tp=0xc10eea20) at ../../kern/tty.c:1417
#11 0xc027978d in tputchar (c=46, tp=0xc10eea20) at ../../kern/tty.c:2484
#12 0xc0268813 in putchar (c=46, arg=0xc7f12e10) at ../../kern/subr_prf.c:304
#13 0xc0268fb8 in kvprintf (
fmt=0xc0468642 ":%d: %s with \"%s\" locked from %s:%d\n",
func=0xc02687c4 putchar, arg=0xc7f12e10, radix=10, ap=0xc7f12e2c "Ç")
at ../../kern/subr_prf.c:637
#14 0xc0268740 in printf (
fmt=0xc0468640 "%s:%d: %s with \"%s\" locked from %s:%d\n")
at ../../kern/subr_prf.c:260
#15 0xc026cff9 in witness_sleep (check_only=0, lock=0xc054765c,
Re: *HEADS UP* libposix1e is integrated into libc
On Wed, Apr 04, 2001 at 07:23:18PM +0200, Thomas Moestl wrote:
src/lib/libposix1e was repocopied to src/lib/libc/posix1e, and I'll
start to commit the necessary patches now and will then activate the
build.
World may be broken during a short interval due to the switch. You
will also need to rebuild anything that uses libposix1e. In the base
system, those are src/bin/getfacl and src/bin/setfacl for now. I'm not
aware of any ports using it, so normally you should be fine after a
buildworld.
The changes are complete now, so any possible breakage should be over.
I think you need to change MAN= to MAN+= in /posix1e/Makefile.inc.
That just caused a make release to fail because it clobbered all
the previous man entries and then ln couldn't link them.
John
--
John Hay -- [EMAIL PROTECTED]
Index: lib/libc/posix1e/Makefile.inc
===
RCS file: /home/ncvs/src/lib/libc/posix1e/Makefile.inc,v
retrieving revision 1.1
diff -u -r1.1 Makefile.inc
--- lib/libc/posix1e/Makefile.inc 2001/04/04 18:00:51 1.1
+++ lib/libc/posix1e/Makefile.inc 2001/04/05 06:39:44
@@ -34,7 +34,7 @@
.if ${LIB} == "c"
-MAN= acl.3 \
+MAN+= acl.3 \
acl_add_perm.3 \
acl_calc_mask.3 \
acl_clear_perms.3 \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
subscription
subscribe freebsd-current subscribe cvs-all Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *HEADS UP* libposix1e is integrated into libc
On Thu, Apr 05, 2001 at 09:33:24AM +0200, John Hay wrote: On Wed, Apr 04, 2001 at 07:23:18PM +0200, Thomas Moestl wrote: src/lib/libposix1e was repocopied to src/lib/libc/posix1e, and I'll start to commit the necessary patches now and will then activate the build. World may be broken during a short interval due to the switch. You will also need to rebuild anything that uses libposix1e. In the base system, those are src/bin/getfacl and src/bin/setfacl for now. I'm not aware of any ports using it, so normally you should be fine after a buildworld. The changes are complete now, so any possible breakage should be over. I think you need to change MAN= to MAN+= in /posix1e/Makefile.inc. That just caused a make release to fail because it clobbered all the previous man entries and then ln couldn't link them. Committed! -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newbus driver code
try teh sample driver in /usr/share/exaples/drivers/make_device_driver.sh it's been updated recently, and commented with useful comments. (-current only) On Wed, 4 Apr 2001, j mckitrick wrote: Could someone point me to a device that is well-written, follows newbus, and would be a good example of how a device driver should be written? thanks, jm -- --- Jonathon McKitrick -- [EMAIL PROTECTED] "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here." --- 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: Panic I got: mutex sx backing lock recursed at ../../kern/kern_condvar.c:198
On Thu, 5 Apr 2001, Richard Todd wrote:
I'm running -CURRENT on a dual PII/400 box with 128M of RAM. The kernel
I'm running was built from sources current as of last night (i.e. around
9PM CDT Apr 3). Just now, while listening to streaming audio with xmms,
the machine crashed. It's done that a couple times before, with recent-ish
kernels while doing streaming audio with xmms, but the other times didn't give
core dumps with usable backtraces. *This* time I got a decent backtrace.
If I'm reading this backtrace right, the thread handling the sound
hardware called selwakeup() (frame #19). This called pfind() (frame
#18), which tries to lock allproc. Somewhere in doing this,
witness_sleep() (frame #15) decides it wants to printf() a message. printf()
calls down into the tty code, which goes into ptsstart() (frame #9) and the
pty code (I'm not entirely sure why). This code then tries to do a selwakeup()
of its own (frame #7) which calls pfind() which tries (again) to lock allproc,
leading to the "mutex recursed" panic.
The TOTTY apparently flag got set by the following code in putchar():
if ((flags TOCONS) tp == NULL constty) {
tp = constty;
flags |= TOTTY;
}
This caused output to be sent to the terminal `constty' instead of to the
low-level console output routine. Terminal output is not designed to
work in arbitary contexts, and bad things happened.
This seems to be a very old, very often exercised bug. printf() always
sets `tp' to NULL, so the output goes to a bad place whenever constty is
non-NULL, but I think this is the normal setup in X. The terminal output
routines are designed to work in some interrupt contexts, but they depend
on spltty() working to prevent them being reentered. Even before SMPng,
when spltty() actually worked and there were no locks to hang on, it
was possible for an interrupt not masked by spltty() to occur and reenter
the output routine.
The low-level syscons output routines have similar bugs:
1) They do some locking for screen saver and/or delayed screen update things.
This causes problems when printf() is called with sched_lock held, e.g.,
in mi_switch(). The printfs in mi_switch() are ifdefed out to avoid
this problem.
2) The routines are not reentrant.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: newbus driver code
On Thu, Apr 05, 2001 at 03:32:23AM -0700, Julian Elischer wrote: | try teh sample driver in /usr/share/exaples/drivers/make_device_driver.sh Perfect! Just what I was looking for. Thanks. jm -- --- Jonathon McKitrick -- [EMAIL PROTECTED] "It took the computing power of three C-64s to fly to the Moon. It takes a 486 to run Windows 95. Something is wrong here." --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
selwakeup()
On Thu, 05 Apr 2001 01:39:35 -0500, Richard Todd [EMAIL PROTECTED] said: If I'm reading this backtrace right, the thread handling the sound hardware called selwakeup() (frame #19). This called pfind() (frame #18), which tries to lock allproc. selwakeup() shouldn't need to call pfind(). Because the process table is in type-stable memory, it should be sufficient to keep a reference to the caller's proc structure and check to see whether its pid is the same one as in the selinfo. The locking that selwakeup() already needs to do should be sufficient to avoid a race. (In 4.4BSD, process structures were not type-stable so this technique could not have been used.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: selwakeup()
On 05-Apr-01 Garrett Wollman wrote: On Thu, 05 Apr 2001 01:39:35 -0500, Richard Todd [EMAIL PROTECTED] said: If I'm reading this backtrace right, the thread handling the sound hardware called selwakeup() (frame #19). This called pfind() (frame #18), which tries to lock allproc. selwakeup() shouldn't need to call pfind(). Because the process table is in type-stable memory, it should be sufficient to keep a reference to the caller's proc structure and check to see whether its pid is the same one as in the selinfo. The locking that selwakeup() already needs to do should be sufficient to avoid a race. (In 4.4BSD, process structures were not type-stable so this technique could not have been used.) There are probably several other places that pfind is called that this check should also be adequate for as well. The ones in syscons for example. -GAWollman -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Some telnet argument cleanup
Since the change was made to telnet to have it attempt autologin and encryption by default, there are some problems with argument handling for telnet. 1. in crypto/telnet/telnet/main.c: case 'l': autologin = 1; if(autologin == 0) autologin = -1; user = optarg; break; The 'if' will never happen, so it should be removed, but the ramifications of this should be thought about harder. The way the code is now, specifying -l will DISable automatic encryption (or rather, it will fail to automatically enable it). This is because later on only if autologin=-1 does the code do encrypt_auto(1); . 2. There are no provisions to disable encryption. -x turns it on. Since it is now on by default, -x becomes redundant, except in cases where it's necessary to repair the -l damage. It would make sense to have -x turn encryption off, except that people may be used to it turning encryption on and may be astonished. Some other letter (-y?) should be added to turn it off. The processing of that option will have to be careful to check to see if autologin is -1 and set it to 1 to insure that it's not automatically enabled later. Perhaps better than the autologin == -1 hack, why not just call encrypt_auto(1); and decrypt_auto(1); once before the options are parsed. Then the user can use -y to disable it if he chooses. Then autologin can start off as 1 and be set to 0 only if the user specifies -K. Having -1 be indicative of an encryption side effect is bizarre. 3. So far as I can tell, none of the changes were synced to the man page. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pppoe, userland ppp
Leif Neland wrote: I'd like to try pppoe to connect to poptop (on a linuxbox). The port is forbidden; I should use ng_pppoe. You're mixing apples and oranges. poptop is for pptp, not pppoe. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review... PR 25577
On Mon, Apr 02, 2001 at 12:28:38PM -0700, Doug Ambrisko wrote: Well I can't see that since it's not an array and the values come from iterating through Cisco's API and a direct query for the transmit key. Look at ancontrol for the ugly secret details! I'm pretty sure I've also managed to get it to reports things that just plain aren't true like Bruce did. I've bitched to my Cisco rep again to try and get better doc, but so far I haven't had much luck. I just made a specific request for more data on setting and getting WEP keys. In my patches, I just copied the stuff from ancontrol since that's all we've got. The linux code is even more non-sensical then ancontrol in that it reports five keys. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Re: Call for review... PR 25577
Brooks Davis writes: | On Mon, Apr 02, 2001 at 12:28:38PM -0700, Doug Ambrisko wrote: | Well I can't see that since it's not an array and the values come | from iterating through Cisco's API and a direct query for the | transmit key. Look at ancontrol for the ugly secret details! | | I'm pretty sure I've also managed to get it to reports things that just | plain aren't true like Bruce did. I've bitched to my Cisco rep again | to try and get better doc, but so far I haven't had much luck. I just | made a specific request for more data on setting and getting WEP keys. | In my patches, I just copied the stuff from ancontrol since that's all | we've got. The linux code is even more non-sensical then ancontrol in | that it reports five keys. FYI we've found a bug in ancontrol and the scheme for reporting keys if keys are not filled in order. It would be nice to get the source for the Linux configuration utilties that they distribute with the driver on the Cisco web site. I've tried to run it under Linux and I get "no radio found" although I can ping over the Aironet card! Linux and no source makes it hard to figure out what is happening. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Failed to load linux.ko during boot
Hi, I upgraded my -Current today and after doing this, it has stopped to load linux.ko into the kernel even though I have linux_enable="YES" in my rc.conf If I manually do a kldload linux.ko it loads the module without any problems. Do you have any suggestion why, it doesn't load the module during boot ? Yours sincerely Morten Skriver Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed to load linux.ko during boot
On Thu, Apr 05, 2001 at 11:16:48PM +0200, Morten Skriver wrote: I upgraded my -Current today and after doing this, it has stopped to load linux.ko into the kernel even though I have linux_enable="YES" in my rc.conf I forgot to tell, that I recive the following error message if I use the linux utility to load the module: [morten@mosk-pc]:/usr/home/morten$ linux kldload: can't load linux: Operation not permitted ELF binary type "3" not known. Abort trap Yours sincerely Morten Skriver Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review... PR 25577
If memory serves me right, Doug Ambrisko wrote: Brooks Davis writes: | On Mon, Apr 02, 2001 at 12:28:38PM -0700, Doug Ambrisko wrote: | Well I can't see that since it's not an array and the values come | from iterating through Cisco's API and a direct query for the | transmit key. Look at ancontrol for the ugly secret details! | | I'm pretty sure I've also managed to get it to reports things that just | plain aren't true like Bruce did. I've bitched to my Cisco rep again | to try and get better doc, but so far I haven't had much luck. I just | made a specific request for more data on setting and getting WEP keys. I'd like to complain to my Cisco rep too, oh wait, I *am* my Cisco rep. Nevermind. I'll try asking around on one of the internal mailing lists to see what I can dig up. But my plate is pretty full if I'm actually going to need to hack code on this. | In my patches, I just copied the stuff from ancontrol since that's all | we've got. The linux code is even more non-sensical then ancontrol in | that it reports five keys. Five keys...could be the new home networking stuff? FYI we've found a bug in ancontrol and the scheme for reporting keys if keys are not filled in order. It would be nice to get the source for the Linux configuration utilties that they distribute with the driver on the Cisco web site. I've tried to run it under Linux and I get "no radio found" although I can ping over the Aironet card! Linux and no source makes it hard to figure out what is happening. Can't use Linux configuration utils...I wonder if there's a minimum firmware rev on the card that you need? Bruce. PGP signature
Re: Failed to load linux.ko during boot
On Thu, 5 Apr 2001, Morten Skriver wrote: On Thu, Apr 05, 2001 at 11:16:48PM +0200, Morten Skriver wrote: I upgraded my -Current today and after doing this, it has stopped to load linux.ko into the kernel even though I have linux_enable="YES" in my rc.conf I forgot to tell, that I recive the following error message if I use the linux utility to load the module: [morten@mosk-pc]:/usr/home/morten$ linux kldload: can't load linux: Operation not permitted Helps to do it as root. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed to load linux.ko during boot
On Thu, Apr 05, 2001 at 11:30:21PM +0200, Morten Skriver wrote: [morten@mosk-pc]:/usr/home/morten$ linux kldload: can't load linux: Operation not permitted ELF binary type "3" not known. Abort trap You did not `brandelf' your /compat/linux/sbin/ldconfig. Did you install this from /usr/ports/emulators/linux_base? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: selwakeup()
On 05-Apr-01 John Baldwin wrote: On 05-Apr-01 Garrett Wollman wrote: On Thu, 05 Apr 2001 01:39:35 -0500, Richard Todd [EMAIL PROTECTED] said: If I'm reading this backtrace right, the thread handling the sound hardware called selwakeup() (frame #19). This called pfind() (frame #18), which tries to lock allproc. selwakeup() shouldn't need to call pfind(). Because the process table is in type-stable memory, it should be sufficient to keep a reference to the caller's proc structure and check to see whether its pid is the same one as in the selinfo. The locking that selwakeup() already needs to do should be sufficient to avoid a race. (In 4.4BSD, process structures were not type-stable so this technique could not have been used.) There are probably several other places that pfind is called that this check should also be adequate for as well. The ones in syscons for example. As a safety check we should probably zero the pid right before zfree()'ing a proc in wait() however, so that a stale pointer to a free'd process doesn't have a valid pid if we do this. -GAWollman -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed to load linux.ko during boot
On Thu, Apr 05, 2001 at 02:41:54PM -0700, David O'Brien wrote: On Thu, Apr 05, 2001 at 11:30:21PM +0200, Morten Skriver wrote: [morten@mosk-pc]:/usr/home/morten$ linux kldload: can't load linux: Operation not permitted ELF binary type "3" not known. Abort trap You did not `brandelf' your /compat/linux/sbin/ldconfig. Did you install this from /usr/ports/emulators/linux_base? Yes, I installed it from /usr/ports/emulators/linux_base, but it was a old installation. All I did was to cvsup my source and do a new make buildworld Yours sincerely Morten Skriver Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: selwakeup()
On Thu, 05 Apr 2001 14:41:29 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said:
As a safety check we should probably zero the pid right before zfree()'ing a
proc in wait() however, so that a stale pointer to a free'd process doesn't
have a valid pid if we do this.
Should not be necessary. Here is the logic:
p = sip-si_p;
mtx_lock_spin(sched_lock);
if (p-p_stat != SZOMB || p-p_pid != sip-si_pid) {
/* oops */
mtx_lock_spin(sched_lock);
return;
}
sip-si_pid = 0;
sip-si_p = 0;
if (p-p_wchan == (caddr_t)selwait) {
/* ... */
If `p' is a pointer to a freed process, then p-p_stat is guaranteed
to be SZOMB -- the only code path which can free a process struct is
wrapped inside `if (p-p_stat == SZOMB)'. (See kern_exit.c:exit1().)
If `p' is a pointer to an active process, and it's the wrong pid, then
we don't wake it up. Otherwise, we wake it up. (`p' might still be
the wrong process, if pid space wrapped around, but the current code
doesn't deal with that condition, either, nor should it.)
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
No Subject
unsubscribe freebsd-current end To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: selwakeup()
On 05-Apr-01 Garrett Wollman wrote: On Thu, 05 Apr 2001 14:41:29 -0700 (PDT), John Baldwin [EMAIL PROTECTED] said: As a safety check we should probably zero the pid right before zfree()'ing a proc in wait() however, so that a stale pointer to a free'd process doesn't have a valid pid if we do this. Should not be necessary. Here is the logic: Ah, forgot about the p_stat check. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Possible Nvidia drivers of XF86
I was talking with some fellows who seemed rather confident that if a FBSD developer would port the rather small NVIDIA_kernel to FBSD that Nvidia would make their driver available for XF86 on FBSD. I'm personally not familiar with FBSD development, still with linux, but would love to switch over to FBSD, but this is very difficult until there are solid drivers for XF86 for the Nvidia boards, as I run an Elsa GeForce 2 Ultra and the current XF86 open drivers are flaky on my system. This was very exciting news to a would-be FBSD user! One of the persons also mentioned that it would be good to get BSDi involved as well. The source from which I gleaned this idea was from Open Projects IRC in channel #nvidia. Whoever starts working on this may be able to find help from the people there. It also may be possible to find people connected with Nvidia there. Here is a link to the current driver: ftp://ftp1.detonator.nvidia.com/pub/drivers/english/XFree86_40/0.9-769/NVIDIA_kernel-0.9-769.tar.gz Hope this takes off! Thanks so much for the continued development of a great OS! -GP To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pppoe, userland ppp
I'd like to try pppoe to connect to poptop (on a linuxbox). The port is forbidden; I should use ng_pppoe. You're mixing apples and oranges. poptop is for pptp, not pppoe. Ahh! While mixing apples and oranges can make a nice juice, it doesn't work for vpn. Using pptpclient instead is better :-) I had pptp running in a terminal session started in a window from my workstation in fbsd-mode. Now I booted my workstation to try in windows. Apparently pptp didn't get stopped properly, because when I now want to run pptp again, I get this error message: warn[open_unixsock:pptp_callmgr.c:308]: Call manager for 123.123.123.123 is already running. fatal[callmgr_main:pptp_callmgr.c:124]: Could not open Unix socket for 123.123.123 fatal[launch_callmgr:pptp.c:214]: Call manager exited with error 256 But ps is not showing any ppp, pptp or call processes. Neither is netstat showing anything I can relate to. I could boot the machine, but then I'd have to walk 20m to power it off and on to reset the isdnadapter. Too late for that now. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
