Re: Re: userland program panics freebsd 4.3
Noop, just verified it again on FBSD 4.4 STABLE, this: int process_alive(pid) pid_t pid; { while (waitpid(pid, NULL, WNOHANG) < 0 && errno == EINTR) /* do nothing */; return kill(pid, 0) == 0; } misses a bunch of closed? deleted? usd up pids? on my client, it stays in 'SMB use SID to enemurate' but i verified these are not still runnning. only one that works is this code: /* * Invalid argument */ if(!pid) return 0; */ for(i=0,ret=1;(i<100) && (ret > 0);i++) ret = waitpid(pid, NULL, WNOHANG); return kill(pid, 0) == 0; Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ - Original Message - From: "Stefan Esser" <[EMAIL PROTECTED]> To: "John Rochester" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Stefan Esser" <[EMAIL PROTECTED]> Sent: Tuesday, January 01, 2002 5:25 PM Subject: Re: Re: userland program panics freebsd 4.3 > On 2002-01-01 19:59 +, John Rochester <[EMAIL PROTECTED]> wrote: > > Stefan Esser wrote: > > > > >Instead of the for loop, I'd rather have: > > > > > > while(waitpid(pid, NULL, WNOHANG) == EINTR) > > > > > This should be > > > > while (waitpid(pid, NULL, WNOHANG) < 0 && errno == EINTR) > > Yes, obviously ... ;-) > > STefan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: userland program panics freebsd 4.3
FYI: just finished up a scan of a network with 1200 hosts and now panic's I did not install the second set of patches (or third) but only that first set ti utils.c that prevented the /procpid% scanning. Not only doesn't it crash, but it seems to be faster. It is a LOT faster than nessus 1.09 (scan of 1200 on nessus 1.09 took 28 hours before, now takes about 4 house with max_hosts = 30, max_threads = 20 on a 850mhz PII with 256MB ram. -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ - Original Message - From: "Stefan Esser" <[EMAIL PROTECTED]> To: "John Rochester" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Stefan Esser" <[EMAIL PROTECTED]> Sent: Tuesday, January 01, 2002 5:25 PM Subject: Re: Re: userland program panics freebsd 4.3 > On 2002-01-01 19:59 +, John Rochester <[EMAIL PROTECTED]> wrote: > > Stefan Esser wrote: > > > > >Instead of the for loop, I'd rather have: > > > > > > while(waitpid(pid, NULL, WNOHANG) == EINTR) > > > > > This should be > > > > while (waitpid(pid, NULL, WNOHANG) < 0 && errno == EINTR) > > Yes, obviously ... ;-) > > STefan > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: userland program panics freebsd 4.3
On 2002-01-01 19:59 +, John Rochester <[EMAIL PROTECTED]> wrote: > Stefan Esser wrote: > > >Instead of the for loop, I'd rather have: > > > > while(waitpid(pid, NULL, WNOHANG) == EINTR) > > > This should be > > while (waitpid(pid, NULL, WNOHANG) < 0 && errno == EINTR) Yes, obviously ... ;-) STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Stefan Esser wrote: >Instead of the for loop, I'd rather have: > > while(waitpid(pid, NULL, WNOHANG) == EINTR) > This should be while (waitpid(pid, NULL, WNOHANG) < 0 && errno == EINTR) > >/* do nothing */; > > return kill(pid, 0) == 0; > -- John Rochester Software Architect, Merus Software Ltd. Tel: +44 7870 174690http://merus.co.uk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: Re: userland program panics freebsd 4.3
On 2001-12-31 11:31 -0500, Michael Scheidell <[EMAIL PROTECTED]> wrote: > > (The second method, used only if there is no PROCFS, is to call > > kill(PID, 0), which will check if a signal could be delivered. > > That method should probably be prefered to the reading of procfs > > anyway, since the latter takes 5 system calls instead of a single > > one in the case of kill() ...) > > would this patch fix it on the nessus side?, and it SEEMS to be faster. > also, several 'core dumps' listed on nessusd.messages werein fact programs > that also were listed as finished. > @@ -898,6 +898,9 @@ > if(!pid) > return 0; > > +#ifndef FREEBSD > +## panics FREEBSD 4.3 and 4.4, might be fixed in FREEBSD 4.5 > + > /* >* First method : attempt to open /proc/ >* (we first check that we can open /proc/ourpid because > @@ -917,6 +920,7 @@ > else return 0; > } > > +#endif Yes, this will fix the port. But I'm not sure, whether the code that will be used instead of reading /proc/ could not be improved: /* * Second method, we attempt to use kill. But first, we * wait() for the process, just in case it's a zombie. */ for(i=0,ret=1;(i<100) && (ret > 0);i++) ret = waitpid(pid, NULL, WNOHANG); return kill(pid, 0) == 0; Instead of the for loop, I'd rather have: while(waitpid(pid, NULL, WNOHANG) == EINTR) /* do nothing */; return kill(pid, 0) == 0; That way only a return code of EINTR will casue a retry of waitpid(), while all other values rather indicate that waitpid() can not succeed, no matter it is called with the same parameter set. In fact, I'm not sure that the waitpid() call is required at all, since there are places where children are being waited for ... (And, looking at uses of waitpid(), I think some other loops should also be changed as shown above, see for example wait_for_children() in file nessusd/pluginlaunch.c). My suggested patch to nessusd/utils.c (combining the #ifndef __FreeBSD__ and my change to the waitpid() loop, diff against nessus-1.1.11): --- nessusd/utils.c~Mon Dec 17 16:11:42 2001 +++ nessusd/utils.c Tue Jan 1 19:48:27 2002 @@ -887,10 +887,10 @@ process_alive(pid) pid_t pid; { +#ifndef __FreeBSD__ char procname[255]; DIR * dir; - int ret; - int i; +#endif /* * Invalid argument @@ -898,6 +898,7 @@ if(!pid) return 0; +#ifndef __FreeBSD__ /* * First method : attempt to open /proc/ * (we first check that we can open /proc/ourpid because @@ -916,13 +917,14 @@ } else return 0; } +#endif /* * Second method, we attempt to use kill. But first, we * wait() for the process, just in case it's a zombie. */ - for(i=0,ret=1;(i<100) && (ret > 0);i++) -ret = waitpid(pid, NULL, WNOHANG); + while(waitpid(pid, NULL, WNOHANG) == EINTR) +/* do nothing */; return kill(pid, 0) == 0; } (Note: This code has not been tested in a large network, but just in my home LAN consisting of two machines ...) Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: userland program panics freebsd 4.3
> > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32681 > > The cause is a NULL pointer dereference in that fstatfs system > call, where some pointer hanging off a vnode is cleared. Nessusd > tries to read from /proc/PID (for PID = process IDs of plugins > spawned) in order to see whether some plugin is still running. > (The second method, used only if there is no PROCFS, is to call > kill(PID, 0), which will check if a signal could be delivered. > That method should probably be prefered to the reading of procfs > anyway, since the latter takes 5 system calls instead of a single > one in the case of kill() ...) would this patch fix it on the nessus side?, and it SEEMS to be faster. also, several 'core dumps' listed on nessusd.messages werein fact programs that also were listed as finished. cd ../nessus-core/nessusd --- utils.c.origMon Dec 17 12:02:23 2001 +++ utils.c Mon Dec 31 11:20:12 2001 @@ -898,6 +898,9 @@ if(!pid) return 0; +#ifndef FREEBSD +## panics FREEBSD 4.3 and 4.4, might be fixed in FREEBSD 4.5 + /* * First method : attempt to open /proc/ * (we first check that we can open /proc/ourpid because @@ -917,6 +920,7 @@ else return 0; } +#endif /* * Second method, we attempt to use kill. But first, we * wait() for the process, just in case it's a zombie. -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: userland program panics freebsd 4.3
On 2001-12-31 10:29 -0500, Michael Scheidell <[EMAIL PROTECTED]> wrote: > as for hanging processes, this is probaly due to the bug in the FBSD > distributer libpcap, hanging on pcap_next(). IIRC, most processes were sleeping in select(). But truss revealed, that some processes were running in a loop executing signal mask functions and not responding to a kill -TERM ... > I got those also in nessus 1.09 > this was fixed in nessusd 1.1x, which uses its one libpcap. Then I must have a different problem, since I'm currently using 1.1.10 (will try 1.1.11 when I'm back in the office on January 8th). > I would be interested in seeing if nessus 1.10 or 1.11x panics freebsd at > your site. Sure it does ;-) http://www.FreeBSD.org/cgi/query-pr.cgi?pr=32681 And it is the same problem you observed (and even the stack trace looks quite similar). The problem occurs on -stable and -current and with SMP and non-SMP kernels. The cause is a NULL pointer dereference in that fstatfs system call, where some pointer hanging off a vnode is cleared. Nessusd tries to read from /proc/PID (for PID = process IDs of plugins spawned) in order to see whether some plugin is still running. (The second method, used only if there is no PROCFS, is to call kill(PID, 0), which will check if a signal could be delivered. That method should probably be prefered to the reading of procfs anyway, since the latter takes 5 system calls instead of a single one in the case of kill() ...) Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
> > I've had similar problems running nessus against a range of 32 class B > networks (i.e. 2mio addresses) with some 1 hosts expected to be > found. Since I need to complete the scan during the next two weeks > (it's running in batch mode right now; but I had trouble with hanging > nessusd processes and I guess I'll have to manually rescan many hosts.) > > If you are interested, we could share our experience running nessus > under FreeBSD ... No German, I am stuck with english. as for hanging processes, this is probaly due to the bug in the FBSD distributer libpcap, hanging on pcap_next(). I got those also in nessus 1.09 this was fixed in nessusd 1.1x, which uses its one libpcap. I would be interested in seeing if nessus 1.10 or 1.11x panics freebsd at your site. -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On 2001-12-18 15:29 -0500, Michael Scheidell <[EMAIL PROTECTED]> wrote: > I have a userland program that canpanic/reboot a freebsd 4.3 system. > Hardware is Intel isp1100 (mbx440 motherboard) 850MHZ pIII, 256mb ram, 640mb > swapfile > software is 'nessusd' (network security scanner) hits the ethernet port > pretty hard when running. > If I read the dumpdev right, it is crashing in the vm section of the kernel, > refrencing a structure that is not within kernel space? This appears to a duplicate of kern/32681, currently assigned to Dag-Erling Smorgrav <[EMAIL PROTECTED]>. You can insert the code shown below as a work-around: > list > 677 > 678 if ((error = getvnode(p->p_fd, SCARG(uap, fd), &fp)) != 0) > 679 return (error); > 680 mp = ((struct vnode *)fp->f_data)->v_mount; if (mp == NULL) return (ENOENT); > 681 sp = &mp->mnt_stat; > 682 error = VFS_STATFS(mp, sp, p); > 683 if (error) > 684 return (error); Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
* Michael Scheidell <[EMAIL PROTECTED]> [011227 15:11] wrote: > > - Original Message - > From: "Alfred Perlstein" <[EMAIL PROTECTED]> > To: "Michael Scheidell" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, December 27, 2001 4:00 PM > Subject: Re: userland program panics freebsd 4.3 ok, what filesystem is this over? Do you have an idea which program causes the fault and what it does before the statfs call and over which type of FS it does it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
- Original Message - From: "Alfred Perlstein" <[EMAIL PROTECTED]> To: "Michael Scheidell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, December 27, 2001 4:00 PM Subject: Re: userland program panics freebsd 4.3 > *mp, *sp, *p, *((struct vnode *)fp->f_data) print *mp: $1 = {mnt_list = {tqe_next = 0x8624c, tqe_prev = 0x28076200}, mnt_op = 0x280623bc, mnt_vfc = 0x280ac75e, mnt_vnodecovered = 0x280ac76e, mnt_syncer = 0x280ac77e, mnt_nvnodelist = {tqh_first = 0x280ac78e, tqh_last = 0x280ac79e}, mnt_lock = {lk_interlock = { lock_data = 672135372}, lk_flags = 672118400, lk_sharecount = 671795150, lk_waitcount = 671971764, lk_exclusivecount = 31188, lk_prio = 10253, lk_wmesg = 0x280ac7fe "hP", lk_timo = 671795214, lk_lockholder = 671795230}, mnt_flag = 671795246, mnt_kern_flag = 672127820, mnt_maxsymlinklen = 671795278, mnt_stat = { f_spare2 = 671795294, f_bsize = 671795310, f_iosize = 672152136, f_blocks = 671795342, f_bfree = 671795358, f_bavail = 671795374, f_files = 671795390, f_ffree = 671795406, f_fsid = {val = {671795422, 671973044}}, f_owner = 671795454, f_type = 671795470, f_flags = 671795486, f_syncwrites = 671795502, f_asyncwrites = 672121400, f_fstypename = "NÉ\n(^É\n(nÉ\n(~É\n(", f_mntonname = "\216É\n(\236É\n(\0006\017(¬\\\021(ð<\021(ÞÉ\n(îÉ\n(þÉ\n(pÁ\017(Ô\177\r(.Ê\n (>Ê\n(NÊ\n(^Ê\n(nÊ\n(~Ê\n(\216Ê\n(\204d\021(®Ê\n(¾Ê\n(", f_syncreads = 672126696, f_asyncreads = 671795934, f_spares1 = -13586, f_mntfromname = "\n(\230É\017(\016Ë\n(\036Ë\n(.Ë\n(>Ë\n(NË\n(^Ë\n(nË\n(~Ë\n(ô\215\020(\236Ë\ n(®Ë\n(Ô\201\r(ÎË\n(ÞË\n(îË\n(þË\n(°>\021(\036Ì\n(.Ì", f_spares2 = 10250, f_spare = {671796286, 671796302}}, mnt_data = 0x280acc5e, mnt_time = 671796334, mnt_iosize_max = 671796350, mnt_reservedvnlist = {tqh_first = 0x280acc8e, tqh_last = 0x280acc9e}} print *sp: Cannot access memory at address 0x7. print *p Cannot access memory at address 0x8000. print *((struct vnode *)fp->f_data) $2 = {v_flag = 0, v_usecount = 1, v_writecount = 0, v_holdcnt = 0, v_id = 3291, v_mount = 0x0, v_op = 0xc11bc300, v_freelist = {tqe_next = 0x0, tqe_prev = 0xce195cdc}, v_nmntvnodes = {tqe_next = 0xce381500, tqe_prev = 0xce3816a4}, v_cleanblkhd = {tqh_first = 0x0, tqh_last = 0xce3815ec}, v_dirtyblkhd = {tqh_first = 0x0, tqh_last = 0xce3815f4}, v_synclist = {le_next = 0x0, le_prev = 0x0}, v_numoutput = 0, v_type = VBAD, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = { sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_object = 0x0, v_interlock = { lock_data = 0}, v_vnlock = 0x0, v_tag = VT_NON, v_data = 0x0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xce381640}, v_dd = 0xce3815c0, v_ddid = 0, v_pollinfo = { vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, si_note = { slh_first = 0x0}, si_flags = 0}, vpi_events = 0, vpi_revents = 0}, v_vxproc = 0x0} kernel config: (needed the PMAP_SHGRPROC to allow apache to run, maxusers 128 mostly for processes and fd's only one user, program is nessusd, a security scanner that wacks the crap out of the network drivers and /dev/bpf's machine i386 cpu I686_CPU ident HACKERTRAP maxusers128 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols makeoptions CONF_CFLAGS=-fno-builtin #Don't allow use of memcmp, etc. options PMAP_SHPGPERPROC=300 options PANIC_REBOOT_WAIT_TIME=32 options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options KBD_INSTALL_CDEV# install a CDEV entry in /dev device isa options AUTO_EOI_1 device pci device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static devi
Re: userland program panics freebsd 4.3
* Michael Scheidell <[EMAIL PROTECTED]> [011227 14:48] wrote: > > same place as before: > > 0 fstatfs (p=0xce1bd260, uap=0xce216f80) at ../../kern/vfs_syscalls.c:684 > 684 error = VFS_STATFS(mp, sp, p); > 680 if ((error = getvnode(p->p_fd, SCARG(uap, fd), &fp)) != 0) > 681 return (error); > 682 mp = ((struct vnode *)fp->f_data)->v_mount; > 683 sp = &mp->mnt_stat; > 684 error = VFS_STATFS(mp, sp, p); > 685 if (error) > 686 return (error); > 687 sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; > 688 if (suser_xxx(p->p_ucred, 0, 0)) { > (kgdb) print mp > $1 = (struct mount *) 0x28121604 > (kgdb) print sp > $2 = (struct statfs *) 0x7 > (kgdb) print p > $3 = (struct proc *) 0x8000 > (kgdb) print sp->f_flags > Cannot access memory at address 0x37. Ah, ok, I did see this before. Can you print: *mp, *sp, *p, *((struct vnode *)fp->f_data) Can you tell me what filesystem this is over? Do you have any special tunables set in your kernel? Anything you can divulge about how this program operates? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
- Original Message - From: "Alfred Perlstein" <[EMAIL PROTECTED]> To: "Michael Scheidell" <[EMAIL PROTECTED]> Cc: "David Malone" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 27, 2001 3:31 PM Subject: Re: userland program panics freebsd 4.3 > * Michael Scheidell <[EMAIL PROTECTED]> [011227 14:26] wrote: > > Just an update: > > userland probram panic's FBSD 4.3-REL, FBSD 4.4-REL and FBSD 4.4-STABLE. > > its not hardware (unless two completly identicle systems have some type of > > chip problem not known yet) > > Can you provide this program or a kernel stack trace from this > crash please? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneld ebug.html same place as before: 0 fstatfs (p=0xce1bd260, uap=0xce216f80) at ../../kern/vfs_syscalls.c:684 684 error = VFS_STATFS(mp, sp, p); (kgdb) lines Undefined command: "lines". Try "help". (kgdb) list 679 680 if ((error = getvnode(p->p_fd, SCARG(uap, fd), &fp)) != 0) 681 return (error); 682 mp = ((struct vnode *)fp->f_data)->v_mount; 683 sp = &mp->mnt_stat; 684 error = VFS_STATFS(mp, sp, p); 685 if (error) 686 return (error); 687 sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; 688 if (suser_xxx(p->p_ucred, 0, 0)) { (kgdb) print mp $1 = (struct mount *) 0x28121604 (kgdb) print sp $2 = (struct statfs *) 0x7 (kgdb) print p $3 = (struct proc *) 0x8000 (kgdb) print sp->f_flags Cannot access memory at address 0x37. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3 (now 4.4 also)
* Michael Scheidell <[EMAIL PROTECTED]> [011227 14:34] wrote: > > > * Michael Scheidell <[EMAIL PROTECTED]> [011227 14:26] wrote: > > > Just an update: > > > userland probram panic's FBSD 4.3-REL, FBSD 4.4-REL and FBSD 4.4-STABLE. > > > its not hardware (unless two completly identicle systems have some type > of > > > chip problem not known yet) > > > > Can you provide this program or a kernel stack trace from this > > crash please? > > I have, several times already > see archives or last weeks emails' > > I was told to go to FBSD 4.4-STABLE due to 'many fixes' in the kernel. > I did. > this was just an update. > > Problem seems to be in the vm section of the kernel. I the most recent backtrace would be the most helpful, so would program source, please provide it directly, I don't have time to search the archives, remeber who is asking for help, eh? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3 (now 4.4 also)
- Original Message - From: "Alfred Perlstein" <[EMAIL PROTECTED]> To: "Michael Scheidell" <[EMAIL PROTECTED]> Cc: "David Malone" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 27, 2001 3:31 PM Subject: Re: userland program panics freebsd 4.3 > * Michael Scheidell <[EMAIL PROTECTED]> [011227 14:26] wrote: > > Just an update: > > userland probram panic's FBSD 4.3-REL, FBSD 4.4-REL and FBSD 4.4-STABLE. > > its not hardware (unless two completly identicle systems have some type of > > chip problem not known yet) > > Can you provide this program or a kernel stack trace from this > crash please? I have, several times already see archives or last weeks emails' I was told to go to FBSD 4.4-STABLE due to 'many fixes' in the kernel. I did. this was just an update. Problem seems to be in the vm section of the kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
* Michael Scheidell <[EMAIL PROTECTED]> [011227 14:26] wrote: > Just an update: > userland probram panic's FBSD 4.3-REL, FBSD 4.4-REL and FBSD 4.4-STABLE. > its not hardware (unless two completly identicle systems have some type of > chip problem not known yet) Can you provide this program or a kernel stack trace from this crash please? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Just an update: userland probram panic's FBSD 4.3-REL, FBSD 4.4-REL and FBSD 4.4-STABLE. its not hardware (unless two completly identicle systems have some type of chip problem not known yet) its not thermal problem (I can do make buildworld's all day long) If I do find it, its easy to tell: I can panic FBSD in 10 or 15 mins. Kept panicing FBSD 4.3, so tried the UPAGES/Stack patch (change UPAGES from 2 to 3) upgraded a system to FBSD-REL 4.4 (RELENG_4_4), make clean, make new kernel, make world, including userland program (just in case) Still panic, so upgraded to FBSD 4.4-STABLE (RELENG_4) same thing, make clean, make workd, also: ssh now give me this when I connect: Using username "scheidell". otp-md5 S/Key Password: -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
> I did this, and instead of crashing in 15 ins, its still running after 3 > hours. > I will rerun tests and report back. > Thanks for the suggestion (now, if I cvsup RELENG_4_3 do I get the OLD > param.h?) I think with cvsup you will get the old one back again. If you use cvs it would preserve the change. At least it is an easy change to make. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
- Original Message - From: "David Malone" <[EMAIL PROTECTED]> To: "Michael Scheidell" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, December 21, 2001 1:18 PM Subject: Re: userland program panics freebsd 4.3 > On Fri, Dec 21, 2001 at 12:51:38PM -0500, Michael Scheidell wrote: > > > My gut reaction tells me that this is either a kernel stack overflow or out > > > of KVM. The kernel stack overflow problem was "fixed" in 4.4-STABLE some > > > time back (change UPAGES from 2 to 3 in the kernel) so that the kernel stack > > > changes from 4.5K to 8.5K. > This one is easy - edit /usr/src/sys/i386/include/param.h and change > UPAGES from 2 to 3 (or even 5 if you like). I got Bruce to add an > errata about this... I did this, and instead of crashing in 15 ins, its still running after 3 hours. I will rerun tests and report back. Thanks for the suggestion (now, if I cvsup RELENG_4_3 do I get the OLD param.h?) -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ > > David. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Fri, Dec 21, 2001 at 12:51:38PM -0500, Michael Scheidell wrote: > > My gut reaction tells me that this is either a kernel stack overflow or out > > of KVM. The kernel stack overflow problem was "fixed" in 4.4-STABLE some > > time back (change UPAGES from 2 to 3 in the kernel) so that the kernel stack > > changes from 4.5K to 8.5K. > > Ok, 'fixed', thats good, makes me want to try the 4.4 kernel, or could I > tune 4.3 kernel to a 8.5k stack? This one is easy - edit /usr/src/sys/i386/include/param.h and change UPAGES from 2 to 3 (or even 5 if you like). I got Bruce to add an errata about this... David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Thu, Dec 20, 2001 at 07:14:08PM -0800, Kris Kennaway wrote: > On Thu, Dec 20, 2001 at 09:08:36PM -0600, Paul Halliday wrote: > > > > On Thu, 20 Dec 2001, Kris Kennaway wrote: > > > > > On Thu, Dec 20, 2001 at 12:45:51PM -0500, Michael Scheidell wrote: > > > > > > > > > > I'm not aware of any services that broke between 4.3 and 4.4. Care to > > > > > elaborate? > > > > > > > > scan through freebsd-questions, freebsd-mobile and freebsd-ports > > > > > > That's completely non-helpful. I read -questions and -ports, and > > > don't recall complaints of massive breakage in 4.4. Perhaps you'd > > > care to be more specific so we can actually address the problems, if > > > they exist? > > > > My soundcard on my lappy has been broken since 4.4. And to be > > brutally honest, it's really starting to piss me off. > > Which PR contains your bug report? I couldn't see one. I'm not Paul Halliday, but I do have an ignored soundcard PR: kern/31445. I made the PR, mentioned it on multimedia, posted a patch a couple days later (to the PR), and even got someone to say he'd tried it and it had helped him. That correspondance is also attached to the PR. The PR is still open and unchanged since 29 Oct 2001. Soundcard behavior is unmodified on the box I reported it on as of a CVSup earlier this week. What did *I* do wrong? msg30368/pgp0.pgp Description: PGP signature
Re: userland program panics freebsd 4.3
> Kris Kennaway wrote: > > On Thu, Dec 20, 2001 at 09:10:14AM -0500, Michael Scheidell wrote: > > > I doubt hardware related > > > I can get it to do it on two seperate boxes. > > > > OK, then you need to get more details as explained. > > My gut reaction tells me that this is either a kernel stack overflow or out > of KVM. The kernel stack overflow problem was "fixed" in 4.4-STABLE some > time back (change UPAGES from 2 to 3 in the kernel) so that the kernel stack > changes from 4.5K to 8.5K. Ok, 'fixed', thats good, makes me want to try the 4.4 kernel, or could I tune 4.3 kernel to a 8.5k stack? > > The other possibility is that he's configured the kernel so big (maxusers > too high etc) and he's running out of KVM. No tuning information was > supplied (kernel configs, any sysctl/tunable changes etc). maxusers 128, guess I could fiddle with vm,kernfiles, etc, but that was easyest way, the 'one' processes (user) can spawn 32*20 individual processes, each one open several files (yes, I uses ulimits on it) limits -C nessusd Resource limits for class nessusd: cputime infinity secs filesize 131072 kb datasize-cur65536 kb stacksize-cur 32768 kb coredumpsize-cur0 kb memoryuse-cur 65536 kb memorylocked-cur65536 kb maxprocesses 64 openfiles 256 sbsize infinity bytes nothing twiddled in sysctl, but in order to get apache to run, did: options PMAP_SHPGPERPROC=300 (sorry, If I didn't post it here, did both (maxusers and PMAP_) on comp.unix.bsd.freebsd.misc group already) > > I'd be interested to know what this says: > # gdb -k /kernel /dev/mem > (kgdb) print ((struct vm_map *)kernel_map)->size print ((struct vm_map *)kernel_map)->size $1 = 247824384 -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Kris Kennaway wrote: > On Thu, Dec 20, 2001 at 09:10:14AM -0500, Michael Scheidell wrote: > > I doubt hardware related > > I can get it to do it on two seperate boxes. > > OK, then you need to get more details as explained. My gut reaction tells me that this is either a kernel stack overflow or out of KVM. The kernel stack overflow problem was "fixed" in 4.4-STABLE some time back (change UPAGES from 2 to 3 in the kernel) so that the kernel stack changes from 4.5K to 8.5K. The other possibility is that he's configured the kernel so big (maxusers too high etc) and he's running out of KVM. No tuning information was supplied (kernel configs, any sysctl/tunable changes etc). I'd be interested to know what this says: # gdb -k /kernel /dev/mem (kgdb) print ((struct vm_map *)kernel_map)->size Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
- Original Message - From: "Paul Halliday" <[EMAIL PROTECTED]> To: "Kris Kennaway" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, December 20, 2001 10:08 PM Subject: Re: userland program panics freebsd 4.3 > > On Thu, 20 Dec 2001, Kris Kennaway wrote: > > > On Thu, Dec 20, 2001 at 12:45:51PM -0500, Michael Scheidell wrote: > > > > > > > > I'm not aware of any services that broke between 4.3 and 4.4. Care to > > > > elaborate? > > > > > > scan through freebsd-questions, freebsd-mobile and freebsd-ports > > > > That's completely non-helpful. I read -questions and -ports, and > > don't recall complaints of massive breakage in 4.4. Perhaps you'd > > care to be more specific so we can actually address the problems, if > > they exist? > > Because there are dozens or even hundreds of kernel bugs fixed since > > 4.3, so there's a very good chance yours was one of them. I guess I forgot a couple of things: #1, this IS a free operating system and noone is being paid to fix my problems #2, you probably get a lot of 'its broke please fix it' posts to these newsgroups #3, when I am frustrated I get a little testy. I would like to thank those who have assisted me in trying to find this problem and fix it. Nick Hilliard for his original pointer to FBSD handbook and the dumpdev section. Matthew Dillon for his offer to look at the vmcore (I know someone asked for more information, but beyond the gdb kernel traces and the description of the hardware, I don't think posting a 256MB core here would be a good idea) I also forgot that those of you who do try to help fix problems might also get frustrated at the lack of information given during the initial posts. Sorry, I did the best I could. I described the hardware and the environment and thought I pointed to the section in the kernel that had the problem. I was hoping that the given environment would trigger some suggestions, other than going to a new version. I like FBSD, It is faster and easier to use than Linux (for my application). I like the ports section. It is very easy to use, easy to update, and it contains most of what I would need. FBSD has been very stable except for this one thing. I expect that eventually we will find why it is happening and find some small, obscure 'feature' in the os that is causing this. It will get fixed quickly and help future generations of FBSD users who aren't so lucky as to be able to reproduce the panic at will. Again, I thank those who helped, even those who I did not mention and when I find the problem, I will post the resolution. -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Kris Kennaway wrote: > OK, so what you're saying is that you haven't even tried to report the > problem such that it can be fixed. I don't think it's fair to hold > your lack of communication about your problem against the FreeBSD > sound developers; if you want this to get fixed then you really need > to get the ball rolling yourself by doing the best you can to describe > and detail the problem in a PR. If you're missing details then > someone will ask for them. Exactly! I have had extremely good experiences with PRs in general, and things are getting better still. Kudos all around. Even if you can't provide enough information in the initial PR, the person looking at it will usually tell you what other information is needed to debug things, and how to obtain it. Hoping that someone else will submit a PR for your problem is not very efficient. It is true, however, that a PR may fall through the cracks sometimes. It isn't a bad idea to ping a newsgroup about a PR after some reasonable time after submission (a week or two). Lars -- Lars Eggert <[EMAIL PROTECTED]> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
:I have a userland program that canpanic/reboot a freebsd 4.3 system. :Hardware is Intel isp1100 (mbx440 motherboard) 850MHZ pIII, 256mb ram, 640mb :swapfile :software is 'nessusd' (network security scanner) hits the ethernet port :pretty hard when running. :If I read the dumpdev right, it is crashing in the vm section of the kernel, :refrencing a structure that is not within kernel space? :(sp) Hi Michael. If you can gzip up the kernel.debug and vmcore files and put them up somewhere where I can download them. This looks like it ought to be fairly easy to locate if I could examine the kernel core. Note that kernel cores often contain sensitive information, so you may not want to do this. If you do, put them up somewhere invisible and email me their locations in private email (without the freebsd list). p.s. I think your bug report was fairly well detailed myself. Most people don't post gdb backtraces the first time around :-) :print sp->f_flags :Cannot access memory at address 0x39. : : print mp :$6 = (struct mount *) 0x2811aea8 :(kgdb) print p :$7 = (struct proc *) 0x8068ee4 :(kgdb) print mp :(kgdb) print sp :$9 = (struct statfs *) 0x9 : :-- :Michael Scheidell gdb doesn't always get local variables correct, due to compiler optimizations. sp obviously cannot be 0x9 if mp is 0x28811aea8. try 'print fp' and 'print *fp' to see whether the fp looks reasonable. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Thu, Dec 20, 2001 at 09:26:53PM -0600, Paul Halliday wrote: > > > My soundcard on my lappy has been broken since 4.4. And to be > > > brutally honest, it's really starting to piss me off. > > > > Which PR contains your bug report? I couldn't see one. > > > > Kris > > > Due to my limited intelligence and poor cognitive skills I > consider a PR to be a waste until someone that actually knows what they > are doing reports the same problem. OK, so what you're saying is that you haven't even tried to report the problem such that it can be fixed. I don't think it's fair to hold your lack of communication about your problem against the FreeBSD sound developers; if you want this to get fixed then you really need to get the ball rolling yourself by doing the best you can to describe and detail the problem in a PR. If you're missing details then someone will ask for them. Kris msg30339/pgp0.pgp Description: PGP signature
Re: userland program panics freebsd 4.3
Paul Halliday <[EMAIL PROTECTED]> writes: > Due to my limited intelligence and poor cognitive skills I > consider a PR to be a waste until someone that actually knows what they > are doing reports the same problem. > > The card compiles, works like a charm. However, No mixer control > with any app that I have tried; aumix, xmms, etc. (which all worked before > the sup) You're half way there. Now, just add the name/model of your sound card, when it broke, and you've got a PR. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Thu, 20 Dec 2001, Kris Kennaway wrote: > On Thu, Dec 20, 2001 at 09:08:36PM -0600, Paul Halliday wrote: > > > > On Thu, 20 Dec 2001, Kris Kennaway wrote: > > > > > On Thu, Dec 20, 2001 at 12:45:51PM -0500, Michael Scheidell wrote: > > > > > > > > > > I'm not aware of any services that broke between 4.3 and 4.4. Care to > > > > > elaborate? > > > > > > > > scan through freebsd-questions, freebsd-mobile and freebsd-ports > > > > > > That's completely non-helpful. I read -questions and -ports, and > > > don't recall complaints of massive breakage in 4.4. Perhaps you'd > > > care to be more specific so we can actually address the problems, if > > > they exist? > > > > My soundcard on my lappy has been broken since 4.4. And to be > > brutally honest, it's really starting to piss me off. > > Which PR contains your bug report? I couldn't see one. > > Kris > Due to my limited intelligence and poor cognitive skills I consider a PR to be a waste until someone that actually knows what they are doing reports the same problem. The card compiles, works like a charm. However, No mixer control with any app that I have tried; aumix, xmms, etc. (which all worked before the sup) Whatever.. Paul H. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Thu, Dec 20, 2001 at 09:08:36PM -0600, Paul Halliday wrote: > > On Thu, 20 Dec 2001, Kris Kennaway wrote: > > > On Thu, Dec 20, 2001 at 12:45:51PM -0500, Michael Scheidell wrote: > > > > > > > > I'm not aware of any services that broke between 4.3 and 4.4. Care to > > > > elaborate? > > > > > > scan through freebsd-questions, freebsd-mobile and freebsd-ports > > > > That's completely non-helpful. I read -questions and -ports, and > > don't recall complaints of massive breakage in 4.4. Perhaps you'd > > care to be more specific so we can actually address the problems, if > > they exist? > > My soundcard on my lappy has been broken since 4.4. And to be > brutally honest, it's really starting to piss me off. Which PR contains your bug report? I couldn't see one. Kris msg30336/pgp0.pgp Description: PGP signature
Re: userland program panics freebsd 4.3
Paul Halliday <[EMAIL PROTECTED]> writes: > My soundcard on my lappy has been broken since 4.4. And to be > brutally honest, it's really starting to piss me off. Enough to open a PR? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Thu, 20 Dec 2001, Kris Kennaway wrote: > On Thu, Dec 20, 2001 at 12:45:51PM -0500, Michael Scheidell wrote: > > > > > > I'm not aware of any services that broke between 4.3 and 4.4. Care to > > > elaborate? > > > > scan through freebsd-questions, freebsd-mobile and freebsd-ports > > That's completely non-helpful. I read -questions and -ports, and > don't recall complaints of massive breakage in 4.4. Perhaps you'd > care to be more specific so we can actually address the problems, if > they exist? My soundcard on my lappy has been broken since 4.4. And to be brutally honest, it's really starting to piss me off. > > > as for moving to fbsd 4.4 for a 'maybe' fix of something that might > still > show up in 4.4 (according to other posts) > > this seems to be > in the kernel anyway, so why would moving from a known > to an unknown > be a good thing? > > Because there are dozens or even hundreds of kernel bugs fixed since > 4.3, so there's a very good chance yours was one of them. > > Kris > Paul H. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
* Kris Kennaway <[EMAIL PROTECTED]> [011220 19:56] wrote: > On Thu, Dec 20, 2001 at 09:10:14AM -0500, Michael Scheidell wrote: > > I doubt hardware related > > I can get it to do it on two seperate boxes. > > OK, then you need to get more details as explained. > > > Updating to freebsd 4.4 is a bad option, with all the reported ports and > > services broken. > > I'm not sure what you're talking about here. Can you explain? Kris, stop wasting your time with this guy, when he gets his act together he might post something useful other than vague references to "things being broken". For the time being I'll assume it's PEBKAC. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Thu, Dec 20, 2001 at 12:45:51PM -0500, Michael Scheidell wrote: > > > > I'm not aware of any services that broke between 4.3 and 4.4. Care to > > elaborate? > > scan through freebsd-questions, freebsd-mobile and freebsd-ports That's completely non-helpful. I read -questions and -ports, and don't recall complaints of massive breakage in 4.4. Perhaps you'd care to be more specific so we can actually address the problems, if they exist? > as for moving to fbsd 4.4 for a 'maybe' fix of something that might still > show up in 4.4 (according to other posts) > > this seems to be in the kernel anyway, so why would moving from a known > to an unknown be a good thing? Because there are dozens or even hundreds of kernel bugs fixed since 4.3, so there's a very good chance yours was one of them. Kris msg30332/pgp0.pgp Description: PGP signature
Re: userland program panics freebsd 4.3
On Thu, Dec 20, 2001 at 09:10:14AM -0500, Michael Scheidell wrote: > I doubt hardware related > I can get it to do it on two seperate boxes. OK, then you need to get more details as explained. > Updating to freebsd 4.4 is a bad option, with all the reported ports and > services broken. I'm not sure what you're talking about here. Can you explain? Kris msg30331/pgp0.pgp Description: PGP signature
Re: userland program panics freebsd 4.3
> > I'm not aware of any services that broke between 4.3 and 4.4. Care to > elaborate? scan through freebsd-questions, freebsd-mobile and freebsd-ports as for moving to fbsd 4.4 for a 'maybe' fix of something that might still show up in 4.4 (according to other posts) this seems to be in the kernel anyway, so why would moving from a known to an unknown be a good thing? I did what everyone said, enable dumpdev and send in results. Its not hardware (too consistant, same spot, two different pieces of hardware) its a userland program and should not panic the kernel -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
Michael Scheidell <[EMAIL PROTECTED]> writes: > I doubt hardware related > I can get it to do it on two seperate boxes. > Updating to freebsd 4.4 is a bad option, with all the reported ports and > services broken. I'm not aware of any services that broke between 4.3 and 4.4. Care to elaborate? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
I doubt hardware related I can get it to do it on two seperate boxes. Updating to freebsd 4.4 is a bad option, with all the reported ports and services broken. -- Michael Scheidell Secnap Network Security, LLC [EMAIL PROTECTED] 1+(561) 368-9561 See updated IT Security News at http://www.fdma.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: userland program panics freebsd 4.3
On Tue, Dec 18, 2001 at 03:29:17PM -0500, Michael Scheidell wrote: > I have a userland program that canpanic/reboot a freebsd 4.3 system. Can you upgrade to 4.4-STABLE and test whether the problem persists? Chances are it's either a) fixed, or b) hardware-related. Kris msg30305/pgp0.pgp Description: PGP signature
userland program panics freebsd 4.3
I have a userland program that canpanic/reboot a freebsd 4.3 system. Hardware is Intel isp1100 (mbx440 motherboard) 850MHZ pIII, 256mb ram, 640mb swapfile software is 'nessusd' (network security scanner) hits the ethernet port pretty hard when running. If I read the dumpdev right, it is crashing in the vm section of the kernel, refrencing a structure that is not within kernel space? (sp) enabled ulimits (as per suggestion in comp.os.group) cputime infinity secs filesize 131072 kb datasize-cur65536 kb stacksize-cur 32768 kb coredumpsize-cur0 kb memoryuse-cur 65536 kb memorylocked-cur65536 kb maxprocesses 64 openfiles 128 sbsize infinity bytes never hits these (at least, not log entries) top shows it doesn't even hit swap file:(note, crashes with and without snort running for those who know snort) last pid: 27785; load averages: 0.46, 0.36, 0.25up 0+03:28:26 14:13:58 33 processes: 3 running, 30 sleeping CPU states: 23.3% user, 0.0% nice, 4.7% system, 1.6% interrupt, 70.5% idle Mem: 42M Active, 157M Inact, 24M Wired, 14M Cache, 35M Buf, 13M Free Swap: 640M Total, 640M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 317 root4 0 9940K 9508K bpf 16:58 11.52% 11.52% snort 322 root4 0 9368K 8968K bpf 11:18 6.88% 6.88% snort 27343 root 10 0 5148K 4800K RUN 0:03 0.15% 0.15% nessusd 24346 root 10 0 4960K 4604K RUN 0:37 0.00% 0.00% nessusd 24566 root 28 0 1888K 1108K RUN 0:07 0.00% 0.00% top 165 root2 0 932K 512K select 0:07 0.00% 0.00% syslogd 14859 root2 0 2240K 1748K select 0:03 0.00% 0.00% sshd 262 root 10 0 4072K 3692K nanslp 0:02 0.00% 0.00% perl 173 root2 -12 1256K 912K select 0:01 0.00% 0.00% ntpd 330 root2 0 5692K 5168K select 0:00 0.00% 0.00% perl 255 root2 0 7208K 4780K select 0:00 0.00% 0.00% httpd 299 mysql 2 0 26168K 5280K poll 0:00 0.00% 0.00% mysqld 27353 root2 0 2280K 1792K select 0:00 0.00% 0.00% sshd 25728 root2 0 2240K 1756K select 0:00 0.00% 0.00% sshd 231 root 10 0 3380K 2904K nanslp 0:00 0.00% 0.00% perl 14887 root 18 0 1324K 944K pause0:00 0.00% 0.00% csh 27363 root3 0 1328K 960K ttyin0:00 0.00% 0.00% csh enabled dumpdev and compiled kernel with -g panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode stray irq 7 fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01625d5 stack pointer = 0x10:0xd2110e1c frame pointer= 0x10:0xd2110f2c stray irq 7 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 = 27343 (nessusd) interrupt mask = none stray irq 7 trap number = 12 stray irq 7 panic: page fault syncing disks... 7 1 done Uptime: 3h27m57s dumping to dev #ad/0x20001, offset 786944 dump ata0: resetting devices .. done where #0 dumpsys () at ../../kern/kern_shutdown.c:469 #1 0xc0134643 in boot (howto=256) at ../../kern/kern_shutdown.c:309 #2 0xc01349c0 in poweroff_wait (junk=0xc020454f, howto=-791358464) at ../../kern/kern_shutdown.c:556 #3 0xc01d8b11 in trap_fatal (frame=0xd2110ddc, eva=8) at ../../i386/i386/trap.c:951 #4 0xc01d87e9 in trap_pfault (frame=0xd2110ddc, usermode=0, eva=8) at ../../i386/i386/trap.c:844 #5 0xc01d83cf in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = -791358464, tf_esi = 72, tf_ebp = -770633940, tf_isp = -770634232, tf_ebx = 0, tf_edx = -1047781184, tf_ecx = -1071582376, tf_eax = -769392960, tf_trapno = 12, tf_err = 0, tf_eip = -1072290347, tf_cs = 8, tf_eflags = 66118, tf_esp = -791358464, tf_ss = 2}) at ../../i386/i386/trap.c:443 #6 0xc01625d5 in fstatfs (p=0xd0d4d400, uap=0xd2110f80) at ../../kern/vfs_syscalls.c:681 #7 0xc01d8dbd in syscall2 (frame={tf_fs = 134610991, tf_es = 47, tf_ds = -1078001617, tf_edi = 134647524, tf_esi = 9, tf_ebp = -1077939040, tf_isp = -770633772, tf_ebx = 672247464, tf_edx = 3, tf_ecx = 672320104, tf_eax = 158, tf_trapno = 7, tf_err = 2, tf_eip = 671957244, tf_cs = 31, tf_eflags = 663, tf_esp = -1077939468, tf_ss = 47}) at ../../i386/i386/trap.c:1150 #8 0xc01cdb45 in Xint0x80_syscall () up 5 #5 0xc01d83cf in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = -791358464, tf_esi = 72, tf_ebp = -770633940, tf_isp = -770634232, tf_ebx = 0, tf_edx = -1047781184, tf_ecx = -1071582376, tf_eax = -769392960, tf_trapno = 12, tf_err = 0, tf_eip = -1072290347, tf_cs = 8, tf_eflags = 66118, tf_esp = -791358464,