From owner-freebsd-bugs Sun Mar 3 00:15:18 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA27111 for bugs-outgoing; Sun, 3 Mar 1996 00:15:18 -0800 (PST) Received: from sargon.wanet.com (sargon.wanet.com [205.229.179.82]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA27106 for ; Sun, 3 Mar 1996 00:15:15 -0800 (PST) Received: (from jd@localhost) by sargon.wanet.com (8.6.12/8.6.12) id AAA04025 for bugs@FreeBSD.org; Sun, 3 Mar 1996 00:08:16 -0800 Date: Sun, 3 Mar 1996 00:08:16 -0800 From: "Joseph I. Davida" Message-Id: <199603030808.AAA04025@sargon.wanet.com> To: bugs@FreeBSD.org Subject: intr signals and ksh Sender: owner-bugs@FreeBSD.org Precedence: bulk If I invoke Mail and later decide to interrupt out before sending the message, I will get a scrolling Cc: for a long time before the Mail process dies with sig 11. This only happens if my shell is ksh. It does not happen with csh or sh. From owner-freebsd-bugs Sun Mar 3 00:21:59 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA27676 for bugs-outgoing; Sun, 3 Mar 1996 00:21:59 -0800 (PST) Received: from sargon.wanet.com (sargon.wanet.com [205.229.179.82]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA27666 for ; Sun, 3 Mar 1996 00:21:55 -0800 (PST) Received: (from jd@localhost) by sargon.wanet.com (8.6.12/8.6.12) id AAA04149 for bugs@FreeBSD.org; Sun, 3 Mar 1996 00:14:56 -0800 Date: Sun, 3 Mar 1996 00:14:56 -0800 From: "Joseph I. Davida" Message-Id: <199603030814.AAA04149@sargon.wanet.com> To: bugs@FreeBSD.org Subject: Re: interrupt signals and ksh.... Sender: owner-bugs@FreeBSD.org Precedence: bulk I found out the cause of the scrolling Cc: lines: if I interrupt Mail: ksh was using shell script also named Mail which was not passing the interrupt signal to the /usr/bin/Mail program. Weird. I got rid of the shell script and the problem went away. From owner-freebsd-bugs Sun Mar 3 00:46:09 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29020 for bugs-outgoing; Sun, 3 Mar 1996 00:46:09 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29001 Sun, 3 Mar 1996 00:46:07 -0800 (PST) Date: Sun, 3 Mar 1996 00:46:07 -0800 (PST) From: Peter Wemm Message-Id: <199603030846.AAA29001@freefall.freebsd.org> To: hsu@clinet.fi, peter, freebsd-bugs Subject: Re: kern/884 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: arnet driver does not assert DTR, which is necessary for modems State-Changed-From-To: open-closed State-Changed-By: peter State-Changed-When: Sun Mar 3 00:45:16 PST 1996 State-Changed-Why: Believed to be fixed in rev 1.6 of if_ar.c From owner-freebsd-bugs Sun Mar 3 00:51:57 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29319 for bugs-outgoing; Sun, 3 Mar 1996 00:51:57 -0800 (PST) Received: (from jkh@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29300 Sun, 3 Mar 1996 00:51:54 -0800 (PST) Date: Sun, 3 Mar 1996 00:51:54 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603030851.AAA29300@freefall.freebsd.org> To: paul@isl.cf.ac.uk, jkh, freebsd-bugs Subject: Re: docs/218 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: dbm references from hash(3) State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sun Mar 3 00:47:42 PST 1996 State-Changed-Why: Fixed. BTW, any reason this PR was marked "confidential?" :-) From owner-freebsd-bugs Sun Mar 3 00:54:41 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29846 for bugs-outgoing; Sun, 3 Mar 1996 00:54:41 -0800 (PST) Received: (from jkh@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29827 Sun, 3 Mar 1996 00:54:40 -0800 (PST) Date: Sun, 3 Mar 1996 00:54:40 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603030854.AAA29827@freefall.freebsd.org> To: muir@idiom.com, jkh, freebsd-bugs Subject: Re: i386/222 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: boot prompt doesn't always work State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sun Mar 3 00:53:31 PST 1996 State-Changed-Why: This is over a year old - is it still relevant? I cannot reproduce the error myself. If it still persists, please let me know and I'll reopen this PR. From owner-freebsd-bugs Sun Mar 3 00:57:32 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA00448 for bugs-outgoing; Sun, 3 Mar 1996 00:57:32 -0800 (PST) Received: (from jkh@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA00435 Sun, 3 Mar 1996 00:57:31 -0800 (PST) Date: Sun, 3 Mar 1996 00:57:31 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603030857.AAA00435@freefall.freebsd.org> To: jkh, jkh, freebsd-bugs Subject: Re: bin/464 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: dialog_gauge goes one char too far for 100% value State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sun Mar 3 00:56:49 PST 1996 State-Changed-Why: This is actually the cursor, and the problem can be worked around by moving it elsewhere during updates. Not worth worrying about though. From owner-freebsd-bugs Sun Mar 3 01:02:44 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA01126 for bugs-outgoing; Sun, 3 Mar 1996 01:02:44 -0800 (PST) Received: (from jkh@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA01093 Sun, 3 Mar 1996 01:02:38 -0800 (PST) Date: Sun, 3 Mar 1996 01:02:38 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603030902.BAA01093@freefall.freebsd.org> To: tom@misery.sdf.com, jkh, freebsd-bugs Subject: Re: docs/633 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: no manpage for ndbm State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sun Mar 3 01:01:59 PST 1996 State-Changed-Why: This man page isn't even supposed to exist, and it's the actual references to it which are in error. From owner-freebsd-bugs Sun Mar 3 04:13:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA19723 for bugs-outgoing; Sun, 3 Mar 1996 04:13:06 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA19717 Sun, 3 Mar 1996 04:13:03 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA23694; Sun, 3 Mar 1996 22:07:28 +1000 Date: Sun, 3 Mar 1996 22:07:28 +1000 From: Bruce Evans Message-Id: <199603031207.WAA23694@godzilla.zeta.org.au> To: freebsd-bugs@freefall.freebsd.org, jkh@freefall.freebsd.org Subject: Re: bin/464 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk >Synopsis: dialog_gauge goes one char too far for 100% value >... >This is actually the cursor, and the problem can be worked around by >moving it elsewhere during updates. Not worth worrying about though. Cursor handling in dialog is bad for almost everything. It should be mostly off and restored when the application exits. I noticed/remembered the following problems when I ran devmenu to check where the cursor goes: - a PgDn immediately after starting the application causes the cursor to go to the end of the text above the menu. The cursor is normally over OK or Cancel where a "normal" unblinking syscons cursor lowlights the selection. - a suitable font isn't switched to automatically. The line graphics borders are wrong for iso8x16.fnt. The font should be restored when the application exits. Switching the font shouldn't affect other vt's. - devmenu uses too much of the screen and the shadowing wipes out most of the blue border. - the screen attributes aren't restored when applications exit. Bruce From owner-freebsd-bugs Sun Mar 3 22:20:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA06411 for bugs-outgoing; Sun, 3 Mar 1996 22:20:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA06402 Sun, 3 Mar 1996 22:20:02 -0800 (PST) Resent-Date: Sun, 3 Mar 1996 22:20:02 -0800 (PST) Resent-Message-Id: <199603040620.WAA06402@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, pst@Shockwave.COM Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA06340 for ; Sun, 3 Mar 1996 22:19:14 -0800 (PST) Received: (from pst@localhost) by precipice.shockwave.com (8.7.4/8.7.3) id WAA03864; Sun, 3 Mar 1996 22:18:42 -0800 (PST) Message-Id: <199603040618.WAA03864@precipice.shockwave.com> Date: Sun, 3 Mar 1996 22:18:42 -0800 (PST) From: Paul Traina Reply-To: pst@Shockwave.COM To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1058: crash in raw ip output Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1058 >Category: kern >Synopsis: system crashes when sending IP packet with bad length >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 3 22:20:01 PST 1996 >Last-Modified: >Originator: Paul Traina >Organization: Shockwave Engineering >Release: FreeBSD 2.2-CURRENT i386 >Environment: >Description: I was porting in the new LBL traceroute code. There is a questionable bug in the code -- it sets the IP packet's TL field in network order not host order, I believe that to be a bug... The system crashed because it walked off the end of the mbuf chain because it thought it had a nice long packet to send. The system should NOT crash. I'll fix traceroute, but someone needs to fix the kernel (I may fix it too.) >How-To-Repeat: get ftp://ftp.ee.lbl.gov/traceroute-1.2.tar.gz, compile it and run it Script started on Sun Mar 3 10:35:07 1996 GDB is free software and you are welcome to 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. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 3a9000 current pcb at 1bfdf4 panic: m_copym #0 boot (howto=260) at ../../i386/i386/machdep.c:940 940 dumppcb.pcb_ptd = rcr3(); (kgdb) where #0 boot (howto=260) at ../../i386/i386/machdep.c:940 #1 0xf0118304 in panic () #2 0xf01013de in db_fncall () #3 0xf010110e in db_command () #4 0xf010128d in db_command_loop () #5 0xf01035d4 in db_trap () #6 0xf0175b6a in kdb_trap () #7 0xf017d8ac in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 40, tf_esi = -267233635, tf_ebp = -272630424, tf_isp = -272630452, tf_ebx = 256, tf_edx = 0, tf_ecx = -266904219, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266904173, tf_cs = 8, tf_eflags = 582, tf_esp = -266904235, tf_ss = -267287894}) at ../../i386/i386/trap.c:400 #8 0xf01763c1 in calltrap () #9 0xf01182fe in panic () #10 0xf01256fe in m_copym () #11 0xf014b004 in ip_output (m0=0xf0bdc480, opt=0x0, ro=0xf0ba9a2c, flags=34, imo=0x0) at ../../netinet/ip_output.c:421 #12 0xf014c18f in rip_output (m=0xf0bdc480, so=0xf0bde200, dst=2919318955) at ../../netinet/raw_ip.c:179 #13 0xf014c5a8 in rip_usrreq (so=0xf0bde200, req=9, m=0xf0bdc480, nam=0xf0baa280, control=0x0) at ../../netinet/raw_ip.c:400 #14 0xf0126d4a in sosend () #15 0xf012941b in sendit () ---Type to continue, or q to quit--- #16 0xf01294f8 in sendto () #17 0xf017e32e in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1, tf_esi = -272639016, tf_ebp = -272639116, tf_isp = -272629788, tf_ebx = 1, tf_edx = 825877907, tf_ecx = 45056, tf_eax = 133, tf_trapno = 12, tf_err = 646, tf_eip = 134605509, tf_cs = 31, tf_eflags = 646, tf_esp = -272639152, tf_ss = 39}) at ../../i386/i386/trap.c:919 #18 0xf017640d in Xsyscall () #19 0x2039 in ?? () #20 0x1096 in ?? () (kgdb) up #1 0xf0118304 in panic () (kgdb) up #2 0xf01013de in db_fncall () (kgdb) up #3 0xf010110e in db_command () (kgdb) up #4 0xf010128d in db_command_loop () (kgdb) up #5 0xf01035d4 in db_trap () (kgdb) up #6 0xf0175b6a in kdb_trap () (kgdb) up #7 0xf017d8ac in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 40, tf_esi = -267233635, tf_ebp = -272630424, tf_isp = -272630452, tf_ebx = 256, tf_edx = 0, tf_ecx = -266904219, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266904173, tf_cs = 8, tf_eflags = 582, tf_esp = -266904235, tf_ss = -267287894}) at ../../i386/i386/trap.c:400 400 if (kdb_trap (type, 0, &frame)) (kgdb) up #8 0xf01763c1 in calltrap () (kgdb) up #9 0xf01182fe in panic () (kgdb) up #10 0xf01256fe in m_copym () (kgdb) up #11 0xf014b004 in ip_output (m0=0xf0bdc480, opt=0x0, ro=0xf0ba9a2c, flags=34, imo=0x0) at ../../netinet/ip_output.c:421 421 m->m_next = m_copy(m0, off, len); (kgdb) print len $1 = 1496 (kgdb) print of No symbol "of" in current context. (kgdb) print off $2 = 1496 (kgdb) print m0 $3 = (struct mbuf *) 0xf0bdc480 (kgdb) up #12 0xf014c18f in rip_output (m=0xf0bdc480, so=0xf0bde200, dst=2919318955) at ../../netinet/raw_ip.c:179 179 return (ip_output(m, opts, &inp->inp_route, flags, inp->inp_moptions)); (kgdb) print flags $4 = 34 (kgdb) print /x flags $5 = 0x22 (kgdb) up #13 0xf014c5a8 in rip_usrreq (so=0xf0bde200, req=9, m=0xf0bdc480, nam=0xf0baa280, control=0x0) at ../../netinet/raw_ip.c:400 400 error = rip_output(m, so, dst); (kgdb) up #14 0xf0126d4a in sosend () (kgdb) up #15 0xf012941b in sendit () (kgdb) up #16 0xf01294f8 in sendto () (kgdb) up #17 0xf017e32e in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1, tf_esi = -272639016, tf_ebp = -272639116, tf_isp = -272629788, tf_ebx = 1, tf_edx = 825877907, tf_ecx = 45056, tf_eax = 133, tf_trapno = 12, tf_err = 646, tf_eip = 134605509, tf_cs = 31, tf_eflags = 646, tf_esp = -272639152, tf_ss = 39}) at ../../i386/i386/trap.c:919 919 error = (*callp->sy_call)(p, args, rval); (kgdb) up #18 0xf017640d in Xsyscall () (kgdb) down #17 0xf017e32e in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1, tf_esi = -272639016, tf_ebp = -272639116, tf_isp = -272629788, tf_ebx = 1, tf_edx = 825877907, tf_ecx = 45056, tf_eax = 133, tf_trapno = 12, tf_err = 646, tf_eip = 134605509, tf_cs = 31, tf_eflags = 646, tf_esp = -272639152, tf_ss = 39}) at ../../i386/i386/trap.c:919 919 error = (*callp->sy_call)(p, args, rval); (kgdb) down #16 0xf01294f8 in sendto () (kgdb) down #15 0xf012941b in sendit () (kgdb) down #14 0xf0126d4a in sosend () (kgdb) down #13 0xf014c5a8 in rip_usrreq (so=0xf0bde200, req=9, m=0xf0bdc480, nam=0xf0baa280, control=0x0) at ../../netinet/raw_ip.c:400 400 error = rip_output(m, so, dst); (kgdb) print so $6 = (struct socket *) 0xf0bde200 (kgdb) print *so $7 = {so_type = 3, so_options = 0, so_linger = 0, so_state = 128, so_pcb = 0xf0ba9a00 "\200o½ðøò\eð\200o½ð\200\017±ðüò\eð", so_proto = 0xf01ad7f0, so_head = 0x0, so_q0 = 0x0, so_q = 0x0, so_q0len = 0, so_qlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_pgid = 0, so_oobmark = 0, so_rcv = {sb_cc = 0, sb_hiwat = 8192, sb_mbcnt = 0, sb_mbmax = 65536, sb_lowat = 1, sb_mb = 0x0, sb_sel = {si_pid = 0, si_flags = 0}, sb_flags = 0, sb_timeo = 0}, so_snd = {sb_cc = 0, sb_hiwat = 40, sb_mbcnt = 0, sb_mbmax = 320, sb_lowat = 40, sb_mb = 0x0, sb_sel = {si_pid = 0, si_flags = 0}, sb_flags = 1, sb_timeo = 0}, so_tpcb = 0x0, so_upcall = 0, so_upcallarg = 0x0} (kgdb) print *dst $8 = 74581447 (kgdb) print dst $9 = 1 (kgdb) print /x dst $10 = 0x1 (kgdb) print *m $11 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_len = 40, mh_data = 0xf0bdc4d8 "", mh_type = 1, mh_flags = 2}, M_dat = {MH = { MH_pkthdr = {len = 40, rcvif = 0x0}, MH_dat = {MH_ext = {ext_buf = 0x0, ext_free = 0, ext_size = 4038968480}, MH_databuf = "\000\000\000\000\000\000\000\000 Ä½ð\001\000\000\000\001\000\000\000\000\000\000\000\210\001", '\000' , "(\000X\000\000\001\021\000\000«El!«E\001®\200­\202\233\000\024\000\000\001\001\000\000\223å91Òÿ\004"}}, M_databuf = "(", '\000' , " Ä½ð\001\000\000\000\001\000\000\000\000\000\000\000\210\001", '\000' , "(\000X\000\000\001\021\000\000«El!«E\001®\200­\202\233\000\024\000\000\001\001\000\000\223å91Òÿ\004"}} (kgdb) pr  down #12 0xf014c18f in rip_output (m=0xf0bdc480, so=0xf0bde200, dst=2919318955) at ../../netinet/raw_ip.c:179 179 return (ip_output(m, opts, &inp->inp_route, flags, inp->inp_moptions)); (kgdb) print opts $12 = (struct mbuf *) 0x0 (kgdb) print *inp    inp $13 = (struct inpcb *) 0xf0ba9a00 (kgdb) print inp->inpo _route $14 = {ro_rt = 0xf0b77d00, ro_dst = {sa_len = 16 '\020', sa_family = 2 '\002', sa_data = "\000\000«E\001®\000\000\000\000\000\000\000"}} (kgdb) print flags $15 = 34 (kgdb) print inp->inp_moptions $16 = (struct ip_moptions *) 0x0 (kgdb) down #11 0xf014b004 in ip_output (m0=0xf0bdc480, opt=0x0, ro=0xf0ba9a2c, flags=34, imo=0x0) at ../../netinet/ip_output.c:421 421 m->m_next = m_copy(m0, off, len); (kgdb) list 416 if (off + len >= (u_short)ip->ip_len) 417 len = (u_short)ip->ip_len - off; 418 else 419 mhip->ip_off |= IP_MF; 420 mhip->ip_len = htons((u_short)(len + mhlen)); 421 m->m_next = m_copy(m0, off, len); 422 if (m->m_next == 0) { 423 (void) m_free(m); 424 error = ENOBUFS; /* ??? */ 425 ipstat.ips_odropped++; (kgdb) print m0 $17 = (struct mbuf *) 0xf0bdc480 (kgdb) print mhip->ip_len $18 = -5115 (kgdb) print mhip $19 = (struct ip *) 0xf0bdc0ac (kgdb) print *mhip $20 = {ip_hl = 0 '\000', ip_v = 0 '\000', ip_tos = 0 '\000', ip_len = -5115, ip_id = 22528, ip_off = 8379, ip_ttl = 1 '\001', ip_p = 17 '\021', ip_sum = 0, ip_src = {s_addr = 560743851}, ip_dst = {s_addr = 2919318955}} (kgdb) print len $21 = 1496 (kgdb) print mhlen $22 = 20 (kgdb) print /x m *mhip     mhip->(kgdb) print /x *mhip $23 = {ip_hl = 0x0, ip_v = 0x0, ip_tos = 0x0, ip_len = 0xec05, ip_id = 0x5800, ip_off = 0x20bb, ip_ttl = 0x1, ip_p = 0x11, ip_sum = 0x0, ip_src = { s_addr = 0x216c45ab}, ip_dst = {s_addr = 0xae0145ab}} (kgdb) where #0 boot (howto=260) at ../../i386/i386/machdep.c:940 #1 0xf0118304 in panic () #2 0xf01013de in db_fncall () #3 0xf010110e in db_command () #4 0xf010128d in db_command_loop () #5 0xf01035d4 in db_trap () #6 0xf0175b6a in kdb_trap () #7 0xf017d8ac in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 40, tf_esi = -267233635, tf_ebp = -272630424, tf_isp = -272630452, tf_ebx = 256, tf_edx = 0, tf_ecx = -266904219, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -266904173, tf_cs = 8, tf_eflags = 582, tf_esp = -266904235, tf_ss = -267287894}) at ../../i386/i386/trap.c:400 #8 0xf01763c1 in calltrap () #9 0xf01182fe in panic () #10 0xf01256fe in m_copym () #11 0xf014b004 in ip_output (m0=0xf0bdc480, opt=0x0, ro=0xf0ba9a2c, flags=34, imo=0x0) at ../../netinet/ip_output.c:421 #12 0xf014c18f in rip_output (m=0xf0bdc480, so=0xf0bde200, dst=2919318955) at ../../netinet/raw_ip.c:179 #13 0xf014c5a8 in rip_usrreq (so=0xf0bde200, req=9, m=0xf0bdc480, nam=0xf0baa280, control=0x0) at ../../netinet/raw_ip.c:400 #14 0xf0126d4a in sosend () #15 0xf012941b in sendit () ---Type to continue, or q to quit--- #16 0xf01294f8 in sendto () #17 0xf017e32e in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 1, tf_esi = -272639016, tf_ebp = -272639116, tf_isp = -272629788, tf_ebx = 1, tf_edx = 825877907, tf_ecx = 45056, tf_eax = 133, tf_trapno = 12, tf_err = 646, tf_eip = 134605509, tf_cs = 31, tf_eflags = 646, tf_esp = -272639152, tf_ss = 39}) at ../../i386/i386/trap.c:919 #18 0xf017640d in Xsyscall () #19 0x2039 in ?? () #20 0x1096 in ?? () (kgdb) up #12 0xf014c18f in rip_output (m=0xf0bdc480, so=0xf0bde200, dst=2919318955) at ../../netinet/raw_ip.c:179 179 return (ip_output(m, opts, &inp->inp_route, flags, inp->inp_moptions)); (kgdb) down #11 0xf014b004 in ip_output (m0=0xf0bdc480, opt=0x0, ro=0xf0ba9a2c, flags=34, imo=0x0) at ../../netinet/ip_output.c:421 421 m->m_next = m_copy(m0, off, len); (kgdb) list 400 395 */ 396 m0 = m; 397 mhlen = sizeof (struct ip); 398 for (off = hlen + len; off < (u_short)ip->ip_len; off += len) { 399 MGETHDR(m, M_DONTWAIT, MT_HEADER); 400 if (m == 0) { 401 error = ENOBUFS; 402 ipstat.ips_odropped++; 403 goto sendorfree; 404 } (kgdb) 405 m->m_data += max_linkhdr; 406 mhip = mtod(m, struct ip *); 407 *mhip = *ip; 408 if (hlen > sizeof (struct ip)) { 409 mhlen = ip_optcopy(ip, mhip) + sizeof (struct ip); 410 mhip->ip_hl = mhlen >> 2; 411 } 412 m->m_len = mhlen; 413 mhip->ip_off = ((off - hlen) >> 3) + (ip->ip_off & ~IP_MF); 414 if (ip->ip_off & IP_MF) (kgdb) print *ip $24 = {ip_hl = 0 '\000', ip_v = 0 '\000', ip_tos = 0 '\000', ip_len = 10240, ip_id = 22528, ip_off = 0, ip_ttl = 1 '\001', ip_p = 17 '\021', ip_sum = 0, ip_src = {s_addr = 560743851}, ip_dst = {s_addr = 2919318955}} (kgdb) print heln    l hlen $25 = 0 (kgdb) print len $26 = 1496 (kgdb) quit bash# exit Script done on Sun Mar 3 10:40:35 1996 >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Mar 3 22:57:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA08058 for bugs-outgoing; Sun, 3 Mar 1996 22:57:07 -0800 (PST) Received: from idiom.com ([140.174.82.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA08052 Sun, 3 Mar 1996 22:57:04 -0800 (PST) Received: (from muir@localhost) by idiom.com (8.6.12/8.6.12) id WAA28110; Sun, 3 Mar 1996 22:57:03 -0800 Date: Sun, 3 Mar 1996 22:57:03 -0800 From: David Muir Sharnoff Message-Id: <199603040657.WAA28110@idiom.com> To: "Jordan K. Hubbard" Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: Re: i386/222 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk * Synopsis: boot prompt doesn't always work * * State-Changed-From-To: open-closed * State-Changed-By: jkh * State-Changed-When: Sun Mar 3 00:53:31 PST 1996 * State-Changed-Why: * This is over a year old - is it still relevant? I cannot reproduce * the error myself. If it still persists, please let me know and I'll * reopen this PR. This has been fixed. I don't know exactly when, but sometime between 2.0R and 2.1R it started working perfectly. -Dave From owner-freebsd-bugs Sun Mar 3 23:38:36 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA09587 for bugs-outgoing; Sun, 3 Mar 1996 23:38:36 -0800 (PST) Received: from lirmm.lirmm.fr (lirmm.lirmm.fr [193.49.104.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA09582 for ; Sun, 3 Mar 1996 23:38:33 -0800 (PST) Received: from lirmm.fr (baobab.lirmm.fr [193.49.106.14]) by lirmm.lirmm.fr (8.7.1/8.6.4) with ESMTP id IAA14667 for ; Mon, 4 Mar 1996 08:38:18 +0100 (MET) Message-Id: <199603040738.IAA14667@lirmm.lirmm.fr> To: bugs@freebsd.org Subject: savecore patches Date: Mon, 04 Mar 1996 08:38:16 +0100 From: "Philippe Charnier" Sender: owner-bugs@freebsd.org Precedence: bulk Hi, You will find enclosed a patch for savecore that correct the following bugs: - dumpsize was used (in check_space) before being computed (in save_core): dumpsize was always 0 in check_space. Compute dumpsize before calling check_space which need it. - convert all quantities required for free space computation to a number of bytes (some of them were in Kbytes, others in bytes, making result a little bit silly). Minfree is really take into account now. - cosmetics changes. - only dump a core is minfree bytes are left on the disk after the dump. -------- -------- Philippe Charnier charnier@lirmm.fr LIRMM, 161 rue Ada, 34392 Montpellier cedex 5 -- France ------------------------------------------------------------------------ Index: sbin/savecore/./savecore.c =================================================================== RCS file: /home2h/FreeBSD.cvsroot/src/sbin/savecore/savecore.c,v retrieving revision 1.11 diff -u -r1.11 savecore.c --- savecore.c 1995/12/13 11:36:20 1.11 +++ savecore.c 1996/03/02 14:09:22 @@ -290,6 +290,11 @@ *cp = getc(fp); while (*cp++ && cp < &panic_mesg[sizeof(panic_mesg)]); } + /* Read the dump size, and convert it to a number of bytes. */ + (void)fseek(fp, + (off_t)(dumplo + ok(dump_nl[X_DUMPSIZE].n_value)), L_SET); + (void)fread(&dumpsize, sizeof(dumpsize), 1, fp); + dumpsize *= NBPG; /* Don't fclose(fp), we use dumpfd later. */ } @@ -369,15 +374,10 @@ ifd = dumpfd; } - /* Read the dump size. */ - Lseek(dumpfd, (off_t)(dumplo + ok(dump_nl[X_DUMPSIZE].n_value)), L_SET); - (void)Read(dumpfd, &dumpsize, sizeof(dumpsize)); - /* Seek to the start of the core. */ Lseek(ifd, (off_t)dumplo, L_SET); /* Copy the core file. */ - dumpsize *= NBPG; syslog(LOG_NOTICE, "writing %score to %s", compress ? "compressed " : "", path); for (; dumpsize > 0; dumpsize -= nr) { @@ -547,28 +547,27 @@ syslog(LOG_ERR, "%s: %m", dirname); exit(1); } - spacefree = (fsbuf.f_bavail * fsbuf.f_bsize) / 1024; - + spacefree = fsbuf.f_bavail * fsbuf.f_bsize; + minfree = 0; (void)snprintf(path, sizeof(path), "%s/minfree", dirname); - if ((fp = fopen(path, "r")) == NULL) - minfree = 0; - else { - if (fgets(buf, sizeof(buf), fp) == NULL) - minfree = 0; - else - minfree = atoi(buf); + if ((fp = fopen(path, "r"))) { + if (fgets(buf, sizeof(buf), fp)) minfree = atoi(buf); (void)fclose(fp); } - - needed = (dumpsize + kernelsize) / 1024; - if (minfree > 0 && spacefree - needed < minfree) { - syslog(LOG_WARNING, - "no dump, not enough free space on device"); + /* dumpsize, kernelsize, minfree, and spacefree are in bytes */ + needed = dumpsize + kernelsize; /* minfree? not yet */ + if (verbose) { + syslog(LOG_INFO, "dumpsize: %d", dumpsize); + syslog(LOG_INFO, "kernelsize: %d", kernelsize); + syslog(LOG_INFO, "minfree: %d", minfree); + syslog(LOG_INFO, "spacefree: %d", spacefree); + syslog(LOG_INFO, "needed: %d", needed); + } + /* space left (after the dump) must be greater than minfree */ + if (spacefree < needed + minfree) { + syslog(LOG_WARNING, "no dump, not enough free space on device"); return (0); } - if (spacefree - needed < minfree) - syslog(LOG_WARNING, - "dump performed, but free space threshold crossed"); return (1); } From owner-freebsd-bugs Mon Mar 4 00:00:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA10364 for bugs-outgoing; Mon, 4 Mar 1996 00:00:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA10354 Mon, 4 Mar 1996 00:00:02 -0800 (PST) Resent-Date: Mon, 4 Mar 1996 00:00:02 -0800 (PST) Resent-Message-Id: <199603040800.AAA10354@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, kls Received: from wetware.com (root@wetware.wetware.com [192.216.52.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA10280 for ; Sun, 3 Mar 1996 23:59:21 -0800 (PST) Received: from ditka by wetware.com with uucp (Smail3.1.28.1 #4) id m0ttVAo-000JaZC; Sun, 3 Mar 96 23:59 PST Received: from ohare.chicago.com by ditka.chicago.com with smtp (Smail3.1.28.1 #1) id m0ttV9x-0001VuC; Sun, 3 Mar 96 23:58 WET Received: by ohare.chicago.com (Smail3.1.28.1 #1) id m0ttV9x-0000FbC; Sun, 3 Mar 96 23:58 WET Message-Id: Date: Sun, 3 Mar 96 23:58 WET From: kls@ohare.chicago.com Reply-To: kls To: FreeBSD-gnats-submit@freebsd.org, kls@chicago.com X-Send-Pr-Version: 3.2 Subject: kern/1059: null fs panics system Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1059 >Category: kern >Synopsis: null fs panics system >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 4 00:00:00 PST 1996 >Last-Modified: >Originator: Karl Swartz >Organization: Karl Swartz |Home kls@chicago.com |Work kls@slac.stanford.edu |WWW http://www.chicago.com/~kls/ Moderator of sci.aeronautics.airliners -- Unix/network work pays the bills >Release: FreeBSD 2.1-STABLE i386 >Environment: Newly installed FreeBSD 2.1 system (from Walnut Creek CDROM), with selected packages installed (including bash and perl) but no other special software, running the stock kernel on the following hardware: Alaris motherboard with IBM 486SLC2-66 (no 387 installed) 8 MB memory generic IDE controller Maxtor 7420AV disk SMC Ultra Ethernet User home directories in /usr/u/, which preferably would be visible as /u/ via a null/lofs mount. Running as nonprivileged user with bash as the default shell. >Description: The system panics as follows when trying to execute a newly created Perl script iff running from a null fs: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf05586fc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1119 (bash) interrupt mask = panic: page fault >How-To-Repeat: (login) $ echo $SHELL /usr/local/bin/bash $ echo $HOME /usr/u/user $ su Password: # mkdir /u # mount -t null /usr/u /u # exit $ cd /u/user $ mkdir panic $ cd panic $ cat >hello <Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Mar 4 01:20:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA14920 for bugs-outgoing; Mon, 4 Mar 1996 01:20:07 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA14893 Mon, 4 Mar 1996 01:20:04 -0800 (PST) Resent-Date: Mon, 4 Mar 1996 01:20:04 -0800 (PST) Resent-Message-Id: <199603040920.BAA14893@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, samorosh@marmot.cs.ucdavis.edu Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA14532 for ; Mon, 4 Mar 1996 01:13:42 -0800 (PST) Received: from marmot.cs.ucdavis.edu (marmot.cs.ucdavis.edu [128.120.56.45]) by relay.nuxi.com (8.6.12/8.6.12) with ESMTP id BAA02773 for ; Mon, 4 Mar 1996 01:14:05 -0800 Received: (from samorosh@localhost) by marmot.cs.ucdavis.edu (8.6.12/8.6.12) id BAA18657; Mon, 4 Mar 1996 01:05:55 -0800 Message-Id: <199603040905.BAA18657@marmot.cs.ucdavis.edu> Date: Mon, 4 Mar 1996 01:05:55 -0800 From: Steven Samorodin Reply-To: samorosh@marmot.cs.ucdavis.edu To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: ports/1060: xrisk port did not correctly set permis for binary on install Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1060 >Category: ports >Synopsis: xrisk port did not correctly set permis for binary on install >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 4 01:20:02 PST 1996 >Last-Modified: >Originator: Steven Samorodin >Organization: Steven H. Samorodin >Release: FreeBSD 2.1-STABLE i386 >Environment: free bsd 2.1.0 >Description: see synopsis that is it, perms were set to 700 instead of 755 for the xrisk binary after it had been installed in /usr/X11R6/bin >How-To-Repeat: presumably, # make # make install # ls -l /usr/X11R6/bin/xrisk >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Mar 4 12:46:17 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA25967 for bugs-outgoing; Mon, 4 Mar 1996 12:46:17 -0800 (PST) Received: from wiz.plymouth.edu (ness.plymouth.edu [158.136.75.104]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA25962 for ; Mon, 4 Mar 1996 12:46:15 -0800 (PST) Received: (from ted@localhost) by wiz.plymouth.edu (8.6.11/8.6.9) id PAA11007 for bugs@FreeBSD.org; Mon, 4 Mar 1996 15:46:01 -0500 From: Ted Wisniewski Message-Id: <199603042046.PAA11007@wiz.plymouth.edu> Subject: DES missing from 2.2-960303-SNAP To: bugs@FreeBSD.org Date: Mon, 4 Mar 1996 15:46:01 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.org Precedence: bulk DES Distribution is missing from the Latest SNAP. -- | Ted Wisniewski INET: ted@oz.plymouth.edu | | Computer Services ted@wiz.plymouth.edu | | Plymouth State College tedw@psc.plymouth.edu | | Plymouth NH, 03264 HTTP: http://oz.plymouth.edu/~ted/ | From owner-freebsd-bugs Mon Mar 4 13:20:16 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA28546 for bugs-outgoing; Mon, 4 Mar 1996 13:20:16 -0800 (PST) Received: from wiz.plymouth.edu (ness.plymouth.edu [158.136.75.104]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA28512 for ; Mon, 4 Mar 1996 13:20:11 -0800 (PST) Received: (from ted@localhost) by wiz.plymouth.edu (8.6.11/8.6.9) id QAA11067 for bugs@FreeBSD.org; Mon, 4 Mar 1996 16:20:09 -0500 From: Ted Wisniewski Message-Id: <199603042120.QAA11067@wiz.plymouth.edu> Subject: 2.2-960303-SNAP To: bugs@FreeBSD.org Date: Mon, 4 Mar 1996 16:20:08 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.org Precedence: bulk Boot floppy menu to set timezone to US-* does not work... "... Failed.. Wrong DIMS..." The system is not up, so Send-pr was not an option. -- | Ted Wisniewski INET: ted@oz.plymouth.edu | | Computer Services ted@wiz.plymouth.edu | | Plymouth State College tedw@psc.plymouth.edu | | Plymouth NH, 03264 HTTP: http://oz.plymouth.edu/~ted/ | From owner-freebsd-bugs Mon Mar 4 14:37:23 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA04516 for bugs-outgoing; Mon, 4 Mar 1996 14:37:23 -0800 (PST) Received: (from pst@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA04501 Mon, 4 Mar 1996 14:37:21 -0800 (PST) Date: Mon, 4 Mar 1996 14:37:21 -0800 (PST) From: Paul Traina Message-Id: <199603042237.OAA04501@freefall.freebsd.org> To: pst, freebsd-bugs, pst Subject: Re: kern/1058 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: system crashes when sending IP packet with bad length Responsible-Changed-From-To: freebsd-bugs->pst Responsible-Changed-By: pst Responsible-Changed-When: Mon Mar 4 14:36:50 PST 1996 Responsible-Changed-Why: From owner-freebsd-bugs Mon Mar 4 17:56:59 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA17601 for bugs-outgoing; Mon, 4 Mar 1996 17:56:59 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA17596 for ; Mon, 4 Mar 1996 17:56:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id RAA25884; Mon, 4 Mar 1996 17:56:21 -0800 (PST) To: Ted Wisniewski cc: bugs@FreeBSD.org Subject: Re: DES missing from 2.2-960303-SNAP In-reply-to: Your message of "Mon, 04 Mar 1996 15:46:01 EST." <199603042046.PAA11007@wiz.plymouth.edu> Date: Mon, 04 Mar 1996 17:56:21 -0800 Message-ID: <25882.825990981@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@FreeBSD.org Precedence: bulk I know. This will be fixed in the next SNAP. Jordan > DES Distribution is missing from the Latest SNAP. > > -- > | Ted Wisniewski INET: ted@oz.plymouth.edu | > | Computer Services ted@wiz.plymouth.edu | > | Plymouth State College tedw@psc.plymouth.edu | > | Plymouth NH, 03264 HTTP: http://oz.plymouth.edu/~ted/ | From owner-freebsd-bugs Mon Mar 4 17:57:08 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA17625 for bugs-outgoing; Mon, 4 Mar 1996 17:57:08 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA17615 for ; Mon, 4 Mar 1996 17:57:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id RAA25895; Mon, 4 Mar 1996 17:56:45 -0800 (PST) To: Ted Wisniewski cc: bugs@FreeBSD.org Subject: Re: 2.2-960303-SNAP In-reply-to: Your message of "Mon, 04 Mar 1996 16:20:08 EST." <199603042120.QAA11067@wiz.plymouth.edu> Date: Mon, 04 Mar 1996 17:56:45 -0800 Message-ID: <25893.825991005@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@FreeBSD.org Precedence: bulk > Boot floppy menu to set timezone to US-* does not work... > > "... Failed.. Wrong DIMS..." Hmm! That I didn't know about - thanks for the bug report! Jordan From owner-freebsd-bugs Mon Mar 4 22:14:18 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA10790 for bugs-outgoing; Mon, 4 Mar 1996 22:14:18 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA10779 for ; Mon, 4 Mar 1996 22:14:12 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id IAA28596; Tue, 5 Mar 1996 08:13:19 +0200 (SAT) Message-Id: <199603050613.IAA28596@grumble.grondar.za> To: "Jordan K. Hubbard" cc: Ted Wisniewski , bugs@FreeBSD.org Subject: Re: DES missing from 2.2-960303-SNAP Date: Tue, 05 Mar 1996 08:13:19 +0200 From: Mark Murray Sender: owner-bugs@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > I know. This will be fixed in the next SNAP. > > Jordan > > > DES Distribution is missing from the Latest SNAP. In the meanwhile ftp://ftp.internat.freebsd.org/pub/FreeBSD/2.2-960303-SNAP has a DES and eBones. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-bugs Mon Mar 4 22:54:48 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA17887 for bugs-outgoing; Mon, 4 Mar 1996 22:54:48 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id WAA17873 for ; Mon, 4 Mar 1996 22:54:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id WAA28105; Mon, 4 Mar 1996 22:53:54 -0800 (PST) To: Mark Murray cc: Ted Wisniewski , bugs@FreeBSD.org Subject: Re: DES missing from 2.2-960303-SNAP In-reply-to: Your message of "Tue, 05 Mar 1996 08:13:19 +0200." <199603050613.IAA28596@grumble.grondar.za> Date: Mon, 04 Mar 1996 22:53:54 -0800 Message-ID: <28103.826008834@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@FreeBSD.org Precedence: bulk > In the meanwhile ftp://ftp.internat.freebsd.org/pub/FreeBSD/2.2-960303-SNAP > has a DES and eBones. Thanks, Mark! I must confess that the error was pretty simple. I made the tree, then I sanitized it for CDROM, then I ran out of space making the CD image and pruned my FTP area away, forgetting that I'd not copied it over yet! I then figured "oh what the heck, I'm going to re-roll this thing soon anyway" so I just copied over a re-arranged copy (basically mv dists/* . && rmdir dists) of the CD to the FTP area. Now those that need DES can get it from South Africa and register a protest against the stupid US ITAR policy at the same time.. :-) Perhaps we should talk to someone like the EFF about providing funding to get ZA a faster international link.. Then nothing would stand in the way of their becoming a bastion of exportable encryption software for the entire free world! :-) Jordan From owner-freebsd-bugs Mon Mar 4 23:04:45 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA19811 for bugs-outgoing; Mon, 4 Mar 1996 23:04:45 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA19785 for ; Mon, 4 Mar 1996 23:04:36 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id JAA28991; Tue, 5 Mar 1996 09:03:44 +0200 (SAT) Message-Id: <199603050703.JAA28991@grumble.grondar.za> To: "Jordan K. Hubbard" cc: Mark Murray , Ted Wisniewski , bugs@FreeBSD.org Subject: Re: DES missing from 2.2-960303-SNAP Date: Tue, 05 Mar 1996 09:03:43 +0200 From: Mark Murray Sender: owner-bugs@FreeBSD.org Precedence: bulk "Jordan K. Hubbard" wrote: > > In the meanwhile ftp://ftp.internat.freebsd.org/pub/FreeBSD/2.2-960303-SNAP > > has a DES and eBones. > > Thanks, Mark! Pleasure! > Perhaps we should talk to someone like the EFF about providing funding > to get ZA a faster international link.. Then nothing would stand in > the way of their becoming a bastion of exportable encryption software > for the entire free world! :-) YEHBO! Bayete! M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-bugs Mon Mar 4 23:52:36 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA29227 for bugs-outgoing; Mon, 4 Mar 1996 23:52:36 -0800 (PST) Received: (from asami@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA29196 Mon, 4 Mar 1996 23:52:30 -0800 (PST) Date: Mon, 4 Mar 1996 23:52:30 -0800 (PST) From: Satoshi Asami Message-Id: <199603050752.XAA29196@freefall.freebsd.org> To: obrien@cs.ucdavis.edu, asami, freebsd-bugs Subject: Re: ports/1041 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: ports submissions State-Changed-From-To: feedback-closed State-Changed-By: asami State-Changed-When: Mon Mar 4 23:51:16 PST 1996 State-Changed-Why: New portball submitted, and port committed. From owner-freebsd-bugs Tue Mar 5 09:16:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09182 for bugs-outgoing; Tue, 5 Mar 1996 09:16:04 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA08964 for ; Tue, 5 Mar 1996 09:10:08 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA06529 for bugs@freebsd.org; Tue, 5 Mar 1996 18:03:50 +0100 From: Luigi Rizzo Message-Id: <199603051703.SAA06529@labinfo.iet.unipi.it> Subject: sio probe conflicts with Atlantis Video board To: bugs@freebsd.org Date: Tue, 5 Mar 1996 18:03:50 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-bugs@freebsd.org Precedence: bulk A little bit of investigation... the sio probe code in 2.1R seems to blank the screen on the built-in video board of the Intel Atlantis. It does not seem related to the implementation of DELAY(), because I have used it in other places (to add pauses in order to see the point where things were going wrong) and it does not cause the screen to go blank. Any ideas ? Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-bugs Tue Mar 5 09:20:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09315 for bugs-outgoing; Tue, 5 Mar 1996 09:20:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09291 Tue, 5 Mar 1996 09:20:02 -0800 (PST) Resent-Date: Tue, 5 Mar 1996 09:20:02 -0800 (PST) Resent-Message-Id: <199603051720.JAA09291@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, luigi@iet.unipi.it Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA09199 for ; Tue, 5 Mar 1996 09:16:36 -0800 (PST) Received: from prova.iet.unipi.it (prova.iet.unipi.it [131.114.9.236]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id JAA09512 for ; Tue, 5 Mar 1996 09:15:54 -0800 Received: (from luigi@localhost) by prova.iet.unipi.it (8.6.12/8.6.12) id RAA00301; Tue, 5 Mar 1996 17:58:04 +0100 Message-Id: <199603051658.RAA00301@prova.iet.unipi.it> Date: Tue, 5 Mar 1996 17:58:04 +0100 From: Luigi.Rizzo@prova.iet.unipi.it Reply-To: luigi@iet.unipi.it To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: i386/1062: sio probe blanks video on Intel Atlantis Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1062 >Category: i386 >Synopsis: sio probe blanks video on Intel Atlantis >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 5 09:20:00 PST 1996 >Last-Modified: >Originator: Luigi Rizzo >Organization: Dip. Ing. Informazione, Univ. Pisa >Release: FreeBSD 2.1-STABLE i386 >Environment: Intel Atlantis MB with Video and Sound card on the motherboard. Pentium 133 FreeBSD 2.1R >Description: The sio probes cause the screen to become blank. Other than that, the boot process continues regularly and the system seems to work. But no screen output is available. >How-To-Repeat: Just boot the OS. Disable the sio probes and you see the screen output. Enable them, and the screen becomes blank at the first sio probe. >Fix: Not available yet. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Mar 5 09:25:13 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09576 for bugs-outgoing; Tue, 5 Mar 1996 09:25:13 -0800 (PST) Received: from grumble.grondar.za (root@grumble.grondar.za [196.7.18.130]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA09539 for ; Tue, 5 Mar 1996 09:24:42 -0800 (PST) Received: from grumble.grondar.za (mark@localhost [127.0.0.1]) by grumble.grondar.za (8.7.4/8.7.3) with ESMTP id TAA00674; Tue, 5 Mar 1996 19:17:04 +0200 (SAT) Message-Id: <199603051717.TAA00674@grumble.grondar.za> To: *Hobbit* cc: eichin@cygnus.com, freebsd-bugs@freefall.freebsd.org, problems@bsdi.com, sra@epilogue.com Subject: Re: Kerberos 4 rsh/rcp fixes Date: Tue, 05 Mar 1996 19:17:02 +0200 From: Mark Murray Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Hi Mark Murray here. I am doing the code maintenance for eBones(Kerberos) for FreeBSD. *Hobbit* wrote: > As long as maintainers are in there fixing the Kerberos 4 random_key stuff, > it seems appropriate that other release tree fixes could be made at the same > time before new "official" releases go out. Great idea! > I've [finally!] completed some work on the encrypting modes of "rsh" and > "rcp", and have released the patches for review. These apply to Cygnus CNS, > and the built-in applications that come with BSDI 2.0 and FreeBSD 2.x. > > Please anonymous-FTP to ftp.epilogue.com, and do > > cd /pub/hobbit/crypto/f9601 > get krbfix-out.tar > > This single tar file contains a detailed description of the problems/fixes, > and patch kits for various releases. We had a look at these, but are unablle to use them, as they are aimed at FreeBSD 2.0.5 (already released) and 2.1.0 (also released). Our "stable" branch (2.1.n is only for well-proven code, not new stuff, so I can't put anything in there yet. Where we would like something like this is in our development branch "current", where it can be banged on and fine tuned. There has been at least one big change - our pipes are now bidirectional. We would be very interested in your input for 2.2-current. I can assist you in getting up to speed if you like? > Sorry for the sort of scatter-shot mailing; please forward to the right > places if I blew it.. I've got it now! M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grondar.za for PGP key From owner-freebsd-bugs Tue Mar 5 09:50:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11109 for bugs-outgoing; Tue, 5 Mar 1996 09:50:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA11103 Tue, 5 Mar 1996 09:50:02 -0800 (PST) Resent-Date: Tue, 5 Mar 1996 09:50:02 -0800 (PST) Resent-Message-Id: <199603051750.JAA11103@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, phk@critter.tfs.com Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA10762 for ; Tue, 5 Mar 1996 09:43:08 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0tu0lJ-0003vqC; Tue, 5 Mar 96 09:43 PST Received: (from phk@localhost) by critter.tfs.com (8.6.12/8.6.12) id RAA03787; Tue, 5 Mar 1996 17:43:03 GMT Message-Id: <199603051743.RAA03787@critter.tfs.com> Date: Tue, 5 Mar 1996 17:43:03 GMT From: Poul-Henning Kamp Reply-To: phk@critter.tfs.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1063: gzip a.out execution is not ok (?) Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1063 >Category: kern >Synopsis: gzip a.out execution is not ok (?) >Confidential: yes >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 5 09:50:01 PST 1996 >Last-Modified: >Originator: Poul-Henning Kamp >Organization: >Release: FreeBSD 2.2-CURRENT i386 >Environment: >Description: --------------15FB7483794BDF32446B9B3D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Some interesting reports of binaries that behave differently when zip'd. -- - Jordan Hubbard President, FreeBSD Project --------------15FB7483794BDF32446B9B3D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Path: reason.cdrom.com!nntp-ucb.barrnet.net!agate!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!lerc.nasa.gov!purdue!news.bu.edu!usenet From: mi@aldan.bu.edu (Mikhail Teterin) Newsgroups: comp.unix.bsd.freebsd.misc Subject: executing gziped a.outs Date: 3 Feb 1996 04:46:44 GMT Organization: Aldan at Newton Upper Falls Lines: 19 Message-ID: <4eupbl$7uh@news.bu.edu> NNTP-Posting-Host: ppp-84-12.bu.edu X-Newsreader: knews 0.9.4 The ability in subject is amazing. But this is what I've hit... Knews comes with status disconnected and will not connect to the news-server automaticly, like it used to being non-compressed. If you tell it to connect it obeys just fine and works... The game called CRAFT is also fine, but always takes the same map for the game, as opposite to picking it randomly as it used to being non-compressed. At the same time Netscape does not seem to care, that netscape.bin is now netscape.bin.gz ... Ideas? -mi -- "Windows for dummies" --------------15FB7483794BDF32446B9B3D-- >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Mar 5 11:50:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18666 for bugs-outgoing; Tue, 5 Mar 1996 11:50:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18660 Tue, 5 Mar 1996 11:50:02 -0800 (PST) Resent-Date: Tue, 5 Mar 1996 11:50:02 -0800 (PST) Resent-Message-Id: <199603051950.LAA18660@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, hsu@clinet.fi Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA18519 for ; Tue, 5 Mar 1996 11:46:10 -0800 (PST) Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id VAA10341 for ; Tue, 5 Mar 1996 21:45:50 +0200 (EET) Received: (root@localhost) by katiska.clinet.fi (8.7.3/8.6.4) id VAA02822; Tue, 5 Mar 1996 21:45:49 +0200 (EET) Message-Id: <199603051945.VAA02822@katiska.clinet.fi> Date: Tue, 5 Mar 1996 21:45:49 +0200 (EET) From: Heikki Suonsivu Reply-To: hsu@clinet.fi To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1064: Recursive panic? Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1064 >Category: kern >Synopsis: Recursive panic? >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 5 11:50:01 PST 1996 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-CURRENT i386 >Environment: Sup from about 1-2 weeks ago. Mar 5 20:40:57 news /kernel: FreeBSD 2.2-CURRENT #16: Thu Feb 22 22:38:14 EET 1996 Mar 5 20:40:57 news /kernel: hsu@news.clinet.fi:/usr/current/src/sys/compile/CLINETSERVER Mar 5 20:40:57 news /kernel: CPU: Pentium (89.80-MHz 586-class CPU) Mar 5 20:40:58 news /kernel: Origin = "GenuineIntel" Id = 0x525 Stepping=5 Mar 5 20:40:58 news /kernel: Features=0x1bf Mar 5 20:40:58 news /kernel: real memory = 67108864 (65536K bytes) Mar 5 20:40:58 news /kernel: avail memory = 63606784 (62116K bytes) Mar 5 20:40:58 news /kernel: DEVFS: ready for devices Mar 5 20:40:58 news /kernel: Probing for devices on PCI bus 0: Mar 5 20:40:58 news /kernel: chip0 rev 0 on pci0:0 Mar 5 20:40:58 news /kernel: chip1 rev 1 on pci0:1 Mar 5 20:40:58 news /kernel: pci0:1: Silicon Integrated Systems, device=0x5513, class=storage (ide) int a irq ?? [no driver assigned] Mar 5 20:40:58 news /kernel: ncr0 rev 2 int a irq 12 on pci0:9 Mar 5 20:40:58 news /kernel: ncr0 waiting for scsi devices to settle Mar 5 20:40:58 news /kernel: (ncr0:0:0): "SEAGATE ST15230N 0638" type 0 fixed SCSI 2 Mar 5 20:40:58 news /kernel: sd0(ncr0:0:0): Direct-Access Mar 5 20:40:58 news /kernel: sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Mar 5 20:40:58 news /kernel: 4095MB (8386733 512 byte sectors) Mar 5 20:40:58 news /kernel: sd0(ncr0:0:0): with 3992 cyls, 19 heads, and an average 110 sectors/track Mar 5 20:40:58 news /kernel: (ncr0:3:0): "SEAGATE ST31200N 9348" type 0 fixed SCSI 2 Mar 5 20:40:58 news /kernel: sd3(ncr0:3:0): Direct-Access Mar 5 20:40:58 news /kernel: sd3(ncr0:3:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Mar 5 20:40:58 news /kernel: 1011MB (2072435 512 byte sectors) Mar 5 20:40:58 news /kernel: sd3(ncr0:3:0): with 2700 cyls, 9 heads, and an average 85 sectors/track Mar 5 20:40:59 news /kernel: ncr1 rev 1 int a irq 10 on pci0:10 Mar 5 20:40:59 news /kernel: ncr1 waiting for scsi devices to settle Mar 5 20:40:59 news /kernel: (ncr1:1:0): "SEAGATE ST15230N 0638" type 0 fixed SCSI 2 Mar 5 20:40:59 news /kernel: sd7(ncr1:1:0): Direct-Access Mar 5 20:40:59 news /kernel: sd7(ncr1:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Mar 5 20:40:59 news /kernel: 4095MB (8386733 512 byte sectors) Mar 5 20:40:59 news /kernel: sd7(ncr1:1:0): with 3992 cyls, 19 heads, and an average 110 sectors/track Mar 5 20:40:59 news /kernel: (ncr1:2:0): "SEAGATE ST15230N 0638" type 0 fixed SCSI 2 Mar 5 20:40:59 news /kernel: sd8(ncr1:2:0): Direct-Access Mar 5 20:40:59 news /kernel: sd8(ncr1:2:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Mar 5 20:40:59 news /kernel: 4095MB (8386733 512 byte sectors) Mar 5 20:40:59 news /kernel: sd8(ncr1:2:0): with 3992 cyls, 19 heads, and an average 110 sectors/track Mar 5 20:40:59 news /kernel: de0 rev 35 int a irq 11 on pci0:11 Mar 5 20:40:59 news /kernel: de0: DC21040 [10Mb/s] pass 2.3 Ethernet address 00:c0:95:ec:47:a3 Mar 5 20:40:59 news /kernel: de0: enabling Thinwire/AUI port Mar 5 20:40:59 news /kernel: Probing for devices on the ISA bus: Mar 5 20:40:59 news /kernel: vt0 at 0x60-0x6f irq 1 on motherboard Mar 5 20:40:59 news /kernel: vt0: generic, 80/132 col, color, 8 scr, mf2-kbd, [R3.20-b24] Mar 5 20:40:59 news /kernel: ed0 not found at 0x280 Mar 5 20:40:59 news /kernel: lpt0 at 0x378-0x37f irq 7 on isa Mar 5 20:40:59 news /kernel: lpt0: Interrupt-driven port Mar 5 20:40:59 news /kernel: lp0: TCP/IP capable interface Mar 5 20:41:00 news /kernel: lpt1 not found at 0xffffffff Mar 5 20:41:00 news /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Mar 5 20:41:00 news /kernel: sio0: type 16550A Mar 5 20:41:00 news /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Mar 5 20:41:00 news /kernel: sio1: type 16550A Mar 5 20:41:00 news /kernel: cy0 not found Mar 5 20:41:00 news /kernel: bt0 not found at 0x330 Mar 5 20:41:00 news /kernel: aha0 not found at 0x330 Mar 5 20:41:00 news /kernel: wdc0 not found at 0x1f0 Mar 5 20:41:00 news /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Mar 5 20:41:00 news /kernel: fdc0: NEC 72065B Mar 5 20:41:00 news /kernel: fd0: 1.44MB 3.5in Mar 5 20:41:00 news /kernel: matcdc0 not found at 0x230 Mar 5 20:41:00 news /kernel: npx0 on motherboard Mar 5 20:41:00 news /kernel: npx0: INT 16 interface Mar 5 20:41:00 news /kernel: changing root device to sd0a Mar 5 20:41:00 news /kernel: devfs ready to run Mar 5 20:41:00 news /kernel: new masks: bio c0001440, tty c003089a, net c003089a Mar 5 20:41:00 news /kernel: WARNING: / was not properly dismounted. >Description: hsu#news.clinet.fi Tue 34: gdb -k kernel.55 vmcore.55 GDB is free software and you are welcome to 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. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... IdlePTD 258000 current pcb at 21839c panic: tsleep #0 boot (howto=260) at ../../i386/i386/machdep.c:940 940 dumppcb.pcb_ptd = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../i386/i386/machdep.c:940 #1 0xf0116326 in panic (fmt=0xf01c4df9 "trace trap") at ../../kern/subr_prf.c:125 #2 0xf01c590a in trap_fatal (frame=0xefbfe250) at ../../i386/i386/trap.c:758 #3 0xf01c51ca in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -272636912, tf_esi = -265777152, tf_ebp = -272637228, tf_isp = -272637320, tf_ebx = -265777148, tf_edx = 127, tf_ecx = -236387072, tf_eax = 50, tf_trapno = 10, tf_err = 0, tf_eip = -272637464, tf_cs = 8, tf_eflags = 514, tf_esp = 176, tf_ss = -1073610324}) at ../../i386/i386/trap.c:437 #4 0xf01bd8d1 in calltrap () #5 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #6 0xf01b5b05 in vm_map_lookup (var_map=0xefbfe410, vaddr=4057956352, fault_type=1 '\001', out_entry=0xefbfe3e4, object=0xefceff10, pindex=0xefbfe3db, out_prot=0xefbfe3db "", wired=0xefbfe3d4, single_use=0xefbfe3d0) at ../../vm/vm_map.c:2007 #7 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4057956352, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #8 0xf01c5432 in trap_pfault (frame=0xefbfe46c, usermode=0) at ../../i386/i386/trap.c:669 #9 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073741824, tf_esi = -1073741824, tf_ebp = -272636752, tf_isp = -272636780, tf_ebx = -235590176, tf_edx = -237010176, tf_ecx = -238896576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267067751, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -267067816}) at ../../i386/i386/trap.c:320 #10 0xf01bd8d1 in calltrap () #11 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #12 0xf01bec27 in doreti_swi () #13 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #14 0xf01b5b05 in vm_map_lookup (var_map=0xefbfe660, vaddr=4057956352, fault_type=1 '\001', out_entry=0xefbfe634, object=0xefbfe630, pindex=0xefbfe62c, out_prot=0xefbfe62b "ïLæ¿ï\001", wired=0xefbfe624, single_use=0xefbfe620) at ../../vm/vm_map.c:2007 #15 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4057956352, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #16 0xf01c5432 in trap_pfault (frame=0xefbfe6bc, usermode=0) at ../../i386/i386/trap.c:669 #17 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073741824, tf_esi = -1073741824, tf_ebp = -272636160, tf_isp = -272636188, tf_ebx = -235590176, tf_edx = -237010176, tf_ecx = -238896576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267067751, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -267067816}) at ../../i386/i386/trap.c:320 #18 0xf01bd8d1 in calltrap () #19 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #20 0xf01becac in splz_swi () #21 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #22 0xf01b5b05 in vm_map_lookup (var_map=0xefbfe878, vaddr=4057956352, fault_type=1 '\001', out_entry=0xefbfe84c, object=0xefbfe848, pindex=0xefbfe844, out_prot=0xefbfe843 "", wired=0xefbfe83c, single_use=0xefbfe838) at ../../vm/vm_map.c:2007 #23 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4057956352, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #24 0xf01c5432 in trap_pfault (frame=0xefbfe8d4, usermode=0) at ../../i386/i386/trap.c:669 #25 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073741824, tf_esi = -1073741824, tf_ebp = -272635624, tf_isp = -272635652, tf_ebx = -235590176, tf_edx = -237010176, tf_ecx = -238896576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267067751, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -267067816}) at ../../i386/i386/trap.c:320 #26 0xf01bd8d1 in calltrap () #27 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #28 0xf01becac in splz_swi () #29 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #30 0xf01b5b05 in vm_map_lookup (var_map=0xefbfea90, vaddr=4057956352, fault_type=1 '\001', out_entry=0xefbfea64, object=0xefbfea60, pindex=0xefbfea5c, out_prot=0xefbfea5b "", wired=0xefbfea54, single_use=0xefbfea50) at ../../vm/vm_map.c:2007 #31 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4057956352, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #32 0xf01c5432 in trap_pfault (frame=0xefbfeaec, usermode=0) at ../../i386/i386/trap.c:669 ---Type to continue, or q to quit--- #33 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073741824, tf_esi = -1073741824, tf_ebp = -272635088, tf_isp = -272635116, tf_ebx = -235590176, tf_edx = -237010176, tf_ecx = -238896576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267067751, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -267067816}) at ../../i386/i386/trap.c:320 #34 0xf01bd8d1 in calltrap () #35 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #36 0xf01becac in splz_swi () #37 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #38 0xf01b5b05 in vm_map_lookup (var_map=0xefbfeca8, vaddr=4057956352, fault_type=1 '\001', out_entry=0xefbfec7c, object=0xefbfec78, pindex=0xefbfec74, out_prot=0xefbfec73 "", wired=0xefbfec6c, single_use=0xefbfec68) at ../../vm/vm_map.c:2007 #39 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4057956352, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #40 0xf01c5432 in trap_pfault (frame=0xefbfed04, usermode=0) at ../../i386/i386/trap.c:669 #41 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073741824, tf_esi = -1073741824, tf_ebp = -272634552, tf_isp = -272634580, tf_ebx = -235590176, tf_edx = -237010176, tf_ecx = -238896576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267067751, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -267067816}) at ../../i386/i386/trap.c:320 #42 0xf01bd8d1 in calltrap () #43 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #44 0xf01bec27 in doreti_swi () #45 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #46 0xf01b5b05 in vm_map_lookup (var_map=0xefbfeef8, vaddr=4057956352, fault_type=1 '\001', out_entry=0xefbfeecc, object=0xefbfeec8, pindex=0xefbfeec4, out_prot=0xefbfeec3 "", wired=0xefbfeebc, single_use=0xefbfeeb8) at ../../vm/vm_map.c:2007 #47 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4057956352, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #48 0xf01c5432 in trap_pfault (frame=0xefbfef54, usermode=0) at ../../i386/i386/trap.c:669 #49 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1073741824, tf_esi = -1073741824, tf_ebp = -272633960, tf_isp = -272633988, tf_ebx = -235590176, tf_edx = -237010176, tf_ecx = -238896576, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267067751, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -267067816}) at ../../i386/i386/trap.c:320 #50 0xf01bd8d1 in calltrap () #51 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #52 0xf01becac in splz_swi () #53 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #54 0xf01b5b05 in vm_map_lookup (var_map=0xefbff110, vaddr=4055875584, fault_type=1 '\001', out_entry=0xefbff0e4, object=0xefbff0e0, pindex=0xefbff0dc, out_prot=0xefbff0db "", wired=0xefbff0d4, single_use=0xefbff0d0) at ../../vm/vm_map.c:2007 #55 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4055875584, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #56 0xf01c5432 in trap_pfault (frame=0xefbff16c, usermode=0) at ../../i386/i386/trap.c:669 #57 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -272633372, tf_esi = -267054912, tf_ebp = -272633416, tf_isp = -272633452, tf_ebx = -241414144, tf_edx = -239091432, tf_ecx = -242120244, tf_eax = -242120244, tf_trapno = 12, tf_err = 0, tf_eip = -267084201, tf_cs = 8, tf_eflags = 66054, tf_esp = -1073741824, tf_ss = -242120320}) at ../../i386/i386/trap.c:320 #58 0xf01bd8d1 in calltrap () #59 0xf01511ef in in_rtqtimo (rock=0xf1918980) at ../../netinet/in_rmx.c:298 #60 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #61 0xf01becac in splz_swi () #62 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #63 0xf01b5b05 in vm_map_lookup (var_map=0xefbff374, vaddr=4055875584, fault_type=1 '\001', out_entry=0xefbff348, object=0xefbff344, pindex=0xefbff340, out_prot=0xefbff33f "", wired=0xefbff338, single_use=0xefbff334) at ../../vm/vm_map.c:2007 #64 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4055875584, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #65 0xf01c5432 in trap_pfault (frame=0xefbff3d0, usermode=0) at ../../i386/i386/trap.c:669 #66 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -240606976, ---Type to continue, or q to quit--- tf_esi = 0, tf_ebp = -272632816, tf_isp = -272632840, tf_ebx = -235600212, tf_edx = -235600256, tf_ecx = -238048256, tf_eax = -239091456, tf_trapno = 12, tf_err = 0, tf_eip = -267014547, tf_cs = 8, tf_eflags = 66182, tf_esp = -240606976, tf_ss = -272632804}) at ../../i386/i386/trap.c:320 #67 0xf01bd8d1 in calltrap () #68 0xf015ae9f in tcp_gettaocache (inp=0xf1f50680) at ../../netinet/tcp_subr.c:603 #69 0xf0159bdf in tcp_output (tp=0xf1a8a100) at ../../netinet/tcp_output.c:152 #70 0xf015b1f1 in tcp_timers (tp=0xf1a8a100, timer=0) at ../../netinet/tcp_timer.c:280 #71 0xf015b6e9 in tcp_usrreq (so=0xf1cfac00, req=19, m=0x0, nam=0x0, control=0x0) at ../../netinet/tcp_usrreq.c:377 #72 0xf015b003 in tcp_slowtimo () at ../../netinet/tcp_timer.c:141 #73 0xf012310b in pfslowtimo (arg=0x0) at ../../kern/uipc_domain.c:214 #74 0xf01082cc in softclock () at ../../kern/kern_clock.c:664 #75 0xf01bec27 in doreti_swi () #76 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #77 0xf01b5b05 in vm_map_lookup (var_map=0xefbff6b0, vaddr=4042997760, fault_type=1 '\001', out_entry=0xefbff684, object=0xefbff680, pindex=0xefbff67c, out_prot=0xefbff67b "", wired=0xefbff674, single_use=0xefbff670) at ../../vm/vm_map.c:2007 #78 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4042997760, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #79 0xf01c5432 in trap_pfault (frame=0xefbff70c, usermode=0) at ../../i386/i386/trap.c:669 #80 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -242548940, tf_esi = -238201088, tf_ebp = -272631948, tf_isp = -272632012, tf_ebx = -236153216, tf_edx = 85, tf_ecx = -1073543014, tf_eax = -251967488, tf_trapno = 12, tf_err = 0, tf_eip = -266803285, tf_cs = 8, tf_eflags = 66050, tf_esp = -60358460, tf_ss = -242549760}) at ../../i386/i386/trap.c:320 #81 0xf01bd8d1 in calltrap () #82 0xf018f0f8 in tulip_intr (arg=0xf18afc00) at ../../pci/if_de.c:1463 #83 0xf01be8fd in Xresume11 () #84 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #85 0xf01b5b05 in vm_map_lookup (var_map=0xefbff928, vaddr=4054679552, fault_type=1 '\001', out_entry=0xefbff8fc, object=0xefbff8f8, pindex=0xefbff8f4, out_prot=0xefbff8f3 "", wired=0xefbff8ec, single_use=0xefbff8e8) at ../../vm/vm_map.c:2007 #86 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4054679552, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #87 0xf01c5432 in trap_pfault (frame=0xefbff984, usermode=0) at ../../i386/i386/trap.c:669 #88 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -242115072, tf_esi = -241027968, tf_ebp = -272631340, tf_isp = -272631380, tf_ebx = -238040960, tf_edx = -242245888, tf_ecx = 33, tf_eax = -240285696, tf_trapno = 12, tf_err = 0, tf_eip = -267191306, tf_cs = 8, tf_eflags = 66182, tf_esp = -242115072, tf_ss = 0}) at ../../i386/i386/trap.c:320 #89 0xf01bd8d1 in calltrap () #90 0xf0130170 in sync (p=0xf02431a8, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:355 #91 0xf01c00ba in boot (howto=256) at ../../i386/i386/machdep.c:889 #92 0xf0116326 in panic (fmt=0xf0111997 "tsleep") at ../../kern/subr_prf.c:125 #93 0xf0111a5a in tsleep (ident=0xf0289004, priority=4, wmesg=0xf01af157 "lockrd", timo=0) at ../../kern/kern_synch.c:320 #94 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #95 0xf01b5b05 in vm_map_lookup (var_map=0xefbffb90, vaddr=4058423296, fault_type=1 '\001', out_entry=0xefbffb64, object=0xefbffb60, pindex=0xefbffb5c, out_prot=0xefbffb5b "ñ\001", wired=0xefbffb54, single_use=0xefbffb50) at ../../vm/vm_map.c:2007 #96 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4058423296, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #97 0xf01c5432 in trap_pfault (frame=0xefbffbec, usermode=0) at ../../i386/i386/trap.c:669 #98 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 17, tf_esi = -236387072, tf_ebp = -272630716, tf_isp = -272630764, tf_ebx = -236541440, tf_edx = 0, tf_ecx = 165604, tf_eax = 17, tf_trapno = 12, tf_err = 0, tf_eip = -267313048, tf_cs = 8, tf_eflags = 66195, tf_esp = -236387072, tf_ss = 0}) at ../../i386/i386/trap.c:320 #99 0xf01bd8d1 in calltrap () #100 0xf0111b31 in tsleep (ident=0xf0289004, priority=4, ---Type to continue, or q to quit--- wmesg=0xf01af157 "lockrd", timo=0) at ../../kern/kern_synch.c:359 #101 0xf01af19b in lock_read (l=0xf0289004) at ../../vm/kern_lock.c:184 #102 0xf01b5b05 in vm_map_lookup (var_map=0xefbffd98, vaddr=4053790720, fault_type=1 '\001', out_entry=0xefbffd6c, object=0xefbffd68, pindex=0xefbffd64, out_prot=0xefbffd63 "ñÐý¿ïBe\025ð", wired=0xefbffd5c, single_use=0xefbffd58) at ../../vm/vm_map.c:2007 #103 0xf01b16d2 in vm_fault (map=0xf0289000, vaddr=4053790720, fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:193 #104 0xf01c5432 in trap_pfault (frame=0xefbffdf4, usermode=0) at ../../i386/i386/trap.c:669 #105 0xf01c511b in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -237646592, tf_esi = 0, tf_ebp = -272630192, tf_isp = -272630244, tf_ebx = 4, tf_edx = -241173440, tf_ecx = -236387072, tf_eax = -237646564, tf_trapno = 12, tf_err = 0, tf_eip = -267287000, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -2147483648}) at ../../i386/i386/trap.c:320 #106 0xf01bd8d1 in calltrap () #107 0xf011842b in select (p=0xf1e90500, uap=0xefbfff94, retval=0xefbfff8c) at ../../kern/sys_generic.c:575 #108 0xf01c5bd7 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -1, tf_esi = -272638508, tf_ebp = -272638516, tf_isp = -272629788, tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 93, tf_trapno = 0, tf_err = 647, tf_eip = 134527637, tf_cs = 31, tf_eflags = 647, tf_esp = -272638644, tf_ss = 39}) at ../../i386/i386/trap.c:918 #109 0xf01bd91d in Xsyscall () #110 0x6ce0 in ?? () #111 0x109b in ?? () (kgdb) frame $109 History has not yet reached $109. (kgdb) frame #109 #0 boot (howto=260) at ../../i386/i386/machdep.c:940 940 dumppcb.pcb_ptd = rcr3(); (kgdb) print dumppcb.pcb_ptd There is no member named pcb_ptd. (kgdb) print dumppcb $1 = {pcb_tss = {tss_link = 0, tss_esp0 = 0, tss_ss0 = 0, tss_esp1 = 0, tss_ss1 = 0, tss_esp2 = 0, tss_ss2 = 0, tss_cr3 = 5681152, tss_eip = -266599881, tss_eflags = 0, tss_eax = 1, tss_ecx = 0, tss_edx = 0, tss_ebx = 260, tss_esp = -272637500, tss_ebp = -272637480, tss_esi = -266580487, tss_edi = 10, tss_es = 0, tss_cs = 0, tss_ss = 0, tss_ds = 0, tss_fs = 0, tss_gs = 0, tss_ldt = 0, tss_ioopt = 0}, pcb_ldt = 0x0, pcb_ldt_len = 0, pcb_savefpu = {sv_env = {en_cw = 0, en_sw = 0, en_tw = 0, en_fip = 0, en_fcs = 0, en_opcode = 0, en_foo = 0, en_fos = 0}, sv_ac = {{ fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}}, sv_ex_sw = 0, sv_pad = '\000' }, pcb_flags = 0 '\000', pcb_inl = 0 '\000', pcb_onfault = 0x0, pcb_sigc = {0, 0, 0, 0, 0, 0, 0, 0}} (kgdb) set radix 16 Input and output radices now set to decimal 16, hex 10, octal 20. (kgdb) print dumppcb $2 = {pcb_tss = {tss_link = 0x0, tss_esp0 = 0x0, tss_ss0 = 0x0, tss_esp1 = 0x0, tss_ss1 = 0x0, tss_esp2 = 0x0, tss_ss2 = 0x0, tss_cr3 = 0x56b000, tss_eip = 0xf01c0237, tss_eflags = 0x0, tss_eax = 0x1, tss_ecx = 0x0, tss_edx = 0x0, tss_ebx = 0x104, tss_esp = 0xefbfe1c4, tss_ebp = 0xefbfe1d8, tss_esi = 0xf01c4df9, tss_edi = 0xa, tss_es = 0x0, tss_cs = 0x0, tss_ss = 0x0, tss_ds = 0x0, tss_fs = 0x0, tss_gs = 0x0, tss_ldt = 0x0, tss_ioopt = 0x0}, pcb_ldt = 0x0, pcb_ldt_len = 0x0, pcb_savefpu = {sv_env = {en_cw = 0x0, en_sw = 0x0, en_tw = 0x0, en_fip = 0x0, en_fcs = 0x0, en_opcode = 0x0, en_foo = 0x0, en_fos = 0x0}, sv_ac = {{ fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}, { fp_bytes = "\000\000\000\000\000\000\000\000\000"}}, sv_ex_sw = 0x0, sv_pad = '\000' }, pcb_flags = 0x0, pcb_inl = 0x0, pcb_onfault = 0x0, pcb_sigc = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} (kgdb) quit kernel and dump are available in ftp://ftp.clinet.fi/pub/FreeBSD/crashdumps/*.55.gz >How-To-Repeat: Serious load. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Mar 5 11:59:11 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA19095 for bugs-outgoing; Tue, 5 Mar 1996 11:59:11 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA19090 for ; Tue, 5 Mar 1996 11:59:08 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA10004; Wed, 6 Mar 1996 06:55:19 +1100 Date: Wed, 6 Mar 1996 06:55:19 +1100 From: Bruce Evans Message-Id: <199603051955.GAA10004@godzilla.zeta.org.au> To: bugs@freebsd.org, luigi@labinfo.iet.unipi.it Subject: Re: sio probe conflicts with Atlantis Video board Sender: owner-bugs@freebsd.org Precedence: bulk >A little bit of investigation... the sio probe code in 2.1R seems to >blank the screen on the built-in video board of the Intel Atlantis. This was fixed long ago: -current: 1995/11/29 -stable: 1996/01/29 Bruce From owner-freebsd-bugs Tue Mar 5 13:23:37 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA25838 for bugs-outgoing; Tue, 5 Mar 1996 13:23:37 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25727 for ; Tue, 5 Mar 1996 13:21:52 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA17736; Tue, 5 Mar 1996 22:21:00 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA02004; Tue, 5 Mar 1996 22:21:00 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.4/8.6.9) id VAA07047; Tue, 5 Mar 1996 21:45:46 +0100 (MET) From: J Wunsch Message-Id: <199603052045.VAA07047@uriah.heep.sax.de> Subject: Re: sio probe conflicts with Atlantis Video board To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 5 Mar 1996 21:45:46 +0100 (MET) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199603051703.SAA06529@labinfo.iet.unipi.it> from "Luigi Rizzo" at Mar 5, 96 06:03:50 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@freebsd.org Precedence: bulk As Luigi Rizzo wrote: > > A little bit of investigation... the sio probe code in 2.1R seems to > blank the screen on the built-in video board of the Intel Atlantis. Remove the only occurance of `0x2e8' in /sys/i386/isa/sio.c, and recompile. There's a better fix in the current code, but as a quick hack, the above should get you working with 2.1R. (Your PR is already stale by the time of submission. :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Mar 6 05:20:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA19648 for bugs-outgoing; Wed, 6 Mar 1996 05:20:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA19626 Wed, 6 Mar 1996 05:20:03 -0800 (PST) Resent-Date: Wed, 6 Mar 1996 05:20:03 -0800 (PST) Resent-Message-Id: <199603061320.FAA19626@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, vak@crox.net.kiae.su Received: from crox.net.kiae.su (crox.net.kiae.su [144.206.130.72]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA19208 for ; Wed, 6 Mar 1996 05:10:40 -0800 (PST) Received: by crox.net.kiae.su id QAA00489; (8.6.12/vak/1.8a) Wed, 6 Mar 1996 16:10:56 +0300 Message-Id: <199603061310.QAA00489@crox.net.kiae.su> Date: Wed, 6 Mar 1996 16:10:56 +0300 From: vak@crox.net.kiae.su (Serge V.Vakulenko) Reply-To: vak@crox.net.kiae.su To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1065: patch for wt driver Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1065 >Category: kern >Synopsis: wt could crash reading short blocks >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 6 05:20:01 PST 1996 >Last-Modified: >Originator: Serge V.Vakulenko >Organization: Cronyx Ltd., Moscow >Release: FreeBSD 2.1-STABLE i386 >Environment: FreeBSD 2.1 and Archive tape streamer >Description: The system crashes when trying to read the tape using small block size (less than 2048 bytes). >How-To-Repeat: dd bs=1 < /dev/rwt0 > /dev/null >Fix: --- wt21.c Thu Sep 14 11:09:39 1995 +++ wt.c Wed Mar 6 15:41:49 1996 @@ -634,8 +634,6 @@ DEBUG (("unexpected interrupt\n")); return; } - t->flags &= ~TPACTIVE; - t->dmacount += t->bsize; /* increment counter */ /* * Clean up dma. @@ -648,6 +646,10 @@ } else isa_dmadone (t->dmaflags, t->dmavaddr, t->bsize, t->chan); + t->flags &= ~TPACTIVE; + t->dmacount += t->bsize; + t->dmavaddr += t->bsize; + /* * On exception, check for end of file and end of volume. */ @@ -663,7 +665,6 @@ } if (t->dmacount < t->dmatotal) { /* continue i/o */ - t->dmavaddr += t->bsize; wtdma (t); DEBUG (("continue i/o, %d\n", t->dmacount)); return; >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Mar 6 13:21:51 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA25687 for bugs-outgoing; Wed, 6 Mar 1996 13:21:51 -0800 (PST) Received: from wetware.com (root@wetware.wetware.com [192.216.52.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA25677 for ; Wed, 6 Mar 1996 13:21:48 -0800 (PST) Received: from ditka by wetware.com with uucp (Smail3.1.28.1 #4) id m0tuQeR-000Jb9C; Wed, 6 Mar 96 13:21 PST Received: from ohare.chicago.com by ditka.chicago.com with smtp (Smail3.1.28.1 #1) id m0tuQdU-0001W1C; Wed, 6 Mar 96 13:20 WET Received: by ohare.chicago.com (Smail3.1.28.1 #1) id m0tuQdU-0000FbC; Wed, 6 Mar 96 13:20 WET Message-Id: From: kls@ohare.chicago.com (Karl Swartz) Subject: execution from null fs panics system To: bugs@freebsd.org Date: Wed, 6 Mar 1996 13:20:40 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-bugs@freebsd.org Precedence: bulk I submitted the attach gnats report on Sunday but haven't heard anything back yet, not even an ack, so I'm not sure if it made it or not. I've also got some additional information. The original report described a panic while executing a shell script created in a null filesystem mounted over a sub-tree of /usr. It now appears that the system panics when executing *anything* from out of a null fs, not just scripts. I've generated a few crash dumps and found that in some cases the panic is an integer divide fault while in others it is the orignally reported kernel page fault. It seems to depend on the specific kernel. Here's a stack trace from one of the kernel page faults: IdlePTD 20b000 current pcb at 1fbb10 panic: page fault #0 0xf0198a01 in boot () (kgdb) bt #0 0xf0198a01 in boot () #1 0xf0112aa3 in panic () #2 0xf01a07ee in trap_fatal () #3 0xf01a0360 in trap_pfault () #4 0xf019ffff in trap () #5 0xf019621d in calltrap () #6 0xf05ee6fc in end () #7 0xf019469b in vnode_pager_haspage () #8 0xf0193ac4 in vm_pager_has_page () #9 0xf018b128 in vm_fault_additional_pages () #10 0xf018a226 in vm_fault () #11 0xf01a0316 in trap_pfault () #12 0xf019ffff in trap () #13 0xf019621d in calltrap () #14 0xf0104177 in exec_aout_imgact () #15 0xf0108cd2 in execve () #16 0xf01a09cf in syscall () #17 0xf019626b in Xsyscall () The one for an integer divide fault craps out at roughly the same place: IdlePTD 1a2000 current pcb at 1975b8 panic: integer divide fault #0 0xf015f72d in boot () (kgdb) bt #0 0xf015f72d in boot () #1 0xf010eed3 in panic () #2 0xf01645be in trap_fatal () #3 0xf0163e7e in trap () #4 0xf015d05d in calltrap () #5 0xf015b75f in vnode_pager_haspage () #6 0xf015abd4 in vm_pager_has_page () #7 0xf0152238 in vm_fault_additional_pages () #8 0xf0151336 in vm_fault () #9 0xf01640e6 in trap_pfault () #10 0xf0163dcf in trap () #11 0xf015d05d in calltrap () #12 0xf0100587 in exec_aout_imgact () #13 0xf01050c2 in execve () #14 0xf016479f in syscall () #15 0xf015d0ab in Xsyscall () In both cases, I was trying to run a shell script, not an a.out file (though an a.out produces a similar panic). That doesn't leave much suspect code in exec_aout_imgact(), so it seems that it has probably received a bogus reference to vm space from execve(). Within that routine, the VOP_UNLOCK() call or something in exec_check_perissions() seems to be the likely culprit. I followed VOP_UNLOCK() down into the null fs code a bit, but haven't gotten very far yet. -- Karl *** gnats report *** >Submitter-Id: current-users >Originator: Karl Swartz >Organization: Karl Swartz |Home kls@chicago.com |Work kls@slac.stanford.edu |WWW http://www.chicago.com/~kls/ Moderator of sci.aeronautics.airliners -- Unix/network work pays the bills >Confidential: no >Synopsis: null fs panics system >Severity: critical >Priority: medium >Category: kern >Release: FreeBSD 2.1-STABLE i386 >Class: sw-bug >Environment: Newly installed FreeBSD 2.1 system (from Walnut Creek CDROM), with selected packages installed (including bash and perl) but no other special software, running the stock kernel on the following hardware: Alaris motherboard with IBM 486SLC2-66 (no 387 installed) 8 MB memory generic IDE controller Maxtor 7420AV disk SMC Ultra Ethernet User home directories in /usr/u/, which preferably would be visible as /u/ via a null/lofs mount. Running as nonprivileged user with bash as the default shell. >Description: The system panics as follows when trying to execute a newly created Perl script iff running from a null fs: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf05586fc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1119 (bash) interrupt mask = panic: page fault >How-To-Repeat: (login) $ echo $SHELL /usr/local/bin/bash $ echo $HOME /usr/u/user $ su Password: # mkdir /u # mount -t null /usr/u /u # exit $ cd /u/user $ mkdir panic $ cd panic $ cat >hello <Fix: From owner-freebsd-bugs Wed Mar 6 16:10:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA12517 for bugs-outgoing; Wed, 6 Mar 1996 16:10:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA12511 Wed, 6 Mar 1996 16:10:02 -0800 (PST) Resent-Date: Wed, 6 Mar 1996 16:10:02 -0800 (PST) Resent-Message-Id: <199603070010.QAA12511@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, hsu@clinet.fi Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA12421 for ; Wed, 6 Mar 1996 16:08:14 -0800 (PST) Received: from zetor.clinet.fi (root@zetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id CAA04756 for ; Thu, 7 Mar 1996 02:08:05 +0200 (EET) Received: (root@localhost) by zetor.clinet.fi (8.7.3/8.6.4) id CAA28412; Thu, 7 Mar 1996 02:08:04 +0200 (EET) Message-Id: <199603070008.CAA28412@zetor.clinet.fi> Date: Thu, 7 Mar 1996 02:08:04 +0200 (EET) From: Heikki Suonsivu Reply-To: hsu@clinet.fi To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1066: Arnet driver: panic when ifconfig PPP -> HDLC Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1066 >Category: kern >Synopsis: Arnet driver: panic when ifconfig PPP -> HDLC >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 6 16:10:01 PST 1996 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-CURRENT i386 >Environment: FreeBSD 2.2-CURRENT #0: Sun Mar 3 12:00:09 EET 1996 hsu@news.clinet.fi:/usr/current/src/sys/compile/CLINETARNET CPU: i486 SX (486-class CPU) Origin = "GenuineIntel" Id = 0x423 Stepping=3 Features=0x2 real memory = 16777216 (16384K bytes) avail memory = 14467072 (14128K bytes) Probing for devices on the ISA bus: vt0 at 0x60-0x6f irq 1 on motherboard vt0: cl-gd5428, 80/132 col, mono, 8 scr, mf2-kbd, [R3.20-b24] ed0 at 0x280-0x29f irq 5 on isa ed0: address 00:4f:56:00:7c:6b, type NE2000 (16 bit) ed3 at 0x240-0x25f irq 9 on isa ed3: address 00:4f:56:00:4b:76, type NE2000 (16 bit) ed4 at 0x340-0x35f irq 15 on isa ed4: address 00:4f:56:00:ad:e0, type NE2000 (16 bit) ed5 not found at 0x220 sio0 not found at 0x3f8 sio0 not found at 0x3f8 sio1 not found at 0x2f8 sio1 not found at 0x2f8 sio2 not found at 0x2a0 sio2 not found at 0x2a0 sio3 not found at 0x2a8 sio3 not found at 0x2a8 sio4 not found at 0x2b0 sio4 not found at 0x2b0 sio5 not found at 0x2b8 sio5 not found at 0x2b8 cy0 not found cy1 not found bt0 not found at 0x330 aha0 not found at 0x330 wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 402MB (824160 sectors), 1010 cyls, 16 heads, 51 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in arc0 at 0x300-0x30f irq 10 maddr 0xd0000 msize 16384 on isa arc0: 256K RAM, 4 ports, rev 0, EIA-232 or V.35 interface. ar0: Adapter 0, port 0. ar1: Adapter 0, port 1. ar2: Adapter 0, port 2. ar3: Adapter 0, port 3. npx0 on motherboard npx0: 387 emulator new masks: bio c0004040, tty c0038622, net c0038622 <7>arplookup 193.64.6.28 failed: host is not on local network <7>arplookup 193.64.6.27 failed: host is not on local network >Description: When trying to ioctl ar1 from PPP to Cisco HDLC I got this: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1e fault code = supervisor read, page not present instruction pointer = 0x8:0xf01501b3 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 165 (ifconfig) interrupt mask = panic: page fault syncing disks... done dumping to dev 1, offset 0 dump 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 The ar0 device works, but when using ar1 at the same time ar1 fails to work correctly. ar0 is connected to a frame relay box which ignores handshake signals, while ar1 is connected to a pair of modems, with a Cisco 1005 in the other end. I haven't yet fully verified that this is arnet driver problem, as I need to take the setup to lab and try it there. What we see is loss of packets and this: Mar 6 07:09:26 kamppi2-gw /kernel: ar1: down Mar 6 07:09:26 kamppi2-gw /kernel: ar1: up Mar 6 07:32:26 kamppi2-gw /kernel: ar1: down Mar 6 07:32:26 kamppi2-gw /kernel: ar1: up Mar 6 07:47:36 kamppi2-gw /kernel: ar1: down Mar 6 07:47:36 kamppi2-gw /kernel: ar1: up Mar 6 08:10:35 kamppi2-gw /kernel: ar1: down Mar 6 08:10:35 kamppi2-gw /kernel: ar1: up Mar 6 08:33:35 kamppi2-gw /kernel: ar1: down Mar 6 08:33:35 kamppi2-gw /kernel: ar1: up Mar 6 08:48:45 kamppi2-gw /kernel: ar1: down Mar 6 08:48:45 kamppi2-gw /kernel: ar1: up Mar 6 09:11:45 kamppi2-gw /kernel: ar1: down Mar 6 09:11:45 kamppi2-gw /kernel: ar1: up Mar 6 09:47:35 kamppi2-gw /kernel: ar1: down Mar 6 09:47:35 kamppi2-gw /kernel: ar1: up Mar 6 10:15:35 kamppi2-gw /kernel: ar1: down Mar 6 10:15:35 kamppi2-gw /kernel: ar1: up Mar 6 10:31:03 kamppi2-gw /kernel: RX1 So this does happen :), stat a4, ST2 0, cda 4190. Mar 6 10:31:03 kamppi2-gw /kernel: RX1 After reset: ST2 0. Mar 6 10:44:05 kamppi2-gw /kernel: ar1: down Mar 6 10:44:05 kamppi2-gw /kernel: ar1: up Mar 6 10:51:05 kamppi2-gw /kernel: ar1: down Mar 6 10:51:05 kamppi2-gw /kernel: ar1: up Mar 6 11:47:24 kamppi2-gw /kernel: ar1: down Mar 6 11:47:24 kamppi2-gw /kernel: ar1: up Mar 6 11:54:04 kamppi2-gw /kernel: ar1: down Mar 6 11:54:04 kamppi2-gw /kernel: ar1: up Mar 6 12:01:24 kamppi2-gw /kernel: ar1: down Mar 6 12:01:24 kamppi2-gw /kernel: ar1: up Mar 6 12:05:45 kamppi2-gw /kernel: RX1 So this does happen :), stat d4, ST2 0, cda 42b2. Mar 6 12:05:45 kamppi2-gw /kernel: RX1 After reset: ST2 0. Mar 6 12:23:24 kamppi2-gw /kernel: ar1: down Mar 6 12:23:24 kamppi2-gw /kernel: ar1: up Mar 6 12:46:24 kamppi2-gw /kernel: ar1: down Mar 6 12:46:24 kamppi2-gw /kernel: ar1: up Mar 6 13:01:33 kamppi2-gw /kernel: ar1: down Mar 6 13:01:34 kamppi2-gw /kernel: ar1: up Mar 6 13:22:43 kamppi2-gw /kernel: ar1: down Mar 6 13:22:43 kamppi2-gw /kernel: ar1: up Mar 6 14:14:33 kamppi2-gw /kernel: RX1 So this does happen :), stat a4, ST2 0, cda 41ea. Mar 6 14:14:33 kamppi2-gw /kernel: RX1 After reset: ST2 0. Mar 6 14:28:23 kamppi2-gw /kernel: ar1: down Mar 6 14:28:23 kamppi2-gw /kernel: ar1: up Mar 6 14:51:23 kamppi2-gw /kernel: ar1: down Mar 6 14:51:23 kamppi2-gw /kernel: ar1: up Mar 6 15:06:33 kamppi2-gw /kernel: ar1: down Mar 6 15:06:33 kamppi2-gw /kernel: ar1: up Mar 6 15:29:33 kamppi2-gw /kernel: ar1: down Mar 6 15:29:33 kamppi2-gw /kernel: ar1: up Mar 6 15:52:16 kamppi2-gw /kernel: RX1 So this does happen :), stat 84, ST2 0, cda 4104. Mar 6 15:52:16 kamppi2-gw /kernel: RX1 After reset: ST2 0. Mar 6 16:15:52 kamppi2-gw /kernel: ar1: down Mar 6 16:15:52 kamppi2-gw /kernel: ar1: up Mar 6 16:31:02 kamppi2-gw /kernel: ar1: down Mar 6 16:31:02 kamppi2-gw /kernel: ar1: up Mar 6 16:54:02 kamppi2-gw /kernel: ar1: down Mar 6 16:54:02 kamppi2-gw /kernel: ar1: up Mar 6 17:35:02 kamppi2-gw /kernel: ar1: down Mar 6 17:35:02 kamppi2-gw /kernel: ar1: up Mar 6 17:58:02 kamppi2-gw /kernel: ar1: down ftp://ftp.clinet.fi/pub/FreeBSD/crashdumps/kamppi2 Unfortunately there are no symbols in the kernel, the machine was configured with too small root and I had left them out. >How-To-Repeat: I could not repeat the panic, but I didn't want to try it (it is a production link). The packet loss problem I need to verify to work without the telco cable between the modems to make sure it is not their problem (modem error counters do not show anything wrong, and we tried two very different pairs of modems). >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Mar 6 16:19:51 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA13088 for bugs-outgoing; Wed, 6 Mar 1996 16:19:51 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA13078 for ; Wed, 6 Mar 1996 16:19:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id QAA25397; Wed, 6 Mar 1996 16:19:58 -0800 Message-Id: <199603070019.QAA25397@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: kls@ohare.chicago.com (Karl Swartz) cc: bugs@freebsd.org Subject: Re: execution from null fs panics system In-reply-to: Your message of "Wed, 06 Mar 1996 13:20:40 PST." From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 06 Mar 1996 16:19:58 -0800 Sender: owner-bugs@freebsd.org Precedence: bulk >I submitted the attach gnats report on Sunday but haven't heard >anything back yet, not even an ack, so I'm not sure if it made it or >not. I've also got some additional information. Nullfs is completely broken in FreeBSD. There are too many problems to even begin to enumerate. We hope to have it fixed in FreeBSD 2.2. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Wed Mar 6 16:50:08 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA15701 for bugs-outgoing; Wed, 6 Mar 1996 16:50:08 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA15687 Wed, 6 Mar 1996 16:50:05 -0800 (PST) Resent-Date: Wed, 6 Mar 1996 16:50:05 -0800 (PST) Resent-Message-Id: <199603070050.QAA15687@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, hsu@clinet.fi Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA15248 for ; Wed, 6 Mar 1996 16:48:02 -0800 (PST) Received: from zetor.clinet.fi (root@zetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id CAA05924 for ; Thu, 7 Mar 1996 02:47:30 +0200 (EET) Received: (root@localhost) by zetor.clinet.fi (8.7.3/8.6.4) id CAA01586; Thu, 7 Mar 1996 02:47:30 +0200 (EET) Message-Id: <199603070047.CAA01586@zetor.clinet.fi> Date: Thu, 7 Mar 1996 02:47:30 +0200 (EET) From: Heikki Suonsivu Reply-To: hsu@clinet.fi To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/1067: panic: ufs_lock: recursive lock not expected, pid: 27195 Sender: owner-bugs@freebsd.org Precedence: bulk >Number: 1067 >Category: kern >Synopsis: panic: ufs_lock: recursive lock not expected, pid: 27195 >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 6 16:50:02 PST 1996 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-CURRENT i386 >Environment: -current Mar 6 18:46:27 cantina /kernel: FreeBSD 2.2-CURRENT #16: Thu Feb 22 22:38:14 EET 1996 Mar 6 18:46:28 cantina /kernel: hsu@news.clinet.fi:/usr/current/src/sys/compile/CLINETSERVER Mar 6 18:46:28 cantina /kernel: CPU: Pentium (132.61-MHz 586-class CPU) Mar 6 18:46:28 cantina /kernel: Origin = "GenuineIntel" Id = 0x52b Stepping=11 Mar 6 18:46:28 cantina /kernel: Features=0x1bf Mar 6 18:46:28 cantina /kernel: real memory = 67108864 (65536K bytes) Mar 6 18:46:28 cantina /kernel: avail memory = 63606784 (62116K bytes) Mar 6 18:46:28 cantina /kernel: DEVFS: ready for devices Mar 6 18:46:28 cantina /kernel: Probing for devices on PCI bus 0: Mar 6 18:46:28 cantina /kernel: chip0 rev 2 on pci0:0 Mar 6 18:46:28 cantina /kernel: chip1 rev 2 on pci0:7 Mar 6 18:46:28 cantina /kernel: piix0 rev 2 on pci0:7 Mar 6 18:46:28 cantina /kernel: de0 rev 35 int a irq 10 on pci0:10 Mar 6 18:46:28 cantina /kernel: de0: DC21040 [10Mb/s] pass 2.3 Ethernet address 00:c0:95:ec:56:84 Mar 6 18:46:29 cantina /kernel: de0: enabling Thinwire/AUI port Mar 6 18:46:29 cantina /kernel: ncr0 rev 2 int a irq 11 on pci0:12 Mar 6 18:46:29 cantina /kernel: ncr0 waiting for scsi devices to settle Mar 6 18:46:29 cantina /kernel: (ncr0:0:0): "IBM DPES-31080 S31Q" type 0 fixed SCSI 2 Mar 6 18:46:29 cantina /kernel: sd0(ncr0:0:0): Direct-Access Mar 6 18:46:29 cantina /kernel: sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. Mar 6 18:46:29 cantina /kernel: 1034MB (2118144 512 byte sectors) Mar 6 18:46:29 cantina /kernel: sd0(ncr0:0:0): with 4903 cyls, 4 heads, and an average 108 sectors/track Mar 6 18:46:29 cantina /kernel: Probing for devices on the ISA bus: Mar 6 18:46:29 cantina /kernel: vt0 at 0x60-0x6f irq 1 on motherboard Mar 6 18:46:29 cantina /kernel: vt0: tvga 8900cl, 80/132 col, color, 8 scr, mf2-kbd, [R3.20-b24] Mar 6 18:46:29 cantina /kernel: ed0 not found at 0x280 Mar 6 18:46:29 cantina /kernel: lpt0 at 0x378-0x37f irq 7 on isa Mar 6 18:46:29 cantina /kernel: lpt0: Interrupt-driven port Mar 6 18:46:29 cantina /kernel: lp0: TCP/IP capable interface Mar 6 18:46:29 cantina /kernel: lpt1 not found at 0xffffffff Mar 6 18:46:29 cantina /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Mar 6 18:46:29 cantina /kernel: sio0: type 16550A Mar 6 18:46:29 cantina /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Mar 6 18:46:29 cantina /kernel: sio1: type 16550A Mar 6 18:46:29 cantina /kernel: cy0 not found Mar 6 18:46:29 cantina /kernel: bt0 not found at 0x330 Mar 6 18:46:29 cantina /kernel: aha0 not found at 0x330 Mar 6 18:46:30 cantina /kernel: wdc0 not found at 0x1f0 Mar 6 18:46:30 cantina /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Mar 6 18:46:30 cantina /kernel: fdc0: NEC 72065B Mar 6 18:46:30 cantina /kernel: fd0: 1.44MB 3.5in Mar 6 18:46:30 cantina /kernel: matcdc0 not found at 0x230 Mar 6 18:46:30 cantina /kernel: npx0 on motherboard Mar 6 18:46:30 cantina /kernel: npx0: INT 16 interface Mar 6 18:46:30 cantina /kernel: changing root device to sd0a Mar 6 18:46:30 cantina /kernel: devfs ready to run Mar 6 18:46:31 cantina /kernel: new masks: bio c0000840, tty c003049a, net c003049a Mar 6 18:46:31 cantina /kernel: WARNING: / was not properly dismounted. >Description: Mounting a directory on itself panics the system. mount /m/katiska/local /m/katiska/local Mar 6 18:46:26 cantina /kernel: panic: ufs_lock: recursive lock not expected, pid: 27195 Mar 6 18:46:27 cantina /kernel: Mar 6 18:46:27 cantina /kernel: Mar 6 18:46:27 cantina /kernel: syncing disks... 21 21 14 8 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 giving up Mar 6 18:46:27 cantina /kernel: 1: dev:ffffffff, flags:21000014, blkno:1648, lblkno:103 Mar 6 18:46:27 cantina /kernel: 2: dev:ffffffff, flags:21000034, blkno:896, lblkno:56 Mar 6 18:46:27 cantina /kernel: 3: dev:ffffffff, flags:21000034, blkno:448, lblkno:28 Mar 6 18:46:27 cantina /kernel: 4: dev:ffffffff, flags:21000034, blkno:0, lblkno:0 Mar 6 18:46:27 cantina /kernel: Mar 6 18:46:27 cantina /kernel: dumping to dev 401, offset 0 Mar 6 18:46:27 cantina /kernel: dump 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 succeeded Mar 6 18:46:27 cantina /kernel: Automatic reboot in 15 seconds - press a key on the console to abort Mar 6 18:46:27 cantina /kernel: Rebooting... ftp://ftp.clinet.fi/pub/FreeBSD/cantina/*.1.gz >How-To-Repeat: mount /m/katiska/local /m/katiska/local where /m/katiska/local is a directory (intended mount point, "machine:" was missing). >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Mar 6 18:30:09 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA02971 for bugs-outgoing; Wed, 6 Mar 1996 18:30:09 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA02936 Wed, 6 Mar 1996 18:30:05 -0800 (PST) Date: Wed, 6 Mar 1996 18:30:05 -0800 (PST) Message-Id: <199603070230.SAA02936@freefall.freebsd.org> To: freebsd-bugs Cc: From: asami@cs.berkeley.edu (Satoshi Asami) Subject: Re: ports/1060: xrisk port did not correctly set permis for binary on install Reply-To: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-bugs@FreeBSD.ORG Precedence: bulk The following reply was made to PR ports/1060; it has been noted by GNATS. From: asami@cs.berkeley.edu (Satoshi Asami) To: FreeBSD-gnats-submit@freefall.freebsd.org, samorosh@marmot.cs.ucdavis.edu Cc: Subject: Re: ports/1060: xrisk port did not correctly set permis for binary on install Date: Wed, 6 Mar 1996 18:22:30 -0800 * see synopsis that is it, perms were set to 700 instead of 755 for the * xrisk binary after it had been installed in /usr/X11R6/bin * * * >How-To-Repeat: * * presumably, # make * # make install * # ls -l /usr/X11R6/bin/xrisk I tried this here, and it works fine. Looking at the compile/install log, it is using "cp" to install the executable. Maybe your umask is set to 077 or something? Satoshi From owner-freebsd-bugs Wed Mar 6 18:59:57 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA09984 for bugs-outgoing; Wed, 6 Mar 1996 18:59:57 -0800 (PST) Received: (from asami@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA09951 Wed, 6 Mar 1996 18:59:55 -0800 (PST) Date: Wed, 6 Mar 1996 18:59:55 -0800 (PST) From: Satoshi Asami Message-Id: <199603070259.SAA09951@freefall.freebsd.org> To: samorosh@marmot.cs.ucdavis.edu, asami, freebsd-bugs Subject: Re: ports/1060 Sender: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: xrisk port did not correctly set permis for binary on install State-Changed-From-To: open-closed State-Changed-By: asami State-Changed-When: Wed Mar 6 18:59:02 PST 1996 State-Changed-Why: Changed "cp" to "install -c -m 555" so that user's umask won't matter. From owner-freebsd-bugs Thu Mar 7 00:01:22 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA16454 for bugs-outgoing; Thu, 7 Mar 1996 00:01:22 -0800 (PST) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA16430 Thu, 7 Mar 1996 00:01:13 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <25321-0@bunyip.cc.uq.oz.au>; Thu, 7 Mar 1996 18:00:48 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA07330; Thu, 7 Mar 1996 17:18:15 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA09603; Thu, 7 Mar 1996 07:21:56 GMT Message-Id: <199603070721.HAA09603@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: bugs@freebsd.org, current@freebsd.org Subject: ffs_valloc: dup alloc X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 1996 17:21:55 +1000 From: Stephen Hocking Sender: owner-bugs@freebsd.org Precedence: bulk I've seen a bunch of panics on a couple of machine from kernels built just recently (6th Mar, 7th Mar). They varied in size from 8Mb to 16Mb. The panics occur at _ffs_valloc(efbffdc4,0,efbffe30,efbfff0c,efbffdb8) at _ffs_valloc+0x133 called from _ufs_makeinode. I'd tell you more except that the machine died as I was typing in the details from the other one's crash! Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-bugs Thu Mar 7 00:01:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA16487 for bugs-outgoing; Thu, 7 Mar 1996 00:01:39 -0800 (PST) Received: from bunyip.cc.uq.oz.au (pp@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA16445 Thu, 7 Mar 1996 00:01:19 -0800 (PST) Received: from bunyip.cc.uq.oz.au by bunyip.cc.uq.oz.au id <25329-0@bunyip.cc.uq.oz.au>; Thu, 7 Mar 1996 18:00:55 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id RAA07787; Thu, 7 Mar 1996 17:55:00 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id HAA10277; Thu, 7 Mar 1996 07:58:40 GMT Message-Id: <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6.5 12/11/95 To: bugs@freebsd.org, current@freebsd.org Subject: Re: ufs_valloc: dup whatever X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 1996 17:58:39 +1000 From: Stephen Hocking Sender: owner-bugs@freebsd.org Precedence: bulk Just noticed something really curious - I was running two makes at once, and somehow the output of one compilation (an assembler file of all things) appeared in the middle of a .depend file of a make depend! Help! Terry, John & David, what's going on? Stephen -- I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-bugs Thu Mar 7 01:32:18 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA22205 for bugs-outgoing; Thu, 7 Mar 1996 01:32:18 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA22199 for ; Thu, 7 Mar 1996 01:32:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id BAA26745; Thu, 7 Mar 1996 01:32:03 -0800 Message-Id: <199603070932.BAA26745@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: Stephen Hocking cc: bugs@freebsd.org Subject: Re: ufs_valloc: dup whatever In-reply-to: Your message of "Thu, 07 Mar 1996 17:58:39 +1000." <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 07 Mar 1996 01:32:03 -0800 Sender: owner-bugs@freebsd.org Precedence: bulk >Just noticed something really curious - I was running two makes at once, and >somehow the output of one compilation (an assembler file of all things) >appeared in the middle of a .depend file of a make depend! Help! Terry, John & >David, what's going on? It sounds like you have some filesystem corruption. What kind of disk controller are you using in the machine? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Thu Mar 7 01:39:09 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA22568 for bugs-outgoing; Thu, 7 Mar 1996 01:39:09 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA22548 Thu, 7 Mar 1996 01:39:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id BAA00383; Thu, 7 Mar 1996 01:38:08 -0800 (PST) To: Stephen Hocking cc: bugs@freebsd.org, current@freebsd.org Subject: Re: ufs_valloc: dup whatever In-reply-to: Your message of "Thu, 07 Mar 1996 17:58:39 +1000." <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> Date: Thu, 07 Mar 1996 01:38:08 -0800 Message-ID: <381.826191488@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-bugs@freebsd.org Precedence: bulk > appeared in the middle of a .depend file of a make depend! Help! Terry, John & > David, what's going on? Now you've done it - you've evoked the names of Terry, John and David in the same sentence. I trust you didn't actually want a reply? :-) [Yes, Yes, I'm _just kidding_! :-)] Jordan From owner-freebsd-bugs Thu Mar 7 12:08:11 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA04653 for bugs-outgoing; Thu, 7 Mar 1996 12:08:11 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA04611 Thu, 7 Mar 1996 12:08:03 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA14613; Thu, 7 Mar 1996 13:04:36 -0700 From: Terry Lambert Message-Id: <199603072004.NAA14613@phaeton.artisoft.com> Subject: Re: ufs_valloc: dup whatever To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Thu, 7 Mar 1996 13:04:36 -0700 (MST) Cc: bugs@FreeBSD.org, current@FreeBSD.org In-Reply-To: <199603070758.HAA10277@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Mar 7, 96 05:58:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.org Precedence: bulk > Just noticed something really curious - I was running two makes at once, and > somehow the output of one compilation (an assembler file of all things) > appeared in the middle of a .depend file of a make depend! Help! Terry, John & > David, what's going on? At a guess, I'd say Bruce was the best one to ask. It looks like the VREF/vrele code on the directory traversal has caused a vnode with a non-zero reference count to get onto the free list. I can't say I didn't expect this. It looks like the new pager code being more agressive in recovery is what revealed the traversal race condition. These are just guesses... unfortunately, I can't do anything about any of this, except to recommend going back to a checked out tree of the 1st or 2nd at the latest and waiting for it to be fixed. This is obviously related to your other posting in this thread. Rather than posting each additional problem as you see it, you should work with Bruce, David, and John on resolving the problem using your system as a test bed. I think that otherwise the cascade factor will cause you to post 10 or more problems all related to the same two codependent code changes; the symptoms you've reported so far should be sufficient to resolve the problem. PS: Is it possible that you are running with my "free vnode isn't" kludge fix? I believe this will interact badly with the VREF/vrele changes... if you are, you should remove my kludge, and get around the problem by cranking up numvnodes where the calculation takes place to set it up in the first place ("numvnodes *= 3;" or something similar). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Fri Mar 8 03:38:32 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA03724 for bugs-outgoing; Fri, 8 Mar 1996 03:38:32 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA03716 for ; Fri, 8 Mar 1996 03:38:23 -0800 (PST) Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id DAA00564; Fri, 8 Mar 1996 03:38:10 -0800 Date: Fri, 8 Mar 1996 03:38:10 -0800 From: Matthew Dillon Message-Id: <199603081138.DAA00564@apollo.backplane.com> To: bugs@freebsd.org Subject: bug in netinet/tcp_input.c Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk This is a non-fatal bug that nevertheless defeats all of the recvpipe/sendpipe/mtu stuff in the routing tables. Specifically, the tcp_mssopt() procedure fails to use the rt->rt_rmx.rmx_mtu information when calculating the maximum segment size for outgoing connections. This results in the remote end sending us packets larger then we intend, messing up any fine tuning we tried to do with the route recvpipe/sendpipe/mtu. In anycase, the fix is simple. Here's a new tcp_mssopt() routine: int tcp_mssopt(tp) struct tcpcb *tp; { struct rtentry *rt; int mss; rt = tcp_rtlookup(tp->t_inpcb); if (rt == NULL) return tcp_mssdflt; mss = rt->rt_ifp->if_mtu; if (rt->rt_rmx.rmx_mtu) mss = min(mss, rt->rt_rmx.rmx_mtu); mss -= sizeof(struct tcpiphdr); if (mss < 20) mss = 20; return(mss); } Enjoy! -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From owner-freebsd-bugs Fri Mar 8 04:41:36 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA10746 for bugs-outgoing; Fri, 8 Mar 1996 04:41:36 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA10741 Fri, 8 Mar 1996 04:41:34 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id EAA24709 ; Fri, 8 Mar 1996 04:41:33 -0800 Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id EAA00927; Fri, 8 Mar 1996 04:41:38 -0800 Message-Id: <199603081241.EAA00927@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: Matthew Dillon cc: bugs@freebsd.org, wollman@freebsd.org, olah@freebsd.org Subject: Re: bug in netinet/tcp_input.c In-reply-to: Your message of "Fri, 08 Mar 1996 03:38:10 PST." <199603081138.DAA00564@apollo.backplane.com> From: David Greenman Reply-To: davidg@Root.COM Date: Fri, 08 Mar 1996 04:41:37 -0800 Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk > This is a non-fatal bug that nevertheless defeats all of the > recvpipe/sendpipe/mtu stuff in the routing tables. > > Specifically, the tcp_mssopt() procedure fails to use the > rt->rt_rmx.rmx_mtu information when calculating the maximum > segment size for outgoing connections. This results in the > remote end sending us packets larger then we intend, messing > up any fine tuning we tried to do with the route recvpipe/sendpipe/mtu. > > In anycase, the fix is simple. Here's a new tcp_mssopt() routine: I'll pass this along, but my understanding is that the code was changed to the way it is in order for Path MTU Discovery to work correctly with asymetric routes (all too common in the Internet today). The change was made on Oct 13th of last year: ---------------------------- revision 1.30 date: 1995/10/13 16:00:25; author: wollman; state: Exp; lines: +1 -7 Routes can be asymmetric. Always offer to /accept/ an MSS of up to the capacity of the link, even if the route's MTU indicates that we cannot send that much in their direction. (This might actually make it possible to test Path MTU discovery in a useful variety of cases.) -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-bugs Fri Mar 8 11:20:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA07037 for bugs-outgoing; Fri, 8 Mar 1996 11:20:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA07026 Fri, 8 Mar 1996 11:20:03 -0800 (PST) Resent-Date: Fri, 8 Mar 1996 11:20:03 -0800 (PST) Resent-Message-Id: <199603081920.LAA07026@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, mi@ALDAN.algebra.com Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA06519 for ; Fri, 8 Mar 1996 11:16:09 -0800 (PST) Received: from aldan (PPP-84-6.BU.EDU [128.197.8.122]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id JAA27910 for ; Fri, 8 Mar 1996 09:53:01 -0800 Received: (from mi@localhost) by aldan (8.6.12/8.6.12) id MAA16865; Fri, 8 Mar 1996 12:53:13 -0500 Message-Id: <199603081753.MAA16865@aldan> Date: Fri, 8 Mar 1996 12:53:13 -0500 From: mi@ALDAN.algebra.com Reply-To: mi@ALDAN.algebra.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/1068: man ignores -P option when combined with -k Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1068 >Category: bin >Synopsis: man ignores -P option when combined with -k >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Mar 8 11:20:01 PST 1996 >Last-Modified: >Originator: Mikhail Teterin >Organization: >Release: FreeBSD 2.1-STABLE i386 >Environment: No PAGER environment variable set. >Description: When asked for a specific PAGER on command-line with -P option man uses the pager properly. However, when asked for -k (apropos) man executes /usr/bin/apropos -- a shell script, which only checks for PAGER variable in the environment, but does not accept the -P option. So man -P -k is always outputed through more -s (or your $PAGER). >How-To-Repeat: man -P less -k man suspend with ^Z ps -ww >Fix: Set the $PAGER will work around. /usr/bin/apropos needs a fix, IMHO. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Mar 8 12:36:39 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA10799 for bugs-outgoing; Fri, 8 Mar 1996 12:36:39 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA10793 for ; Fri, 8 Mar 1996 12:36:30 -0800 (PST) Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id MAA02429; Fri, 8 Mar 1996 12:36:15 -0800 Date: Fri, 8 Mar 1996 12:36:15 -0800 From: Matthew Dillon Message-Id: <199603082036.MAA02429@apollo.backplane.com> To: "Garrett A. Wollman" Cc: bugs@freebsd.org Subject: Re: bug in netinet/tcp_input.c Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk :> If you do not *use* that field when calculating :> the mss you send to the other side for outgoing connections, what :> use is it? : :You use it to keep track of the MTU along the path from your host to :the other end. The purpose is to avoid fragmentation, not to allow :users to play games with maximum segment size. : :> For example, if you attempt to streamline TCP operation to a given :> destination by, say, setting the mtu to 296 and setting the recvpipe :> and sendpipe to, say, 768, the expected result only works in one :> direction... : :Which is precisely as it is intended. If you want to control the size :of packets sent by the other end, you have to control the other end! :That's the way TCP is designed to work. If you don't like it, design :your own protocol. Hmmm. Then what is the use of -recvpipe and -sendpipe ? It seems ridiculous to not give one the ability to adjust the remote MSS for a tcp connection. If the path mtu is being stored in the mtu field, perhaps what is needed is a new field to specify the maximum advertised mss. Without being able to do that, -recvpipe and -sendpipe are useless parameters for tuning purposes, and only being able to set the mss for our end asymetrically is even worse then useless. It's sooo close to doing something real, stop using 'the way TCP is designed to work' as an excuse! -Matt :-GAWollman : :-- :Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... :wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. :Opinions not those of| It is a bond more powerful than absence. We like people :MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant : Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From owner-freebsd-bugs Fri Mar 8 12:50:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA11612 for bugs-outgoing; Fri, 8 Mar 1996 12:50:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA11601 Fri, 8 Mar 1996 12:50:03 -0800 (PST) Resent-Date: Fri, 8 Mar 1996 12:50:03 -0800 (PST) Resent-Message-Id: <199603082050.MAA11601@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, mi@ALDAN.algebra.com Received: from aldan (PPP-84-6.BU.EDU [128.197.8.122]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA11229 for ; Fri, 8 Mar 1996 12:44:04 -0800 (PST) Received: (from root@localhost) by aldan (8.6.12/8.6.12) id PAA17381; Fri, 8 Mar 1996 15:44:46 -0500 Message-Id: <199603082044.PAA17381@aldan> Date: Fri, 8 Mar 1996 15:44:46 -0500 From: mi@ALDAN.algebra.com Reply-To: mi@ALDAN.algebra.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: ports/1069: TkMan acts erroneusly on apropos Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1069 >Category: ports >Synopsis: TkMan acts erroneusly on apropos >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Mar 8 12:50:02 PST 1996 >Last-Modified: >Originator: Mikhail Teterin >Organization: >Release: FreeBSD 2.1-STABLE i386 >Environment: TkMan-1.7.5 (NOT the one in ports -- newer version. All the patches applied, though. Only one of them had to be applied manually) >Description: For whatever reason, man -k returns 1, which causes TkMan to think the child process terminated abnormally and display total number of hits as 0. This may well be a man's bug (see my problem report bin/1068 for some more on this), I'm not sure. >How-To-Repeat: mi@aldan:xcoral/work/xcoral-2.5 (1061) man -k less jpegtran(1) - lossless transcoding of JPEG files less(1) - opposite of more lesskey(1) - specify key bindings for less clnp(4) - Connectionless-Mode Network Protocol cltp(4) - ISO Connectionless Transport Protocol mi@aldan:xcoral/work/xcoral-2.5 (1062) echo $status 1 If tkman is asked for less-apropos, it will display the same list and say "child process terminated abnormally", 0 matches. >Fix: alias man (man || true) ? >Audit-Trail: >Unformatted: From owner-freebsd-bugs Fri Mar 8 13:05:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA12931 for bugs-outgoing; Fri, 8 Mar 1996 13:05:04 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA12921 for ; Fri, 8 Mar 1996 13:05:00 -0800 (PST) Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA17181; Fri, 8 Mar 1996 16:04:16 -0500 Date: Fri, 8 Mar 1996 16:04:16 -0500 From: "Garrett A. Wollman" Message-Id: <9603082104.AA17181@halloran-eldar.lcs.mit.edu> To: Matthew Dillon Cc: bugs@freebsd.org Subject: Re: bug in netinet/tcp_input.c In-Reply-To: <199603082036.MAA02429@apollo.backplane.com> References: <199603082036.MAA02429@apollo.backplane.com> Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk < said: > Hmmm. Then what is the use of -recvpipe and -sendpipe ? As I said before, they are to set the default buffer size. Anything more complicated than that voids your warranty... -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Fri Mar 8 13:16:34 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA13507 for bugs-outgoing; Fri, 8 Mar 1996 13:16:34 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA13498 for ; Fri, 8 Mar 1996 13:16:31 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id LAA29757 for ; Fri, 8 Mar 1996 11:48:57 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA13903; Fri, 8 Mar 1996 14:48:37 -0500 Date: Fri, 8 Mar 1996 14:48:37 -0500 From: "Garrett A. Wollman" Message-Id: <9603081948.AA13903@halloran-eldar.lcs.mit.edu> To: Matthew Dillon Cc: bugs@FreeBSD.ORG Subject: Re: bug in netinet/tcp_input.c In-Reply-To: <199603081932.LAA02322@apollo.backplane.com> References: <199603081932.LAA02322@apollo.backplane.com> Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk < said: > The whole point of the 'mtu' field in the route entry, as I understand > it, is to limit the maximum segment size for TCP connections from *and* > TO the destination. You understand wrongly. > If you do not *use* that field when calculating > the mss you send to the other side for outgoing connections, what > use is it? You use it to keep track of the MTU along the path from your host to the other end. The purpose is to avoid fragmentation, not to allow users to play games with maximum segment size. > For example, if you attempt to streamline TCP operation to a given > destination by, say, setting the mtu to 296 and setting the recvpipe > and sendpipe to, say, 768, the expected result only works in one > direction... Which is precisely as it is intended. If you want to control the size of packets sent by the other end, you have to control the other end! That's the way TCP is designed to work. If you don't like it, design your own protocol. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Fri Mar 8 13:16:55 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA13568 for bugs-outgoing; Fri, 8 Mar 1996 13:16:55 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA13540 for ; Fri, 8 Mar 1996 13:16:48 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA29563 for ; Fri, 8 Mar 1996 11:33:05 -0800 Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id LAA02322; Fri, 8 Mar 1996 11:32:48 -0800 Date: Fri, 8 Mar 1996 11:32:48 -0800 From: Matthew Dillon Message-Id: <199603081932.LAA02322@apollo.backplane.com> To: "Garrett A. Wollman" Cc: bugs@FreeBSD.ORG Subject: Re: bug in netinet/tcp_input.c Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk : :As you can see, the MSS option that we send is not supposed to be :related to the Path MTU for packets that we are sending; after all, :the MSS option is about what THEY send back TO US, and their path back :to us is often different. We really should take the maximum over all :interfaces as suggested in the RFC, but I didn't get around to doing :that. : :RFC 1191 goes on to say: : : Note: At the moment, we see no reason to send an MSS greater : than the maximum MTU of the connected networks, and we : recommend that hosts do not use 65495. It is quite possible : that some IP implementations have sign-bit bugs that would be : tickled by unnecessary use of such a large MSS. : :In other words, the current implementation is operating according to :specification. : :-GAWollman : :-- :Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... :wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. :Opinions not those of| It is a bond more powerful than absence. We like people :MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant This may be true, but it makes all those new route table fields completely useless because they wind up being operated asymetrically. The whole point of the 'mtu' field in the route entry, as I understand it, is to limit the maximum segment size for TCP connections from *and* TO the destination. If you do not *use* that field when calculating the mss you send to the other side for outgoing connections, what use is it? For example, if you attempt to streamline TCP operation to a given destination by, say, setting the mtu to 296 and setting the recvpipe and sendpipe to, say, 768, the expected result only works in one direction... you get the desired effect for data you send, but not for data you receive. Since reception of data causes greater buffering and latency problems then transmission, especially over SLIP and PPP links, not setting the advertised mss based on the route table entry basically breaks the whole mechanism and makes it useless for any kind of tuning whatsoever. You might as well remove the -sendpipe, -recvpipe, and -mtu options entirely. -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From owner-freebsd-bugs Fri Mar 8 13:23:12 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA14061 for bugs-outgoing; Fri, 8 Mar 1996 13:23:12 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA14043 for ; Fri, 8 Mar 1996 13:23:03 -0800 (PST) Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id NAA02648; Fri, 8 Mar 1996 13:22:48 -0800 Date: Fri, 8 Mar 1996 13:22:48 -0800 From: Matthew Dillon Message-Id: <199603082122.NAA02648@apollo.backplane.com> To: "Garrett A. Wollman" Cc: bugs@freebsd.org Subject: Re: bug in netinet/tcp_input.c Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk :< said: : :> Hmmm. Then what is the use of -recvpipe and -sendpipe ? : :As I said before, they are to set the default buffer size. Anything :more complicated than that voids your warranty... : :-GAWollman : :-- :Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... :wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. :Opinions not those of| It is a bond more powerful than absence. We like people :MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant Is this supposed to be funny? Look, you guys are already using locked route table fields for minimum and maximum limits, it can't hurt to use the same mechanism for the mtu field as well, as a 'maximum'. Regarding -recvpipe and -sendpipe... sure, if you want to leave those route table fields braindamaged, I suppose you can just be cute and forget about it. Personally, it doesn't increase my respect for the FreeBSD core team when the best answer they can give is a wise crack. I would rather see these fields be put to good rather then made useless. -- Also, tp->t_srtt is not being calculated correctly... I just ran some tcp echo tests and it's nearly four times what it's supposed to be. It gets it right sometimes, but a single lost packet out of 30 destroys the smoothing function for some reason. I haven't traced it down yet. -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From owner-freebsd-bugs Fri Mar 8 15:16:02 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20612 for bugs-outgoing; Fri, 8 Mar 1996 15:16:02 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20570 for ; Fri, 8 Mar 1996 15:15:57 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA02243 for ; Fri, 8 Mar 1996 14:27:44 -0800 Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id OAA00287; Fri, 8 Mar 1996 14:27:38 -0800 Date: Fri, 8 Mar 1996 14:27:38 -0800 From: Matthew Dillon Message-Id: <199603082227.OAA00287@apollo.backplane.com> To: bugs@FreeBSD.ORG Subject: the t_rttvar calculation also has a bug. Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk I should have followed through and fixed t_rttvar as well as t_rtt. t_rttvar has the same problem t_rtt does. I believe it can be fixed by subtracting one more from delta before adding it to t_rttvar around line 1852 of tcp_input.c. -Matt From owner-freebsd-bugs Fri Mar 8 15:16:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20655 for bugs-outgoing; Fri, 8 Mar 1996 15:16:06 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20602 for ; Fri, 8 Mar 1996 15:16:00 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA02104 for ; Fri, 8 Mar 1996 14:21:59 -0800 Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id OAA00262; Fri, 8 Mar 1996 14:21:44 -0800 Date: Fri, 8 Mar 1996 14:21:44 -0800 From: Matthew Dillon Message-Id: <199603082221.OAA00262@apollo.backplane.com> To: "Garrett A. Wollman" Cc: bugs@FreeBSD.ORG Subject: Re: bug in netinet/tcp_input.c Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk :< said: : :> Hmmm. Then what is the use of -recvpipe and -sendpipe ? : :As I said before, they are to set the default buffer size. Anything :more complicated than that voids your warranty... : :-GAWollman : :-- :Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... :wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. :Opinions not those of| It is a bond more powerful than absence. We like people :MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant I guess you people aren't aware of the tricks many people play at all levels to utilize their bandwidth better. I'll describe two of them: (1) T1 connected host - 1.5 Mbps (2) frame connected host - 128K frame (3) modem connected host - 28.8 / telecommuting and serving ftp/www In all cases, the host is often dealing with SMTP, FTP, news feeds, and so on, yet must also support one or more users.. in the case of a small frame connected ISP, perhaps a dozen or two online users. It is possible to use the route table to adjust recvpipe and sendpipe buffer sizes on a per destination basis (and mss as well if you fix your code). Why would one want to do this? Simple: In order to be able to run SMTP, FTP, newsfeeds, and other services without impacting your users. You can set up the route table to automatically use a smaller mss and smaller buffer size (reducing pipelining and thus reducing buffering problems for incoming packets). The only alternative is to hack sendmail, hack ftp, hack apache, hack news, and hack the umpteen other programs to do a socket opt to reduce the buffer size, and even that does not work with the MSS negotiation for incoming connections. What does this give you? This allows you to saturate your link without degrading interactive performance over the same link. Now, unless everyone and his mother has a personal T3, being able to adjust the mss and receive and send pipes on an individual basis is an incredibly powerful tool for reaching that state. Stop thinking small... think BIG! Turn those braindead features into something more useful. -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From owner-freebsd-bugs Fri Mar 8 15:16:31 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20852 for bugs-outgoing; Fri, 8 Mar 1996 15:16:31 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20815 for ; Fri, 8 Mar 1996 15:16:26 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [204.156.134.254]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id OAA01880 for ; Fri, 8 Mar 1996 14:14:34 -0800 Received: (dillon@localhost) by apollo.backplane.com (8.6.12/8.6.5) id OAA00252; Fri, 8 Mar 1996 14:14:11 -0800 Date: Fri, 8 Mar 1996 14:14:11 -0800 From: Matthew Dillon Message-Id: <199603082214.OAA00252@apollo.backplane.com> To: bugs@FreeBSD.ORG Cc: "Garrett A. Wollman" Subject: srtt calculation bug .. found Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk ok, I've found the bug with t_srtt ... the problem is mainly due to the lack of resolution to SLOWHZ (which is only 500ms). That coupled with the following: delta = rtt - 1 - (tp->t_srtt >> TCP_RTT_SHIFT); if ((tp->t_srtt += delta) <= 0) tp->t_srtt = 1; The above equation breaks down statistically for < 500 ms RTT's. You would think that if the rtt variable is 1 half the time and 2 half the time, that srtt should wind up at around 4 (200 ms). Unfortunately, that does not occur because this line: delta = rtt - 1 - (tp->t_srtt >> TCP_RTT_SHIFT); Fails to generate a negative number in the case where 'rtt' is 1 (i.e. delta time is 0 at a 500ms resolution). However, it DOES generate a positive number if rtt is 2. The (tp->t_srtt >> TCP_RTT_SHIFT) also fails to generate a negative number until t_srtt reaches 8, but by that time it's too late.. you effectively get a random number depending on when you sample rather then the rtt. Even if you round tp->t_srtt up by 1/2 (a value of 4), it still breaks down statistically. The proper solution is to balance the weighting of an rtt of 1 and an rtt of 2 (i.e. a delta time of 0 and a delta time of 1).... give the delta time of 0 a -1 value to match the delta time of 1, as follows: delta = rtt - 1 - (tp->t_srtt >> TCP_RTT_SHIFT); if (delta == 0) /* ADD ME */ delta = -1; /* ADD ME */ if ((tp->t_srtt += delta) <= 0) tp->t_srtt = 1; Now you have a reasonably balanced weighting and the statistical calculation no longer breaks down for round trip times < 500ms. There is one other problem, and that is where you update the route table rtt when t_rttupdated >= 16. 16 may not be a high enough number to handle round trip times < 10 ms with a 500 ms timer resolution. The solution is to either increase the timer resolution or to increase rttupdated... though obviously there are practical limits to how large rttupdated can be and still work. -- I have tested this on a slip link, and the route table entries come up with the correct round trip time with the fix in, and the completely incorrect round trip time without the fix. -Matt Matthew Dillon Engineering, BEST Internet Communications, Inc. [always include a portion of the original email in any response!] From owner-freebsd-bugs Fri Mar 8 15:17:07 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA21087 for bugs-outgoing; Fri, 8 Mar 1996 15:17:07 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA21061 for ; Fri, 8 Mar 1996 15:17:03 -0800 (PST) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id IAA27132 for ; Fri, 8 Mar 1996 08:52:03 -0800 Received: by halloran-eldar.lcs.mit.edu; (5.65/1.1.8.2/19Aug95-0530PM) id AA12660; Fri, 8 Mar 1996 11:51:23 -0500 Date: Fri, 8 Mar 1996 11:51:23 -0500 From: "Garrett A. Wollman" Message-Id: <9603081651.AA12660@halloran-eldar.lcs.mit.edu> To: Matthew Dillon Cc: bugs@FreeBSD.ORG Subject: bug in netinet/tcp_input.c In-Reply-To: <199603081138.DAA00564@apollo.backplane.com> References: <199603081138.DAA00564@apollo.backplane.com> Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk < said: > This is a non-fatal bug that nevertheless defeats all of the > recvpipe/sendpipe/mtu stuff in the routing tables. The recvpipe/sendpipe stuff is mis-named. It is really recvbuf/sendbuf. If it really did indicate a pipe size, socket buffers would end up being huge. > Specifically, the tcp_mssopt() procedure fails to use the > rt-> rt_rmx.rmx_mtu information when calculating the maximum > segment size for outgoing connections. Quoth RFC 1191: The MSS option should be 40 octets less than the size of the largest datagram the host is able to reassemble (MMS_R, as defined in [1]); in many cases, this will be the architectural limit of 65495 (65535 - 40) octets. A host MAY send an MSS value derived from the MTU of its connected network (the maximum MTU over its connected networks, for a multi-homed host); this should not cause problems for PMTU Discovery, and may dissuade a broken peer from sending enormous datagrams. As you can see, the MSS option that we send is not supposed to be related to the Path MTU for packets that we are sending; after all, the MSS option is about what THEY send back TO US, and their path back to us is often different. We really should take the maximum over all interfaces as suggested in the RFC, but I didn't get around to doing that. RFC 1191 goes on to say: Note: At the moment, we see no reason to send an MSS greater than the maximum MTU of the connected networks, and we recommend that hosts do not use 65495. It is quite possible that some IP implementations have sign-bit bugs that would be tickled by unnecessary use of such a large MSS. In other words, the current implementation is operating according to specification. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant From owner-freebsd-bugs Sat Mar 9 04:30:17 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA16827 for bugs-outgoing; Sat, 9 Mar 1996 04:30:17 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA16813 for freebsd-bugs; Sat, 9 Mar 1996 04:30:16 -0800 (PST) Date: Sat, 9 Mar 1996 04:30:16 -0800 (PST) From: GNU GNATS Message-Id: <199603091230.EAA16813@freefall.freebsd.org> To: freebsd-bugs Subject: Summary of Problem Reports Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk Number of currently open reports: 279 Number of curently analyzed reports: 15 From owner-freebsd-bugs Sat Mar 9 04:30:19 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA16838 for bugs-outgoing; Sat, 9 Mar 1996 04:30:19 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA16810 for freebsd-bugs; Sat, 9 Mar 1996 04:30:15 -0800 (PST) Date: Sat, 9 Mar 1996 04:30:15 -0800 (PST) From: GNU GNATS Message-Id: <199603091230.EAA16810@freefall.freebsd.org> To: freebsd-bugs Subject: List of open Problem Reports Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk This is the list of currently open problem reports [1994/11/18] conf/22 Cannot use links to share kernel objects [1994/11/30] kern/34 nullfs and union mounts can result in wild pointer r [1995/01/10] bin/104 pax -rwl may corrupt filesystem [1995/01/14] bin/115 systat iostat display doesn't scale high enough [1995/01/14] bin/116 disk transfer rates reported by systat :iostat are t [1995/01/14] bin/124 traceroute doesn't support -g flag. [1995/01/14] bin/129 fsck cannot take a mount point as an argument [1995/01/14] bin/133 mail program doesn't have editheaders option [1995/01/15] bin/146 version of compress is kinda old and slow [1995/01/20] bin/153 mount -u improvement for diskless systems [1995/01/21] misc/166 /usr/include/machine/asmacros.h includes uninstalled [1995/01/21] bin/172 cp -f does not work [1995/01/21] bin/173 rc trys to mount modload fs before ld is available. [1995/01/21] bin/174 Poor error message from stty [1995/01/22] kern/176 EIDRM not defined in errno.h [1995/01/24] gnu/183 can't resolve "operator <<" overload [1995/01/24] bin/184 send-pr says "Aborting ..." and happily removes the [1995/01/30] gnu/196 size of bss in *.o's reported wrong by size [1995/01/30] bin/198 1.1.5.1 pine binary loops; top shows fancy values [1995/02/01] bin/199 quiz(6) reading database bug, pattern matching bug [1995/02/14] kern/216 /kernel: panic: ffs_alloccg: map corrupted [1995/02/16] kern/219 Performance on local net drops too much when SNDBUF [1995/03/02] misc/229 acos() core dump [1995/03/17] kern/247 Berkeley Packet Filter fix [1995/03/28] kern/275 qic-02 streamer won't work [1995/03/28] kern/281 Messages printed when checking CD ROM device too ver [1995/03/28] kern/282 buslogic adapter information WAY too verbose [1995/04/01] kern/291 PCI devices still probe/attach after being disabled [1995/04/09] bin/323 Creating lost+found causes fsck to stop fsck -y FDIV [1995/04/09] bin/326 Weekly cron generates some usage and error messages [1995/04/09] bin/329 FTP transfers above 99K shown in scientific notation [1995/04/15] kern/345 panic "biodone: page busy < 0" [1995/04/17] kern/349 Panic with bad dir [1995/04/20] kern/353 xcdplayer crashes machine (with NCR810 SCSI) [1995/04/20] misc/355 policy on /usr/local permission in base release [1995/04/20] bin/357 pkg_delete aborts when subcommand fails [1995/05/01] gnu/373 In response to admittedly bogus code, gcc emits an o [1995/05/01] kern/374 panic: bad dir [1995/05/08] bin/389 Simultaneous creation/deletion of dirs corrupts file [1995/05/12] bin/398 VI doesnt do the correct thing [1995/05/13] bin/401 Add REMOTE_* variables [1995/05/13] bin/402 w -n shows non-numeric addresses [1995/05/13] misc/403 FreeBSD 1-compiled tcsh, bash and zsh binaries dump [1995/05/14] kern/405 The gpio driver does not work with the AT-GPIB, only [1995/05/14] kern/416 page fault in syscons.c:scopen() [1995/05/14] bin/419 pkg_delete refuses to delete an incompletely added p [1995/05/15] misc/423 Sound devices are too insecure [1995/05/16] kern/425 arp entries not getting removed when interface chang [1995/05/16] kern/427 eg doesn't work with more than one card [1995/05/16] kern/428 configure is not foolproof [1995/05/22] kern/434 umapfs panics when mounting ufs over itself [1995/05/23] i386/440 want vidcontrol option to apply settings to all sysc [1995/05/25] kern/443 65 sendmails crashes system [1995/05/26] i386/444 GUS sound driver does not seem to work. [1995/05/26] kern/446 unable to diskless-boot a PC when the server mounts [1995/05/27] gnu/450 tar --exclude -c doesn't work [1995/05/28] gnu/451 cvsinit/cvs doesn't work as expected with perl [1995/05/29] bin/457 We may have an obscure csh bug [1995/05/30] docs/458 px doc does not find include figure [1995/05/31] kern/466 Unexpected disk errors with sector-mapping controlle [1995/06/01] misc/469 ctm leaves temp files after errors [1995/06/05] kern/492 sysinstall shows "success" after "no space" failure. [1995/06/14] bin/514 Crash recovery impossible without static mt/chflags. [1995/06/15] bin/517 Bad group change with 'install' [1995/06/15] bin/519 execution of quotacheck from /etc/rc fails [1995/06/17] kern/528 slow 386 reports excessive interrupt-level buffer ov [1995/06/18] misc/530 Failed install from SCSI tape [1995/06/20] docs/536 No copyrights in usr/src/lib/libc/stdtime [1995/06/20] bin/537 FSCK Fails [1995/06/26] kern/565 slip freezes machine [1995/07/02] kern/579 sio: RS_IBUFSIZE at 256 bytes serial lines loose dat [1995/07/04] kern/587 if_le hangs on OACTIVE with 2k buffer [1995/07/04] kern/588 Configuration of DEC ethernet cards not possible [1995/07/05] bin/591 SPAP request REJexted in stead of NAKed [1995/07/06] i386/596 and conflict with _POSIX_SOURCE [1995/07/07] bin/599 pkg_add does not stop if dependencies are missing [1995/07/09] misc/605 NIS: get*bynis routine problems [1995/07/13] kern/611 WIDE-dhcp doesn't work with FreeBSD-2.0 bpf [1995/07/21] i386/631 if_ix does not support bpf, nor does it appear to su [1995/07/29] kern/638 Transmitted packets not passed to bpf in if_le.c [1995/08/01] docs/646 vmstat man page out of date [1995/08/01] bin/648 printf format conversion incorrect (duplicate) [1995/08/02] gnu/650 Current flex is outdated [1995/08/03] kern/652 Multiple addresses on one interface interacts badly [1995/08/05] gnu/655 ld -r of shared objects worked in 1.1.5, not in 2.0. [1995/08/07] bin/658 ifconfig alias has to be separately given [1995/08/07] bin/661 Hercules is not capable of having a ISO-Latin1 Scree [1995/08/11] gnu/672 Nor all ph headers get created [1995/08/11] ports/673 /bin/sh + inn1.4 innwatch going belly up [1995/08/11] bin/675 make does unnecessary rebuilds [1995/08/12] kern/677 X gets a bus error when calling mmap() [1995/08/13] bin/680 2.0.5's tip using termios doesn't act the way it did [1995/08/14] bin/683 cron(8) [1995/08/14] kern/688 Page fault: supervisor write, page not present [1995/08/15] i386/692 My modem is not found if my external cache is disabl [1995/08/16] bin/693 `pkg_add' is umask-sensitive [1995/08/16] kern/695 cat B > C ; cmp B C can fail! [1995/08/17] misc/697 "make -DCLOBBER" is broken [1995/08/18] kern/700 The comments in /sys/net/in.h are confusing [1995/08/21] kern/703 ppp not always deleting route properly when a ppp li [1995/08/22] bin/706 increased root DNS traffic and long latencies for r- [1995/08/29] bin/715 ls gives weird tabular form [1995/08/31] bin/716 W returns wrong results at login [1995/09/01] misc/717 ft.c attach fail on my Mountain tape drive [1995/09/02] bin/718 pkg_add incorrectly prints an error message [1995/09/15] bin/722 Off-by-one error in wbkgd() in ncurses [1995/09/19] bin/728 /bin/sh messes up quoting when going through eval [1995/09/21] docs/731 socketpair(2) and man page inconsistent about return [1995/09/23] docs/735 missing description for mount options in fstab(5) ma [1995/09/25] gnu/737 FreeBSD-current/src/gnu/usr.bin/gzip/Makefile [1995/09/26] bin/739 Some problems when an output filter reads all input [1995/09/26] docs/741 netstat -rn not showing all routes in Kernel - not i [1995/09/26] kern/742 syslog errors accessing Mac hard disks [patch] [1995/09/27] bin/743 vi cannot edit a file where the name starts with + [1995/09/27] bin/747 date(1) gives weird time zones and interprets GMT[+- [1995/09/27] kern/750 cd9660 confused by not-ready or I/O errors FDIV030 [1995/09/28] bin/751 crontab(1): `crontab -e' exits on SIGINT [1995/09/28] kern/752 setting multiple addresses for a single interfaces l [1995/09/28] kern/753 my archive scsi tape drive does not work [1995/09/28] docs/754 there is no man page for the psm(4) mouse driver [1995/10/01] kern/757 Removal of mounted CD-ROM causes reboot & single use [1995/10/01] bin/759 nfsd without arg's doesn't work [1995/10/03] kern/765 umount -f can`t umount a NFS filesystem in use [1995/10/05] misc/767 Configure-time does time-warp on non-UTC CMOS - FDIV [1995/10/06] kern/770 Floppy kernel won't boot with T485 or IDT L2 cache F [1995/10/08] kern/772 page fault while in kernel mode (two cases) [1995/10/09] kern/774 dump fails with "slave couldn't reopen disk: Device [1995/10/11] bin/777 patch doesn't realize stdin is closed and asks quest [1995/10/12] bin/778 tar complains "EOF not on block boundary" on a good [1995/10/12] bin/779 #include gets undefined 'rune_t' type. [1995/10/14] kern/781 OPEN_MAX in kernel config and FD_SETSIZE in /usr/inc [1995/10/18] bin/786 Problem with NIS and large group maps [1995/10/23] bin/789 pkg_add doesn't work [1995/10/25] kern/792 cd9660 very slow. [1995/10/25] kern/793 ep0 cannot be configured and more. [1995/10/26] kern/794 swap partition at offset 0 still broken [1995/10/27] misc/796 Network install doesn't update /etc/hosts FDIV036 [1995/10/27] bin/797 X probeonly during install gets Not Found error FDIV [1995/10/29] kern/798 PPP panics, touches 0xdeadc0de pointers [1995/10/29] misc/799 sysinstall segfaults if part of distribution missing [1995/10/29] docs/801 rlogind k, v, and x options are not documented [1995/10/30] misc/802 default fstab mounts disks in bad order [1995/10/31] bin/803 bsd m4 chokes and dies while FSF m4 works... [1995/10/31] kern/806 kernel default parameters need tuning [1995/11/01] bin/809 `.' gives the minimum number of (DIGITS+SIGN) [1995/11/09] ports/814 unable to compile the port of "pine3.91" [1995/11/11] bin/815 mountd reports unknown hosts with non-informative me [1995/11/12] kern/820 scsi tape problems [1995/11/13] kern/821 Config doesn't properly trap signals [1995/11/16] bin/826 tcpmux listener in inetd does not work [1995/11/20] kern/830 installing hang [1995/11/20] kern/831 one minor complaint about the kernel visual config c [1995/11/21] i386/832 Tape drive busy errors - dump aborts [1995/11/21] i386/833 SCSI hard disks time out during tape rewind - FDIV03 [1995/11/22] kern/834 pcvt: console keyboard locks up randonly [1995/11/22] kern/835 ed panics with SMC ultra with iomem, if no iomem in [1995/11/24] misc/838 /usr/src/lib Makefile assumes you want to install... [1995/11/25] bin/839 by default, use of "at" is overly restricted [1995/11/27] bin/841 stale nfs mounts cannot be umounted [1995/11/27] kern/844 mbuf panic, dump available [1995/11/27] kern/845 Automatic reboot says you can abort but boots anyway [1995/11/27] conf/846 2.1R install disk tries to use sd0 even if not reque [1995/11/28] misc/848 Inst gripes about geometry but won't accept true val [1995/11/28] misc/849 Install skimps on inodes and newfs default is wrong [1995/11/28] bin/850 dump treats write-protect as an EOT & spoils set FDI [1995/11/29] bin/852 Sendmail is loosing mail (apparently)! [1995/11/30] bin/854 swapinfo shows incorrect information for vnconfig'd [1995/11/30] misc/856 Install 2.0.5 Upgrade option does too much damage FD [1995/11/30] ports/857 Need ANSI_C define to not declare some functions [1995/12/01] bin/859 /bin/sh -c does not ignore SIGINT [1995/12/02] kern/860 visual mode in kernel -c is too restrictive [1995/12/03] kern/861 sb16 support in 2.1 is erratic and has cosmetic defe [1995/12/03] kern/863 panic on kernel page fault, NULL curproc [1995/12/04] kern/866 pcvt causes system console to lock up [1995/12/04] i386/867 Notebook with APM and 3C589C in PCMCIA freezes after [1995/12/06] ports/869 xcdplayer installs itself is /usr/X11R6, not /usr/lo [1995/12/06] ports/871 port.subdir.mk DEBUG_FLAGS is not used for CFLAGS [1995/12/08] misc/875 Cleaned code using -Wall to remove warnings [1995/12/08] kern/876 NFS allows bogus accesses to cached data [1995/12/09] misc/882 Makefile is not smart enough to bypass libraries... [1995/12/09] ports/883 tclX-port does not build properly [1995/12/14] misc/893 terminfo.h not installed??? [1995/12/17] kern/900 ext2fs triggers divide by zero trap in vnode_pager_h [1995/12/18] kern/902 system becomes very sluggish, odd messages, odd vmst [1995/12/20] i386/906 /sys/i386/boot/netboot/nb8390.com cannot recognize N [1995/12/21] kern/907 scsi-dat tape station has stopped working [1995/12/21] bin/908 sed bug with trailing backslashes [1995/12/24] kern/912 unmount: dangling vnode [1995/12/24] conf/913 2.1.0-RELEASE, problem with cpio verbosity in instal [1995/12/25] bin/914 hayes dialer for tip fails 1st attempt to dial [1995/12/29] kern/919 weird output of vmstat, iostat, top [1995/12/29] kern/920 sio output looses chars in fifo on close() [1995/12/29] kern/921 getrusage() returns 0 after system up for a long tim [1995/12/31] kern/924 EISA devices have disappeared from vmstat/systat int [1996/01/01] bin/926 Mounting nfs disks before starting mountd: Chicken o [1996/01/02] kern/927 VGA mode not restored [1996/01/03] kern/930 sio/getty problem? [1996/01/06] kern/932 de0 occasionally enables 100baseTX when plugged into [1996/01/06] misc/934 ppp dies with Bus Error when processing long LOGIN s [1996/01/07] kern/938 after heavy disk I/O, processes sleep on "newbuf" in [1996/01/09] kern/940 panic: free vnode isn't [1996/01/12] misc/942 X11 mono server dumps core on supported video hardwa [1996/01/13] ports/944 Security fixes for Fvwm 1.24r [1996/01/15] kern/946 divide-by-zero in kernel on bad disk info [1996/01/16] kern/949 panic, undebugable dump? [1996/01/16] kern/950 Two PCI bridge chips fail (multiple multiport ethern [1996/01/17] kern/951 -current kernel crashes with devfs error on bootup [1996/01/19] ports/955 make CFLAGS=whatever for a port will not be honored [1996/01/19] kern/956 Kernel page fault, null callp [1996/01/19] bin/958 ttys file does not include all ptys [1996/01/20] i386/960 gameport enabling on ProAudio Spectrum isn't documen [1996/01/21] bin/961 'more $file', incorrect CRLF compacting. [1996/01/22] kern/962 panic on shutdown -- have crash dump [1996/01/23] ports/968 Netscape & cern_httpd ports out of date/dead links [1996/01/25] kern/971 Default limits for number of processes per user ridi [1996/01/25] conf/972 inetd.conf should comment out k-services if no Kerbe [1996/01/27] kern/974 ktrace causes panic: freeing busy page [1996/01/28] kern/975 getrusage returns negative deltas [1996/01/28] kern/976 NCR SCSI driver gives assertion errors and disk beco [1996/01/29] kern/977 system panic on sowakeup() [1996/01/29] kern/978 Three deadlocks in row [1996/01/29] kern/979 Linux programs using pipes crash system [1996/01/30] bin/981 clnt_broadcast() is not aware of aliases [1996/02/01] bin/986 problems make-ing with cd in the rule [1996/02/03] kern/989 devfs error messages on boot [1996/02/03] kern/991 pcvt keyboard doesn't accept input at crash reboot [1996/02/03] bin/993 g++ complains about /usr/include/machine/cpufunc.h [1996/02/04] kern/994 syscons bug in ESC[nX handling (w/fix) [1996/02/05] misc/995 /var/run/gated.pid is deleted [1996/02/06] kern/998 badness in file system silently crashes machine [1996/02/07] bin/999 /usr/share/mk/sys.mk missing common $(RM) macro [1996/02/07] docs/1000 miscellaneous man page bugs [1996/02/07] kern/1001 M_NAMEI malloc leak in the kernel [1996/02/08] ports/1005 netscape port is obsolete, mv netscape2 netscape [1996/02/08] kern/1008 Daily crash while writing network backups to local t [1996/02/09] kern/1012 vnode_pager_putpages: attempt to write meta-data!!! [1996/02/10] kern/1016 panic: vm_page_free: freeing free page, sddump: no s [1996/02/10] kern/1017 ssh stopped working between 15th Jan and 9th Feb [1996/02/12] kern/1018 panic: unwire: page not in pmap [1996/02/12] bin/1019 getty cannot detect ppp logins [1996/02/12] kern/1020 Boca 16-port board still hangs [1996/02/12] bin/1021 pppd doesn't handle PAP-only authentication well [1996/02/12] bin/1022 daily security report has too much junk in it [1996/02/12] docs/1023 using touch to create swap file for NFS doesn't work [1996/02/13] misc/1024 installation may delete partitions on existing boot [1996/02/14] kern/1026 deadlocks if parent vfork and child has cntrl termin [1996/02/14] kern/1027 panic on vm_map_insert [1996/02/14] bin/1028 shutdown -r does not seem to always complete [1996/02/15] bin/1029 cd behaves erraticly if cwd is a mount-point, which [1996/02/17] bin/1030 /bin/sh does not pass environment variables on prope [1996/02/18] kern/1034 Instant panic in -current [1996/02/19] bin/1035 ls to terminal always uses ? for non-printable chars [1996/02/19] docs/1036 List of dead xrefs in man pages [1996/02/19] bin/1037 2.x telnetd handles CTRL-M differently than other tt [1996/02/23] bin/1040 with certain flags, route can reboot your machine. [1996/02/25] i386/1042 Warning from sio driver reports wrong device FDIV045 [1996/02/26] misc/1043 vm_bounce_alloc error on 2.1 install with 4G drive [1996/02/26] docs/1044 clri(8) man page references man pages that don't exi [1996/02/27] kern/1045 Lockup: b_to_q to a clist with no reserved cblocks [1996/02/27] misc/1046 X dies with sig11 with -current [1996/02/27] gnu/1047 send-pr: Aborting... [1996/02/28] i386/1048 ep driver fails to detect card when told specific va [1996/02/28] kern/1049 /kernel: arpresolve: can't allocate llinfo for 194.1 [1996/02/28] bin/1050 Process (zip) hangs (unkillable) after floppy error [1996/02/29] ports/1051 zip fails on dos partition [1996/02/29] bin/1052 /bin/sh problem with new GCC (snapshot for 2.8) [1996/02/29] bin/1053 /bin/sh problem with new GCC (snapshot for 2.8) [1996/02/29] bin/1054 /bin/sh problem with new GCC (snapshot for 2.8) [1996/03/02] bin/1056 pppd fails if -detach [1996/03/03] kern/1058 system crashes when sending IP packet with bad lengt [1996/03/04] kern/1059 null fs panics system [1996/03/05] i386/1062 sio probe blanks video on Intel Atlantis [1996/03/05] kern/1063 gzip a.out execution is not ok (?) [1996/03/05] kern/1064 Recursive panic? [1996/03/06] kern/1065 wt could crash reading short blocks [1996/03/06] kern/1066 Arnet driver: panic when ifconfig PPP -> HDLC [1996/03/06] kern/1067 panic: ufs_lock: recursive lock not expected, pid: 2 [1996/03/08] bin/1068 man ignores -P option when combined with -k [1996/03/08] ports/1069 TkMan acts erroneusly on apropos This is the list of problem reports already analyzed: [1994/12/01] kern/35 mount -t union -o -b : lower layer not seen by shell [1995/01/11] i386/105 Distributed libm (msun) has non-standard error handl [1995/01/22] docs/177 man pages missing for SYSV IPC funtions [1995/03/20] kern/260 msync and munmap don't bother to update mod times [1995/03/20] docs/264 There are no manual pages for the forms library. [1995/03/22] kern/267 NFS code gives error messages, systems jams for a fe [1995/05/09] bin/392 Simultaneous cp and ls of files on dos f/s hangs pro [1995/06/17] kern/527 dump causes assertion in ncr.c [1995/06/21] docs/538 MAP_FILE not mentioned in mmap man page. [1995/10/07] bin/771 telnet character mode not set and broken when set - [1995/10/15] kern/782 chmod does a null pointer dereference [1995/12/29] misc/922 From line handling incorrect in mail.local [1996/01/09] bin/941 pkg_create removes current directory if interupted [1996/01/22] kern/965 2.0.5: system crashes daily because of "multiple fre [1996/02/08] bin/1006 Kerberized su has poor password interface /* EOF -- this list has not been truncated */ From owner-freebsd-bugs Sat Mar 9 06:50:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA29368 for bugs-outgoing; Sat, 9 Mar 1996 06:50:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA29344 Sat, 9 Mar 1996 06:50:02 -0800 (PST) Resent-Date: Sat, 9 Mar 1996 06:50:02 -0800 (PST) Resent-Message-Id: <199603091450.GAA29344@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, kelly@fsl.noaa.gov Received: from rosemary.fsl.noaa.gov (rosemary.fsl.noaa.gov [137.75.8.41]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA28874 for ; Sat, 9 Mar 1996 06:45:03 -0800 (PST) Received: (from kelly@localhost) by rosemary.fsl.noaa.gov (8.6.12/8.6.9) id HAA03571; Sat, 9 Mar 1996 07:44:57 -0700 Message-Id: <199603091444.HAA03571@rosemary.fsl.noaa.gov> Date: Sat, 9 Mar 1996 07:44:57 -0700 From: Sean Kelly Reply-To: kelly@fsl.noaa.gov To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/1070: /usr/bin/fstat doesn't display open, active pure text Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1070 >Category: bin >Synopsis: /usr/bin/fstat doesn't display open, active pure text >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 9 06:50:01 PST 1996 >Last-Modified: >Originator: Sean Kelly >Organization: Forecast Systems Laboratory >Release: FreeBSD 2.1-STABLE i386 >Environment: FreeBSD 2.1 installed via anon FTP in January '96. Fairly stock machine, as hosts go. More info avail on request. >Description: The fstat man page claims it'll display active pure text inodes for running processes. Under the FD column, it shows the file number in the per-process open file table or one of the following special names: wd, for current working directory; tr, for kernel trace file; root, for root inode; and text for pure text inode. After 1000 runs of fstat looking at a busy system, the `text' entry never appeared. Not necessarily proof, but an inductive argument is within reach. >How-To-Repeat: Run fstat | grep text and see no output until you're blue in the face. >Fix: Don't really know. fstat.c has some special handling for the CDIR, TRACE, and RDIR entries but none for the text. That might be it, but it also just might expect the text entry (-1) to appear in filedesc table. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 9 10:55:37 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16333 for bugs-outgoing; Sat, 9 Mar 1996 10:55:37 -0800 (PST) Received: (from gibbs@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16314 Sat, 9 Mar 1996 10:55:34 -0800 (PST) Date: Sat, 9 Mar 1996 10:55:34 -0800 (PST) From: "Justin T. Gibbs" Message-Id: <199603091855.KAA16314@freefall.freebsd.org> To: rlenk@widget.xmission.com, gibbs, freebsd-bugs Subject: Re: kern/938 Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: after heavy disk I/O, processes sleep on "newbuf" indefinitely State-Changed-From-To: open-closed State-Changed-By: gibbs State-Changed-When: Sat Mar 9 10:51:39 PST 1996 State-Changed-Why: Fixed in rev 1.50.4.3 of sys/i386/isa/isa.c From owner-freebsd-bugs Sat Mar 9 11:10:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17344 for bugs-outgoing; Sat, 9 Mar 1996 11:10:06 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA17320 Sat, 9 Mar 1996 11:10:03 -0800 (PST) Resent-Date: Sat, 9 Mar 1996 11:10:03 -0800 (PST) Resent-Message-Id: <199603091910.LAA17320@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, obrien@Nuxi.cs.ucdavis.edu Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA16836 for ; Sat, 9 Mar 1996 11:00:51 -0800 (PST) Received: (from obrien@localhost) by relay.nuxi.com (8.6.12/8.6.12) id LAA20154; Sat, 9 Mar 1996 11:00:59 -0800 Message-Id: <199603091900.LAA20154@relay.nuxi.com> Date: Sat, 9 Mar 1996 11:00:59 -0800 From: "David E. O'Brien" Reply-To: obrien@Nuxi.cs.ucdavis.edu To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: misc/1071: wrong path for pcvt binaries in sample rc.local file Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1071 >Category: misc >Synopsis: wrong path for pcvt binaries in sample rc.local file >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 9 11:10:02 PST 1996 >Last-Modified: >Originator: David E. O'Brien >Organization: University of California, Davis >Release: FreeBSD 2.1.0-RELEASE i386 >Environment: based upon pcvt from -current of 3/8/96 >Description: The pcvt sample rc.local file uses /usr/local/bin as the path to to the pcvt binaries, yet ``make install'' puts them in /usr/sbin >How-To-Repeat: more /usr/src/usr.sbin/pcvt/Misc/Etc/rc.local >Fix: Use supplied patch: --- pcvt/Misc/Etc/rc.local.orig Sun Mar 5 14:50:22 1995 +++ pcvt/Misc/Etc/rc.local Sat Mar 9 10:52:15 1996 @@ -98,42 +98,42 @@ # loading fonts into vga #-------------------------------------------------- echo 'console driver type: pcvt' - if [ -x /usr/local/bin/loadfont -a -x /usr/local/bin/scon ] + if [ -x /usr/sbin/loadfont -a -x /usr/local/bin/scon ] then - adaptor=`/usr/local/bin/scon -a` + adaptor=`/usr/sbin/scon -a` if [ $adaptor = VGA ] then echo 'loading 25 lines base font into character set 0' - /usr/local/bin/loadfont -c0 -f/usr/share/misc/pcvtfonts/vt220l.816 + /usr/sbin/loadfont -c0 -f/usr/share/misc/pcvtfonts/vt220l.816 echo 'loading 25 lines extension font into character set 1' - /usr/local/bin/loadfont -c1 -f/usr/share/misc/pcvtfonts/vt220h.816 + /usr/sbin/loadfont -c1 -f/usr/share/misc/pcvtfonts/vt220h.816 echo 'loading 28 lines base font into character set 2' - /usr/local/bin/loadfont -c2 -f/usr/share/misc/pcvtfonts/vt220l.814 + /usr/sbin/loadfont -c2 -f/usr/share/misc/pcvtfonts/vt220l.814 echo 'loading 28 lines extension font into character set 3' - /usr/local/bin/loadfont -c3 -f/usr/share/misc/pcvtfonts/vt220h.814 + /usr/sbin/loadfont -c3 -f/usr/share/misc/pcvtfonts/vt220h.814 echo 'loading 40 lines base font into character set 4' - /usr/local/bin/loadfont -c4 -f/usr/share/misc/pcvtfonts/vt220l.810 + /usr/sbin/loadfont -c4 -f/usr/share/misc/pcvtfonts/vt220l.810 echo 'loading 40 lines extension font into character set 5' - /usr/local/bin/loadfont -c5 -f/usr/share/misc/pcvtfonts/vt220h.810 + /usr/sbin/loadfont -c5 -f/usr/share/misc/pcvtfonts/vt220h.810 echo 'loading 50 lines base font into character set 6' - /usr/local/bin/loadfont -c6 -f/usr/share/misc/pcvtfonts/vt220l.808 + /usr/sbin/loadfont -c6 -f/usr/share/misc/pcvtfonts/vt220l.808 echo 'loading 50 lines extension font into character set 7' - /usr/local/bin/loadfont -c7 -f/usr/share/misc/pcvtfonts/vt220h.808 + /usr/sbin/loadfont -c7 -f/usr/share/misc/pcvtfonts/vt220h.808 elif [ $adaptor = EGA ] then echo 'loading 25 lines base font into character set 0' - /usr/local/bin/loadfont -c0 -f/usr/share/misc/pcvtfonts/vt220l.814 + /usr/sbin/loadfont -c0 -f/usr/share/misc/pcvtfonts/vt220l.814 echo 'loading 25 lines extension font into character set 1' - /usr/local/bin/loadfont -c1 -f/usr/share/misc/pcvtfonts/vt220h.814 + /usr/sbin/loadfont -c1 -f/usr/share/misc/pcvtfonts/vt220h.814 echo 'loading 35 lines base font into character set 2' - /usr/local/bin/loadfont -c2 -f/usr/share/misc/pcvtfonts/vt220l.810 + /usr/sbin/loadfont -c2 -f/usr/share/misc/pcvtfonts/vt220l.810 echo 'loading 35 lines extension font into character set 3' - /usr/local/bin/loadfont -c3 -f/usr/share/misc/pcvtfonts/vt220h.810 + /usr/sbin/loadfont -c3 -f/usr/share/misc/pcvtfonts/vt220h.810 # echo 'loading 43 lines base font into character set 2' -# /usr/local/bin/loadfont -c2 -f/usr/share/misc/pcvtfonts/vt220l.808 +# /usr/sbin/loadfont -c2 -f/usr/share/misc/pcvtfonts/vt220l.808 # echo 'loading 43 lines extension font into character set 3' -# /usr/local/bin/loadfont -c3 -f/usr/share/misc/pcvtfonts/vt220h.808 +# /usr/sbin/loadfont -c3 -f/usr/share/misc/pcvtfonts/vt220h.808 fi fi @@ -141,7 +141,7 @@ #-------------------------------------------------- # setting screen sizes and emulation #-------------------------------------------------- - if [ -x /usr/local/bin/scon ] + if [ -x /usr/sbin/scon ] then if [ $adaptor = VGA ] then @@ -158,7 +158,7 @@ # get monitor type (mono/color) - monitor=`/usr/local/bin/scon -m` + monitor=`/usr/sbin/scon -m` # for all screens do @@ -167,13 +167,13 @@ # setup HP mode - /usr/local/bin/scon -d$device $size -H + /usr/sbin/scon -d$device $size -H # setup cursor size - if [ X${set_cursor} = X"YES" -a -x /usr/local/bin/cursor ] + if [ X${set_cursor} = X"YES" -a -x /usr/sbin/cursor ] then - /usr/local/bin/cursor -d$device -s$set_cur_start -e$set_cur_end + /usr/sbin/cursor -d$device -s$set_cur_start -e$set_cur_end fi # if monochrome monitor, set color palette to use a higher intensity @@ -182,38 +182,38 @@ then if [ $adaptor = VGA ] then - /usr/local/bin/scon -d$device -p8,60,60,60 + /usr/sbin/scon -d$device -p8,60,60,60 fi fi done # switch to screen 0 - /usr/local/bin/scon -c0 + /usr/sbin/scon -c0 # set screensaver timeout to one minute - /usr/local/bin/scon -t360 + /usr/sbin/scon -t360 fi #------------------------------------------------------ # if desired, setup keyboard for german keyboard layout #------------------------------------------------------ - if [ X${set_keybd} = X"YES" -a -x /usr/local/bin/kcon ] + if [ X${set_keybd} = X"YES" -a -x /usr/sbin/kcon ] then echo 'switching to german keyboard layout' - /usr/local/bin/kcon -m de + /usr/sbin/kcon -m de fi #------------------------------------------------------ # if desired, setup rate and delay keyboard values #------------------------------------------------------ - if [ X${set_keydr} = X"YES" -a -x /usr/local/bin/kcon ] + if [ X${set_keydr} = X"YES" -a -x /usr/sbin/kcon ] then echo setting keyboard typematic rate = $set_keydr_rate and delay = $set_keydr_delay - /usr/local/bin/kcon -r $set_keydr_rate -d $set_keydr_delay + /usr/sbin/kcon -r $set_keydr_rate -d $set_keydr_delay fi #-------------------------------------------------- @@ -222,10 +222,10 @@ if [ X${xdm_start} = X"YES" -a -x /usr/X386/bin/xdm ] then - /usr/local/bin/scon -c 7 + /usr/sbin/scon -c 7 /usr/X386/bin/xdm sleep 5 - /usr/local/bin/scon -c 0 + /usr/sbin/scon -c 0 fi #-------------------------------------------------- >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 9 15:50:05 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA05220 for bugs-outgoing; Sat, 9 Mar 1996 15:50:05 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA05193 Sat, 9 Mar 1996 15:50:02 -0800 (PST) Resent-Date: Sat, 9 Mar 1996 15:50:02 -0800 (PST) Resent-Message-Id: <199603092350.PAA05193@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, pst@Shockwave.COM Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA04705 for ; Sat, 9 Mar 1996 15:40:49 -0800 (PST) Received: (from pst@localhost) by precipice.shockwave.com (8.7.4/8.7.3) id PAA15072; Sat, 9 Mar 1996 15:40:15 -0800 (PST) Message-Id: <199603092340.PAA15072@precipice.shockwave.com> Date: Sat, 9 Mar 1996 15:40:15 -0800 (PST) From: Paul Traina Reply-To: pst@Shockwave.COM To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: ports/1072: tex port (ftplib.pl) does not support passive mode ftp Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1072 >Category: ports >Synopsis: tex port (ftplib.pl) does not support passive mode ftp >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 9 15:50:01 PST 1996 >Last-Modified: >Originator: Paul Traina >Organization: Shockwave Engineering >Release: FreeBSD 2.2-CURRENT i386 >Environment: >Description: make fetch hangs when you're behind a firewall that enforces pasv mode ftp >How-To-Repeat: see description >Fix: ftplib.pl needs to be rewritten to support PASV connections. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 9 16:21:24 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA07944 for bugs-outgoing; Sat, 9 Mar 1996 16:21:24 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA07925 Sat, 9 Mar 1996 16:21:22 -0800 (PST) Date: Sat, 9 Mar 1996 16:21:22 -0800 (PST) From: Mike Pritchard Message-Id: <199603100021.QAA07925@freefall.freebsd.org> To: wollman@khavrinen.lcs.mit.edu, mpp, freebsd-bugs Subject: Re: kern/434 Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: umapfs panics when mounting ufs over itself State-Changed-From-To: open-closed State-Changed-By: mpp State-Changed-When: Sat Mar 9 16:20:35 PST 1996 State-Changed-Why: This PR is a duplicate of #1067, which has a better description of the problem, so I opted to keep that one open to track this problem instead. From owner-freebsd-bugs Sat Mar 9 16:24:19 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA08203 for bugs-outgoing; Sat, 9 Mar 1996 16:24:19 -0800 (PST) Received: (from mpp@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA08188 Sat, 9 Mar 1996 16:24:17 -0800 (PST) Date: Sat, 9 Mar 1996 16:24:17 -0800 (PST) From: Mike Pritchard Message-Id: <199603100024.QAA08188@freefall.freebsd.org> To: hsu@clinet.fi, mpp, freebsd-bugs, mpp Subject: Re: kern/1067 Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: panic: ufs_lock: recursive lock not expected, pid: 27195 State-Changed-From-To: open-analyzed State-Changed-By: mpp State-Changed-When: Sat Mar 9 16:21:26 PST 1996 State-Changed-Why: I changed mount to not allow the caller to panic the machine if they do something like "mount /mnt /mnt". This is a temporary workaround until some of Terry's file system rework goes in, at which time I can fix the kernel properly and without any kludges. Responsible-Changed-From-To: freebsd-bugs->mpp Responsible-Changed-By: mpp Responsible-Changed-When: Sat Mar 9 16:21:26 PST 1996 Responsible-Changed-Why: From owner-freebsd-bugs Sat Mar 9 17:10:32 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA11165 for bugs-outgoing; Sat, 9 Mar 1996 17:10:32 -0800 (PST) Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA11159 for ; Sat, 9 Mar 1996 17:10:30 -0800 (PST) Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7.4) id RAA15496; Sat, 9 Mar 1996 17:10:27 -0800 (PST) Received: from localhost by newport.ece.uci.edu (8.7.4) id RAA06886; Sat, 9 Mar 1996 17:10:24 -0800 (PST) Message-Id: <199603100110.RAA06886@newport.ece.uci.edu> To: bugs@freebsd.org Subject: TCP loss? Date: Sat, 09 Mar 1996 17:10:22 -0800 From: Steven Wallace Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk I am experiencing TCP freezup on FreeBSD to FreeBSD connection. Sometimes when I'm sending large amounts of text on a pty on my FreeBSD 2.1R machine (connected via ethernet) stops sending its data to my 2.2-Nov21st machine (connected via SLIP). Now I know packets get dropped from time to time over my link, but it should be able to recover and send again. On the 2.1R machine, it says that there is nothing in its Send-Q. The link still receives okay though (observing idle time and tcpdump watch), but the text is stuck and it never resends anything. Anybody else experienced probs like this? Has it been fixed? Steven From owner-freebsd-bugs Sat Mar 9 17:30:04 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA12339 for bugs-outgoing; Sat, 9 Mar 1996 17:30:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA12314 Sat, 9 Mar 1996 17:30:02 -0800 (PST) Resent-Date: Sat, 9 Mar 1996 17:30:02 -0800 (PST) Resent-Message-Id: <199603100130.RAA12314@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, hsu@clinet.fi Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id RAA12106 for ; Sat, 9 Mar 1996 17:27:25 -0800 (PST) Received: from zetor.clinet.fi (root@zetor.clinet.fi [194.100.0.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id DAA17083 for ; Sun, 10 Mar 1996 03:27:16 +0200 (EET) Received: (root@localhost) by zetor.clinet.fi (8.7.3/8.6.4) id DAA00655; Sun, 10 Mar 1996 03:27:16 +0200 (EET) Message-Id: <199603100127.DAA00655@zetor.clinet.fi> Date: Sun, 10 Mar 1996 03:27:16 +0200 (EET) From: Heikki Suonsivu Reply-To: hsu@clinet.fi To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/1073: telnet -8 does not work with SunOS or Solaris Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1073 >Category: bin >Synopsis: telnet -8 does not work with SunOS or Solaris >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 9 17:30:01 PST 1996 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-CURRENT i386 >Environment: -current >Description: telnet -8 does not seem to work from FreeBSD any more, try telnet shadows.cs.hut.fi -8 while telnet shadows.cs.hut.fi works. >How-To-Repeat: telnet a SunOS or Solaris machine with -8 option. I don't know for sure if it is SunOS, but with Solaris FreeBSD exhibits this behavior. >Fix: I don't know whether this is a bug in FreeBSD or Solaris/SunOS. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 9 18:17:43 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA15021 for bugs-outgoing; Sat, 9 Mar 1996 18:17:43 -0800 (PST) Received: (from jkh@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA15010 Sat, 9 Mar 1996 18:17:41 -0800 (PST) Date: Sat, 9 Mar 1996 18:17:41 -0800 (PST) From: "Jordan K. Hubbard" Message-Id: <199603100217.SAA15010@freefall.freebsd.org> To: obrien@Nuxi.cs.ucdavis.edu, jkh, freebsd-bugs Subject: Re: misc/1071 Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk Synopsis: wrong path for pcvt binaries in sample rc.local file State-Changed-From-To: open-closed State-Changed-By: jkh State-Changed-When: Sat Mar 9 18:17:04 PST 1996 State-Changed-Why: Fix applied (modulo one remaining reference to /usr/local/bin/scon which you missed) - thanks! From owner-freebsd-bugs Sat Mar 9 18:40:03 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA16456 for bugs-outgoing; Sat, 9 Mar 1996 18:40:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA16397 Sat, 9 Mar 1996 18:40:01 -0800 (PST) Resent-Date: Sat, 9 Mar 1996 18:40:01 -0800 (PST) Resent-Message-Id: <199603100240.SAA16397@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, hsu@clinet.fi Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA16335 for ; Sat, 9 Mar 1996 18:39:42 -0800 (PST) Received: from smile.clinet.fi (root@smile.clinet.fi [193.64.6.11]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id EAA18757 for ; Sun, 10 Mar 1996 04:39:39 +0200 (EET) Received: (root@localhost) by smile.clinet.fi (8.7.3/8.6.4) id EAA00525; Sun, 10 Mar 1996 04:39:39 +0200 (EET) Message-Id: <199603100239.EAA00525@smile.clinet.fi> Date: Sun, 10 Mar 1996 04:39:39 +0200 (EET) From: Heikki Suonsivu Reply-To: hsu@clinet.fi To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/1074: tty rows & columns settings sometimes reset to zero Sender: owner-bugs@freebsd.org X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk >Number: 1074 >Category: bin >Synopsis: tty rows & columns settings sometimes reset to zero >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 9 18:40:00 PST 1996 >Last-Modified: >Originator: Heikki Suonsivu >Organization: Clinet, Espoo, Finland >Release: FreeBSD 2.2-CURRENT i386 >Environment: Various versions of -current from several past months (may be for the duration of existence of FreeBSD 2). >Description: tty rows and columns settings are reported to be zeroed sometimes. the programs under which this is seen may be emacs, elm, or tin. I haven't seen this personally, but according to one of our users it happens sometimes. It also seems that it never happens twice during same connection, if the values are manually set to correct values they stick. >How-To-Repeat: A user says it happens when reading mail, or using tin to read news. Usually this involves editing something and then going back to tin/elm and when trying to edit the next mail the values have been reset. >Fix: Could this be something in curses library? tin and elm probably both use curses. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sat Mar 9 20:14:10 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA22225 for bugs-outgoing; Sat, 9 Mar 1996 20:14:10 -0800 (PST) Received: from heathers.stdio.com (heathers.stdio.com [204.152.114.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id UAA22217 for ; Sat, 9 Mar 1996 20:14:02 -0800 (PST) Received: (from risner@localhost) by heathers.stdio.com (8.6.12/8.6.13) id XAA00601; Sat, 9 Mar 1996 23:06:49 -0500 Date: Sat, 9 Mar 1996 23:06:49 -0500 From: James Risner Message-Id: <199603100406.XAA00601@heathers.stdio.com> To: freebsd-bugs@freefall.freebsd.org Subject: bin/1073: telnet -8 does not work with SunOS or Solaris Cc: hsu@clinet.fi Sender: owner-bugs@FreeBSD.ORG X-Loop: owner-bugs@FreeBSD.ORG Precedence: bulk I tried -8 from a SCO unix box to a SunOS box. It comes up, and gives a login, but you need to use ctrl-j to actually log into the machine, and once logged into the SunOS machine, you need to do a "stty sane" to get it to WORK like you would expect. If this (ctrl-j problem) is the problem you were having, then I would say that it is a SunOS not negotiating binary mode correctly. I too the telnetd from freebsd-stable and compiled it under the SunOS machine. This telnetd works under SunOS (after ported) and does not share the problem with the SunOS shipped telnetd. My solution was to use the FreeBSD telnetd under SunOS> Risner