Re: Today's special: nessusd panics -CURRENT
On Thu, May 10, 2001 at 11:29:57AM -0700, David Wolfskill wrote: > >Ok, I see what's broken. I don't know how you are out of witness's though. > >We don't have enough types of mutexes for that to happen. Try this patch: <...> > Since I didn't use the "-l" flag to patch, it didn't apply, so I did it > by hand (and subsequently thought to check for whitespace issues). Yes same with me:-) > But the patch appears to work; I'm up & running: Well unfortunately no such luck. It solves the first part of the problem (the "system call open retunrning with nutex(s) held" panic) but even after applying the patch and toning down MAXUSERS to 32 (I suspected it might be somewhat related) I still get the triple panic, which now looks like: witness_get: witness exhausted panic: witness_restore: lock (sleep mutex) Giant not locked After 'c', it says (attempting to sync the disks) witness_save: panic: lock (sleep mutex) Giant not locked And finally after attempting to dump: ata0: resetting devices: panic: lock (sleep mutex) Giant not locked Here come the traces. The third trace also contains the first and the second a bit further down. The third trace: Debugger panic witness_save mawait ata_command ad_reinit ata_reinit addump dumpsys boot panic=> From here is part of the second trace too. witness_save boot panic=> From here this is the first trace too. witness_restore msleep vm_pageout fork_exit fork_trampoline So basically the first trace is: Debugger panic witness_restore msleep vm_pageout fork_exit fork_trampoline And the second: Debugger panic witness_save boot panic witness_restore msleep vm_pageout fork_exit fork_trampoline This problem *only* appears when running nessusd. Any other app I tried (including X) runs fine. If you need more info let me know. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Snapshot Log - world broken in telnetd
On Fri, 11 May 2001 03:16:35 +1000 (EST), Bruce Evans <[EMAIL PROTECTED]> said: > The kerberosIV telnetd is missing linkage to libpam, perhaps > more. The kerberosIV telnet and telnetd are missing linkage to libpam, for about three days. Just adding that lib makes it work ... -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa Creative thought means that you forgot where you read it. --Stanley Hauerwas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WinModem Support
Mark Santcroos writes: > > I have contacted the author and he made a last change in the interrupt > setup. > > I have made a small stand alone package for -CURRENT, it holds the .c, the > linux object file, a Makefile and a script to create the necessary device > files. (If you want it in your kernel you can figure out yourself > probably, this is just a proof of concept) > > http://www.ripe.net/home/mark/files/ltmdm_current_may_10.tgz > > It works great for me, let me know if it is not generic enough and I will > apply the changes. > I tried your package with Toshiba Portege 3440CT and 5.0C cvsupped last weekend. Still the same problems, no connect though it dials and ATI3 gives hard hang. Tomppa -- SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: [EMAIL PROTECTED]+358 9 52556252 fax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS-UP** ficl changes change `base' type
David O'Brien wrote: > > On Thu, May 10, 2001 at 02:21:09AM -0300, Daniel C. Sobral wrote: > > John Sadler is not a Unix user, and has no experience with Unix, and > ... > > If you know exactly how to produce a .tar.gz under Windows that is > > suitable for our use, I'm sure he would appreciate the help. > > Ask him to use infozip/pkzip -- I know that is easy for Winloose users. > Our unzip has a command line option to fix the text line termination. The zip he produces can be extracted fine. That's not the question. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Caffeine is proof that God hates mornings too To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: **HEADS-UP** ficl changes change `base' type
On Thu, May 10, 2001 at 02:21 -0300, Daniel C. Sobral wrote: > > John Sadler is not a Unix user [ ... ] If you know exactly how > to produce a .tar.gz under Windows that is suitable for our > use, I'm sure he would appreciate the help. Most of the distros I've seen (Linux as well as *BSD) have the DOS ports of these tools on their first CD, next to other archivers / partitioners / bootselectors / X-Servers / etc. Given the need (read: if I'm not late) I could provide - binaries of tar and gzip for DOS and i386+ - a .BAT / .CMD file to shove dir %1 into %1.tar.gz but it will be untested or wil take a few days since I'm 100% MS free here. :) virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Today's special: nessusd panics -CURRENT
>Date: Thu, 10 May 2001 09:52:03 -0700 (PDT)
>From: John Baldwin <[EMAIL PROTECTED]>
>> witness_get: witness exhausted
>> exclusive(sleep mutex) Giant(0xc044a760) locked @ ../../i386/i386/trap.c:1169
>> panic: system call open returning with mutex(s) held
>Ok, I see what's broken. I don't know how you are out of witness's though.
>We don't have enough types of mutexes for that to happen. Try this patch:
>Index: subr_witness.c
>===
>RCS file: /usr/cvs/src/sys/kern/subr_witness.c,v
>retrieving revision 1.70
>diff -u -r1.70 subr_witness.c
>--- subr_witness.c 2001/05/04 17:15:16 1.70
>+++ subr_witness.c 2001/05/10 16:39:27
>@@ -1222,6 +1222,9 @@
>("%s: p != curproc and we aren't in the debugger", __func__));
>KASSERT(!witness_cold, ("%s: witness_cold", __func__));
>+ if (!db_active && witness_dead)
>+ return (0);
>+
>nheld = witness_list_locks(&p->p_sleeplocks);
>/*
>--
Since I didn't use the "-l" flag to patch, it didn't apply, so I did it
by hand (and subsequently thought to check for whitespace issues).
But the patch appears to work; I'm up & running:
FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #59: Thu May 10 04:06:04 PDT
2001 root@:/common/C/obj/usr/src/sys/LAPTOP_30W i386
(I had encountered the witness panic before applying the patch.)
Only annoyance I'm encountering with it so far is involving my use of ssh;
perhaps I'm doing something Really Weird, but in any case, that probably
deserves a different Subject:.
Cheers,
david
--
David H. Wolfskill [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
John Baldwin wrote: > > On 10-May-01 Ruslan Ermilov wrote: > > 2) Is it valid that multiple DEVFS mounts over /dev are allowed? > > Why wouldn't it be? (Granted, it is a bit _weird_). You can do the same with > other fs's: ...and happily shoot yourself in the foot this way. :) I had pretty weird experiences into mounting multiple root directories (!). I have a crappy 486 which has an equally crappy IDE controller which can't grok my 3.2G HD. The loader couldn't boot the kernel from the drive. I had to keep another very crappy 250M HD with a duplicate of the / filesystem and a very special kernel that mounted its root from the other drive, since the kernel could recognize the drive correctly. Without DMA, of course. :) But it works. My point here is that I had a lot of fun in totally scrapping my system by doing a spurious mount /. No reboot(1) or halt(1) available... ;) C-A-Del! Anyways... Another OT question.. Is any MFC planned for devfs? I'm getting jealous of -current (running -stable). ;) Thanks, A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DEVFS
On Thu, 10 May 2001, Ruslan Ermilov wrote: > Hi! > > Just installed recent -CURRENT on my PC, and noticed strange things: > > 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still > happening on /dev, and where? Somewhat wierdly and unobviously, it's init that does the magic. > > 2) Is it valid that multiple DEVFS mounts over /dev are allowed? > > perl# mount -t devfs > devfs on /dev (devfs, local) > perl# mount /dev > perl# mount -t devfs > devfs on /dev (devfs, local) > devfs on /dev (devfs, local) > perl# mount /dev > perl# mount -t devfs > devfs on /dev (devfs, local) > devfs on /dev (devfs, local) > devfs on /dev (devfs, local) > perl# > > > Thanks, > -- > Ruslan ErmilovOracle Developer/DBA, > [EMAIL PROTECTED] Sunbay Software AG, > [EMAIL PROTECTED]FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.orgThe 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: DEVFS
On 10-May-01 Ruslan Ermilov wrote: > Hi! > > Just installed recent -CURRENT on my PC, and noticed strange things: > > 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still > happening on /dev, and where? devfs is mounted by /sbin/init IIRC. > 2) Is it valid that multiple DEVFS mounts over /dev are allowed? Why wouldn't it be? (Granted, it is a bit _weird_). You can do the same with other fs's: > mount -t procfs procfs on /proc (procfs, local) > sudo mount /proc > mount -t procfs procfs on /proc (procfs, local) procfs on /proc (procfs, local) > sudo umount /proc -- 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: **HEADS-UP** ficl changes change `base' type
On Thu, May 10, 2001 at 02:21:09AM -0300, Daniel C. Sobral wrote: > John Sadler is not a Unix user, and has no experience with Unix, and ... > If you know exactly how to produce a .tar.gz under Windows that is > suitable for our use, I'm sure he would appreciate the help. Ask him to use infozip/pkzip -- I know that is easy for Winloose users. Our unzip has a command line option to fix the text line termination. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DEVFS
Hi! Just installed recent -CURRENT on my PC, and noticed strange things: 1) If I don't have devfs line in /etc/fstab, why DEVFS mount is still happening on /dev, and where? 2) Is it valid that multiple DEVFS mounts over /dev are allowed? perl# mount -t devfs devfs on /dev (devfs, local) perl# mount /dev perl# mount -t devfs devfs on /dev (devfs, local) devfs on /dev (devfs, local) perl# mount /dev perl# mount -t devfs devfs on /dev (devfs, local) devfs on /dev (devfs, local) devfs on /dev (devfs, local) perl# Thanks, -- 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: FW: Snapshot Log - world broken in telnetd
On Thu, 10 May 2001, John Baldwin wrote: > It looks like the recent changes wrt to libpam in telnetd may have broken world. > ... > cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK > -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos > IV/libexec/telnetd/../../../crypto/telnet -DINET6 > -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I > /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include > -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l > ibexec\"-o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o > utility.o authenc.o -lutil -ltermcap /usr/obj/us > r/src/kerberosIV/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lcrypto > -L/usr/obj/usr/src/kerberosIV/libexec/telnetd/../../ > lib/libkrb -lkrb -lcrypt -lcom_err -lmp > /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../lib/libtelnet/libtelnet.a(sra. > o): In function `check_user': > sra.o(.text+0xb8f): undefined reference to `pam_start' > sra.o(.text+0xba7): undefined reference to `pam_strerror' > sra.o(.text+0xbc9): undefined reference to `pam_authenticate' > sra.o(.text+0xbf9): undefined reference to `pam_get_item' > sra.o(.text+0xc27): undefined reference to `pam_strerror' > sra.o(.text+0xc53): undefined reference to `pam_strerror' > sra.o(.text+0xc71): undefined reference to `pam_end' > sra.o(.text+0xc89): undefined reference to `pam_strerror' > *** Error code 1 The kerberosIV telnetd is missing linkage to libpam, perhaps more. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pgm to kill 4.3 via vm
On 10-May-01 Robert Watson wrote: > > On Wed, 9 May 2001, Garrett Wollman wrote: > >> <> <[EMAIL PROTECTED]> said: >> >> > I followed everything here fine until you asserted that the debugger >> > shouldn't need any locks. >> >> When the debugger is running, everything else should have been >> forcibly halted. > > The process and signal-related structures may be inconsistent if the > debugger disregards existing locks held over those structures. It does > not matter if code is currently still executing, it matters that > preemption can occur. The choices appear to be: > > 1) Disregard locks and risk corruption If I'm sending a kill -9 to a program, I could really care less about clobbering the SIGABRT it is currently getting sent. :) I think that a kernel debugger is a case of where one allows much foot shooting to occur. > 2) Fail if a lock is held mtx_trylock() makes this relatively easy to implement in many cases. -- 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: FW: Snapshot Log - world broken in telnetd
On 10-May-01 John Baldwin wrote: > It looks like the recent changes wrt to libpam in telnetd may have broken > world. Correction, world appears to be ok, just release is broken. -- 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: Today's special: nessusd panics -CURRENT
On 10-May-01 Szilveszter Adam wrote:
> Hello everybody,
>
> I have stumbled across some nice giraffe today.
>
> Look, this is cute (transcribed by hand for your enhanced viewing pleasure):
> (sorry, no serial console handy... should be easy to reproduce though)
>
># nessusd -D
>
> witness_get: witness exhausted
> exclusive(sleep mutex) Giant(0xc044a760) locked @ ../../i386/i386/trap.c:1169
> panic: system call open returning with mutex(s) held
Ok, I see what's broken. I don't know how you are out of witness's though.
We don't have enough types of mutexes for that to happen. Try this patch:
Index: subr_witness.c
===
RCS file: /usr/cvs/src/sys/kern/subr_witness.c,v
retrieving revision 1.70
diff -u -r1.70 subr_witness.c
--- subr_witness.c 2001/05/04 17:15:16 1.70
+++ subr_witness.c 2001/05/10 16:39:27
@@ -1222,6 +1222,9 @@
("%s: p != curproc and we aren't in the debugger", __func__));
KASSERT(!witness_cold, ("%s: witness_cold", __func__));
+ if (!db_active && witness_dead)
+ return (0);
+
nheld = witness_list_locks(&p->p_sleeplocks);
/*
--
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: pgm to kill 4.3 via vm
On Wed, 9 May 2001, Garrett Wollman wrote: > < said: > > > I followed everything here fine until you asserted that the debugger > > shouldn't need any locks. > > When the debugger is running, everything else should have been > forcibly halted. The process and signal-related structures may be inconsistent if the debugger disregards existing locks held over those structures. It does not matter if code is currently still executing, it matters that preemption can occur. The choices appear to be: 1) Disregard locks and risk corruption 2) Fail if a lock is held Note that in either case (1) or case (2), the debugger may need special code paths to implement services such as psignal() to indicate that locking is either not needed, or that it should fail rather than block/spin/... Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FW: Snapshot Log - world broken in telnetd
It looks like the recent changes wrt to libpam in telnetd may have broken world. -FW: <[EMAIL PROTECTED]>- Date: Thu, 10 May 2001 09:11:57 -0700 (PDT) From: Deimos Root <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Snapshot Log ===> libexec/telnetd cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/global.c cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/slc.c cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/state.c In file included from /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/state.c:44: /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/libtelnet/auth.h:86: warning: type defaults to `int' in declaration of `auth_debug_mode' cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/sys_term.c In file included from /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/sys_term.c:46 : /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/libtelnet/auth.h:86: warning: type defaults to `int' in declaration of `auth_debug_mode' /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/sys_term.c: In function `start_login': /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/sys_term.c:15 69: warning: unused variable `user' cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/telnetd.c In file included from /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/telnetd.c:91: /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/libtelnet/auth.h:86: warning: type defaults to `int' in declaration of `auth_debug_mode' /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/telnetd.c: In function `telnet': /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/telnetd.c:115 3: warning: implicit declaration of function `g etent' cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/termstat.c cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos IV/libexec/telnetd/../../../crypto/telnet -DINET6 -I/usr/src/kerberosIV/libexec/telnetd/../../include -Wall -DHAVE_CONFIG_H -I /usr/obj/usr/src/kerberosIV/libexec/telnetd/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/l ibexec\" -c /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/utility.c In file included from /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/telnetd/utility.c:50: /usr/src/kerberosIV/libexec/telnetd/../../../crypto/telnet/libtelnet/auth.h:
Re: pgm to kill 4.3 via vm
On 09-May-01 Dima Dorfman wrote: > [ -stable dropped from cc list ] > > John Baldwin <[EMAIL PROTECTED]> writes: >> >> On 09-May-01 Robert Watson wrote: >> > >> > On Tue, 8 May 2001, John Baldwin wrote: >> > >> >> That's easy enough. Well, it used to be at least. You can use 'ps' to >> >> find the address of the struct proc (first pointer in the display) and >> >> then do 'call psignal(addr, 9)' to send SIGKILL to the process. Then >> >> hit 'c' to continue and voila, the process dies. I think that may panic >> >> now due to proc lock not being held (though the debugger shouldn't need >> >> any locks in theory.) Perhaps mtx_assert() should honor db_active and >> >> not panic if it is set. >> > >> > I followed everything here fine until you asserted that the debugger >> > shouldn't need any locks. I guess I don't see why that is, at least in >> > terms of not corrupting structures. From a practical perspective, the >> > debugger is like any other interupt-driven preemptive code-path: if you >> > want to modify a structure, you need to synchronize appropriately to avoid >> > corrupting the structure. This may not be something you really want to do >> > in a debugger, so in that sense perhaps you *shouldn't* grab a lock in the >> > debugger, but to perform the described action safely, you *should* grab a >> > lock so as not to corrupt fields of the proc structure (i.e., if you broke >> > into the debugger during a non-atomic flags update). Violating system >> > invariants is something you should be allowed to do in a debugger, but >> > this sounded like it was a feature people were looking from to recover >> > from unhappy behavior, not to introduce it :-). >> >> I am more worried about the fact that you can deadlock the debugger. >> What does the debugger do if another process hold the proc lock on >> the process you want to kill? Cute, eh? The debugger is an extra >> special environment. Most of the time you've panic'ed when you are >> in there (but then the panicstr tests that skip lock operations save >> you from that). Also, in the debugger you know that no other >> threads are running. This is why 'show pcpu' can list spin locks on >> other cpu's safely, for example. I'm not sure if a ddb 'kill' >> command shouldn't be better implemented using a 'trylock' and >> refusing to send the signal if it can't get the lock so it can avoid >> doing really bad things. I suppose it wouldn't deadlock but would > > I think this makes sense. How should this be implemented, though? > pfind() locks the process before returning (as you well know). Not > using pfind() will work, but that breaks the abstraction. Is that > something to worry about? There's also no PROC_TRYLOCK macro, but > that's not hard to fix. For the per-process tracing I didn't use pfind but just walked the allproc list myself. Using that in combo with a trylock might be your best bet. -- 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: select(2) converted to use a condition variable, and optimis
On 10-May-01 Terry Lambert wrote: > Seigo Tanimura wrote: >> A quick and hopefully efficient solution to those problems is to >> fhold() struct file's first, then enter polling loop. That seems much >> cheaper than to work on free()ing a vnode or a socket with holding a >> process lock, provided that struct filedesc and file are protected >> properly (and we have to do it anyway). > > Let me once again point out that fhold(), like crhold(), > should act as an l-valued function that takes an r-value > as an "argument", as in: > > a = crhold(b); > q = fhold(r); > etc. (for all such functions). > > [ snip ] I agree with all this, I just haven't had the time to sit down and do it. > -- Terry -- 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: select(2) converted to use a condition variable, and optimis
Seigo Tanimura wrote: > A quick and hopefully efficient solution to those problems is to > fhold() struct file's first, then enter polling loop. That seems much > cheaper than to work on free()ing a vnode or a socket with holding a > process lock, provided that struct filedesc and file are protected > properly (and we have to do it anyway). Let me once again point out that fhold(), like crhold(), should act as an l-valued function that takes an r-value as an "argument", as in: a = crhold(b); q = fhold(r); etc. (for all such functions). The reason is that you can not replace it with an instrumented function, otherwise, which would permit you to catch subtle errors that: a = b; crhold(a); q = r; fhold(r); etc. may cause (yes, I know I have held the r-calue in one case and the l-value in the other in the above example; the kernel itself does this all over the place, and I think it's an error). I also think that they should use common base macros: it is exceedingly dangerous to have multiple hold semantics in the kernel. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Today's special: nessusd panics -CURRENT
Hello everybody,
I have stumbled across some nice giraffe today.
Look, this is cute (transcribed by hand for your enhanced viewing pleasure):
(sorry, no serial console handy... should be easy to reproduce though)
# nessusd -D
witness_get: witness exhausted
exclusive(sleep mutex) Giant(0xc044a760) locked @ ../../i386/i386/trap.c:1169
panic: system call open returning with mutex(s) held
Debugger("panic")
Stoppped at Debugger+0x45: pushl: %ebx
db> trace
Debugger
panic
syscall
syscall_with_err_pushed
db>
OK, so let's see what's next.
db> c
syncing disks... 17 17 panic: witness_restore: lock(sleep mutex) Giant not
locked
Debugger("panic")
Stopped at Debugger+0x45: pushl: %ebx
db>
Hmmm... this is not right. What now?
db> trace
Debugger
panic
witness_restore
msleep
buf_daemon
fork_exit
fork_trampoline
db>
Well if that doesn't work, let's at least try to dump:
db> c
dumping to dev #ad/0x20001, offset 352256
dump ata0: resetting devices... panic: witness_save: lock(sleep mutex) Giant not
locked
Debugger("panic")
Stopped at Debugger+0x45: pushl: %ebx
db>
No, bad Szilveszter, no crash dumps for you today. Well OK, let's see:
db> trace
Debugger
panic
witness_save
mawait
ata_command
ad_reinit
ata_reinit
addump
dumpsys
boot
panic
witness_restore
msleep
buf_daemon
fork_exit
fork_trampoline
db> c
Dump already in progress, bailing...
Automatic reboot in 15 sec etc.
(And of course no dump)
So? Opinions? things to try?
-CURRENT is from yesterday, kernel and world in sync, machine UP PII-233.
Nessus is from ports and has been extra recompiled after the make world.
I will try anything if needed or test any patches...
Thank you for your time...
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: WinModem Support
On Thu, May 10, 2001 at 01:51:25AM -0700, David O'Brien wrote: > On Mon, May 07, 2001 at 02:37:20PM +0200, Mark Santcroos wrote: > > > Please check http://www.geocities.com/wtnbkysh/ . It should work > > > under 4.2R. There is also some 5.0C patches but still some problems > > > probably with interrupts. > > > > Any idea who is the author of this? > > > > I also tried it on -current and it needs some refinement probably. > > I am willing to do that but it would be nice if the author could give me > > some hints. > > Have you gotten anywhere with this? Yes! I have contacted the author and he made a last change in the interrupt setup. I have made a small stand alone package for -CURRENT, it holds the .c, the linux object file, a Makefile and a script to create the necessary device files. (If you want it in your kernel you can figure out yourself probably, this is just a proof of concept) http://www.ripe.net/home/mark/files/ltmdm_current_may_10.tgz It works great for me, let me know if it is not generic enough and I will apply the changes. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
