From owner-freebsd-bugs Sun Nov 1 00:20:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA27032 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 00:20:19 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA27024; Sun, 1 Nov 1998 00:20:13 -0800 (PST) (envelope-from phk@FreeBSD.org) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id AAA22831; Sun, 1 Nov 1998 00:20:14 -0800 (PST) Date: Sun, 1 Nov 1998 00:20:14 -0800 (PST) Message-Id: <199811010820.AAA22831@freefall.freebsd.org> To: junichi@jp.FreeBSD.ORG, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/8523 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: The Write_Disk() doesn't support any length of device name. State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Sun Nov 1 00:19:50 PST 1998 State-Changed-Why: this has already been fixed in other ways as part of the alpha port. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 03:00:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA13021 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 03:00:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12947 for ; Sun, 1 Nov 1998 03:00:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id DAA23504; Sun, 1 Nov 1998 03:00:01 -0800 (PST) Date: Sun, 1 Nov 1998 03:00:01 -0800 (PST) Message-Id: <199811011100.DAA23504@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Joachim Kuebart Subject: Re: kern/5038: FreeBSD can't read MS Joliet CDs. Reply-To: Joachim Kuebart Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/5038; it has been noted by GNATS. From: Joachim Kuebart To: lxv@nest.org Cc: freebsd-gnats-submit@freebsd.org, joki@kuebart.stuttgart.netsurf.de Subject: Re: kern/5038: FreeBSD can't read MS Joliet CDs. Date: Sun, 1 Nov 1998 11:52:48 +0100 (CET) Alex Vasylenko wrote: > hi, > > below is a diff from -stable (as of 10/30) sources to support Joliet > extensions to cd9660 filesystem (author Joachim Kuebart > ) ... > > --Alex. > > > ===== ~/s/src/sys/isofs/cd9660 > diff -u orig/cd9660_rrip.c ./cd9660_rrip.c > --- orig/cd9660_rrip.c Sun Aug 17 06:28:37 1997 > +++ ./cd9660_rrip.c Fri Oct 30 23:48:14 1998 > @@ -516,12 +518,11 @@ > * it will be padding 1 byte after the name > */ > pwhead = isodir->name + isonum_711(isodir->name_len); > - if (!(isonum_711(isodir->name_len)&1)) > - pwhead++; > + isochar(isodir->name, pwhead, ana->imp->joliet_level, &c); > + pwhead += isonum_711(isodir->name_len) & 1; > > /* If it's not the '.' entry of the root dir obey SP field */ > - if (*isodir->name != 0 > - || isonum_733(isodir->extent) != ana->imp->root_extent) > + if (c != 0 || isonum_733(isodir->extent) != ana->imp->root_extent) > pwhead += ana->imp->rr_skip; > else > pwhead += ana->imp->rr_skip0; This patch broke RRIP for me. It should be: ===== ~/s/src/sys/isofs/cd9660 diff -u orig/cd9660_rrip.c ./cd9660_rrip.c --- orig/cd9660_rrip.c Sun Aug 17 06:28:37 1997 +++ ./cd9660_rrip.c Fri Oct 30 23:48:14 1998 @@ -518,10 +520,10 @@ pwhead = isodir->name + isonum_711(isodir->name_len); if (!(isonum_711(isodir->name_len)&1)) pwhead++; + isochar(isodir->name, pwhead, ana->imp->joliet_level, &c); /* If it's not the '.' entry of the root dir obey SP field */ - if (*isodir->name != 0 - || isonum_733(isodir->extent) != ana->imp->root_extent) + if (c != 0 || isonum_733(isodir->extent) != ana->imp->root_extent) pwhead += ana->imp->rr_skip; else pwhead += ana->imp->rr_skip0; I'm sorry I forgot to submit a follow-up when I noticed that. This applies to the -current patch as well, of course. cu Jo --------------------------------------------------------------------- Pray that there's intelligent life Joachim Kuebart Somewhere up in space Stuttgart, Germany 'Cause there's bugger all down here on earth. --- Monty Python To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 03:00:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA13037 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 03:00:05 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12969 for ; Sun, 1 Nov 1998 03:00:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id DAA23513; Sun, 1 Nov 1998 03:00:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA12695; Sun, 1 Nov 1998 02:55:33 -0800 (PST) (envelope-from nobody) Message-Id: <199811011055.CAA12695@hub.freebsd.org> Date: Sun, 1 Nov 1998 02:55:33 -0800 (PST) From: ilg@Romania.EU.net To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: misc/8524: /usr/X11R6/bin mode bits: drwx------ ? Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8524 >Category: misc >Synopsis: /usr/X11R6/bin mode bits: drwx------ ? >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 1 03:00:01 PST 1998 >Last-Modified: >Originator: Liviu Ionescu >Organization: EUnet Romania >Release: 3.0-RELEASE >Environment: FreeBSD boca.ro.eu.net 3.0-RELEASE FreeBSD 3.0-RELEASE #0: Sat Oct 17 17:45:06 GMT 1998 jkh@kickme.freebsd.org:/usr/src/sys/compile/GENERIC i386 >Description: after reinstalling 3.0R on an empty disk, the /usr/X11R6/bin directory resulted to allow only root access to it. although the installation was not easy (due to some SCSI problems), there were no manual chmod commands issued. >How-To-Repeat: probably reinstall the system on an empty disk ("probably" because I had no time to check it). >Fix: manualy change the mode bits to: "drwxrwxr-x" >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 05:05:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA03122 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 05:05:27 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03115; Sun, 1 Nov 1998 05:05:24 -0800 (PST) (envelope-from wosch@FreeBSD.org) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA07115; Sun, 1 Nov 1998 05:05:24 -0800 (PST) Date: Sun, 1 Nov 1998 05:05:24 -0800 (PST) Message-Id: <199811011305.FAA07115@freefall.freebsd.org> To: wosch@bento.freebsd.org, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: conf/8330 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [PATCH] modload usage in etc/etc.i386/rc.i386 State-Changed-From-To: open-closed State-Changed-By: wosch State-Changed-When: Sun Nov 1 05:04:46 PST 1998 State-Changed-Why: Patch applied in rev 1.36 src/etc/etc.i386/rc.i386 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 07:40:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA22220 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 07:40:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA22182 for ; Sun, 1 Nov 1998 07:40:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id HAA24630; Sun, 1 Nov 1998 07:40:01 -0800 (PST) Received: from baerenklau.de.freebsd.org (baerenklau.de.freebsd.org [195.185.195.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA22070 for ; Sun, 1 Nov 1998 07:38:49 -0800 (PST) (envelope-from wosch@panke.de.freebsd.org) Received: (from uucp@localhost) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with UUCP id QAA22687 for FreeBSD-gnats-submit@freebsd.org; Sun, 1 Nov 1998 16:38:44 +0100 (CET) (envelope-from wosch@panke.de.freebsd.org) Received: (from wosch@localhost) by campa.panke.de.freebsd.org (8.8.8/8.8.8) id LAA01342; Sun, 1 Nov 1998 11:40:46 +0100 (MET) (envelope-from wosch) Message-Id: <199811011040.LAA01342@campa.panke.de.freebsd.org> Date: Sun, 1 Nov 1998 11:40:46 +0100 (MET) From: Wolfram Schneider Reply-To: wosch@panke.de.freebsd.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8528: swap_pager: suggest more swap space warning Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8528 >Category: kern >Synopsis: swap_pager: suggest more swap space warning >Confidential: yes >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 1 07:40:00 PST 1998 >Last-Modified: >Originator: Wolfram Schneider >Organization: >Release: FreeBSD 3.0-current i386 >Environment: I bought a computer with 64MB and installed 137MB swap space. Some weeks later I upgrade the RAM to 128MB, still using 137MB swap space. Randomly (twice a week) I get a strange swap space warning: swap_pager: suggest more swap space: 253 MB the current swap usage at this time is less than 10% (5-15MB of 137MB). IHMO the kernel should not print a warning unless 50% of the total swap space is in use. >Description: >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 14:20:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16302 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 14:20:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16265 for ; Sun, 1 Nov 1998 14:19:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id OAA18998; Sun, 1 Nov 1998 14:20:00 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA15837; Sun, 1 Nov 1998 14:18:01 -0800 (PST) (envelope-from nobody) Message-Id: <199811012218.OAA15837@hub.freebsd.org> Date: Sun, 1 Nov 1998 14:18:01 -0800 (PST) From: rv@fore.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: conf/8531: sysinstall on 3.0-RELEASE (and 3.0-current) doesn't find XFree-3.3.x package Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8531 >Category: conf >Synopsis: sysinstall on 3.0-RELEASE (and 3.0-current) doesn't find XFree-3.3.x package >Confidential: no >Severity: non-critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 1 14:20:00 PST 1998 >Last-Modified: >Originator: Rajesh Vaidheeswarran >Organization: >Release: FreeBSD 3.0-RELEASE #0: Sat Oct 17 17:45:06 GMT 1998 jkh@kickme.freebsd.org:/usr/src/sys/compile/GENERIC i386 >Environment: FreeBSD freebsd.eng.fore.com 3.0-RELEASE FreeBSD 3.0-RELEASE #0: Sat Oct 17 17:45:06 GMT 1998 jkh@kickme.freebsd.org:/usr/src/sys/compile/GENERIC i386 >Description: This was a full ftp installation of the 3.0-RELEASE. When I chose any packages that required either 'XFree-3.3.6' or Mesa-1.0? package, sysinstall couldn't fetch or install either of these from ftp.freebsd.org or current.freebsd.org >How-To-Repeat: Try installing 3.0-RELEASE through ftp and select all the 'kde' packages to be installed. You should see the problem right away. >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 15:00:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21044 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 15:00:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21035 for ; Sun, 1 Nov 1998 14:59:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id PAA20386; Sun, 1 Nov 1998 15:00:00 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20701; Sun, 1 Nov 1998 14:56:29 -0800 (PST) (envelope-from nobody) Message-Id: <199811012256.OAA20701@hub.freebsd.org> Date: Sun, 1 Nov 1998 14:56:29 -0800 (PST) From: rv@fore.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8532: 3.0-RELEASE panics with standard SMP kernel from /sys/i386/conf/SMP-GENERIC Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8532 >Category: kern >Synopsis: 3.0-RELEASE panics with standard SMP kernel from /sys/i386/conf/SMP-GENERIC >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 1 15:00:00 PST 1998 >Last-Modified: >Originator: Rajesh Vaidheeswarran >Organization: >Release: 3.0-RELEASE >Environment: FreeBSD linux.eng.fore.com 3.0-RELEASE FreeBSD 3.0-RELEASE #0: Sun Nov 1 15:27:24 EST 1998 bash@freebsd.eng.fore.com:/usr/src/sys/compile/FB30 i386 >Description: On boot, the kernel falls into ddb with the following panic, panic: pmap_botostrap: no local apic! mp_lock = 00000001; cpuid = 0; lapic.id = 00000000 Debugger("panic") Stopped at _Debugger+0x35: movb $0,_in_Debugger.98 db> I am using a Micron Millenia Mme with one Pentium 200Mhz, 160Mb RAM and nothing fancy. I would like to know what is the supported architecture to run the SMP kernel on. Also, when will there be a version of SMP FreeBSD that will run on a run-of-the-mill PC? Thanks >How-To-Repeat: On a generic PC platform load 3.0, and (as root) cd /sys/i386/conf/ config SMP-GENERIC cd ../../compile/SMP-GENERIC make depend; make ; make install reboot >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 15:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22289 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 15:10:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22281 for ; Sun, 1 Nov 1998 15:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id PAA20867; Sun, 1 Nov 1998 15:10:00 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21996; Sun, 1 Nov 1998 15:06:36 -0800 (PST) (envelope-from nobody) Message-Id: <199811012306.PAA21996@hub.freebsd.org> Date: Sun, 1 Nov 1998 15:06:36 -0800 (PST) From: rv@fore.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8533: Bootloader doesn't recognize ELF kernel Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8533 >Category: kern >Synopsis: Bootloader doesn't recognize ELF kernel >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 1 15:10:00 PST 1998 >Last-Modified: >Originator: Rajesh Vaidheeswarran >Organization: >Release: 3.0-RELEASE >Environment: FreeBSD freebsd.eng.fore.com 3.0-RELEASE FreeBSD 3.0-RELEASE #0: Sun Nov 1 15:27:24 EST 1998 bash@freebsd.eng.fore.com:/usr/src/sys/compile/FB30 i386 >Description: I compiled a kernel with KERNFORMAT?= elf and the bootloader couldn't load the elf kernel. The complaint was: kernel: Invalid format! 1. If it was unsupported, then should the makefile probably warn that it is invalid to change the format? 2. When do we plan to support elf format in the kernel? Thanks >How-To-Repeat: config a kernel of your choice in 3.0, cd /sys/compile/Myourkernel> edit the Makefile and replace 'aout' with 'elf' in KERNFORMAT? flag and compile (make clean; make depend; make; make install) >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 16:18:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04098 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 16:18:39 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04084; Sun, 1 Nov 1998 16:18:36 -0800 (PST) (envelope-from rnordier@FreeBSD.org) From: Robert Nordier Received: (from rnordier@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id QAA24352; Sun, 1 Nov 1998 16:18:37 -0800 (PST) Date: Sun, 1 Nov 1998 16:18:37 -0800 (PST) Message-Id: <199811020018.QAA24352@freefall.freebsd.org> To: rv@fore.com, rnordier@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8533 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: Bootloader doesn't recognize ELF kernel State-Changed-From-To: open-closed State-Changed-By: rnordier State-Changed-When: Sun Nov 1 16:12:20 PST 1998 State-Changed-Why: You need to "make world" or otherwise ensure that the directory /boot is correctly populated. Then create or edit the file /boot.config and ensure that it contains the string "/boot/loader". (Alternatively, you can type /boot/loader at the "Boot: " prompt.) (Pilot error.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 16:20:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04322 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 16:20:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04248 for ; Sun, 1 Nov 1998 16:20:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id QAA24429; Sun, 1 Nov 1998 16:20:01 -0800 (PST) Date: Sun, 1 Nov 1998 16:20:01 -0800 (PST) Message-Id: <199811020020.QAA24429@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Steve Friedrich" Subject: Re: kern/8532: 3.0-RELEASE panics with standard SMP kernel from /sys/i386/conf/SMP-GENERIC Reply-To: "Steve Friedrich" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8532; it has been noted by GNATS. From: "Steve Friedrich" To: "freebsd-gnats-submit@FreeBSD.ORG" , "rv@fore.com" Cc: Subject: Re: kern/8532: 3.0-RELEASE panics with standard SMP kernel from /sys/i386/conf/SMP-GENERIC Date: Sun, 01 Nov 1998 19:05:42 -0500 On Sun, 1 Nov 1998 14:56:29 -0800 (PST), rv@fore.com wrote: >I am using a Micron Millenia Mme with one Pentium 200Mhz, 160Mb RAM and >nothing fancy. I think SMP kernels REQUIRE at least 2 CPUs. See http://www.freebsd.org/~fsmp/SMP/SMP.html Follow the link to getting started http://www.freebsd.org/~fsmp/SMP/getstarted.html and you'll see: Important facts: The FreeBSD SMP kernel is BETA LEVEL software, use with caution! The motherboard must be Intel MP Spec. 1.1 or 1.4 compatible. The SMP kernel WILL NOT WORK on a uniprocessor motherboard. This is ambigious. But I think I read that it requires 2 CPUs somewhere else... You might email to the guy who was maintaining these pages for clarification... Unix systems measure "uptime" in years, Winblows measures it in minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 17:20:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11034 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 17:20:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10997 for ; Sun, 1 Nov 1998 17:20:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id RAA26882; Sun, 1 Nov 1998 17:20:01 -0800 (PST) Date: Sun, 1 Nov 1998 17:20:01 -0800 (PST) Message-Id: <199811020120.RAA26882@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Peter Wemm Subject: Re: kern/8532: 3.0-RELEASE panics with standard SMP kernel from /sys/i386/conf/SMP-GENERIC Reply-To: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8532; it has been noted by GNATS. From: Peter Wemm To: rv@fore.com Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/8532: 3.0-RELEASE panics with standard SMP kernel from /sys/i386/conf/SMP-GENERIC Date: Mon, 02 Nov 1998 09:15:44 +0800 rv@fore.com wrote: [..] > panic: pmap_botostrap: no local apic! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I am using a Micron Millenia Mme with one Pentium 200Mhz, 160Mb RAM and > nothing fancy. > > I would like to know what is the supported architecture to run the > SMP kernel on. > > Also, when will there be a version of SMP FreeBSD that will run on a > run-of-the-mill PC? You cannot run a SMP kernel on a uniprocessor motherboard - it is missing too much support hardware, the local and IO APICs in particular. The interrupt mechanism is extensively different when compiled in APIC_IO mode, it is not practical to have one kernel architecture that works on both UP and SMP motherboards, the differences are too great. Also, it's worth noting that the motherboard will disable the on-cpu local apic unless it's SMP capable. I think I've heard that some SMP motherboards will do this too if there is only one cpu, but I am not sure about that. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sun Nov 1 17:50:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA13494 for freebsd-bugs-outgoing; Sun, 1 Nov 1998 17:50:02 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13444 for ; Sun, 1 Nov 1998 17:50:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id RAA28304; Sun, 1 Nov 1998 17:50:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12941; Sun, 1 Nov 1998 17:43:06 -0800 (PST) (envelope-from nobody) Message-Id: <199811020143.RAA12941@hub.freebsd.org> Date: Sun, 1 Nov 1998 17:43:06 -0800 (PST) From: rv@fore.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8534: insufficient support routines for poll(2) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8534 >Category: kern >Synopsis: insufficient support routines for poll(2) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Nov 1 17:50:01 PST 1998 >Last-Modified: >Originator: Rajesh Vaidheeswarran >Organization: >Release: 3.0-RELEASE >Environment: FreeBSD freebsd.eng.fore.com 3.0-RELEASE FreeBSD 3.0-RELEASE #0: Sun Nov 1 15:27:24 EST 1998 bash@freebsd.eng.fore.com:/usr/src/sys/compile/FB30 i386 >Description: the newly supported poll(2) routine still has no real kernel support. All the poll event entry points are still required to use struct selinfo, with selrecord and selwakeup to deal with the events. When do we plan to create an equivalent of the SYSV pollwakeup and struct pollhead to natively deal with poll(2)? Also, till such time selinfo, selwakeup and selrecord are used, a man page describing the functionality would do good. >How-To-Repeat: >Fix: implementation of pollwakeup :) >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 08:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01459 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 08:10:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01453 for ; Mon, 2 Nov 1998 08:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id IAA22335; Mon, 2 Nov 1998 08:10:01 -0800 (PST) Date: Mon, 2 Nov 1998 08:10:01 -0800 (PST) Message-Id: <199811021610.IAA22335@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Robert S. Sciuk" Subject: Re: i386/8487: FreeBSD 3.0 RELEASE fails with Adaptec 7880 and SMP Reply-To: "Robert S. Sciuk" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/8487; it has been noted by GNATS. From: "Robert S. Sciuk" To: freebsd-gnats-submit@freebsd.org, rob@ControlQ.com Cc: Subject: Re: i386/8487: FreeBSD 3.0 RELEASE fails with Adaptec 7880 and SMP Date: Mon, 02 Nov 1998 10:58:20 -0500 I guess this should have been assessed critical status, since the OS will not work at all under SMP in the presence of the 7880 and the Seagate Elite 9GB disk. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 09:30:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10642 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 09:30:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10636 for ; Mon, 2 Nov 1998 09:29:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id JAA26749; Mon, 2 Nov 1998 09:30:00 -0800 (PST) Date: Mon, 2 Nov 1998 09:30:00 -0800 (PST) Message-Id: <199811021730.JAA26749@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Tony Finch Subject: Re: kern/8500: FreeBSD 3.0 thread scheduler is broken Reply-To: Tony Finch Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8500; it has been noted by GNATS. From: Tony Finch To: peter@netplex.com.au Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/8500: FreeBSD 3.0 thread scheduler is broken Date: Mon, 2 Nov 1998 17:41:39 +0000 Peter Wemm wrote: > HighWind Software Information wrote: > > > The only alternatives are to use the aio/lio syscalls (which work), or > > rfork(). libc_r could probably be modified to use rfork() to have the > > read/write/open/close/etc done in parallel. > > > > I don't think that is necessary. > > It is if you want the threading to continue while the disk is grinding > away. aio_read() and aio_write() would probably be enough to help file > IO, but open() will still be blocking. > > Squid has some fairly extensive async disk-IO routines. They happen to > use pthreads as a mechanism of having child processes do the blocking > work. FreeBSD could use rfork() for arranging the blocking stuff in child > processes with shared address space. It would be a lot of work though, > and would be a problem on SMP systems. We have been trying out Squid on 3.0 because of the possibilities offered by async IO, but so far we haven't managed to get it to work satisfactorily. I was also thinking about the possibility of using rfork() to implement threads -- the Linux pthreads implementation does this (except that Linux has clone() instead of rfork() and the interface is slightly different). What are the SMP issues? Tony. -- gg yhf**f.a.n.finch fanf@demon.net dot@dotat.at To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 13:16:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA05753 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 13:16:51 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA05742; Mon, 2 Nov 1998 13:16:43 -0800 (PST) (envelope-from gibbs@FreeBSD.org) From: "Justin T. Gibbs" Received: (from gibbs@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id NAA09654; Mon, 2 Nov 1998 13:16:45 -0800 (PST) Date: Mon, 2 Nov 1998 13:16:45 -0800 (PST) Message-Id: <199811022116.NAA09654@freefall.freebsd.org> To: rob@controlq.com, gibbs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/8487 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: FreeBSD 3.0 RELEASE fails with Adaptec 7880 and SMP State-Changed-From-To: open-closed State-Changed-By: gibbs State-Changed-When: Mon Nov 2 13:16:34 PST 1998 State-Changed-Why: Fixed by configuring the system bios to use v1.4 of the mpspec. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 13:19:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06336 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 13:19:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from alpha.netaccess.on.ca (netaccess.on.ca [199.243.225.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06298; Mon, 2 Nov 1998 13:18:51 -0800 (PST) (envelope-from rob@ControlQ.com) Received: from fatlady.controlq.com (dial084.netaccess.on.ca [199.243.225.212]) by alpha.netaccess.on.ca (8.8.5/8.7.3) with SMTP id QAA29483; Mon, 2 Nov 1998 16:18:40 -0500 (EST) Date: Mon, 2 Nov 1998 16:22:56 -0500 (EST) From: "Robert S. Sciuk" To: "Justin T. Gibbs" cc: freebsd-bugs@FreeBSD.ORG Subject: Re: i386/8487 In-Reply-To: <199811022116.NAA09654@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ack, This is likely the fix -- though it may have been a longer settling time for the disk (changed to 15 sec). On Mon, 2 Nov 1998, Justin T. Gibbs wrote: > Synopsis: FreeBSD 3.0 RELEASE fails with Adaptec 7880 and SMP > > State-Changed-From-To: open-closed > State-Changed-By: gibbs > State-Changed-When: Mon Nov 2 13:16:34 PST 1998 > State-Changed-Why: > Fixed by configuring the system bios to use v1.4 of the mpspec. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert S. Sciuk 1032 Howard Rd. PO Box 6A Ph:905 632-2466 Control-Q Research Burlington, Ont. Canada Fx:905 632-7417 rob@ControlQ.com L7R 3X5 http://www.ControlQ.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 13:50:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11174 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 13:50:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11135 for ; Mon, 2 Nov 1998 13:50:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id NAA11174; Mon, 2 Nov 1998 13:50:01 -0800 (PST) Received: from geisha.samurai.com (geisha.samurai.com [205.207.28.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11029 for ; Mon, 2 Nov 1998 13:49:27 -0800 (PST) (envelope-from bryanf@geisha.samurai.com) Received: (from bryanf@localhost) by geisha.samurai.com (8.9.1a/8.9.1) id QAA00521; Mon, 2 Nov 1998 16:47:26 -0500 (EST) Message-Id: <199811022147.QAA00521@geisha.samurai.com> Date: Mon, 2 Nov 1998 16:47:26 -0500 (EST) From: bryanf@samurai.com Reply-To: bryanf@samurai.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/8544: mount /dev/wd0s1 + mount_msdos /dev/wd0s1 = crash Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8544 >Category: i386 >Synopsis: mount /dev/wd0s1 + mount_msdos /dev/wd0s1 = crash >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 2 13:50:01 PST 1998 >Last-Modified: >Originator: Bryan Fullerton >Organization: Samurai Consulting >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD geisha.samurai.com 3.0-CURRENT FreeBSD 3.0-CURRENT #3: Tue Oct 20 19:00:23 GMT 1998 root@geisha.samurai.com:/usr/src/sys/compile/GEISHA i386 wd0s1 = Win95 FAT partition wd2s1 = FreeBSD partition >Description: Attempting to mount a FAT filesystem using the regular mount command, and then immediately after mounting the same filesystem with mount_msdos, results in FreeBSD locking up, dumping core, and rebooting. I have a savecore file here, but I have no idea how to analyze it - if someone wants a copy I can gzip it and email and/or make it available for FTP. It's possible this could be specific to my system - I don't have another FreeBSD system with FAT partitions to test with. >How-To-Repeat: mount /dev/wd0s1 /mnt mount_msdos /dev/wd0s1 /mnt wait while system dumps core and reboots >Fix: Wish I knew. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 18:41:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA23323 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 18:41:02 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA23306; Mon, 2 Nov 1998 18:40:26 -0800 (PST) (envelope-from yokota@FreeBSD.org) From: Kazutaka YOKOTA Received: (from yokota@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id SAA24856; Mon, 2 Nov 1998 18:40:28 -0800 (PST) Date: Mon, 2 Nov 1998 18:40:28 -0800 (PST) Message-Id: <199811030240.SAA24856@freefall.freebsd.org> To: ru@ucb.crimea.ua, yokota@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/8344 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: syscons destructive cursor is bad displayed State-Changed-From-To: open-closed State-Changed-By: yokota State-Changed-When: Mon Nov 2 18:39:47 PST 1998 State-Changed-Why: Fixed in 3.0-CURRENT (syscons.c 1.286) and 2.2-STABLE (1.182.2.38). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 21:00:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA11287 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 21:00:02 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11237 for ; Mon, 2 Nov 1998 20:59:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id VAA02637; Mon, 2 Nov 1998 21:00:00 -0800 (PST) Date: Mon, 2 Nov 1998 21:00:00 -0800 (PST) Message-Id: <199811030500.VAA02637@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Peter Wemm Subject: Re: kern/8500: FreeBSD 3.0 thread scheduler is broken Reply-To: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8500; it has been noted by GNATS. From: Peter Wemm To: Tony Finch Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/8500: FreeBSD 3.0 thread scheduler is broken Date: Tue, 03 Nov 1998 12:54:48 +0800 Tony Finch wrote: > Peter Wemm wrote: > > HighWind Software Information wrote: > > > > > The only alternatives are to use the aio/lio syscalls (which work), or > > > rfork(). libc_r could probably be modified to use rfork() to have the > > > read/write/open/close/etc done in parallel. > > > > > > I don't think that is necessary. > > > > It is if you want the threading to continue while the disk is grinding > > away. aio_read() and aio_write() would probably be enough to help file > > IO, but open() will still be blocking. > > > > Squid has some fairly extensive async disk-IO routines. They happen to > > use pthreads as a mechanism of having child processes do the blocking > > work. FreeBSD could use rfork() for arranging the blocking stuff in child > > processes with shared address space. It would be a lot of work though, > > and would be a problem on SMP systems. > > We have been trying out Squid on 3.0 because of the possibilities > offered by async IO, but so far we haven't managed to get it to work > satisfactorily. I was also thinking about the possibility of using > rfork() to implement threads -- the Linux pthreads implementation does > this (except that Linux has clone() instead of rfork() and the > interface is slightly different). > > What are the SMP issues? Pretty dramatic, ie: it doesn't work. :-( The reason is that under SMP, there is a per-cpu page table directory slot that is changed each context switch. We store a heap of per-cpu variables here (with more to come), including the virtual cpuid. With a shared address space rfork(), the same PTD, page tables and pages are used in both processes. If both CPUs happened to schedule both processes on each cpu at the same time, one cpu would clobber the other CPU's private PTD slot and they would both end up using the same privated pages on both cpus. This kills the system on the spot as they both think they are the same cpu. For this reason, fast vfork is disabled and rfork() in shared address space mode returns an error. There is not a simple fix for this. There is a possibility that loading the MPPTDI slot after gaining the giant kernel lock could be made to work as a short-term fix, but obviously that fails when the giant kernel lock starts to go away, and something needs to be done about fast interrupts and the boundary code that runs outside the kernel lock. Longer term fixes include drastic VM (pmap and support) modifications: - have seperate address spaces for the kernel and user. This isn't such a bad option as it positions us for very large memory systems very well. The kernel would load and run at 0x00100000 rather than 0xf0100000, and would have one PTD[] for each CPU. Each process could have 4GB of address space, rather than having to leave room for the kernel to live at the top of it. Needless to say this is a fair amount of work. :-) - have multiple PTDs for each shared address space, up to the number of present cpus. ie: if an address space was rforked for 20 threads, but you had 4 CPUs, then you need 4 PTDs. Neither of these have been attempted yet, but the second is probably the simpler of the two, while the first is probably the best for future capabilities. It would give us a lot more room to move on the large memory PPro and PII systems with 36 bits (64GB ram) of address space. > Tony. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Mon Nov 2 22:40:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24711 for freebsd-bugs-outgoing; Mon, 2 Nov 1998 22:40:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24650 for ; Mon, 2 Nov 1998 22:39:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id WAA16284; Mon, 2 Nov 1998 22:40:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24546; Mon, 2 Nov 1998 22:38:37 -0800 (PST) (envelope-from nobody) Message-Id: <199811030638.WAA24546@hub.freebsd.org> Date: Mon, 2 Nov 1998 22:38:37 -0800 (PST) From: haokercsma@hotmail.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: conf/8549: how to configure the network Card and Setup the X_window Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8549 >Category: conf >Synopsis: how to configure the network Card and Setup the X_window >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 2 22:40:00 PST 1998 >Last-Modified: >Originator: csma >Organization: CTC Co. >Release: FreeBSD 2.2.5 >Environment: PII 333MHz,128M RAM,6.4G IDE/PCI/SCSI,3com 10/100Base Ethernet (3C905B) >Description: >How-To-Repeat: As the title, how to configure the Network Card and setup the X-Window >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 02:00:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA17698 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 02:00:09 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA17586 for ; Tue, 3 Nov 1998 02:00:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id CAA24460; Tue, 3 Nov 1998 02:00:02 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17237; Tue, 3 Nov 1998 01:57:07 -0800 (PST) (envelope-from nobody) Message-Id: <199811030957.BAA17237@hub.freebsd.org> Date: Tue, 3 Nov 1998 01:57:07 -0800 (PST) From: nick.hibma@jrc.it To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8550: strip kernel before moving it during make install Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8550 >Category: kern >Synopsis: strip kernel before moving it during make install >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 02:00:01 PST 1998 >Last-Modified: >Originator: Nick Hibma >Organization: n/a >Release: FreeBSD-3.0-CURRENT >Environment: >Description: To save disk space on the root partition one could strip -d the old during make install. It is to be expected that as soon as a new kernel is installed the old one is not needed for debugging anymore. It saves about 9Mb when the complete kernel is compiled with -g. If there is no debugging symbols in the kernel the penalty of stripping the kernel first is a neglactable IMHO. >How-To-Repeat: >Fix: *** Makefile.i386.orig Mon Oct 5 13:49:51 1998 --- Makefile.i386 Sun Nov 1 14:20:59 1998 *************** *** 217,222 **** --- 217,223 ---- fi .if exists(${DESTDIR}/kernel) chflags noschg ${DESTDIR}/kernel + -strip -d ${DESTDIR}/kernel mv ${DESTDIR}/kernel ${DESTDIR}/kernel.old .endif PATH=$${PATH}:/sbin:/usr/sbin; \ >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 05:30:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA07605 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 05:30:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA07549 for ; Tue, 3 Nov 1998 05:29:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA04034; Tue, 3 Nov 1998 05:30:00 -0800 (PST) Received: from smilla.rueskamp.com (smilla.rueskamp.com [194.97.69.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA06668 for ; Tue, 3 Nov 1998 05:22:06 -0800 (PST) (envelope-from br@smilla.rueskamp.com) Received: (from br@localhost) by smilla.rueskamp.com (8.8.8/8.8.8) id OAA26460; Tue, 3 Nov 1998 14:21:55 +0100 (CET) (envelope-from br) Message-Id: <199811031321.OAA26460@smilla.rueskamp.com> Date: Tue, 3 Nov 1998 14:21:55 +0100 (CET) From: Bodo Rueskamp Reply-To: br@rueskamp.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/8553: /usr/libexec/mail.local doesn't handle ">From " lines transparently Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8553 >Category: bin >Synopsis: /usr/libexec/mail.local doesn't handle ">From " lines transparently >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 05:30:00 PST 1998 >Last-Modified: >Originator: Bodo Rueskamp >Organization: >Release: FreeBSD 2.2.6-RELEASE i386 >Environment: FreeBSD smilla.rueskamp.com 2.2.6-RELEASE FreeBSD 2.2.6-RELEASE #21: Thu Oct 15 16:26:53 CEST 1998 roof@smilla.rueskamp.com:/u1/src/sys/compile/SMILLA i386 >Description: mail.local inserts a ">" before "From " lines but doesn't insert ">" before ">From " lines. Because of this a mail frontend (like ELM) cannot convert the message back into its original form. >How-To-Repeat: (XXX inserted to preserve 'From ' lines) XXX mail root <From - Thu Jan 1 09:36:29 1998 XXX XXX EOF >Fix: *** mail.local.c.orig Fri Feb 20 18:32:27 1998 --- mail.local.c Tue Nov 3 13:43:37 1998 *************** *** 143,148 **** --- 143,158 ---- exit(eval); } + static + int + fromcmp(line) + char *line; + { + while (*line == '>') + ++line; + return(memcmp(line, "From ", 5)); + } + int store(from) char *from; *************** *** 168,175 **** if (line[0] == '\n') eline = 1; else { ! if (eline && line[0] == 'F' && ! !memcmp(line, "From ", 5)) (void)putc('>', fp); eline = 0; } --- 178,185 ---- if (line[0] == '\n') eline = 1; else { ! if (eline && ((line[0] == 'F') || (line[0] == '>')) && ! !fromcmp(line)) (void)putc('>', fp); eline = 0; } >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 07:50:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA24173 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 07:50:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA24134 for ; Tue, 3 Nov 1998 07:49:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id HAA19381; Tue, 3 Nov 1998 07:50:00 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA23521; Tue, 3 Nov 1998 07:43:55 -0800 (PST) (envelope-from nobody) Message-Id: <199811031543.HAA23521@hub.freebsd.org> Date: Tue, 3 Nov 1998 07:43:55 -0800 (PST) From: ilg@Romania.EU.net To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8555 >Category: kern >Synopsis: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 07:50:00 PST 1998 >Last-Modified: >Originator: Liviu Ionescu >Organization: EUnet Romania >Release: 3.0-RELEASE >Environment: FreeBSD boca.ro.eu.net 3.0-RELEASE FreeBSD 3.0-RELEASE #1: Sun Nov 1 17:06:33 EET 1998 ilg@boca.ro.eu.net:/usr/src/sys/compile/ILGB i386 >Description: hooking one SONY SCSI CD-ROM CDU625-S 1.0r on the 8-bit cable of the secondary SCSI bus of an Intel DK440LX motherboard generates a panic while booting. the problem apears both for the customized kernel and the generic one. inserting a CD in the unit does not help. probably not related to the problem, but display of "target 3 using asynchronous transfers" and next messages is intersparsed with something like "Considering MFS root f/s." captures of serial console output are attached. if you think I can do anything to further diagnose this problem, please let me know. regards, Liviu Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-RELEASE #1: Sun Nov 1 17:06:33 EET 1998 ilg@boca.ro.eu.net:/usr/src/sys/compile/ILGB Timecounter "i8254" frequency 1193182 Hz cost 3250 ns CPU: Pentium II (686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80fbff real memory = 268435456 (262144K bytes) avail memory = 258293760 (252240K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Found BIOS32 Service Directory header at 0xf00f7060 Entry = 0xfd781 (0xf00fd781) Rev = 0 Len = 1 PCI BIOS entry at 0x21c DMI header at 0xf00f7050 Version 2.0 Table at 0xef9a0, 49 entries, 1581 bytes Other BIOS signatures found: ACPI: 00000000 $PnP: 000f7090 SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71808086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x7180, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 3, range 32, base f8000000, size 26 chip0: rev 0x03 on pci0.0.0 found-> vendor=0x8086, dev=0x7181, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1 secondarybus=1 chip1: rev 0x03 on pci0.1.0 found-> vendor=0x8086, dev=0x7110, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 chip2: rev 0x01 on pci0.2.0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 ide_pci0: rev 0x01 on pci0.2.1 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 20 from port: 0000fcb2 ide_pci: ide0:0 has been configured for DMA by BIOS intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 20 from port: 0000fcba ide_pci: ide1:0 has been configured for DMA by BIOS Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=19 chip3: rev 0x01 int d irq 19 on pci0.2.2 found-> vendor=0x8086, dev=0x7113, revid=0x01 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip4: rev 0x01 on pci0.2.3 Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=19 map[0]: type 3, range 32, base fecfc000, size 12 map[1]: type 4, range 32, base 0000fcc0, size 5 map[2]: type 1, range 32, base fed00000, size 20 fxp0: rev 0x02 int a irq 19 on pci0.3.0 fxp0: Ethernet address 00:a0:c9:ac:c4:7b bpf: fxp0 attached Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x9004, dev=0x7895, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=a, irq=17 map[0]: type 4, range 32, base 0000f800, size 8 map[1]: type 1, range 32, base fecff000, size 12 ahc0: rev 0x03 int a irq 17 on pci0.9.0 ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: High byte termination Enabled ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Resetting Channel A ahc0: Downloading Sequencer Program... 384 instructions downloaded Freeing (NOT implemented) redirected PCI irq 9. found-> vendor=0x9004, dev=0x7895, revid=0x03 class=01-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 intpin=b, irq=17 map[0]: type 4, range 32, base 0000f400, size 8 map[1]: type 1, range 32, base fecfe000, size 12 ahc1: rev 0x03 int b irq 17 on pci0.9.1 using shared irq17. ahc1: Reading SEEPROM...done. ahc1: Low byte termination Enabled ahc1: High byte termination Enabled ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs ahc1: Resetting Channel B ahc1: Downloading Sequencer Program... 384 instructions downloaded Probing for devices on PCI bus 1: Freeing (NOT implemented) redirected PCI irq 11. found-> vendor=0x8086, dev=0x7800, revid=0x21 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=16 map[0]: type 3, range 32, base f6000000, size 24 map[1]: type 1, range 32, base feb00000, size 19 vga0: rev 0x21 int a irq 16 on pci1.0.0 Probing for devices on the ISA bus: video: RTC equip. code:0x03, DCC code:0x09 video: CRTC:0x3d4, video option:0x60, rows:80, cols:25, font height:16 video: param table EGA/VGA:0xf00c02b8, CGA/MDA:0 video: rows_offset:1 video#0: adapter type:VGA (5), flags:0x7f, CRTC:0x3d4 video#0: init mode:24, bios mode:3, current mode:24 video#0: window:0xf00b8000 size:32k gran:32k, buf:0xf0000000 size:0k video#0: mode:0, flags:0x1 T 40x25, font:8x8, win:0xb8000 video#0: mode:1, flags:0x1 T 40x25, font:8x8, win:0xb8000 video#0: mode:2, flags:0x1 T 80x25, font:8x8, win:0xb8000 video#0: mode:3, flags:0x1 T 80x25, font:8x8, win:0xb8000 video#0: mode:19, flags:0x1 T 40x25, font:8x14, win:0xb8000 video#0: mode:20, flags:0x1 T 40x25, font:8x14, win:0xb8000 video#0: mode:21, flags:0x1 T 80x25, font:8x14, win:0xb8000 video#0: mode:22, flags:0x1 T 80x25, font:8x14, win:0xb8000 video#0: mode:23, flags:0x1 T 40x25, font:8x16, win:0xb8000 video#0: mode:25, flags:0x0 T 80x25, font:8x16, win:0xb0000 video#0: mode:24, flags:0x1 T 80x25, font:8x16, win:0xb8000 video#0: mode:7, flags:0x0 T 80x25, font:8x14, win:0xb0000 video#0: mode:112, flags:0x1 T 80x43, font:8x8, win:0xb8000 video#0: mode:113, flags:0x1 T 80x43, font:8x8, win:0xb8000 video#0: mode:33, flags:0x0 T 80x30, font:8x16, win:0xb0000 video#0: mode:32, flags:0x1 T 80x30, font:8x16, win:0xb8000 video#0: mode:31, flags:0x0 T 80x50, font:8x8, win:0xb0000 video#0: mode:30, flags:0x1 T 80x50, font:8x8, win:0xb8000 video#0: mode:35, flags:0x0 T 80x60, font:8x8, win:0xb0000 video#0: mode:34, flags:0x1 T 80x60, font:8x8, win:0xb8000 video#0: mode:4, flags:0x3 G 320x200x2, 1 plane(s), font:8x8, win:0xb8000 video#0: mode:5, flags:0x3 G 320x200x2, 1 plane(s), font:8x8, win:0xb8000 video#0: mode:6, flags:0x3 G 640x200x1, 1 plane(s), font:8x8, win:0xb8000 video#0: mode:13, flags:0x3 G 320x200x4, 4 plane(s), font:8x8, win:0xa0000 video#0: mode:14, flags:0x3 G 640x200x4, 4 plane(s), font:8x8, win:0xa0000 video#0: mode:15, flags:0x2 G 640x350x4, 4 plane(s), font:8x14, win:0xa0000 video#0: mode:17, flags:0x2 G 640x350x4, 4 plane(s), font:8x14, win:0xa0000 video#0: mode:16, flags:0x3 G 640x350x2, 2 plane(s), font:8x14, win:0xa0000 video#0: mode:18, flags:0x3 G 640x350x4, 4 plane(s), font:8x14, win:0xa0000 video#0: mode:26, flags:0x3 G 640x480x4, 4 plane(s), font:8x16, win:0xa0000 video#0: mode:27, flags:0x3 G 640x480x4, 4 plane(s), font:8x16, win:0xa0000 video#0: mode:28, flags:0x3 G 320x200x8, 1 plane(s), font:8x8, win:0xa0000 video#0: mode:37, flags:0x3 G 320x240x8, 1 plane(s), font:8x8, win:0xa0000 VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: the current keyboard controller command byte 0045 kbdio: DIAGNOSE status:0055 kbdio: TEST_KBD_PORT status:0000 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0: keyboard device ID: ab41 sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x30 on isa sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 4104MB (8406720 sectors), 8896 cyls, 15 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 wdc1 at 0x170-0x177 irq 15 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface imasks: bio c800c040, tty c708009a, net c708009a SMP: enabled INTs: 1, 3, 4, 6, 7, 14, 15, 17, 19, apic_imen: 0x00f53f25 BIOS Geometries: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 1:0209fe3f 0..521=522 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry bpf: tun0 attached bpf: sl0 attached bpf: sl1 attached bpf: ppp0 attached bpf: ppp1 attached new masks: bio c800c040, tty c708009a, net c708009a bpf: lo0 attached bpf: ds0 attached ccd0-3: Concatenated disk drivers IP Filter: initialized. Default = pass all, Logging = enabledWaiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:X:X): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahc1:0:X:X): SCSI bus reset delivered. 0 SCBs aborted. SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff ahc0: Selection Timeout on A:1. 1 SCBs aborted ahc1: Selection Timeout on A:0. 1 SCBs aborted ahc0: Selection Timeout on A:2. 1 SCBs aborted ahc1: Selection Timeout on A:1. 1 SCBs aborted ahc0: Selection Timeout on A:3. 1 SCBs aborted ahc1: Selection Timeout on A:2. 1 SCBs aborted ahc0: Selection Timeout on A:4. 1 SCBs aborted ahc1: Selection Timeout on A:4. 1 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted ahc1: Selection Timeout on A:5. 1 SCBs aborted ahc0: Selection Timeout on A:6. 1 SCBs aborted ahc1: Selection Timeout on A:6. 1 SCBs aborted ahc0: Selection Timeout on A:8. 1 SCBs aborted ahc1: Selection Timeout on A:8. 1 SCBs aborted ahc0: Selection Timeout on A:9. 1 SCBs aborted ahc1: Selection Timeout on A:9. 1 SCBs aborted ahc0: Selection Timeout on A:10. 1 SCBs aborted ahc1: Selection Timeout on A:10. 1 SCBs aborted ahc0: Selection Timeout on A:11. 1 SCBs aborted ahc1: Selection Timeout on A:11. 1 SCBs aborted ahc0: Selection Timeout on A:12. 1 SCBs aborted ahc1: Selection Timeout on A:12. 1 SCBs aborted ahc0: Selection Timeout on A:13. 1 SCBs aborted ahc1: Selection Timeout on A:13. 1 SCBs aborted ahc0: Selection Timeout on A:14. 1 SCBs aborted ahc1: Selection Timeout on A:14. 1 SCBs aborted ahc0: Selection Timeout on A:15. 1 SCBs aborted ahc0: target 0 using 16bit transfers ahc1: Selection Timeout on A:15. 1 SCBs aborted ahc0: target 0 synchronous at 20.0MHz, offset = 0x8 (probe18:ahc1:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe18:ahc1:0:3:0): ILLEGAL REQUEST asc:24,0 (probe18:ahc1:0:3:0): Invalid field in CDB ahc1: target 3 synchronous at 20.0MHz, offset = 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe18:ahc1:0:3:0): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe0:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe0:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe0:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11a SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 using asynchronous transfers ahc1: target 3 using asynchronous transfers pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI2 device pass0: Serial Number NJ12634600002903H0A1 pass0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled pass1 at ahc1 bus 0 target 3 lun 0 pass1: Removable CD-ROM SCSI2 device pass1: 3.300MB/s transfers pass2 at ahc1 bus 0 target 3 lun 1 pass2: < > Fixed Direct Access SCSI0 device pass2: 3.300MB/s transfers da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number NJ12634600002903H0A1 da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) ahc1: target 3 using asynchronous transfers Coahc1: target 3 using asynchronous transfers nsahc1: target 3 using asynchronous transfers idahc1: target 3 using asynchronous transfers erahc1: target 3 using asynchronous transfers inahc1: target 3 using asynchronous transfers g ahc1: target 3 using asynchronous transfers MFahc1: target 3 using asynchronous transfers S(cd0:ahc1:0:3:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahc1:0:3:0): NOT READY asc:3a,0 (cd0:ahc1:0:3:0): Medium not present cd0 at ahc1 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ahc1: target 3 using asynchronous transfers rahc1: target 3 using asynchronous transfers ooahc1: target 3 using asynchronous transfers t ahc1: target 3 using asynchronous transfers f/ahc1: target 3 using asynchronous transfers s.ahc1: target 3 using asynchronous transfers (da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 (da1:ahc1:0:3:1): Logical unit not supported (da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 (da1:ahc1:0:3:1): Logical unit not supported (da1:ahc1:0:3:1): fatal error, failed to attach to device(da1:ahc1:0:3:1): removing device entry Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x20d50 fault code = supervisor read, page not present instruction pointer = 0x8:0xf0104f95 stack pointer = 0x10:0xf02e0bb8 frame pointer = 0x10:0xf02e0bc8 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 = 0 (swapper) interrupt mask = net tty cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at _xpt_release_ccb+0x55: movl 0x30(%eax),%eax db> sh page cnt.v_free_count: 62867 cnt.v_cache_count: 0 cnt.v_inactive_count: 0 cnt.v_active_count: 0 cnt.v_wire_count: 1116 cnt.v_free_reserved: 0 cnt.v_free_min: 0 cnt.v_free_target: 0 cnt.v_cache_min: 0 cnt.v_inactive_target: 0 db> sh pro p = 0xf02961c0, vmspace = 0xf026c140, map = 0xf026c140, pmap = 0xf026c1a0 Task map 0xf026c140: pmap=0xf026c1a0, nentries=0, version=0 db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 0 f02961c0 f02df000 0 0 0 000204 2 swapper db> ... and the same problem with a CD in the unit: [...] Waiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:X:X): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahc1:0:X:X): SCSI bus reset delivered. 0 SCBs aborted. SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff ahc0: Selection Timeout on A:1. 1 SCBs aborted ahc1: Selection Timeout on A:0. 1 SCBs aborted ahc0: Selection Timeout on A:2. 1 SCBs aborted ahc1: Selection Timeout on A:1. 1 SCBs aborted ahc0: Selection Timeout on A:3. 1 SCBs aborted ahc1: Selection Timeout on A:2. 1 SCBs aborted ahc0: Selection Timeout on A:4. 1 SCBs aborted ahc1: Selection Timeout on A:4. 1 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted ahc1: Selection Timeout on A:5. 1 SCBs aborted ahc0: Selection Timeout on A:6. 1 SCBs aborted ahc1: Selection Timeout on A:6. 1 SCBs aborted ahc0: Selection Timeout on A:8. 1 SCBs aborted ahc1: Selection Timeout on A:8. 1 SCBs aborted ahc0: Selection Timeout on A:9. 1 SCBs aborted ahc1: Selection Timeout on A:9. 1 SCBs aborted ahc0: Selection Timeout on A:10. 1 SCBs aborted ahc1: Selection Timeout on A:10. 1 SCBs aborted ahc0: Selection Timeout on A:11. 1 SCBs aborted ahc1: Selection Timeout on A:11. 1 SCBs aborted ahc0: Selection Timeout on A:12. 1 SCBs aborted ahc1: Selection Timeout on A:12. 1 SCBs aborted ahc0: Selection Timeout on A:13. 1 SCBs aborted ahc1: Selection Timeout on A:13. 1 SCBs aborted ahc0: Selection Timeout on A:14. 1 SCBs aborted ahc1: Selection Timeout on A:14. 1 SCBs aborted ahc0: Selection Timeout on A:15. 1 SCBs aborted ahc0: target 0 using 16bit transfers ahc1: Selection Timeout on A:15. 1 SCBs aborted ahc0: target 0 synchronous at 20.0MHz, offset = 0x8 (probe18:ahc1:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe18:ahc1:0:3:0): ILLEGAL REQUEST asc:24,0 (probe18:ahc1:0:3:0): Invalid field in CDB ahc1: target 3 synchronous at 20.0MHz, offset = 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe18:ahc1:0:3:0): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe0:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11a SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe0:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 synchronous at 20.0MHz, offset = 0xf (probe0:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf ahc1: target 3 using asynchronous transfers ahc1: target 3 using asynchronous transfers ahc1: target 3 using asynchronous transfers pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI2 device pass0: Serial Number NJ12634600002903H0A1 pass0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled pass1 at ahc1 bus 0 target 3 lun 0 pass1: Removable CD-ROM SCSI2 device pass1: 3.300MB/s transfers pass2 at ahc1 bus 0 target 3 lun 1 pass2: < > Fixed Direct Access SCSI0 device pass2: 3.300MB/s transfers da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number NJ12634600002903H0A1 da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) ahc1: target 3 using asynchronous transfers Coahc1: target 3 using asynchronous transfers nscd0 at ahc1 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 3.300MB/s transfers cd0: cd present [214536 x 2048 byte records] ahc1: target 3 using asynchronous transfers idahc1: target 3 using asynchronous transfers erahc1: target 3 using asynchronous transfers inahc1: target 3 using asynchronous transfers g ahc1: target 3 using asynchronous transfers MFahc1: target 3 using asynchronous transfers S ahc1: target 3 using asynchronous transfers roahc1: target 3 using asynchronous transfers o(da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 (da1:ahc1:0:3:1): Logical unit not supported (da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 (da1:ahc1:0:3:1): Logical unit not supported (da1:ahc1:0:3:1): fatal error, failed to attach to device(da1:ahc1:0:3:1): removing device entry Fatal trap 12: page fault while in kernel mode mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 fault virtual address = 0x20d50 fault code = supervisor read, page not present instruction pointer = 0x8:0xf0104f95 stack pointer = 0x10:0xf02e0bb8 frame pointer = 0x10:0xf02e0bc8 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 = 0 (swapper) interrupt mask = net tty cam <- SMP: XXX kernel: type 12 trap, code=0 Stopped at _xpt_release_ccb+0x55: movl 0x30(%eax),%eax db> cor completeness, the same problem with the GENERIC kernel: boot: 1:wd(0,a)kernel Booting 1:wd(0,a)kernel @ 0x100000 text=0x178000 data=0x1c000 bss=0x1de70 symbols=[+0x190+0x4+0x17dcc+0x4+0x216e2] total=0x2eb4b6 entry point=0x100000 BIOS basemem (638K) != RTC basemem (640K), setting to BIOS value BIOS extmem (65532K) != RTC extmem (65535K) Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-RELEASE #0: Sat Oct 17 17:45:06 GMT 1998 jkh@kickme.freebsd.org:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz cost 3031 ns CPU: Pentium II (266.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping=3 Features=0x80fbff real memory = 268435456 (262144K bytes) avail memory = 258510848 (252452K bytes) Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x01 on pci0.2.0 ide_pci0: rev 0x01 on pci0.2.1 chip3: rev 0x01 int d irq 9 on pci0.2.2 chip4: rev 0x01 on pci0.2.3 fxp0: rev 0x02 int a irq 9 on pci0.3.0 fxp0: Ethernet address 00:a0:c9:ac:c4:7b ahc0: rev 0x03 int a irq 9 on pci0.9.0 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Host Adapter Bios disabled. Using default SCSI device parameters ahc1: rev 0x03 int b irq 9 on pci0.9.1 ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs Probing for devices on PCI bus 1: vga0: rev 0x21 int a irq 11 on pci1.0.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 fe0 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0 not found at 0x60 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 4104MB (8406720 sectors), 8896 cyls, 15 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 203MB (415872 sectors), 684 cyls, 16 heads, 38 S/T, 512 B/S wdc1 not found at 0x170 wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 ie0: unknown board_id: f000 ie0 not found at 0x300 ep0 not found at 0x300 ex0 not found le0 not found at 0x300 lnc0 not found at 0x280 ze0 not found at 0x300 zp0 not found at 0x300 cs0 not found at 0x300 adv0 not found at 0x330 bt0 not found at 0x134 aha0 not found at 0x134 npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle (probe18:ahc1:0:3:0): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf (probe1:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf (probe1:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf (probe1:ahc1:0:3:1): parity error during Data-In phase. SEQADDR == 0x11b SCSIRATE == 0xf cda0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) hanging root device to wd0s1a cd0 at ahc1 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present (da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 (da1:ahc1:0:3:1): Logical unit not supported (da1:ahc1:0:3:1): fatal error, failed to attach to device(da1:ahc1:0:3:1): removing device entry swapon: adding /dev/wd0s1b as swap device Automatic reboot in progress... /dev/rwd0s1a: clean, 6335 free (39 frags, 787 blocks, 0.1% fragmentation) /dev/rwd0s1f: clean, 1777296 free (30744 frags, 218319 blocks, 0.9% fragmentation) /dev/rwd0s1e: clean, 28177 free (121 frags, 3507 blocks, 0.4% fragmentation) dmesg: kvm_read: kvm_read: Bad address Doing initial network setup: hostname. fxp0: flags=8843 mtu 1500 inet 193.226.128.210 netmask 0xffffff80 broadcast 193.226.128.255 ether 00:a0:c9:ac:c4:7b media: autoselect supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 add net default: gateway 193.226.128.130 Additional routing options:. recording kernel -c changes additional daemons: syslogd. Doing additional network setup: ntpdate portmap. Starting final network daemons:. setting ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib starting standard daemons: inetd cron sendmailOct 29 15:03:48 boca inetd[112]: setsockopt (SO_PRIVSTATE): Protocol not available >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 10:30:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17689 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 10:30:04 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17628 for ; Tue, 3 Nov 1998 10:30:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id KAA29063; Tue, 3 Nov 1998 10:30:01 -0800 (PST) Date: Tue, 3 Nov 1998 10:30:01 -0800 (PST) Message-Id: <199811031830.KAA29063@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Kenneth D. Merry" Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Reply-To: "Kenneth D. Merry" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8555; it has been noted by GNATS. From: "Kenneth D. Merry" To: ilg@Romania.EU.net Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Date: Tue, 3 Nov 1998 11:20:51 -0700 (MST) --ELM910117251-12016-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ilg@Romania.EU.net wrote... > > >Number: 8555 > >Category: kern > >Synopsis: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Tue Nov 3 07:50:00 PST 1998 > >Last-Modified: > >Originator: Liviu Ionescu > >Organization: > EUnet Romania > >Release: 3.0-RELEASE > >Environment: > FreeBSD boca.ro.eu.net 3.0-RELEASE FreeBSD 3.0-RELEASE #1: Sun Nov 1 17:06:33 EET 1998 ilg@boca.ro.eu.net:/usr/src/sys/compile/ILGB i386 > >Description: > hooking one SONY SCSI CD-ROM CDU625-S 1.0r on the 8-bit cable of the secondary SCSI bus of an Intel DK440LX motherboard generates a panic while booting. the problem apears both for the customized kernel and the generic one. inserting a CD in the unit d oes not help. > > probably not related to the problem, but display of "target 3 using asynchronous transfers" and next messages is intersparsed with something like "Considering MFS root f/s." > > captures of serial console output are attached. > > if you think I can do anything to further diagnose this problem, please let me know. [ ... ] > pass0 at ahc0 bus 0 target 0 lun 0 > pass0: Fixed Direct Access SCSI2 device > pass0: Serial Number NJ12634600002903H0A1 > pass0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled > pass1 at ahc1 bus 0 target 3 lun 0 > pass1: Removable CD-ROM SCSI2 device > pass1: 3.300MB/s transfers > pass2 at ahc1 bus 0 target 3 lun 1 > pass2: < > Fixed Direct Access SCSI0 device > pass2: 3.300MB/s transfers [ ... ] > cd0: Removable CD-ROM SCSI2 device > cd0: 3.300MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present [ ... ] > (da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 > (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 > (da1:ahc1:0:3:1): Logical unit not supported > (da1:ahc1:0:3:1): READ CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 > (da1:ahc1:0:3:1): ILLEGAL REQUEST asc:25,0 > (da1:ahc1:0:3:1): Logical unit not supported > (da1:ahc1:0:3:1): fatal error, failed to attach to device(da1:ahc1:0:3:1): removing device entry > > > Fatal trap 12: page fault while in kernel mode > mp_lock = 01000003; cpuid = 1; lapic.id = 00000000 > fault virtual address = 0x20d50 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf0104f95 > stack pointer = 0x10:0xf02e0bb8 > frame pointer = 0x10:0xf02e0bc8 > 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 = 0 (swapper) > interrupt mask = net tty cam <- SMP: XXX > kernel: type 12 trap, code=0 > Stopped at _xpt_release_ccb+0x55: movl 0x30(%eax),%eax Thanks for the detailed information. I believe this problem (the panic, at least) has been fixed in FreeBSD-current. A lot of the Sony CDROM drives don't behave properly when they are probed on multiple LUNs. Try applying the attached patch to src/sys/cam/cam_xpt.c, and see if it fixes your problem. It disables multi-lun probing for most every Sony CDROM drive, since as far as I can tell, most of them behave badly. The patch may or may not apply cleanly to your version of cam_xpt.c, but at least you can get an idea of the quirk entry you need to disable multi-LUN probing for your CDROM drive. Ken -- Kenneth Merry ken@plutotech.com --ELM910117251-12016-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=cam_xpt.sony_cd_drives_stink.110398 Content-Description: cam_xpt.sony_cd_drives_stink.110398 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/cam_xpt.c#173 - /usr/home/ken/perforce/cam/sys/cam/cam_xpt.c ==== *** /tmp/tmp.7907.0 Tue Nov 3 11:12:25 1998 --- /usr/home/ken/perforce/cam/sys/cam/cam_xpt.c Tue Nov 3 11:04:48 1998 *************** *** 339,350 **** }, { /* ! * This drive doesn't like multiple LUN probing. ! * Verified by: Jean-Marc Zucconi */ { T_CDROM, SIP_MEDIA_REMOVABLE, sony, ! "CD-ROM CDU-80*", "*" }, CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, --- 339,349 ---- }, { /* ! * Many Sony CDROM drives don't like multi-LUN probing. */ { T_CDROM, SIP_MEDIA_REMOVABLE, sony, ! "CD-ROM CDU*", "*" }, CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0 }, --ELM910117251-12016-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 11:10:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22899 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 11:10:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22850 for ; Tue, 3 Nov 1998 11:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id LAA00816; Tue, 3 Nov 1998 11:10:01 -0800 (PST) Date: Tue, 3 Nov 1998 11:10:01 -0800 (PST) Message-Id: <199811031910.LAA00816@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bill Fenner Subject: Re: misc/8494: sbcheck is broken Reply-To: Bill Fenner Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/8494; it has been noted by GNATS. From: Bill Fenner To: freebsd-gnats-submit@FreeBSD.org, avr@juniper.net Cc: Subject: Re: misc/8494: sbcheck is broken Date: Tue, 3 Nov 1998 11:00:04 -0800 (PST) I wrote this code when trying to use sbcheck() myself a while ago. Does this do what you want? Bill cvs diff: Diffing . Index: uipc_socket2.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.39 diff -u -r1.39 uipc_socket2.c --- uipc_socket2.c 1998/09/05 13:24:39 1.39 +++ uipc_socket2.c 1998/11/03 18:58:16 @@ -477,15 +477,17 @@ register struct sockbuf *sb; { register struct mbuf *m; + register struct mbuf *n = 0; register int len = 0, mbcnt = 0; - for (m = sb->sb_mb; m; m = m->m_next) { + for (m = sb->sb_mb; m; m = n) { + n = m->m_nextpkt; + for (; m; m = m->m_next) { len += m->m_len; mbcnt += MSIZE; if (m->m_flags & M_EXT) /*XXX*/ /* pretty sure this is bogus */ mbcnt += m->m_ext.ext_size; - if (m->m_nextpkt) - panic("sbcheck nextpkt"); + } } if (len != sb->sb_cc || mbcnt != sb->sb_mbcnt) { printf("cc %d != %d || mbcnt %d != %d\n", len, sb->sb_cc, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 11:11:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23388 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 11:11:35 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23371; Tue, 3 Nov 1998 11:11:18 -0800 (PST) (envelope-from gibbs@FreeBSD.org) From: "Justin T. Gibbs" Received: (from gibbs@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id LAA00869; Tue, 3 Nov 1998 11:11:20 -0800 (PST) Date: Tue, 3 Nov 1998 11:11:20 -0800 (PST) Message-Id: <199811031911.LAA00869@freefall.freebsd.org> To: ilg@Romania.EU.net, gibbs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8555 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked State-Changed-From-To: open-feedback State-Changed-By: gibbs State-Changed-When: Tue Nov 3 11:09:56 PST 1998 State-Changed-Why: I'm not positive that this is a multi-lun probing problem. The parity errors on the second channel indicate a potential cabeling or termination issue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 12:20:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03936 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 12:20:08 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03868 for ; Tue, 3 Nov 1998 12:20:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id MAA03189; Tue, 3 Nov 1998 12:20:02 -0800 (PST) Received: from niobe.ewox.org (ppp108.uio.no [129.240.240.113]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03160 for ; Tue, 3 Nov 1998 12:15:50 -0800 (PST) (envelope-from finrod@niobe.ewox.org) Received: (from finrod@localhost) by niobe.ewox.org (8.9.1/8.9.1) id VAA25432; Tue, 3 Nov 1998 21:15:42 +0100 (CET) (envelope-from finrod) Message-Id: <199811032015.VAA25432@niobe.ewox.org> Date: Tue, 3 Nov 1998 21:15:42 +0100 (CET) From: des@FreeBSD.ORG Reply-To: des@FreeBSD.ORG To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8560: [REMINDER] bpfilter is deprecated and should be removed Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8560 >Category: kern >Synopsis: [REMINDER] bpfilter is deprecated and should be removed >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 12:20:01 PST 1998 >Last-Modified: >Originator: Dag-Erling Smørgrav >Organization: The FreeBSD Project >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD 3.0-CURRENT >Description: The 'bpfilter' pseudo-device is deprecated and should be removed. >How-To-Repeat: Not relevant. >Fix: $ cd src/sys/conf $ grep -v bpfilter files > xfiles $ mv xfiles files >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 12:26:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04562 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 12:26:22 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04365; Tue, 3 Nov 1998 12:24:47 -0800 (PST) (envelope-from des@FreeBSD.org) From: "Dag-Erling C. Sm\xf8rgrav" Received: (from des@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id MAA03350; Tue, 3 Nov 1998 12:24:49 -0800 (PST) Date: Tue, 3 Nov 1998 12:24:49 -0800 (PST) Message-Id: <199811032024.MAA03350@freefall.freebsd.org> To: des@FreeBSD.ORG, des@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, des@FreeBSD.ORG Subject: Re: kern/8560 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [REMINDER] bpfilter is deprecated and should be removed State-Changed-From-To: open-suspended State-Changed-By: des State-Changed-When: Tue Nov 3 12:24:00 PST 1998 State-Changed-Why: Just a reminder. Responsible-Changed-From-To: freebsd-bugs->des Responsible-Changed-By: des Responsible-Changed-When: Tue Nov 3 12:24:00 PST 1998 Responsible-Changed-Why: Just a reminder. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 12:40:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06400 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 12:40:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06371 for ; Tue, 3 Nov 1998 12:39:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id MAA04105; Tue, 3 Nov 1998 12:40:01 -0800 (PST) Received: from mgw.inetex.com (news2.wlc.com [204.239.181.4] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06361 for ; Tue, 3 Nov 1998 12:39:42 -0800 (PST) (envelope-from cys@mgw.inetex.com) Received: (from root@localhost) by mgw2.inetex.com (8.9.1/8.9.1) id EAA00305; Tue, 3 Nov 1998 04:55:24 -0800 (PST) Message-Id: <199811031255.EAA00305@mgw2.inetex.com> Date: Tue, 3 Nov 1998 04:55:24 -0800 (PST) From: cys@wlc.com Reply-To: cys@wlc.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8561: kernel inode change Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8561 >Category: kern >Synopsis: /kernel inode change time changes every reboot >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 12:40:00 PST 1998 >Last-Modified: >Originator: Cy Schubert for wlc.com >Organization: Westcoast LAN Company Ltd. >Release: FreeBSD 2.2.7-STABLE i386 >Environment: FreeBSD mgw2.inetex.com 2.2.7-STABLE FreeBSD 2.2.7-STABLE #0: Mon Nov 2 19:33:53 PST 1998 root@mgw2.inetex.com:/usr/src/sys/compile/MGW i386 >Description: Whenever this system (-stable from Oct 26) reboots, /kernel inode change time is altered to the time of reboot. >How-To-Repeat: reboot >Fix: Unknown >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 14:50:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26756 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 14:50:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26704 for ; Tue, 3 Nov 1998 14:49:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id OAA10906; Tue, 3 Nov 1998 14:50:01 -0800 (PST) Date: Tue, 3 Nov 1998 14:50:01 -0800 (PST) Message-Id: <199811032250.OAA10906@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Wolfram Schneider Subject: Re: bin/8553: /usr/libexec/mail.local doesn't handle ">From " lines transparently Reply-To: Wolfram Schneider Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/8553; it has been noted by GNATS. From: Wolfram Schneider To: br@rueskamp.com, FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: bin/8553: /usr/libexec/mail.local doesn't handle ">From " lines transparently Date: Tue, 3 Nov 1998 21:55:53 +0100 > >Description: > mail.local inserts a ">" before "From " lines > but doesn't insert ">" before ">From " lines. > Because of this a mail frontend (like ELM) cannot convert > the message back into its original form. I would like if we insert a space or a tab instead the ">" before a "From " line. A space is a harmless character in most computer or human languages. The ">" is not, for example in LaTeX it will create strange output. See The UNIX-HATERS Handbook Wolfram To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 15:40:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04625 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 15:40:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA04583 for ; Tue, 3 Nov 1998 15:39:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id PAA14559; Tue, 3 Nov 1998 15:40:00 -0800 (PST) Date: Tue, 3 Nov 1998 15:40:00 -0800 (PST) Message-Id: <199811032340.PAA14559@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bodo Rueskamp Subject: Re: bin/8553: /usr/libexec/mail.local doesn't handle ">From " lines transparently Reply-To: Bodo Rueskamp Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/8553; it has been noted by GNATS. From: Bodo Rueskamp To: wosch@panke.de.freebsd.org (Wolfram Schneider) Cc: br@rueskamp.com, FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/8553: /usr/libexec/mail.local doesn't handle ">From " lines transparently Date: Wed, 4 Nov 1998 00:32:18 +0100 (CET) Wolfram: > Bodo: > > mail.local inserts a ">" before "From " lines > > but doesn't insert ">" before ">From " lines. > > Because of this a mail frontend (like ELM) cannot convert > > the message back into its original form. > > I would like if we insert a space or a tab instead the ">" > before a "From " line. > > A space is a harmless character in most computer or > human languages. The ">" is not, for example in LaTeX it will > create strange output. See The UNIX-HATERS Handbook The '>' char is UNIX standard since 20 years (or more). We shouldn't change that. We just have to do the escape algorithm right. (and do the right unescape algorithm in /usr/bin/mail et al) ; Bodo -- Bodo Rüskamp, br@rueskamp.com, 51°55' N 7°41' E A Unix a day keeps Linux away. . f y cnnt rd ths y mst b sng a brkn mlr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 16:00:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07479 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 16:00:06 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07409 for ; Tue, 3 Nov 1998 16:00:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id QAA15503; Tue, 3 Nov 1998 16:00:02 -0800 (PST) Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06584 for ; Tue, 3 Nov 1998 15:53:00 -0800 (PST) (envelope-from shmit@natasya.noc.erols.net) Received: from natasya.noc.erols.net (natasya.noc.erols.net [207.172.25.236]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id SAA18369 for ; Tue, 3 Nov 1998 18:53:54 -0500 (EST) Received: (from shmit@localhost) by natasya.noc.erols.net (8.9.1/8.9.1) id SAA00472; Tue, 3 Nov 1998 18:52:51 -0500 (EST) Message-Id: <199811032352.SAA00472@natasya.noc.erols.net> Date: Tue, 3 Nov 1998 18:52:51 -0500 (EST) From: Brian Cully Reply-To: shmit@rcn.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8565: New bootloader fails with new kernel Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8565 >Category: kern >Synopsis: New bootloader fails with new kernel >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 16:00:01 PST 1998 >Last-Modified: >Originator: Brian Cully >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD natasya.noc.erols.net 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Thu Oct 29 20:23:50 EST 1998 shmit@natasya.noc.erols.net:/usr/src/sys/compile/NATASYA i386 This is an ELF kernel, I haven't tried with an a.out kernel yet. -[Kernel config]- ident "NATASYA" # # Chipset options. # machine "i386" cpu "I586_CPU" # # Boot time options. # config kernel root on wd0 options USERCONFIG options FFS_ROOT # # Debugging options. # options DDB options DDB_UNATTENDED options KTRACE #options DIAGNOSTIC # Extra sanity checking. # # File system options. # options FFS options MSDOSFS #options "EXT2FS" options "CD9660" options FDESC #options DEVFS #options SLICE # Allow FreeBSD to use Soft Updates, see LINT. options SOFTUPDATES # # Networking options. # options INET options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options "IPFIREWALL_VERBOSE_LIMIT=100" # Network pseudo devices. Regular devices in the HARDWARE section. pseudo-device ether pseudo-device loop pseudo-device bpfilter 4 # # Compatibility options. # options "COMPAT_43" options SYSVSHM options SYSVSEM options SYSVMSG # # Miscellaneous options. # maxusers 64 # # Hardware. # # Hardware controllers. controller isa0 controller pnp0 controller pci0 # Console interface. device sc0 at isa? port "IO_KBD" tty flags 0x03 irq 1 options "MAXCONS=4" # Number of Virtual Consoles. options "SC_HISTORY_SIZE=200" # Number of lines in history buffer. options SC_DISABLE_REBOOT # Disable CTRL-ALT-DEL reboot. options UCONSOLE # Allow users to grab console (for X). options XSERVER # I/O subsystem. device lpt0 at isa? port? tty irq 7 device sio0 at isa? port "IO_COM1" tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 # SCSI subsystem. controller scbus0 device da0 device sa0 device pass0 # SCSI controllers. controller ahc0 # IDE subsystem. controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 # Networking subsystem. device de0 #device vx0 # Sound subsystem. device pcm0 at isa? port ? irq ? tty # Miscellaneous devices. device npx0 at isa? port "IO_NPX" iosiz 0x0 flags 0x0 irq 13 #device bktr0 pseudo-device pty 16 >Description: When booting the above kernel config, with sources CVSupped to-day (03-November-98), I get the following message while booting: config> autocheck gives assize=0 asp=0 The comes right after the memory probe. At this point my machine hangs. >How-To-Repeat: Boot the above kernel. >Fix: Dunno. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 16:30:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13832 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 16:30:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA13773 for ; Tue, 3 Nov 1998 16:30:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id QAA17144; Tue, 3 Nov 1998 16:30:01 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA12942 for ; Tue, 3 Nov 1998 16:23:27 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA19252 for ; Tue, 3 Nov 1998 16:23:15 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma019248; Tue Nov 3 16:22:58 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id QAA16848; Tue, 3 Nov 1998 16:22:57 -0800 (PST) Message-Id: <199811040022.QAA16848@bubba.whistle.com> Date: Tue, 3 Nov 1998 16:22:57 -0800 (PST) From: Archie Cobbs Reply-To: archie@whistle.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/8566: mergesort() core dumps if number of elements is zero Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8566 >Category: bin >Synopsis: mergesort() core dumps if number of elements is zero >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 16:30:01 PST 1998 >Last-Modified: >Originator: Archie Cobbs >Organization: Whistle Communications, Inc. >Release: FreeBSD 2.2.6-RELEASE i386 >Environment: FreeBSD 2.2-stable AND 3.0-current >Description: If meregsort() is called with number of elements == 0, it will still try to compare them (!), causing a core dump or worse. >How-To-Repeat: Compile and run this program: #include #include static int compare(const void *v1, const void *v2) { return(*((int *) v1) - *((int *) v2)); } int main(void) { int *array = NULL; if (mergesort(array, 0, 4, compare) < 0) err(1, "mergesort"); } >Fix: NOTE: Please fix this in BOTH 2.2 and 3.0.. thanks! Index: merge.c =================================================================== RCS file: /cvs/freebsd/src/lib/libc/stdlib/merge.c,v retrieving revision 1.2 diff -u -r1.2 merge.c --- merge.c 1995/05/30 05:41:50 1.2 +++ merge.c 1998/11/04 00:19:56 @@ -111,6 +111,9 @@ return (-1); } + if (nmemb == 0) + return (0); + /* * XXX * Stupid subtraction for the Cray. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 17:50:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24531 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 17:50:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24494 for ; Tue, 3 Nov 1998 17:49:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id RAA21262; Tue, 3 Nov 1998 17:50:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA23681; Tue, 3 Nov 1998 17:40:13 -0800 (PST) (envelope-from nobody) Message-Id: <199811040140.RAA23681@hub.freebsd.org> Date: Tue, 3 Nov 1998 17:40:13 -0800 (PST) From: ctapang@easystreet.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: i386/8567: Intel EtherExpress Pro/10 driver (if_ex.c) fails to recognize Plus card (Pro/10+) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8567 >Category: i386 >Synopsis: Intel EtherExpress Pro/10 driver (if_ex.c) fails to recognize Plus card (Pro/10+) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 17:50:01 PST 1998 >Last-Modified: >Originator: Carlos C. Tapang >Organization: n/a >Release: 2.2.7 >Environment: Not needed. I have already debugged and fixed the problem, but my fix needs to be tested on a regular, non-Plus Pro/10 card. >Description: The ethernet card driver if_ex.c fails to recognize my Pro/10+ card. It thinks it's a regular Pro/10 and therefore does not work at all. >How-To-Repeat: Need a Pro/10+ card with Ethernet Address that starts with 00:AA:00. The driver uses the Ethernet Address to distinguish between the Pro/10+ and the regular, older Pro/10. However, some Pro/10+ cards, like mine, has an Ethernet Address which starts with the same 3 bytes as that for regular Pro/10s. >Fix: The fix is to read the stepping of the i82595 chip on the card. If the steping is 4 or more, then the chip is an FX, which the chip used in the Pro/10+. Otherwise, it's a regular Pro/10. I have the fix, but since I can not submit it with this web form, I do not know how to submit the fixed code. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 21:00:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17018 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 21:00:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA16974 for ; Tue, 3 Nov 1998 21:00:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id VAA02463; Tue, 3 Nov 1998 21:00:01 -0800 (PST) Received: from cheshire.dynip.com (pm-wsh1-60.coastalnet.com [205.245.121.60]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA16647 for ; Tue, 3 Nov 1998 20:58:50 -0800 (PST) (envelope-from ryan@cheshire.dynip.com) Received: (from ryan@localhost) by cheshire.dynip.com (8.9.1/8.9.1) id XAA16334; Tue, 3 Nov 1998 23:58:26 -0500 (EST) (envelope-from ryan) Message-Id: <199811040458.XAA16334@cheshire.dynip.com> Date: Tue, 3 Nov 1998 23:58:26 -0500 (EST) From: ryany@pobox.com Reply-To: ryany@pobox.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/8568: du(1) usage message missing "-c" option Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8568 >Category: bin >Synopsis: du(1) usage message missing "-c" option >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 21:00:01 PST 1998 >Last-Modified: >Originator: Ryan Younce >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD cheshire.dynip.com 3.0-CURRENT FreeBSD 3.0-CURRENT #10: Sat Oct 24 13:01:15 GMT 1998 ryan@cheshire.dynip.com:/usr/src/sys/compile/CHESHIRE i386 >Description: the "-c" option of du(1) (which displays grand total disk usage of all files or directories passed to du) is not included in the du(1) usage message >How-To-Repeat: du -h >Fix: *** du.c.orig Tue Nov 3 23:30:35 1998 --- du.c Tue Nov 3 23:30:47 1998 *************** *** 263,268 **** usage() { (void)fprintf(stderr, ! "usage: du [-H | -L | -P] [-a | -s | -d depth] [-k] [-x] [file ...]\n"); exit(1); } --- 263,268 ---- usage() { (void)fprintf(stderr, ! "usage: du [-H | -L | -P] [-a | -s | -d depth] [-c] [-k] [-x] [file ...]\n"); exit(1); } >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 21:03:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17569 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 21:03:55 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA17561; Tue, 3 Nov 1998 21:03:53 -0800 (PST) (envelope-from pst@juniper.net) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA17226; Tue, 3 Nov 1998 21:03:45 -0800 (PST) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.9.1/8.7.3) with ESMTP id VAA03130; Tue, 3 Nov 1998 21:03:44 -0800 (PST) Message-Id: <199811040503.VAA03130@base.juniper.net> To: bugs@FreeBSD.ORG cc: pwemm@FreeBSD.ORG Subject: panic: vrele: negative ref count Date: Tue, 03 Nov 1998 21:03:44 -0800 From: Paul Traina Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been seeing a slew of these ever since I updated to -current yesterday. Sorry, I didn't get a good core. Are you aware of the problem? If not, I'll make sure you get a traceback. Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Tue Nov 3 23:30:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA07978 for freebsd-bugs-outgoing; Tue, 3 Nov 1998 23:30:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA07969 for ; Tue, 3 Nov 1998 23:29:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA09177; Tue, 3 Nov 1998 23:30:00 -0800 (PST) Received: from diginix.net (diginix.net [206.222.176.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA07094 for ; Tue, 3 Nov 1998 23:24:59 -0800 (PST) (envelope-from ncb@diginix.net) Received: (from root@localhost) by diginix.net (8.8.8/8.8.8) id XAA15378; Tue, 3 Nov 1998 23:26:00 -0600 (CST) (envelope-from ncb) Message-Id: <199811040526.XAA15378@diginix.net> Date: Tue, 3 Nov 1998 23:26:00 -0600 (CST) From: root@diginix.net Reply-To: ncb@attrition.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8570: patch for randomised process id allocation Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8570 >Category: kern >Synopsis: patch for randomised process id allocation >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Nov 3 23:30:00 PST 1998 >Last-Modified: >Originator: Charlie & >Organization: none >Release: FreeBSD 2.2.7-RELEASE i386 >Environment: i386 FreeBSD 2.2 system. >Description: The incremental nature of current process id allocation can lend itself to a number of potentially serious security problems. This patch allocates a pid using the kernels random() function in libkern. It is nearly the same as OpenBSD's equivalent, only difference being that obsd uses the arc4random() PRNG. >How-To-Repeat: >Fix: *** kern_fork.c.orig Mon Nov 2 22:11:24 1998 --- kern_fork.c Tue Nov 3 21:41:13 1998 *************** *** 53,58 **** --- 53,61 ---- #include #include #include + #include + #include + #include #include #include *************** *** 113,119 **** --- 116,124 ---- int nprocs = 1; /* process 0 */ + static int randompid = 1; /* set to 1 for randomised pids */ static int nextpid = 0; + SYSCTL_INT(_kern, OID_AUTO, randompid, CTLFLAG_RW, &randompid, 0, ""); static int fork1(p1, flags, retval) *************** *** 124,129 **** --- 129,135 ---- register struct proc *p2, *pptr; register uid_t uid; struct proc *newproc; + struct timeval tv; int count; static int pidchecked = 0; fle_p ep ; *************** *** 174,179 **** --- 180,187 ---- * ready to use (from nextpid+1 through pidchecked-1). */ nextpid++; + if (randompid) + nextpid = PID_MAX; retry: /* * If the process ID prototype has wrapped around, *************** *** 181,188 **** * tend to include daemons that don't exit. */ if (nextpid >= PID_MAX) { ! nextpid = 100; ! pidchecked = 0; } if (nextpid >= pidchecked) { int doingzomb = 0; --- 189,206 ---- * tend to include daemons that don't exit. */ if (nextpid >= PID_MAX) { ! if(randompid) ! { ! microtime(&tv); ! srandom(tv.tv_sec ^ tv.tv_usec); ! nextpid = random() % PID_MAX; ! pidchecked = 0; ! } ! else ! { ! nextpid = 100; ! pidchecked = 0; ! } } if (nextpid >= pidchecked) { int doingzomb = 0; >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 00:10:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14739 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 00:10:02 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14684 for ; Wed, 4 Nov 1998 00:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id AAA11147; Wed, 4 Nov 1998 00:10:01 -0800 (PST) Date: Wed, 4 Nov 1998 00:10:01 -0800 (PST) Message-Id: <199811040810.AAA11147@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: David Greenman Subject: Re: kern/8570: patch for randomised process id allocation Reply-To: David Greenman Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8570; it has been noted by GNATS. From: David Greenman To: ncb@attrition.org Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/8570: patch for randomised process id allocation Date: Wed, 04 Nov 1998 00:01:06 -0800 > The incremental nature of current process id allocation can lend > itself to a number of potentially serious security problems. This > patch allocates a pid using the kernels random() function in > libkern. It is nearly the same as OpenBSD's equivalent, only > difference being that obsd uses the arc4random() PRNG. Sounds like a serious pessimization to me. You're going to need a lot of justification for the alleged improved security that this brings before I'll buy into it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 00:10:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14761 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 00:10:07 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA14689 for ; Wed, 4 Nov 1998 00:10:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id AAA11156; Wed, 4 Nov 1998 00:10:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13802; Wed, 4 Nov 1998 00:03:12 -0800 (PST) (envelope-from nobody) Message-Id: <199811040803.AAA13802@hub.freebsd.org> Date: Wed, 4 Nov 1998 00:03:12 -0800 (PST) From: igusarov@crow.mephi.net.ru To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: i386/8571: Bug in config utility in FreeBSD 2.2.6-RELEASE Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8571 >Category: i386 >Synopsis: Bug in config utility in FreeBSD 2.2.6-RELEASE >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Nov 4 00:10:01 PST 1998 >Last-Modified: >Originator: Igor Goussarov >Organization: Moscow Engineering and Physics Institute >Release: 2.2.6 >Environment: FreeBSD crow.mephi.net.ru 2.2.6-RELEASE FreeBSD 2.2.6-RELEASE #0: Sat Apr 25 18:54:30 MSD 1998 root@crow.mephi.ru:/usr/src/sys/compile/CROW i386 >Description: CONFIG incorrectly processes explicitly supplied IO addresses for IDE controller (wdc). When I try to set it's IO address for wdc controller via "port" parametr even to it's standard value 0x0170, the kernel compilation fails with error in ioconf.c >How-To-Repeat: Make a copy of standard config file: cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/TMP And edit the lines in /usr/src/sys/i386/conf/TMP so that the definition of IDE controller looks like controller wdc1 at isa? port 0x0170 bio irq 15 flags 0x80ff80ff vector wdintr disk wd2 at wdc1 drive 0 It'll produce the following lines in /usr/src/sys/compile/TMP/ioconf.c struct isa_device isa_devtab_bio[] = { /* id driver iobase irq drq maddr msiz intr unit flags scsiid alive ri_flags reconfig enabled conflicts next */ { 6, &fdcdriver, IO_FD1, IRQ6, 2, C 0x00000, 0, fdintr, 0, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, { 7, &wdcdriver, IO_WD1, IRQ14, -1, C 0x00000, 0, wdintr, 0, 0x80FF80FF, 0, 0, 0, 0, 1, 0, 0 }, { 8, &wdcdriver, 0x0170, IRQ15, -1, C 0x00000, 0, wdintr, 1, 0x80FF80FF, 0, 0, 0, 0, 1, 0, 0 }, 0}; struct isa_device isa_biotab_wdc[] = { /* id driver iobase irq drq maddr msiz intr unit flags drive alive ri_flags reconfig enabled conflicts next */ { -1, &wdcdriver, IO_WD1, IRQ14, -1, C 0x00000, 0, wdintr, 0, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, { -1, &wdcdriver, IO_WD1, IRQ14, -1, C 0x00000, 0, wdintr, 1, 0x0000, 1, 0, 0, 0, 1, 0, 0 }, { -1, &wdcdriver, (null), IRQ15, -1, C 0x00000, 0, wdintr, 2, 0x0000, 0, 0, 0, 0, 1, 0, 0 }, 0}; No doubt, the kernel with (null) instead of wdc1 IO base address can't be compiled. Note that in isa_devtab_bio structure IO address stated correctly. >Fix: This situation can be avoided only if I type controller wdc1 at isa? port "0x0170" bio irq 15 flags 0x80ff80ff vector wdintr then that port address appears in ioconf.c as it was given in config file and such kernel compiles just fine. So as far as all the other devices can be configured with IO address without any quotation marks and this controller can not - thus I guess it's a kind of bug. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 00:40:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18180 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 00:40:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA18175 for ; Wed, 4 Nov 1998 00:39:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id AAA12379; Wed, 4 Nov 1998 00:40:00 -0800 (PST) Date: Wed, 4 Nov 1998 00:40:00 -0800 (PST) Message-Id: <199811040840.AAA12379@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Carlos C. Tapang" Subject: Re: i386/8567 Reply-To: "Carlos C. Tapang" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/8567; it has been noted by GNATS. From: "Carlos C. Tapang" To: Cc: Subject: Re: i386/8567 Date: Wed, 4 Nov 1998 01:30:16 -0800 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BE0792.AD989430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Pls. see attached files. I am new to this, so I may not have attached the correct format. Please let me know. --Carlos ------=_NextPart_000_002C_01BE0792.AD989430 Content-Type: application/octet-stream; name="if_ex.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="if_ex.diff" SW5kZXg6IGlmX2V4LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9jdnNyb290L3NyYy9zeXMv aTM4Ni9pc2EvaWZfZXguYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMgpkaWZmIC1jIC1yMS4x MiBpZl9leC5jCioqKiBpZl9leC5jCTE5OTgvMDYvMDcgMTc6MTA6MzAJMS4xMgotLS0gaWZfZXgu YwkxOTk4LzExLzA0IDAwOjE5OjQ1CioqKioqKioqKioqKioqKgoqKiogMjMsMzQgKioqKgogICAq IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkKICAgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBF VkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCiAgICogU1VDSCBEQU1BR0UuCi0g ICoKLSAgKgkkSWQ6IGlmX2V4LmMsdiAxLjEyIDE5OTgvMDYvMDcgMTc6MTA6MzAgZGZyIEV4cCAk CiAgICovCiAgCiAgLyoKISAgKiBJbnRlbCBFdGhlckV4cHJlc3MgUHJvLzEwLCBQcm8vMTArIEV0 aGVybmV0IGRyaXZlcgogICAqCiAgICogUmV2aXNpb24gaGlzdG9yeToKICAgKgotLS0gMjMsMzIg LS0tLQogICAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RI RVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKICAgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNP RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCiAgICogU1VDSCBE QU1BR0UuCiAgICovCiAgCiAgLyoKISAgKiBJbnRlbCBFdGhlckV4cHJlc3MgUHJvLzEwIEV0aGVy bmV0IGRyaXZlcgogICAqCiAgICogUmV2aXNpb24gaGlzdG9yeToKICAgKgoqKioqKioqKioqKioq KioKKioqIDM4LDU3ICoqKioKICAjaW5jbHVkZSAiZXguaCIKICAjaWYgTkVYID4gMAogICNpbmNs dWRlICJicGZpbHRlci5oIgotICNpbmNsdWRlICJvcHRfaW5ldC5oIgotICNpbmNsdWRlICJvcHRf aXB4LmgiCiAgCiAgI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogICNpbmNsdWRlIDxzeXMvc3lzdG0u aD4KICAjaW5jbHVkZSA8c3lzL2NvbmYuaD4KISAjaW5jbHVkZSA8c3lzL3NvY2tpby5oPgogICNp bmNsdWRlIDxzeXMvbWJ1Zi5oPgogICNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CiAgCiAgI2luY2x1 ZGUgPG5ldC9pZi5oPgogIAogICNpZmRlZiBJTkVUCiAgI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4K ICAjaW5jbHVkZSA8bmV0aW5ldC9pZl9ldGhlci5oPgogICNlbmRpZgogIAotLS0gMzYsNjEgLS0t LQogICNpbmNsdWRlICJleC5oIgogICNpZiBORVggPiAwCiAgI2luY2x1ZGUgImJwZmlsdGVyLmgi CiAgCiAgI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogICNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKyAj aW5jbHVkZSA8c3lzL2tlcm5lbC5oPgogICNpbmNsdWRlIDxzeXMvY29uZi5oPgohICNpbmNsdWRl IDxzeXMvZXJybm8uaD4KISAjaW5jbHVkZSA8c3lzL2lvY3RsLmg+CiAgI2luY2x1ZGUgPHN5cy9t YnVmLmg+CiAgI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyAjaW5jbHVkZSA8c3lzL3N5c2xvZy5o PgogIAogICNpbmNsdWRlIDxuZXQvaWYuaD4KKyAjaW5jbHVkZSA8bmV0L2lmX2RsLmg+CisgI2lu Y2x1ZGUgPG5ldC9pZl90eXBlcy5oPgogIAogICNpZmRlZiBJTkVUCiAgI2luY2x1ZGUgPG5ldGlu ZXQvaW4uaD4KKyAjaW5jbHVkZSA8bmV0aW5ldC9pbl9zeXN0bS5oPgorICNpbmNsdWRlIDxuZXRp bmV0L2luX3Zhci5oPgorICNpbmNsdWRlIDxuZXRpbmV0L2lwLmg+CiAgI2luY2x1ZGUgPG5ldGlu ZXQvaWZfZXRoZXIuaD4KICAjZW5kaWYKICAKKioqKioqKioqKioqKioqCioqKiA2Nyw3MiAqKioq Ci0tLSA3MSw3NyAtLS0tCiAgCiAgI2lmIE5CUEZJTFRFUiA+IDAKICAjaW5jbHVkZSA8bmV0L2Jw Zi5oPgorICNpbmNsdWRlIDxuZXQvYnBmZGVzYy5oPgogICNlbmRpZgogIAogICNpbmNsdWRlIDxt YWNoaW5lL2Nsb2NrLmg+CioqKioqKioqKioqKioqKgoqKiogNzQsODUgKioqKgogICNpbmNsdWRl IDxpMzg2L2lzYS9pc2FfZGV2aWNlLmg+CiAgI2luY2x1ZGUgPGkzODYvaXNhL2lmX2V4cmVnLmg+ CiAgCiAgI2lmZGVmIEVYREVCVUcKICAjZGVmaW5lIFN0YXJ0X0VuZCAxCiAgI2RlZmluZSBSY3Zk X1BrdHMgMgogICNkZWZpbmUgU2VudF9Qa3RzIDQKICAjZGVmaW5lIFN0YXR1cyAgICA4CiEgc3Rh dGljIGludCBkZWJ1Z19tYXNrID0gMDsKICBzdGF0aWMgaW50IGV4aW50cl9jb3VudCA9IDA7CiAg I2RlZmluZSBET0RFQlVHKGxldmVsLCBhY3Rpb24pIGlmIChsZXZlbCAmIGRlYnVnX21hc2spIGFj dGlvbgogICNlbHNlCi0tLSA3OSw5MSAtLS0tCiAgI2luY2x1ZGUgPGkzODYvaXNhL2lzYV9kZXZp Y2UuaD4KICAjaW5jbHVkZSA8aTM4Ni9pc2EvaWZfZXhyZWcuaD4KICAKKyAKICAjaWZkZWYgRVhE RUJVRwogICNkZWZpbmUgU3RhcnRfRW5kIDEKICAjZGVmaW5lIFJjdmRfUGt0cyAyCiAgI2RlZmlu ZSBTZW50X1BrdHMgNAogICNkZWZpbmUgU3RhdHVzICAgIDgKISBzdGF0aWMgaW50IGRlYnVnX21h c2sgPSAweEY7CiAgc3RhdGljIGludCBleGludHJfY291bnQgPSAwOwogICNkZWZpbmUgRE9ERUJV RyhsZXZlbCwgYWN0aW9uKSBpZiAobGV2ZWwgJiBkZWJ1Z19tYXNrKSBhY3Rpb24KICAjZWxzZQoq KioqKioqKioqKioqKioKKioqIDkzLDk4ICoqKioKLS0tIDk5LDEwNSAtLS0tCiAgc3RydWN0IGV4 X3NvZnRjIHsKICAgIAlzdHJ1Y3QgYXJwY29tIGFycGNvbTsJLyogRXRoZXJuZXQgY29tbW9uIGRh dGEgKi8KICAJdV9pbnQgaW9iYXNlOwkvKiBJL08gYmFzZSBhZGRyZXNzLiAqLworIAl1X3Nob3J0 IGNoaXBfc3RlcHBpbmc7IC8qIGVpdGhlciBUWCBvciBGWCAoRlggaXMgdXNlZCBpbiBQcm8vMTAr KSAqLwogIAl1X3Nob3J0IGNvbm5lY3RvcjsJLyogQ29ubmVjdG9yIHR5cGUuICovCiAgCXVfc2hv cnQgaXJxX25vOyAvKiBJUlEgbnVtYmVyLiAqLwogIAljaGFyICppcnEyZWU7IC8qIGlycSA8LT4g aW50ZXJuYWwgcmVwcmVzZW50YXRpb24gY29udmVyc2lvbiAqLwoqKioqKioqKioqKioqKioKKioq IDExOSwxMjUgKioqKgogIHN0YXRpYyB2b2lkIGV4X2luaXQgX19QKCh2b2lkICopKTsKICBzdGF0 aWMgdm9pZCBleF9zdGFydCBfX1AoKHN0cnVjdCBpZm5ldCAqKSk7CiAgc3RhdGljIHZvaWQgZXhf c3RvcCBfX1AoKGludCkpOwohIHN0YXRpYyBpbnQgZXhfaW9jdGwgX19QKChzdHJ1Y3QgaWZuZXQg KiwgdV9sb25nLCBjYWRkcl90KSk7CiAgc3RhdGljIHZvaWQgZXhfcmVzZXQgX19QKChpbnQpKTsK ICBzdGF0aWMgdm9pZCBleF93YXRjaGRvZyBfX1AoKHN0cnVjdCBpZm5ldCAqKSk7CiAgCi0tLSAx MjYsMTMyIC0tLS0KICBzdGF0aWMgdm9pZCBleF9pbml0IF9fUCgodm9pZCAqKSk7CiAgc3RhdGlj IHZvaWQgZXhfc3RhcnQgX19QKChzdHJ1Y3QgaWZuZXQgKikpOwogIHN0YXRpYyB2b2lkIGV4X3N0 b3AgX19QKChpbnQpKTsKISBzdGF0aWMgaW50IGV4X2lvY3RsIF9fUCgoc3RydWN0IGlmbmV0ICos IGludCwgY2FkZHJfdCkpOwogIHN0YXRpYyB2b2lkIGV4X3Jlc2V0IF9fUCgoaW50KSk7CiAgc3Rh dGljIHZvaWQgZXhfd2F0Y2hkb2cgX19QKChzdHJ1Y3QgaWZuZXQgKikpOwogIAoqKioqKioqKioq KioqKioKKioqIDE4NiwxOTEgKioqKgotLS0gMTkzLDIwMiAtLS0tCiAgCW91dGIoaW9iYXNlICsg Q01EX1JFRywgUmVzZXRfQ01EKTsKICAJREVMQVkoNDAwKTsKICAKKyAJb3V0Yihpb2Jhc2UgKyBD TURfUkVHLCBCYW5rMl9TZWwpOworIAl0bXAgPSBpbmIoaW9iYXNlICsgRUVQUk9NX1JFRyk7Cisg CXNjLT5jaGlwX3N0ZXBwaW5nID0gKHRtcCAmIGk4MjU5NV9TdGVwcGluZykgPj4gNTsKKyAKICAJ LyoKICAJICogRmlsbCBpbiBzZXZlcmFsIGZpZWxkcyBvZiB0aGUgc29mdGMgc3RydWN0dXJlOgog IAkgKgktIEkvTyBiYXNlIGFkZHJlc3MuCioqKioqKioqKioqKioqKgoqKiogMjA2LDIxNCAqKioq CiAgCXRtcCA9IGVlcHJvbV9yZWFkKGlvYmFzZSwgRUVfSVJRX05vKSAmIElSUV9Ob19NYXNrOwog IAogIAkvKiB3b3JrIG91dCB3aGljaCBzZXQgb2YgaXJxIDwtPiBpbnRlcm5hbCB0YWJsZXMgdG8g dXNlICovCiEgCWlmIChzYy0+YXJwY29tLmFjX2VuYWRkclswXSA9PSAweDAwICYmCiEgCSAgICBz Yy0+YXJwY29tLmFjX2VuYWRkclsxXSA9PSAweEEwICYmCiEgCSAgICBzYy0+YXJwY29tLmFjX2Vu YWRkclsyXSA9PSAweEM5KSB7ICAgIC8qIGl0J3MgYSAxMCsgKi8KICAJCXNjLT5pcnEyZWUgPSBw bHVzX2lycTJlZW1hcDsKICAJCXNjLT5lZTJpcnEgPSBwbHVzX2VlMmlycW1hcDsKICAJfSBlbHNl IHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogaXQncyBhbiBvcmRpbmFyeSAx MCAqLwotLS0gMjE3LDIyMyAtLS0tCiAgCXRtcCA9IGVlcHJvbV9yZWFkKGlvYmFzZSwgRUVfSVJR X05vKSAmIElSUV9Ob19NYXNrOwogIAogIAkvKiB3b3JrIG91dCB3aGljaCBzZXQgb2YgaXJxIDwt PiBpbnRlcm5hbCB0YWJsZXMgdG8gdXNlICovCiEgCWlmIChzYy0+Y2hpcF9zdGVwcGluZyA+PSBG WF9TdGVwcGluZykgeyAvKiBpdCdzIGEgUHJvLzEwIFBsdXMgKi8KICAJCXNjLT5pcnEyZWUgPSBw bHVzX2lycTJlZW1hcDsKICAJCXNjLT5lZTJpcnEgPSBwbHVzX2VlMmlycW1hcDsKICAJfSBlbHNl IHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogaXQncyBhbiBvcmRpbmFyeSAx MCAqLwoqKioqKioqKioqKioqKioKKioqIDI1MSwyNTYgKioqKgotLS0gMjYwLDI2NyAtLS0tCiAg CWludCB1bml0ID0gZGV2LT5pZF91bml0OwogIAlzdHJ1Y3QgZXhfc29mdGMgKnNjID0gJmV4X3Nj W3VuaXRdOwogIAlzdHJ1Y3QgaWZuZXQgKmlmcCA9ICZzYy0+YXJwY29tLmFjX2lmOworIAlzdHJ1 Y3QgaWZhZGRyICppZmE7CisgCXN0cnVjdCBzb2NrYWRkcl9kbCAqc2RsOwogIAogIAlET0RFQlVH KFN0YXJ0X0VuZCwgcHJpbnRmKCJleF9hdHRhY2glZDogc3RhcnRcbiIsIHVuaXQpOyk7CiAgCioq KioqKioqKioqKioqKgoqKiogMjc0LDI4NSAqKioqCiAgCWlmX2F0dGFjaChpZnApOwogIAlldGhl cl9pZmF0dGFjaChpZnApOwogIAohIAlpZiAoc2MtPmFycGNvbS5hY19lbmFkZHJbMF0gPT0gMHgw MCAmJgohIAkgICAgc2MtPmFycGNvbS5hY19lbmFkZHJbMV0gPT0gMHhBMCAmJgohIAkgICAgc2Mt PmFycGNvbS5hY19lbmFkZHJbMl0gPT0gMHhDOSkgewohIAkJcHJpbnRmKCJleCVkOiBJbnRlbCBF dGhlckV4cHJlc3MgUHJvLzEwKywgYWRkcmVzcyAlNkQsIGNvbm5lY3RvciAiLCBkZXYtPmlkX3Vu aXQsIHNjLT5hcnBjb20uYWNfZW5hZGRyLCAiOiIpOwogIAl9IGVsc2UgewohIAkJcHJpbnRmKCJl eCVkOiBJbnRlbCBFdGhlckV4cHJlc3MgUHJvLzEwLCBhZGRyZXNzICU2RCwgY29ubmVjdG9yICIs IGRldi0+aWRfdW5pdCwgc2MtPmFycGNvbS5hY19lbmFkZHIsICI6Iik7CiAgCX0KICAJc3dpdGNo KHNjLT5jb25uZWN0b3IpIHsKICAJCWNhc2UgQ29ubl9UUEU6IHByaW50ZigiVFBFXG4iKTsgYnJl YWs7Ci0tLSAyODUsMjk0IC0tLS0KICAJaWZfYXR0YWNoKGlmcCk7CiAgCWV0aGVyX2lmYXR0YWNo KGlmcCk7CiAgCiEgCWlmIChzYy0+Y2hpcF9zdGVwcGluZyA+PSBGWF9TdGVwcGluZykgewohIAkJ cHJpbnRmKCJleCVkOiBJbnRlbCBFdGhlckV4cHIgUHJvLzEwKywgYWRkcmVzcyAlNkQsIHN0ZXAg JWQsIGNvbm5lY3RvciAiLCBkZXYtPmlkX3VuaXQsIHNjLT5hcnBjb20uYWNfZW5hZGRyLCAiOiIs IHNjLT5jaGlwX3N0ZXBwaW5nKTsKICAJfSBlbHNlIHsKISAJCXByaW50ZigiZXglZDogSW50ZWwg RXRoZXJFeHByZXNzIFByby8xMCwgYWRkcmVzcyAlNkQsIHN0ZXAgJWQsIGNvbm5lY3RvciAiLCBk ZXYtPmlkX3VuaXQsIHNjLT5hcnBjb20uYWNfZW5hZGRyLCAiOiIsIHNjLT5jaGlwX3N0ZXBwaW5n KTsKICAJfQogIAlzd2l0Y2goc2MtPmNvbm5lY3RvcikgewogIAkJY2FzZSBDb25uX1RQRTogcHJp bnRmKCJUUEVcbiIpOyBicmVhazsKKioqKioqKioqKioqKioqCioqKiAzMDksMzE1ICoqKioKICAK ICAJRE9ERUJVRyhTdGFydF9FbmQsIHByaW50ZigiZXhfaW5pdCVkOiBzdGFydFxuIiwgaWZwLT5p Zl91bml0KTspOwogIAohIAlpZiAoaWZwLT5pZl9hZGRyaGVhZC50cWhfZmlyc3QgPT0gTlVMTCkK ICAJICByZXR1cm47CiAgCXMgPSBzcGxpbXAoKTsKICAJc2MtPmFycGNvbS5hY19pZi5pZl90aW1l ciA9IDA7Ci0tLSAzMTgsMzI0IC0tLS0KICAKICAJRE9ERUJVRyhTdGFydF9FbmQsIHByaW50Zigi ZXhfaW5pdCVkOiBzdGFydFxuIiwgaWZwLT5pZl91bml0KTspOwogIAohIAlpZiAoaWZwLT5pZl9h ZGRybGlzdCA9PSAoc3RydWN0IGlmYWRkciAqKSAwKQogIAkgIHJldHVybjsKICAJcyA9IHNwbGlt cCgpOwogIAlzYy0+YXJwY29tLmFjX2lmLmlmX3RpbWVyID0gMDsKKioqKioqKioqKioqKioqCioq KiAzOTMsMzk5ICoqKioKICAgIHJlZ2lzdGVyIHN0cnVjdCBleF9zb2Z0YyAqc2MgPSAmZXhfc2Nb dW5pdF07CiAgICByZWdpc3RlciBpbnQgaW9iYXNlID0gc2MtPmlvYmFzZTsKICAgIGludCBpLCBz LCBsZW4sIGRhdGFfbGVuLCBhdmFpbCwgZGVzdCwgbmV4dDsKISAgIHVuc2lnbmVkIGNoYXIgdG1w MTZbMl07CiAgICBzdHJ1Y3QgbWJ1ZiAqb3BrdDsKICAgIHJlZ2lzdGVyIHN0cnVjdCBtYnVmICpt OwogIAotLS0gNDAyLDQwOCAtLS0tCiAgICByZWdpc3RlciBzdHJ1Y3QgZXhfc29mdGMgKnNjID0g JmV4X3NjW3VuaXRdOwogICAgcmVnaXN0ZXIgaW50IGlvYmFzZSA9IHNjLT5pb2Jhc2U7CiAgICBp bnQgaSwgcywgbGVuLCBkYXRhX2xlbiwgYXZhaWwsIGRlc3QsIG5leHQ7CiEgICB1bnNpZ25lZCBj aGFyIHRtcDE2WzJdLCAqY1A7CiAgICBzdHJ1Y3QgbWJ1ZiAqb3BrdDsKICAgIHJlZ2lzdGVyIHN0 cnVjdCBtYnVmICptOwogIAoqKioqKioqKioqKioqKioKKioqIDU3MCw1NzYgKioqKgogICAgc3Ry dWN0IGV4X3NvZnRjICpzYyA9ICZleF9zY1t1bml0XTsKICAgIHN0cnVjdCBpZm5ldCAqaWZwID0g JnNjLT5hcnBjb20uYWNfaWY7CiAgICBpbnQgaW9iYXNlID0gc2MtPmlvYmFzZTsKISAgIGludCBp bnRfc3RhdHVzLCBzZW5kX3BrdHM7CiAgCiAgICBET0RFQlVHKFN0YXJ0X0VuZCwgcHJpbnRmKCJl eGludHIlZDogc3RhcnRcbiIsIHVuaXQpOyk7CiAgCi0tLSA1NzksNTg1IC0tLS0KICAgIHN0cnVj dCBleF9zb2Z0YyAqc2MgPSAmZXhfc2NbdW5pdF07CiAgICBzdHJ1Y3QgaWZuZXQgKmlmcCA9ICZz Yy0+YXJwY29tLmFjX2lmOwogICAgaW50IGlvYmFzZSA9IHNjLT5pb2Jhc2U7CiEgICBpbnQgcywg aW50X3N0YXR1cywgc2VuZF9wa3RzOwogIAogICAgRE9ERUJVRyhTdGFydF9FbmQsIHByaW50Zigi ZXhpbnRyJWQ6IHN0YXJ0XG4iLCB1bml0KTspOwogIAoqKioqKioqKioqKioqKioKKioqIDc0OSw3 NTUgKioqKgogICAgICBlbHNlCiAgICAgICAgaWZwLT5pZl9pZXJyb3JzKys7CiAgICAgIG91dHco aW9iYXNlICsgSE9TVF9BRERSX1JFRywgc2MtPnJ4X2hlYWQpOwohICAgcnhfYW5vdGhlcjogOwog ICAgfQogICAgaWYgKHNjLT5yeF9oZWFkIDwgc2MtPnJ4X2xvd2VyX2xpbWl0ICsgMikKICAgICAg b3V0dyhpb2Jhc2UgKyBSQ1ZfU1RPUF9SRUcsIHNjLT5yeF91cHBlcl9saW1pdCk7Ci0tLSA3NTgs NzY0IC0tLS0KICAgICAgZWxzZQogICAgICAgIGlmcC0+aWZfaWVycm9ycysrOwogICAgICBvdXR3 KGlvYmFzZSArIEhPU1RfQUREUl9SRUcsIHNjLT5yeF9oZWFkKTsKISAgIHJ4X2Fub3RoZXI6CiAg ICB9CiAgICBpZiAoc2MtPnJ4X2hlYWQgPCBzYy0+cnhfbG93ZXJfbGltaXQgKyAyKQogICAgICBv dXR3KGlvYmFzZSArIFJDVl9TVE9QX1JFRywgc2MtPnJ4X3VwcGVyX2xpbWl0KTsKKioqKioqKioq KioqKioqCioqKiA3NjAsNzY2ICoqKioKICB9CiAgCiAgCiEgaW50IGV4X2lvY3RsKHJlZ2lzdGVy IHN0cnVjdCBpZm5ldCAqaWZwLCB1X2xvbmcgY21kLCBjYWRkcl90IGRhdGEpCiAgewogICAgcmVn aXN0ZXIgc3RydWN0IGlmYWRkciAqaWZhID0gKHN0cnVjdCBpZmFkZHIgKikgZGF0YTsKICAgIHN0 cnVjdCBleF9zb2Z0YyAqc2MgPSAmZXhfc2NbaWZwLT5pZl91bml0XTsKLS0tIDc2OSw3NzUgLS0t LQogIH0KICAKICAKISBpbnQgZXhfaW9jdGwocmVnaXN0ZXIgc3RydWN0IGlmbmV0ICppZnAsIGlu dCBjbWQsIGNhZGRyX3QgZGF0YSkKICB7CiAgICByZWdpc3RlciBzdHJ1Y3QgaWZhZGRyICppZmEg PSAoc3RydWN0IGlmYWRkciAqKSBkYXRhOwogICAgc3RydWN0IGV4X3NvZnRjICpzYyA9ICZleF9z Y1tpZnAtPmlmX3VuaXRdOwoqKioqKioqKioqKioqKioKKioqIDg3MSw4NzYgKioqKgotLS0gODgw LDg4NiAtLS0tCiAgdm9pZCBleF9yZXNldChpbnQgdW5pdCkKICB7CiAgICBzdHJ1Y3QgZXhfc29m dGMgKnNjID0gJmV4X3NjW3VuaXRdOworICAgc3RydWN0IGlmbmV0ICppZnAgPSAmc2MtPmFycGNv bS5hY19pZjsKICAgIGludCBzOwogIAogICAgRE9ERUJVRyhTdGFydF9FbmQsIHByaW50ZigiZXhf cmVzZXQlZDogc3RhcnRcbiIsIHVuaXQpOyk7CioqKioqKioqKioqKioqKgoqKiogODg4LDg5MyAq KioqCi0tLSA4OTgsOTA0IC0tLS0KICAKICB2b2lkIGV4X3dhdGNoZG9nKHN0cnVjdCBpZm5ldCAq aWZwKQogIHsKKyAgIHN0cnVjdCBleF9zb2Z0YyAqc2MgPSAmZXhfc2NbaWZwLT5pZl91bml0XTsK ICAKICAgIERPREVCVUcoU3RhcnRfRW5kLCBwcmludGYoImV4X3dhdGNoZG9nJWQ6IHN0YXJ0XG4i LCBpZnAtPmlmX3VuaXQpOyk7CiAgCg== ------=_NextPart_000_002C_01BE0792.AD989430 Content-Type: application/octet-stream; name="if_exreg.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="if_exreg.diff" SW5kZXg6IGlmX2V4cmVnLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL3Vzci9jdnNyb290L3NyYy9z eXMvaTM4Ni9pc2EvaWZfZXhyZWcuaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xCmRpZmYgLWMg LXIxLjEgaWZfZXhyZWcuaAoqKiogaWZfZXhyZWcuaAkxOTk3LzAxLzE2IDEyOjE5OjIxCTEuMQot LS0gaWZfZXhyZWcuaAkxOTk4LzExLzA0IDAwOjE4OjEzCioqKioqKioqKioqKioqKgoqKiogMTIx LDEyNiAqKioqCi0tLSAxMjEsMTI4IC0tLS0KICAjZGVmaW5lIElfQUREUl9SRUcwIDQKICAjZGVm aW5lIEVFUFJPTV9SRUcgMTAKICAjZGVmaW5lIFRybm9mZl9FbmFibGUgMHgxMAorICNkZWZpbmUg aTgyNTk1X1N0ZXBwaW5nIDB4RTAKKyAjZGVmaW5lIEZYX1N0ZXBwaW5nIDQKICAKICAvKiBFRVBS T00gbWVtb3J5IHBvc2l0aW9ucyAoMTYtYml0IHdpZGUpLiAqLwogIAo= ------=_NextPart_000_002C_01BE0792.AD989430-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 01:07:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA21347 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 01:07:24 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA21340; Wed, 4 Nov 1998 01:07:20 -0800 (PST) (envelope-from rnordier@FreeBSD.org) From: Robert Nordier Received: (from rnordier@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id BAA14421; Wed, 4 Nov 1998 01:07:21 -0800 (PST) Date: Wed, 4 Nov 1998 01:07:21 -0800 (PST) Message-Id: <199811040907.BAA14421@freefall.freebsd.org> To: archie@whistle.com, rnordier@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/8566 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: mergesort() core dumps if number of elements is zero State-Changed-From-To: open-closed State-Changed-By: rnordier State-Changed-When: Wed Nov 4 01:04:55 PST 1998 State-Changed-Why: Patch committed: merge.c 1.3/1.2.6.1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 04:11:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA12515 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 04:11:34 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12469; Wed, 4 Nov 1998 04:11:25 -0800 (PST) (envelope-from phk@FreeBSD.org) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id EAA24614; Wed, 4 Nov 1998 04:11:27 -0800 (PST) Date: Wed, 4 Nov 1998 04:11:27 -0800 (PST) Message-Id: <199811041211.EAA24614@freefall.freebsd.org> To: seva@alex-ua.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/7159 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [PATCH] Unknown option OVERRIDE_CARD (bt848 driver) State-Changed-From-To: suspended-closed State-Changed-By: phk State-Changed-When: Wed Nov 4 04:11:01 PST 1998 State-Changed-Why: Roger Hardiman says so. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 06:09:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA27989 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 06:09:31 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA27982 for ; Wed, 4 Nov 1998 06:09:29 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id GAA28990; Wed, 4 Nov 1998 06:00:01 -0800 (PST) Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA25774 for ; Wed, 4 Nov 1998 05:53:47 -0800 (PST) (envelope-from viro@math.psu.edu) Received: from hilbert.math.psu.edu (hilbert.math.psu.edu [146.186.130.197]) by math.psu.edu (8.8.5/8.7.3) with ESMTP id IAA07726 for ; Wed, 4 Nov 1998 08:53:38 -0500 (EST) Received: (viro@localhost) by hilbert.math.psu.edu (8.8.8/8.6.9) id IAA09242 for FreeBSD-gnats-submit@freebsd.org; Wed, 4 Nov 1998 08:53:38 -0500 (EST) Message-Id: <199811041353.IAA09242@hilbert.math.psu.edu> Date: Wed, 4 Nov 1998 08:53:38 -0500 (EST) From: viro@math.psu.edu Reply-To: viro@math.psu.edu To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/8573: [PATCH] SIGSEGV in nvi 1.79 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8573 >Category: bin >Synopsis: nvi 1.79 SIGSEGVs on any address in .exrc >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Nov 4 06:00:01 PST 1998 >Last-Modified: >Originator: Al Viro >Organization: -ENOENT >Release: FreeBSD 2.2.7-RELEASE i386 >Environment: Any OS that doesn't like NULL dereferencing ;-/ Reproducable on 3.0, Linux, SunOS, Slowlaris... >Description: ex/ex.c::ex_badaddr(sp,ba,cp,nret) passes cp->name to ex_emsg() in case when sp->ep is NULL. It doesn't check for cp!=NULL. Bad, since in many places it is explicitly called in such setup. One of them (in ex/ex.c): 1834: /* No addresses permitted until a file has been read in. */ 1835: if (sp->ep == NULL && strchr("$0123456789'\\/?.+-^", *ecp->cp)) { 1836: ex_badaddr(sp, NULL, A_EMPTY, NUM_OK); ... which could as well be foo(*(char*)NULL)... >How-To-Repeat: Just put into .exrc any command with address. Plain . will go. >Fix: *** ex/ex.c Thu Oct 10 18:49:46 1996 --- ex/ex.c.new Wed Nov 4 02:32:49 1998 *************** *** 2307,2313 **** * underlying file, that's the real problem. */ if (sp->ep == NULL) { ! ex_emsg(sp, cp->name, EXM_NOFILEYET); return; } --- 2307,2313 ---- * underlying file, that's the real problem. */ if (sp->ep == NULL) { ! ex_emsg(sp, cp ? cp->name : NULL, EXM_NOFILEYET); return; } >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 09:00:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23007 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 09:00:05 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA22953 for ; Wed, 4 Nov 1998 09:00:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id JAA16984; Wed, 4 Nov 1998 09:00:01 -0800 (PST) Date: Wed, 4 Nov 1998 09:00:01 -0800 (PST) Message-Id: <199811041700.JAA16984@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Liviu Ionescu" Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Reply-To: "Liviu Ionescu" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8555; it has been noted by GNATS. From: "Liviu Ionescu" To: Cc: Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Date: Wed, 4 Nov 1998 18:53:05 +0200 > Thanks for the detailed information. I believe this problem (the panic, at > least) has been fixed in FreeBSD-current. ok, as soon as I'll have time to test the current version, I'll check it. > A lot of the Sony CDROM drives don't behave properly when they are probed > on multiple LUNs. > Try applying the attached patch to src/sys/cam/cam_xpt.c, and see if it > fixes your problem. It disables multi-lun probing for most every Sony > CDROM drive, since as far as I can tell, most of them behave badly. > The patch may or may not apply cleanly to your version of cam_xpt.c, but at > least you can get an idea of the quirk entry you need to disable multi-LUN > probing for your CDROM drive. I applied the patch and (bingo!) the kernel now boots without panic. the picture also changed a bit, the CD-ROM is listed now at 20.0MB/s. but when I try to mount a disc I get an error: boca# mount /dev/cd0c /mnt mount: Input/output error and the syslog shows: Nov 4 19:50:03 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command phase. Nov 4 19:50:03 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command phase. Nov 4 19:50:03 boca /kernel: SEQADDR == 0x153 Nov 4 19:50:03 boca /kernel: SEQADDR == 0x153 Nov 4 19:50:03 boca /kernel: SCSIRATE == 0xf Nov 4 19:50:03 boca /kernel: SCSIRATE == 0xf Nov 4 19:50:12 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command phase. Nov 4 19:50:12 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command phase. Nov 4 19:50:12 boca /kernel: SEQADDR == 0x153 Nov 4 19:50:12 boca /kernel: SEQADDR == 0x153 Nov 4 19:50:12 boca /kernel: SCSIRATE == 0xf Nov 4 19:50:12 boca /kernel: SCSIRATE == 0xf I also tried to remove the parity/termination jumpers from the Sony drive, without success. anyway, I remember that exactly the same hardware configuration worked fine with 2.2.7 with cam patches applied, so it shouldn't be a parity/terminator misconfiguration. regards, Liviu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 11:16:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15388 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 11:16:29 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from slibinas.ku.lt (slibinas.ku.lt [193.219.76.129]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA15372 for ; Wed, 4 Nov 1998 11:16:09 -0800 (PST) (envelope-from giedrius@rekt.ku.lt) Received: by slibinas.ku.lt with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Wed, 4 Nov 1998 20:12:59 +0100 Received: from KU_REKT/SpoolDir by rekt.ku.lt (Mercury 1.43); 4 Nov 98 20:19:44 +0100 Received: from SpoolDir by KU_REKT (Mercury 1.43); 4 Nov 98 20:19:32 +0100 From: "Giedrius Trapkauskas" Organization: KU To: freebsd-bugs@FreeBSD.ORG Date: Wed, 4 Nov 1998 20:19:25 +0100 Subject: sysinstall X-mailer: Pegasus Mail for Windows (v3.01b) Message-ID: <230B08F62FC@rekt.ku.lt> Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm using freebsd 2.2.7. When I configure it using /stand/sysinstall utility, after finishing the routed option in rc.conf file is always set to NO. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 11:50:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21806 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 11:50:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21753 for ; Wed, 4 Nov 1998 11:49:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id LAA24306; Wed, 4 Nov 1998 11:50:00 -0800 (PST) Date: Wed, 4 Nov 1998 11:50:00 -0800 (PST) Message-Id: <199811041950.LAA24306@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Alexander (Sasha) Robinson" Subject: Re: misc/8494: sbcheck is broken Reply-To: "Alexander (Sasha) Robinson" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR misc/8494; it has been noted by GNATS. From: "Alexander (Sasha) Robinson" To: Bill Fenner Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: misc/8494: sbcheck is broken Date: Wed, 04 Nov 1998 11:44:02 -0800 Bill Fenner wrote: > > I wrote this code when trying to use sbcheck() myself a while ago. > Does this do what you want? > > Bill > > cvs diff: Diffing . > Index: uipc_socket2.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v > retrieving revision 1.39 > diff -u -r1.39 uipc_socket2.c > --- uipc_socket2.c 1998/09/05 13:24:39 1.39 > +++ uipc_socket2.c 1998/11/03 18:58:16 > @@ -477,15 +477,17 @@ > register struct sockbuf *sb; > { > register struct mbuf *m; > + register struct mbuf *n = 0; > register int len = 0, mbcnt = 0; > > - for (m = sb->sb_mb; m; m = m->m_next) { > + for (m = sb->sb_mb; m; m = n) { > + n = m->m_nextpkt; > + for (; m; m = m->m_next) { > len += m->m_len; > mbcnt += MSIZE; > if (m->m_flags & M_EXT) /*XXX*/ /* pretty sure this is bogus */ > mbcnt += m->m_ext.ext_size; > - if (m->m_nextpkt) > - panic("sbcheck nextpkt"); > + } > } > if (len != sb->sb_cc || mbcnt != sb->sb_mbcnt) { > printf("cc %d != %d || mbcnt %d != %d\n", len, sb->sb_cc, Yep, that's it. Thanks for the quick response. I have to admit that when I filed this I had only intended to send it to our (Juniper Networks) internal gnats database as a placeholder for myself and mistakenly sent it out to you. I would have made the bug description a little less flip if I had realized where I was sending it :). Hope I didn't offend. Sasha -- Alexander (Sasha) Robinson avr@juniper.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 11:59:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23471 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 11:59:50 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23464; Wed, 4 Nov 1998 11:59:47 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id MAA19486; Wed, 4 Nov 1998 12:59:28 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199811041959.MAA19486@panzer.plutotech.com> Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked In-Reply-To: <199811041700.JAA16984@freefall.freebsd.org> from Liviu Ionescu at "Nov 4, 98 09:00:01 am" To: Liviu.Ionescu@Romania.EU.net Date: Wed, 4 Nov 1998 12:59:27 -0700 (MST) Cc: freebsd-bugs@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Liviu Ionescu wrote... > I applied the patch and (bingo!) the kernel now boots without panic. > > the picture also changed a bit, the CD-ROM is listed now at 20.0MB/s. > > but when I try to mount a disc I get an error: > > boca# mount /dev/cd0c /mnt > mount: Input/output error > > and the syslog shows: > > Nov 4 19:50:03 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:03 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:03 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:03 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:03 boca /kernel: SCSIRATE == 0xf > Nov 4 19:50:03 boca /kernel: SCSIRATE == 0xf > Nov 4 19:50:12 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:12 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:12 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:12 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:12 boca /kernel: SCSIRATE == 0xf > Nov 4 19:50:12 boca /kernel: SCSIRATE == 0xf > > I also tried to remove the parity/termination jumpers from the Sony drive, > without success. anyway, I remember that exactly the same hardware > configuration worked fine with 2.2.7 with cam patches applied, so it > shouldn't be a parity/terminator misconfiguration. This really looks like a cabling or termination problem. The Adaptec driver in -current isn't significantly different than the CAM driver you used with 2.2.7. So it's most likely some change in your hardware that has caused the problem. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 12:00:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA23565 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 12:00:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23534 for ; Wed, 4 Nov 1998 11:59:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id MAA25112; Wed, 4 Nov 1998 12:00:01 -0800 (PST) Date: Wed, 4 Nov 1998 12:00:01 -0800 (PST) Message-Id: <199811042000.MAA25112@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: "Kenneth D. Merry" Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Reply-To: "Kenneth D. Merry" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8555; it has been noted by GNATS. From: "Kenneth D. Merry" To: Liviu.Ionescu@Romania.EU.net Cc: freebsd-bugs@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/8555: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked Date: Wed, 4 Nov 1998 12:59:27 -0700 (MST) Liviu Ionescu wrote... > I applied the patch and (bingo!) the kernel now boots without panic. > > the picture also changed a bit, the CD-ROM is listed now at 20.0MB/s. > > but when I try to mount a disc I get an error: > > boca# mount /dev/cd0c /mnt > mount: Input/output error > > and the syslog shows: > > Nov 4 19:50:03 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:03 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:03 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:03 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:03 boca /kernel: SCSIRATE == 0xf > Nov 4 19:50:03 boca /kernel: SCSIRATE == 0xf > Nov 4 19:50:12 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:12 boca /kernel: (cd0:ahc1:0:3:0): parity error during Command > phase. > Nov 4 19:50:12 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:12 boca /kernel: SEQADDR == 0x153 > Nov 4 19:50:12 boca /kernel: SCSIRATE == 0xf > Nov 4 19:50:12 boca /kernel: SCSIRATE == 0xf > > I also tried to remove the parity/termination jumpers from the Sony drive, > without success. anyway, I remember that exactly the same hardware > configuration worked fine with 2.2.7 with cam patches applied, so it > shouldn't be a parity/terminator misconfiguration. This really looks like a cabling or termination problem. The Adaptec driver in -current isn't significantly different than the CAM driver you used with 2.2.7. So it's most likely some change in your hardware that has caused the problem. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 17:10:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17268 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 17:10:02 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17214 for ; Wed, 4 Nov 1998 17:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id RAA11138; Wed, 4 Nov 1998 17:10:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16050; Wed, 4 Nov 1998 17:00:28 -0800 (PST) (envelope-from nobody) Message-Id: <199811050100.RAA16050@hub.freebsd.org> Date: Wed, 4 Nov 1998 17:00:28 -0800 (PST) From: hyuckchj@usc.edu To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: conf/8576: server goes down when client mount its file system and run programs. Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8576 >Category: conf >Synopsis: server goes down when client mount its file system and run programs. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Nov 4 17:10:00 PST 1998 >Last-Modified: >Originator: Hyuckchul Jung >Organization: USC >Release: FreeBSD 2.2.7 >Environment: FreeBSD roqueta.usc.edu 2.2.7-RELEASE FreeBSD 2.2.7-RELEASE #0: Sun Sep 13 19:48:59 PDT 1998 puneet@roqueta.usc.edu:/usr/src/sys/compile/ROQUETA i386 >Description: There are seven clients and one server in my lab. All machines are PC's(i586) and run on FreeBSD. When I mount server's file system(/usr/local/bin) and run 'sdr', 'netscape', or other programs, the server goes down. Followings are kernel configuration: >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 19:20:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05692 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 19:20:04 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05642 for ; Wed, 4 Nov 1998 19:19:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id TAA16557; Wed, 4 Nov 1998 19:20:01 -0800 (PST) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05433 for ; Wed, 4 Nov 1998 19:17:35 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id TAA04251 for ; Wed, 4 Nov 1998 19:17:25 -0800 (PST) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma004247; Wed Nov 4 19:17:23 1998 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id TAA03886; Wed, 4 Nov 1998 19:17:23 -0800 (PST) Message-Id: <199811050317.TAA03886@bubba.whistle.com> Date: Wed, 4 Nov 1998 19:17:23 -0800 (PST) From: Archie Cobbs Reply-To: archie@whistle.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8577: Request [v]snprintf() in the kernel Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8577 >Category: kern >Synopsis: Request [v]snprintf() in the kernel >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Nov 4 19:20:00 PST 1998 >Last-Modified: >Originator: Archie Cobbs >Organization: Whistle Communications, Inc. >Release: FreeBSD 2.2.6-RELEASE i386 >Environment: FreeBSD 3.0-current >Description: Request that snprintf() and vsnprintf() functions be added to the kernel. This would enable us to change kernel code that uses sprintf() for: - Greater safety from buffer overflows - Eliminate code that does manual bounds checking, ie, the equivalent of what snprintf() does automatically Also, the amount of code to add to the kernel is just a few lines. >How-To-Repeat: >Fix: This patch is a start.. it enable the aforementioned cleanups to start happening. Index: kern/subr_prf.c =================================================================== RCS file: /cvs/freebsd/src/sys/kern/subr_prf.c,v retrieving revision 1.50 diff -u -r1.50 subr_prf.c --- subr_prf.c 1998/09/06 06:25:04 1.50 +++ subr_prf.c 1998/11/05 03:10:12 @@ -68,6 +68,8 @@ struct putchar_arg {int flags; struct tty *tty; }; static void putchar __P((int ch, void *arg)); static char *ksprintn __P((u_long num, int base, int *len)); +static void snprintf_func __P((int ch, void *arg)); +struct snprintf_arg { char *buf; size_t remain; }; static int consintr = 1; /* Ok to handle console interrupts? */ static int msgbufmapped; /* Set when safe to use msgbuf */ @@ -326,6 +328,47 @@ retval = kvprintf(cfmt, NULL, (void *)buf, 10, ap); buf[retval] = '\0'; return retval; +} + +/* + * Scaled down version of snprintf(3). + */ +int +snprintf(char *buf, size_t max, const char *cfmt, ...) +{ + int retval; + va_list ap; + + va_start(ap, cfmt); + retval = vsnprintf(buf, max, cfmt, ap); + va_end(ap); + return retval; +} + +/* + * Scaled down version of vsnprintf(3). + */ +int +vsnprintf(char *buf, size_t size, const char *cfmt, va_list ap) +{ + struct snprintf_arg info = { buf, size }; + int retval; + + retval = kvprintf(cfmt, snprintf_func, &info, 10, ap); + if (info.remain >= 1) + *info.buf++ = '\0'; + return retval; +} + +static void +snprintf_func(int ch, void *arg) +{ + struct snprintf_arg *const info = (struct snprintf_arg *) arg; + + if (info->remain >= 2) { + *info->buf++ = ch; + info->remain--; + } } /* Index: sys/systm.h =================================================================== RCS file: /cvs/freebsd/src/sys/sys/systm.h,v retrieving revision 1.78 diff -u -r1.78 systm.h --- systm.h 1998/10/30 05:41:15 1.78 +++ systm.h 1998/11/05 03:10:13 @@ -108,6 +108,8 @@ void logwakeup __P((void)); int printf __P((const char *, ...)) __printflike(1, 2); int sprintf __P((char *buf, const char *, ...)) __printflike(2, 3); +int snprintf __P((char *, size_t, const char *, ...)) __printflike(3, 4); +int vsnprintf __P((char *, size_t, const char *, _BSD_VA_LIST_)) __printflike(3, 0); void uprintf __P((const char *, ...)) __printflike(1, 2); void vprintf __P((const char *, _BSD_VA_LIST_)) __printflike(1, 0); int vsprintf __P((char *buf, const char *, _BSD_VA_LIST_)) __printflike(2, 0); >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 19:25:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA06523 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 19:25:43 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from market.net.tw (market.net.tw [203.74.62.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA06517 for ; Wed, 4 Nov 1998 19:25:37 -0800 (PST) (envelope-from cch@market.net.tw) Received: (from cch@localhost) by market.net.tw (8.8.8/8.8.5) id LAA14196 for freebsd-bugs@FreeBSD.org; Thu, 5 Nov 1998 11:20:29 +0800 (CST) Date: Thu, 5 Nov 1998 11:20:29 +0800 (CST) From: Cchsieh Message-Id: <199811050320.LAA14196@market.net.tw> To: freebsd-bugs@FreeBSD.ORG Subject: When dd writes write-protected floppy (in 3.0R) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear core team members, When I use dd to write a write-proteced floppy in FreeBSD 3.0 RELEASE, I can not stop the process by press Ctrl-C, Ctrl-Z, or "kill -9 dd-pid". Is this a bug? details: command: dd if=picobsd.bin of=/dev/fd0 # but I forget to enable # the floppy writable error messages: Nov 4 16:39:11 pico /kernel: fd0c: hard error writing fsbn 0 of 0-3 (ST0 40 ST1 2 ST2 0 cyl 0 hd 0 sec 1) Nov 4 16:39:11 pico /kernel: fd0c: hard error writing fsbn 4 of 4-7 (ST0 40 ST1 2 ST2 0 cyl 0 hd 0 sec 5) Nov 4 16:39:11 pico /kernel: fd0c: hard error writing fsbn 8 of 8-11 (ST0 40 ST1 2 ST2 0 cyl 0 hd 0 sec 9) Nov 4 16:41:10 pico /kernel: fd0c: hard error writing fsbn 1572 of 1572-1575 (ST0 40 ST1 2 ST2 0 cyl 43 hd 1 sec 7) ... ... (skipped) Nov 4 16:41:10 pico /kernel: fd0c: hard error writing fsbn 1576 of 1576-1579 (ST0 40 ST1 2 ST2 0 cyl 43 hd 1 sec 11) Nov 4 16:41:11 pico sudo: cch : TTY=ttyv1 ; PWD=/etc ; USER=root ; COMMAND=/sbin/reboot Nov 4 16:41:11 pico reboot: rebooted by cch Nov 4 16:41:11 pico syslogd: exiting on signal 15 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 19:44:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA08565 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 19:44:48 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA08546 for ; Wed, 4 Nov 1998 19:44:44 -0800 (PST) (envelope-from xroot@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA07490; Wed, 4 Nov 1998 19:45:26 -0800 (PST) Message-Id: <199811050345.TAA07490@implode.root.com> To: Cchsieh cc: freebsd-bugs@FreeBSD.ORG Subject: Re: When dd writes write-protected floppy (in 3.0R) In-reply-to: Your message of "Thu, 05 Nov 1998 11:20:29 +0800." <199811050320.LAA14196@market.net.tw> From: David Greenman Reply-To: dg@root.com Date: Wed, 04 Nov 1998 19:45:26 -0800 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > When I use dd to write a write-proteced floppy in FreeBSD 3.0 RELEASE, > > I can not stop the process by press Ctrl-C, Ctrl-Z, or "kill -9 dd-pid". > > Is this a bug? Probably. The kernel should return EROFS to dd. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 23:29:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27555 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 23:29:07 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27549; Wed, 4 Nov 1998 23:29:03 -0800 (PST) (envelope-from rnordier@FreeBSD.org) From: Robert Nordier Received: (from rnordier@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA27306; Wed, 4 Nov 1998 23:29:05 -0800 (PST) Date: Wed, 4 Nov 1998 23:29:05 -0800 (PST) Message-Id: <199811050729.XAA27306@freefall.freebsd.org> To: ryany@pobox.com, rnordier@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/8568 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: du(1) usage message missing "-c" option State-Changed-From-To: open-closed State-Changed-By: rnordier State-Changed-When: Wed Nov 4 23:27:33 PST 1998 State-Changed-Why: Patch committed: du.c 1.14 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Wed Nov 4 23:46:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29407 for freebsd-bugs-outgoing; Wed, 4 Nov 1998 23:46:32 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA29401; Wed, 4 Nov 1998 23:46:29 -0800 (PST) (envelope-from rnordier@FreeBSD.org) From: Robert Nordier Received: (from rnordier@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA28089; Wed, 4 Nov 1998 23:46:30 -0800 (PST) Date: Wed, 4 Nov 1998 23:46:30 -0800 (PST) Message-Id: <199811050746.XAA28089@freefall.freebsd.org> To: shmit@rcn.com, rnordier@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/8565 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: New bootloader fails with new kernel State-Changed-From-To: open-closed State-Changed-By: rnordier State-Changed-When: Wed Nov 4 23:44:45 PST 1998 State-Changed-Why: Fixed in userconfig.c 1.115 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Nov 5 07:20:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA23736 for freebsd-bugs-outgoing; Thu, 5 Nov 1998 07:20:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA23702 for ; Thu, 5 Nov 1998 07:19:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id HAA23940; Thu, 5 Nov 1998 07:20:01 -0800 (PST) Received: from bsd7.cs.sunysb.edu (bsd7.cs.sunysb.edu [130.245.1.197]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA23354 for ; Thu, 5 Nov 1998 07:14:38 -0800 (PST) (envelope-from gene@starkhome.cs.sunysb.edu) Received: (from uucp@localhost) by bsd7.cs.sunysb.edu (8.8.7/8.8.5) with UUCP id KAA00674 for FreeBSD-gnats-submit@freebsd.org; Thu, 5 Nov 1998 10:14:22 -0500 (EST) Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.8.7/8.8.5) id JAA27573; Thu, 5 Nov 1998 09:55:46 -0500 (EST) Message-Id: <199811051455.JAA27573@starkhome.cs.sunysb.edu> Date: Thu, 5 Nov 1998 09:55:46 -0500 (EST) From: stark@FreeBSD.ORG Reply-To: stark@FreeBSD.ORG To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8580: Hanging NFS pagein in nfs_bio.c (2.2.7, workaround patch) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8580 >Category: kern >Synopsis: Hanging NFS pagein in nfs_bio.c (2.2.7, workaround patch) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 5 07:20:00 PST 1998 >Last-Modified: >Originator: Gene Stark >Organization: SUNY at Stony Brook CS Dept. >Release: FreeBSD 2.2.7-RELEASE i386 >Environment: FreeBSD 2.2.7-RELEASE on a system with user files located on an NFS server. Filesystem buffer size 8192. >Description: A race condition involving ptrace and NFS causes the system to loop in nfs_bioread() while attempting to page in text segment. >How-To-Repeat: Run a certain program under gdb Interrupt the program by ^C Install a breakpoint Re-run the program (so that it is killed and restarts right away) System loops in kernel trying to page in (over NFS) the text page that has the breakpoint in it. The bug is timing-dependent -- I can reproduce the hang a certain fraction of the time, but it seems to require other system load to be present. To get a core dump I had to turn on RB_NOSYNC, because otherwise the system hangs syncing the FS. The looping occurs between "again:" and the "goto again" in the following portion of nfs_bioread(): if (not_readin && n > 0) { if (on < bp->b_validoff || (on + n) > bp->b_validend) { bp->b_flags |= B_NOCACHE; if (bp->b_dirtyend > 0) { if ((bp->b_flags & B_DELWRI) == 0) panic("nfsbioread"); if (VOP_BWRITE(bp) == EINTR) return (EINTR); } else brelse(bp); goto again; } } The system hangs because it is spinning here -- maybe for general robustness the CPU should be yielded if possible in this loop. The reason for the looping is that the desired page of bp is outside the valid range. Stepping through the code with DDB (below), shows that each time around the loop, the buffer bp is not in the cache, and is getting reconstituted. I am using a bsize of 8192, so there are two pages per buffer. The second page is the one that is desired. Examining the VM pages in the buffer shows the first one valid, but the second one invalid, with m->busy == 1, but with PG_BUSY not set. Thus, it seems that pagein is supposed to be occurring. Either the pagein never got started, or else somehow it's completion was missed or forgotten. What seems to be the case is that when the breakpoint is set, a COW occurs, moving? the VM page from the underlying object (assocated with a vnode/NFS pager) to the top-level, anonymous object. Then this process terminates, and a new process is restarted, freeing the top-level object but leaving no VM page in the underlying object. When the new process tries to fetch from this page, it faults. Somehow there is a race condition involving the pagein of this page, leading to the observed looping. (DDB trace showing loop follows) --------- After 72 instructions (0 loads, 0 stores), Stopped at _vm_map_simplify_entry+0x175: call _vm_object_deallocate db> trace _vm_map_simplify_entry(f09f5f00,f1466e80) at _vm_map_simplify_entry+0x175 __vm_map_clip_start(f09f5f00,f1466e80,f3172000) at __vm_map_clip_start+0x14 _vm_map_delete(f09f5f00,f3172000,f3174000,f03983ec,efbffd14) at _vm_map_delete+0x3a _bfreekva(f2d567b4) at _bfreekva+0x22 _brelse(f2d567b4) at _brelse+0x300 _nfs_bioread(f13d3780,efbffe44,8,f102f780,1) at _nfs_bioread+0x716 _nfs_getpages(efbffe80) at _nfs_getpages+0xc8 _vnode_pager_getpages(f1478f80,efbfff38,1,0,efbfff58) at _vnode_pager_getpages+0x64 _vm_pager_get_pages(f1478f80,efbfff38,1,0) at _vm_pager_get_pages+0x1f _vm_fault(f13eb000,a000,1,0,0) at _vm_fault+0x5be _trap_pfault(efbfffbc,1) at _trap_pfault+0xe8 _trap(27,27,9f68,a748,efbfd0fc) at _trap+0x12f calltrap() at calltrap+0x15 --- trap 0xc, eip = 0x2000e8a9, esp = 0xefbfd0c8, ebp = 0xefbfd0fc --- db> step ,100 Stopped at __vm_map_clip_end+0xaf: call _vm_object_reference db> trace __vm_map_clip_end(f09f5f00,f1466e80,f3174000) at __vm_map_clip_end+0xaf _vm_map_delete(f09f5f00,f3172000,f3174000,f03983ec,efbffd14) at _vm_map_delete+0x93 _bfreekva(f2d567b4) at _bfreekva+0x22 _brelse(f2d567b4) at _brelse+0x300 _nfs_bioread(f13d3780,efbffe44,8,f102f780,1) at _nfs_bioread+0x716 _nfs_getpages(efbffe80) at _nfs_getpages+0xc8 _vnode_pager_getpages(f1478f80,efbfff38,1,0,efbfff58) at _vnode_pager_getpages+0x64 _vm_pager_get_pages(f1478f80,efbfff38,1,0) at _vm_pager_get_pages+0x1f _vm_fault(f13eb000,a000,1,0,0) at _vm_fault+0x5be _trap_pfault(efbfffbc,1) at _trap_pfault+0xe8 _trap(27,27,9f68,a748,efbfd0fc) at _trap+0x12f calltrap() at calltrap+0x15 --- trap 0xc, eip = 0x2000e8a9, esp = 0xefbfd0c8, ebp = 0xefbfd0fc --- db> unti After 10 instructions (0 loads, 0 stores), Stopped at _vm_object_reference+0x4e: ret db> After 6 instructions (0 loads, 0 stores), Stopped at __vm_map_clip_end+0xbb: ret db> After 28 instructions (0 loads, 0 stores), Stopped at _vm_map_delete+0x157: call _pmap_remove db> After 19 instructions (0 loads, 0 stores), Stopped at _pmap_remove+0x46: call _get_ptbase db> After 11 instructions (0 loads, 0 stores), Stopped at _get_ptbase+0x30: ret db> After 51 instructions (0 loads, 0 stores), Stopped at _pmap_remove+0xd3: ret db> After 4 instructions (0 loads, 0 stores), Stopped at _vm_map_delete+0x163: call _vm_map_entry_delete db> After 20 instructions (0 loads, 0 stores), Stopped at _vm_map_entry_delete+0x3b: call _vm_object_deallocate db> After 20 instructions (0 loads, 0 stores), Stopped at _vm_object_deallocate+0x1b3: ret db> After 4 instructions (0 loads, 0 stores), Stopped at _vm_map_entry_delete+0x45: call _vm_map_entry_dispose db> After 18 instructions (0 loads, 0 stores), Stopped at _vm_map_entry_dispose+0x81: ret db> After 5 instructions (0 loads, 0 stores), Stopped at _vm_map_entry_delete+0x50: ret db> After 16 instructions (0 loads, 0 stores), Stopped at _vm_map_delete+0x185: ret db> After 4 instructions (0 loads, 0 stores), Stopped at _bfreekva+0x2d: ret db> After 18 instructions (0 loads, 0 stores), Stopped at _brelse+0x45b: ret db> After 21 instructions (0 loads, 0 stores), Stopped at _nfs_bioread+0x5d6: call _nfs_getcacheblk db> After 20 instructions (0 loads, 0 stores), Stopped at _nfs_getcacheblk+0x81: call _getblk db> After 24 instructions (0 loads, 0 stores), Stopped at _getblk+0x5f: call _gbincore db> After 23 instructions (0 loads, 0 stores), Stopped at _gbincore+0x37: ret db> After 9 instructions (0 loads, 0 stores), Stopped at _getblk+0x13c: call _getnewbuf db> After 19 instructions (0 loads, 0 stores), Stopped at _getnewbuf+0x41: call _bremfree db> After 33 instructions (0 loads, 0 stores), Stopped at _bremfree+0x7e: ret db> After 46 instructions (0 loads, 0 stores), Stopped at _getnewbuf+0x2d4: call _bfreekva db> After 9 instructions (0 loads, 0 stores), Stopped at _bfreekva+0x2d: ret db> After 7 instructions (0 loads, 0 stores), Stopped at _getnewbuf+0x2e7: call _vm_map_findspace db> After 202 instructions (0 loads, 0 stores), Stopped at _vm_map_findspace+0xb6: ret db> After 21 instructions (0 loads, 0 stores), Stopped at _getnewbuf+0x339: call _vm_map_insert db> After 26 instructions (0 loads, 0 stores), Stopped at _vm_map_insert+0x5c: call _vm_map_lookup_entry db> After 38 instructions (0 loads, 0 stores), Stopped at _vm_map_lookup_entry+0x6e: ret db> After 66 instructions (0 loads, 0 stores), Stopped at _vm_map_insert+0x250: ret db> After 12 instructions (0 loads, 0 stores), Stopped at _getnewbuf+0x356: ret db> After 12 instructions (0 loads, 0 stores), Stopped at _getblk+0x196: calll *%eax db> After 10 instructions (0 loads, 0 stores), Stopped at _nfs_islocked+0x1b: ret db> After 6 instructions (0 loads, 0 stores), Stopped at _getblk+0x1a3: call _gbincore db> After 23 instructions (0 loads, 0 stores), Stopped at _gbincore+0x37: ret db> After 9 instructions (0 loads, 0 stores), Stopped at _getblk+0x1cf: call _bgetvp db> After 40 instructions (0 loads, 0 stores), Stopped at _bgetvp+0x8c: ret db> After 40 instructions (0 loads, 0 stores), Stopped at _getblk+0x25f: call _allocbuf db> After 90 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x412: call _vm_page_lookup db> After 52 instructions (0 loads, 0 stores), Stopped at _vm_page_lookup+0x96: ret db> After 30 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x51a: call _vfs_buf_set_valid db> After 67 instructions (0 loads, 0 stores), Stopped at _vfs_buf_set_valid+0x87: ret db> After 3 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x523: call _vm_page_wire db> After 13 instructions (0 loads, 0 stores), Stopped at _vm_page_wire+0x27: call _vm_page_unqueue db> After 34 instructions (0 loads, 0 stores), Stopped at _vm_page_unqueue+0x7a: ret db> After 16 instructions (0 loads, 0 stores), Stopped at _vm_page_wire+0x60: ret db> After 32 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x412: call _vm_page_lookup db> After 59 instructions (0 loads, 0 stores), Stopped at _vm_page_lookup+0x96: ret db> After 30 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x51a: call _vfs_buf_set_valid db> After 32 instructions (0 loads, 0 stores), Stopped at _vfs_buf_set_valid+0x87: ret db> After 3 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x523: call _vm_page_wire db> After 13 instructions (0 loads, 0 stores), Stopped at _vm_page_wire+0x27: call _vm_page_unqueue db> After 33 instructions (0 loads, 0 stores), Stopped at _vm_page_unqueue+0x7a: ret db> After 16 instructions (0 loads, 0 stores), Stopped at _vm_page_wire+0x60: ret db> After 27 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x585: call _pmap_qenter db> After 53 instructions (0 loads, 0 stores), Stopped at _pmap_qenter+0x54: ret db> After 24 instructions (0 loads, 0 stores), Stopped at _allocbuf+0x5d2: ret db> After 7 instructions (0 loads, 0 stores), Stopped at _getblk+0x26d: ret db> After 14 instructions (0 loads, 0 stores), Stopped at _nfs_getcacheblk+0xaa: ret db> After 41 instructions (0 loads, 0 stores), Stopped at _nfs_bioread+0x711: call _brelse db> After 77 instructions (0 loads, 0 stores), Stopped at _brelse+0x1d1: call _vm_page_test_dirty db> After 9 instructions (0 loads, 0 stores), Stopped at _vm_page_test_dirty+0x21: ret db> After 32 instructions (0 loads, 0 stores), Stopped at _brelse+0x1d1: call _vm_page_test_dirty db> After 8 instructions (0 loads, 0 stores), Stopped at _vm_page_test_dirty+0x10: call _pmap_is_modified db> After 5 instructions (0 loads, 0 stores), Stopped at _pmap_is_modified+0x8: call _pmap_testbit db> After 37 instructions (0 loads, 0 stores), Stopped at _pmap_testbit+0x100: ret db> After 2 instructions (0 loads, 0 stores), Stopped at _pmap_is_modified+0xe: ret db> After 5 instructions (0 loads, 0 stores), Stopped at _vm_page_test_dirty+0x21: ret db> After 7 instructions (0 loads, 0 stores), Stopped at _brelse+0x1e4: call _vm_page_set_invalid db> After 37 instructions (0 loads, 0 stores), Stopped at _vm_page_set_invalid+0x81: ret db> After 8 instructions (0 loads, 0 stores), Stopped at _brelse+0x1fd: call _pmap_page_protect db> After 10 instructions (0 loads, 0 stores), Stopped at _pmap_page_protect+0x21: call _pmap_remove_all db> After 39 instructions (0 loads, 0 stores), Stopped at _pmap_remove_all+0x18b: ret db> After 2 instructions (0 loads, 0 stores), Stopped at _pmap_page_protect+0x27: ret db> After 21 instructions (0 loads, 0 stores), Stopped at _brelse+0x263: call _vfs_vmio_release db> After 14 instructions (0 loads, 0 stores), Stopped at _vfs_vmio_release+0x2b: call _vm_page_unwire db> After 29 instructions (0 loads, 0 stores), Stopped at _vm_page_unwire+0x75: ret db> After 27 instructions (0 loads, 0 stores), Stopped at _vfs_vmio_release+0x2b: call _vm_page_unwire db> After 29 instructions (0 loads, 0 stores), Stopped at _vm_page_unwire+0x75: ret db> After 17 instructions (0 loads, 0 stores), Stopped at _vfs_vmio_release+0x11a: call _pmap_qremove db> After 27 instructions (0 loads, 0 stores), Stopped at _pmap_qremove+0x32: ret db> After 8 instructions (0 loads, 0 stores), Stopped at _vfs_vmio_release+0x141: call _brelvp db> After 36 instructions (0 loads, 0 stores), Stopped at _brelvp+0x7d: ret db> After 6 instructions (0 loads, 0 stores), Stopped at _vfs_vmio_release+0x14d: ret db> After 35 instructions (0 loads, 0 stores), Stopped at _brelse+0x2fb: call _bfreekva db> After 12 instructions (0 loads, 0 stores), Stopped at _bfreekva+0x1d: call _vm_map_delete db> After 12 instructions (0 loads, 0 stores), Stopped at _vm_map_delete+0x14: call _vm_map_lookup_entry db> After 26 instructions (0 loads, 0 stores), Stopped at _vm_map_lookup_entry+0x6e: ret db> After 10 instructions (0 loads, 0 stores), Stopped at _vm_map_delete+0x35: call __vm_map_clip_start db> After 9 instructions (0 loads, 0 stores), Stopped at __vm_map_clip_start+0xf: call _vm_map_simplify_entry db> After 72 instructions (0 loads, 0 stores), Stopped at _vm_map_simplify_entry+0x175: call _vm_object_deallocate >Fix: WORKAROUND I have been running the following patch for about a month on a moderately loaded system that currently averages about 60 users during peak periods each day. There can be up to 15 or 20 students doing debugging with GDB at a time. The printf is exercised several times per day, more frequently if lots of people are doing debugging. The system has not wedged since the patch was installed, and I have noticed no other ill effects. Gene Stark stark@freebsd.org # cvs diff -c nfs_bio.c Index: nfs_bio.c =================================================================== RCS file: /A/cvs/src/sys/nfs/nfs_bio.c,v retrieving revision 1.28.2.7 diff -c -r1.28.2.7 nfs_bio.c *** nfs_bio.c 1998/01/28 00:26:54 1.28.2.7 --- nfs_bio.c 1998/10/07 00:16:17 *************** *** 356,363 **** panic("nfsbioread"); if (VOP_BWRITE(bp) == EINTR) return (EINTR); ! } else brelse(bp); goto again; } } --- 356,387 ---- panic("nfsbioread"); if (VOP_BWRITE(bp) == EINTR) return (EINTR); ! } else { ! #ifdef NFS_PTRACE_BUG ! /* ! * E. Stark - 9/30/98 ! * Avoid spinning here on a partial ! * buffer, by invalidating the buffer ! * and yielding the CPU for awhile. ! * There is a race condition involving ! * ptrace writes to text segment that ! * seems to exercise this bug. ! */ ! int ret; ! bp->b_flags |= B_INVAL; brelse(bp); + if((ret = + tsleep (0xdeadbeef, PRIBIO | PCATCH, + "nfsptbug", hz/10)) != 0) { + if(ret != EWOULDBLOCK) { + printf("nfs_bioread: nfs_ptrace_bug (ret=0x%x)\n", ret); + return(ret); + } + } + #else + brelse(bp); + #endif + } goto again; } } >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Nov 5 14:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA09148 for freebsd-bugs-outgoing; Thu, 5 Nov 1998 14:10:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA09136 for ; Thu, 5 Nov 1998 14:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id OAA16899; Thu, 5 Nov 1998 14:10:00 -0800 (PST) Date: Thu, 5 Nov 1998 14:10:00 -0800 (PST) Message-Id: <199811052210.OAA16899@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: John Fieber Subject: Re: kern/6858: inetd in realloc(): warning: junk pointer, too low to make sense. Reply-To: John Fieber Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/6858; it has been noted by GNATS. From: John Fieber To: freebsd-gnats-submit@freebsd.org Cc: jher@io.com Subject: Re: kern/6858: inetd in realloc(): warning: junk pointer, too low to make sense. Date: Thu, 5 Nov 1998 17:07:54 -0500 (EST) At least some dimension of this PR seems to be the same problem as bin/8183 (http://www.freebsd.org/cgi/query-pr.cgi?pr=8183) I doubt it is hardware related because my inetd started dying regularly as a consequence of upgrading from 2.2.7 to 3.0, with no hardware change at all. I've just applied the last patch in the bin/8183 and I'll see how it goes. -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Nov 5 14:43:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12743 for freebsd-bugs-outgoing; Thu, 5 Nov 1998 14:43:06 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12735; Thu, 5 Nov 1998 14:43:00 -0800 (PST) (envelope-from ken@FreeBSD.org) From: Kenneth Merry Received: (from ken@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id OAA18857; Thu, 5 Nov 1998 14:43:02 -0800 (PST) Date: Thu, 5 Nov 1998 14:43:02 -0800 (PST) Message-Id: <199811052243.OAA18857@freefall.freebsd.org> To: ilg@Romania.EU.net, ken@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, ken@FreeBSD.ORG Subject: Re: kern/8555 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: boot panic with SONY SCSI CD-ROM CDU625-S 1.0r hooked State-Changed-From-To: feedback-closed State-Changed-By: ken State-Changed-When: Thu Nov 5 14:38:52 PST 1998 State-Changed-Why: There are three separate problems in this PR. The first is that in 3.0, we panic when the da or CD drivers fail to attach. This has been fixed in -current. The second is that this user's Sony CDROM drive doesn't like being probed on multiple LUNs. The patch I sent, which has been committed to -current, fixes that problem. It also causes the first problem above to be avoided. The third problem is that the user appears to have a cabling, parity or termination problem on his SCSI chain. That can't be fixed in software. Responsible-Changed-From-To: freebsd-bugs->ken Responsible-Changed-By: ken Responsible-Changed-When: Thu Nov 5 14:38:52 PST 1998 Responsible-Changed-Why: I committed the fixes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Thu Nov 5 19:39:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10604 for freebsd-bugs-outgoing; Thu, 5 Nov 1998 19:39:10 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA10593; Thu, 5 Nov 1998 19:39:03 -0800 (PST) (envelope-from jkoshy@FreeBSD.org) From: Joseph Koshy Received: (from jkoshy@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id TAA01675; Thu, 5 Nov 1998 19:39:04 -0800 (PST) Date: Thu, 5 Nov 1998 19:39:04 -0800 (PST) Message-Id: <199811060339.TAA01675@freefall.freebsd.org> To: jbackus@plex.nl, jkoshy@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/7629 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: fdisk does not recognize BSD/OS partitions State-Changed-From-To: open-closed State-Changed-By: jkoshy State-Changed-When: Thu Nov 5 19:38:35 PST 1998 State-Changed-Why: Patch committed to rev 1.25 of "src/sbin/i386/fdisk/fdisk.c", thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Nov 6 02:48:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14547 for freebsd-bugs-outgoing; Fri, 6 Nov 1998 02:48:37 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from vss.sci-nnov.ru (vss.sci-nnov.ru [193.125.71.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14172; Fri, 6 Nov 1998 02:43:33 -0800 (PST) (envelope-from dmiter@sci-nnov.ru) Received: from winhome (home.sci-nnov.ru [194.190.176.102]) by vss.sci-nnov.ru (8.8.8/Dmiter-4.2vss) with SMTP id NAA06955; Fri, 6 Nov 1998 13:42:38 +0300 (MSK) Message-ID: <000301be0972$10f05460$0200000a@winhome.sci-nnov.ru> Reply-To: "Dmitry Eremin" From: "Dmitry Eremin" To: Cc: Subject: /kernel: arp: 192.168.1.188 is on de1 but got reply from 00:c0:4f:a4:81:2d on de0 Date: Fri, 6 Nov 1998 13:41:43 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have cvsuped version FreeBSD 3.0-CURRENT #6: Fri Nov 6 10:24:07 MSK 1998 and following configuration. Interface de0 have real IP address and connected to Internet router. In this network only two address, our computer and router. Interface de1 connected to our Intranet. $ Ifconfig -a de0: flags=88c3 mtu 1500 inet xx.xx.xx.xx netmask 0xfffffffc broadcast xx.xx.xx.xx ether 00:00:c0:b2:9f:d0 media: 10baseT/UTP status: active supported media: 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP de1: flags=8843 mtu 1500 inet 192.168.1.239 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:00:c0:b8:a1:d0 media: 10baseT/UTP status: active supported media: 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP I have the following messages in the syslog: /kernel: arp: 192.168.1.188 is on de1 but got reply from 00:c0:4f:a4:81:2d on de0 $ tcpdump -i de1 arp arp who-has 192.168.1.188 tell 192.168.1.231 arp reply 192.168.1.188 is-at 0:c0:4f:a4:81:2d $ tcpdump -i de0 arp arp who-has 192.168.1.188 tell 192.168.1.231 As you see, into de0 relay hasn't been received. What is happening? What I do not right? Help me please. Best regards, Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Nov 6 08:39:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA22848 for freebsd-bugs-outgoing; Fri, 6 Nov 1998 08:39:16 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from alpha.xerox.com (omega.Xerox.COM [13.1.64.95]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA22829; Fri, 6 Nov 1998 08:39:06 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <430726(3)>; Fri, 6 Nov 1998 08:38:50 PST Received: from mango.parc.xerox.com (localhost.parc.xerox.com [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id IAA28819; Fri, 6 Nov 1998 08:38:43 -0800 (PST) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199811061638.IAA28819@mango.parc.xerox.com> To: "Dmitry Eremin" cc: freebsd-current@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: /kernel: arp: 192.168.1.188 is on de1 but got reply from 00:c0:4f:a4:81:2d on de0 In-reply-to: Your message of "Fri, 06 Nov 1998 02:41:43 PST." <000301be0972$10f05460$0200000a@winhome.sci-nnov.ru> Date: Fri, 6 Nov 1998 08:38:43 PST From: Bill Fenner Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Did the message get printed during your tcpdump, or was the tcpdump taken at a different time? Could you try to replicate this with both tcpdumps running at the same time (on different screens to not intersperse the output) and include the timestamps? Does the ARP entry get installed correctly? i.e. 1) Does "arp 192.168.1.188" show the right MAC address? 2) Does "route get 192.168.1.188" list the correct interface? Do you have any idea why the ARP request shows up on both interfaces? FreeBSD doesn't send ARP requests out multiple interfaces, so perhaps you have something funny going on at layer 2 (e.g. shared hub between the two different networks, or a broken switch)? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Nov 6 13:08:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA02698 for freebsd-bugs-outgoing; Fri, 6 Nov 1998 13:08:16 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from vss.sci-nnov.ru (vss.sci-nnov.ru [193.125.71.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA02690; Fri, 6 Nov 1998 13:08:03 -0800 (PST) (envelope-from dmiter@sci-nnov.ru) Received: from winhome (home.sci-nnov.ru [194.190.176.102]) by vss.sci-nnov.ru (8.8.8/Dmiter-4.2vss) with SMTP id AAA25453; Sat, 7 Nov 1998 00:07:18 +0300 (MSK) Message-ID: <001a01be09c9$510c0010$0200000a@winhome.sci-nnov.ru> Reply-To: "Dmitry Eremin" From: "Dmitry Eremin" To: "Bill Fenner" Cc: , Subject: Re: /kernel: arp: 192.168.1.188 is on de1 but got reply from 00:c0:4f:a4:81:2d on de0 Date: Sat, 7 Nov 1998 00:06:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Did the message get printed during your tcpdump, or was the tcpdump taken >at a different time? Could you try to replicate this with both tcpdumps >running at the same time (on different screens to not intersperse the >output) and include the timestamps? Both tcpdump runing in same time in defferent window. $ tcpdump -tvvi de1 arp 22:55:35.096038 arp who-has 192.168.1.205 tell 192.168.1.48 22:55:35.096517 arp reply 192.168.1.205 is-at 0:10:4b:35:60:6c $ tcpdump -tvvi de0 arp 22:55:35.096107 arp who-has 192.168.1.205 tell 192.168.1.48 >Does the ARP entry get installed correctly? i.e. >1) Does "arp 192.168.1.188" show the right MAC address? # arp 192.168.1.205 192.168.1.205 (192.168.1.205) -- no entry >2) Does "route get 192.168.1.188" list the correct interface? # route get 192.168.1.205 route to: 192.168.1.205 destination: 192.168.1.0 mask: 255.255.255.0 interface: de1 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 -24616 >Do you have any idea why the ARP request shows up on both interfaces? I don't known hay this happening. This system has working as router. May be it is forwarding? sysctl say: [...skip...] net.inet.ip.forwarding: 1 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.sourceroute: 0 [...skip...] net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 [...skip...] >FreeBSD doesn't send ARP requests out multiple interfaces, so perhaps >you have something funny going on at layer 2 (e.g. shared hub between >the two different networks, or a broken switch)? NO. We have't any devices between these networks. de0: flags=88c3 mtu 1500 inet xx.xx.xx.xx netmask 0xfffffffc broadcast xx.xx.xx.xx ^^^^^^^^^^^^^^^^^^ In the net de0 we have only TWO address. One have my FreeBSD computer and second have Internet router!!!! I want to attract you attention on my Ethernet cards. This is identical card. de0: rev 0x12 int a irq 11 on pci0.12.0 de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:b2:9f:d0 de0: enabling 10baseT port de1: rev 0x12 int a irq 10 on pci0.13.0 de1: SMC 9332DST 21140 [10-100Mb/s] pass 1.2 de1: address 00:00:c0:b8:a1:d0 de1: enabling 10baseT port I think kernel doesn't correct work in this case. Best regards, Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Nov 6 14:08:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10391 for freebsd-bugs-outgoing; Fri, 6 Nov 1998 14:08:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10360; Fri, 6 Nov 1998 14:07:57 -0800 (PST) (envelope-from mike@seidata.com) From: mike@seidata.com Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id RAA20780; Fri, 6 Nov 1998 17:07:04 -0500 (EST) Date: Fri, 6 Nov 1998 17:07:00 -0500 (EST) To: Bill Fenner cc: Dmitry Eremin , freebsd-current@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: /kernel: arp: 192.168.1.188 is on de1 but got reply from 00:c0:4f:a4:81:2d on de0 In-Reply-To: <199811061638.IAA28819@mango.parc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 6 Nov 1998, Bill Fenner wrote: > FreeBSD doesn't send ARP requests out multiple interfaces, so perhaps > you have something funny going on at layer 2 (e.g. shared hub between > the two different networks, or a broken switch)? Broken switch? *sigh* I've got (they've died off lately, but were much more frequent when I first implemented the BSD-based NAT box) the same sort of error here with the following setup: +---------------+ LAN1--| Catalyst 1900 | +---------------+ +-------------+ +---------------+ LAN2--| Catalyst 1900 |--| FreeBSD 3.0 |--| Catalyst 2940 |--INET +---------------+ +-------------+ +---------------+ LAN3--| Catalyst 1900 | | Catalyst 1900 | +---------------+ +---------------+ The Catalyst 1900's on the left provide 10BT connectivity to three local nets (10.0.1, 10.0.2, 10.0.3) and connect to the BSD box via 100BT. They are daisey-chained via standard cross over cables using their 100BT uplink ports. LAN's 1-3 and Windows 95, Windows NT and Macintosh LANs. They undergo packet filtering and NAT at the BSD box. The Catalyst 2940 and 1900 switches on the right provide 100BT and 10BT connectivity (repsectively) for servers I have 'outside' of my firewall (FreeBSD shell, FTP, personal WWW, etc. servers). Just FYI, maybe my setup will be similar to his in some way and present an obvious design flaw. Later, -mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Fri Nov 6 15:18:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19656 for freebsd-bugs-outgoing; Fri, 6 Nov 1998 15:18:35 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19622; Fri, 6 Nov 1998 15:18:25 -0800 (PST) (envelope-from msmith@FreeBSD.org) From: Michael Smith Received: (from msmith@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id PAA04530; Fri, 6 Nov 1998 15:18:26 -0800 (PST) Date: Fri, 6 Nov 1998 15:18:26 -0800 (PST) Message-Id: <199811062318.PAA04530@freefall.freebsd.org> To: nik@iii.co.uk, msmith@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/7586 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: [PATCH] Threads bug in libc_r preventing MySQL from shutting down State-Changed-From-To: open-closed State-Changed-By: msmith State-Changed-When: Fri Nov 6 15:18:04 PST 1998 State-Changed-Why: Patch committed by jb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 00:10:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA07646 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 00:10:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA07596 for ; Sat, 7 Nov 1998 00:09:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id AAA22443; Sat, 7 Nov 1998 00:10:01 -0800 (PST) Received: from newport-1-5.quick.net (newport-1-5.quick.net [207.212.160.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA07362 for ; Sat, 7 Nov 1998 00:05:04 -0800 (PST) (envelope-from josh@newport-1-5.quick.net) Received: (from josh@localhost) by newport-1-5.quick.net (8.9.1/8.9.1) id EAA05651; Sat, 7 Nov 1998 04:09:28 -0800 (PST) (envelope-from josh) Message-Id: <199811071209.EAA05651@newport-1-5.quick.net> Date: Sat, 7 Nov 1998 04:09:28 -0800 (PST) From: josh@quick.net Reply-To: josh@quick.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/8586: new port: misc/kmamerun Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8586 >Category: i386 >Synopsis: new port: misc/kmamerun >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 00:10:00 PST 1998 >Last-Modified: >Originator: Josh Gilliam >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: >Description: KMameRun is a KDE frontend to X-Mame, the X11/Unix port of the MultiArcade Machine Emulator. >How-To-Repeat: >Fix: Port located at ftp://ftp.freebsd.org/pub/FreeBSD/incoming/kmamerun-0.2.1-port.tgz MD5 (kmamerun-0.2.1-port.tgz) = fcc004bf588cd26f0288b676f3aec877 >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 01:45:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA14663 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 01:45:22 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from relay1.nk.ukrtel.net (relay2.aip.mk.ua [195.5.7.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA14590 for ; Sat, 7 Nov 1998 01:44:10 -0800 (PST) (envelope-from alec@nikts.nk.ukrtel.net) Received: from nikts.nk.ukrtel.net (nikts-LAN-gw.nk.ukrtel.net [195.5.9.14]) by relay1.nk.ukrtel.net (KSerg;v2.8r/8.9.1) with ESMTP id LAA08786 for ; Sat, 7 Nov 1998 11:44:01 +0200 (EET) (envelope-from alec@nikts.nk.ukrtel.net) Received: from alec1.nikts (IDENT:alec@[128.5.4.22]) by nikts.nk.ukrtel.net (KSerg;v2.8r/8.9.1) with ESMTP id LAA06211 for ; Sat, 7 Nov 1998 11:43:05 +0200 (EET) (envelope-from alec@nikts.nk.ukrtel.net) Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-5 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 07 Nov 1998 11:46:06 +0200 (EET) From: Alexander N Shulyak To: freebsd-bugs@FreeBSD.ORG Subject: FreeBSD bug Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org malloc: cannot allocate memory This error message i get when try to retrive big enough table PostgreSQL using interactive monitor psql. My system Free-BSD 2.2.7, PostgreSQL v6.3.2 and v6.4 running on Pentium 166 with 48MB-RAM, swap space 200MB(the most usage at the moment of error 37%) Table size is about 5MB (not too big i think). If I link psql with libmalloc (from 2.2.7 packages) request works. To repeat start Postgres, run psql and request SELECT * FROM Big_Enough_Table; Sorry, but with Linux RH-5.1 all works well. --- -------------------------------------------------------------------------- Alexander N Shulyak | E-Mail: Alexander N Shulyak | Date: 07-Nov-98 Nikolaev | Time: 11:45:56 Ukraine | This message was sent by XFMail -------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 01:49:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA15251 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 01:49:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA15242 for ; Sat, 7 Nov 1998 01:49:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id BAA25506; Sat, 7 Nov 1998 01:50:00 -0800 (PST) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA14625 for ; Sat, 7 Nov 1998 01:44:44 -0800 (PST) (envelope-from marcs@alive.znep.com) Received: (from marcs@localhost) by alive.znep.com (8.9.1/8.9.1) id BAA18272; Sat, 7 Nov 1998 01:40:32 -0800 (PST) (envelope-from marcs) Message-Id: <199811070940.BAA18272@alive.znep.com> Date: Sat, 7 Nov 1998 01:40:32 -0800 (PST) From: marcs@znep.com Reply-To: marcs@znep.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: conf/8587: login.conf should not set manpath Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8587 >Category: conf >Synopsis: login.conf should not set manpath >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 01:50:00 PST 1998 >Last-Modified: >Originator: Marc Slemko >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD alive.znep.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Fri Nov 6 23:10:01 PST 1998 marcs@alive.znep.com:/usr/src/sys/compile/ALIVE i386 Appears to have been around for a long time, possibly even before login.conf. >Description: login.conf sets a manpath. The default manpath doesn't include /usr/X11R6/man, so things don't work right. I shouldn't have to mess with activating a special class just for X users, etc. >How-To-Repeat: marcs@alive:~$ echo $MANPATH /usr/share/man:/usr/local/man marcs@alive:~$ man xrdb No manual entry for xrdb marcs@alive:~$ unset MANPATH marcs@alive:~$ man xrdb (now it works right) >Fix: Remove the manpath setting from /etc/login.conf. Then man will use the manpath program to figure out the manpath, which actually uses the manpath.config file, etc. Let manpath do its job. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 05:10:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA02126 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 05:10:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA02077 for ; Sat, 7 Nov 1998 05:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id FAA03774; Sat, 7 Nov 1998 05:10:01 -0800 (PST) Date: Sat, 7 Nov 1998 05:10:01 -0800 (PST) Message-Id: <199811071310.FAA03774@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Josh Gilliam Subject: Re: i386/8586: new port: misc/kmamerun Reply-To: Josh Gilliam Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/8586; it has been noted by GNATS. From: Josh Gilliam To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: i386/8586: new port: misc/kmamerun Date: Sat, 7 Nov 1998 09:11:01 -0800 > >Category: i386 Should be ports -- Josh Gilliam 6745 Washington Ave #198 1 626 968 5232 Whittier CA 90601-4325 USA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 06:10:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA05907 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 06:10:02 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA05856 for ; Sat, 7 Nov 1998 06:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id GAA04945; Sat, 7 Nov 1998 06:10:01 -0800 (PST) Date: Sat, 7 Nov 1998 06:10:01 -0800 (PST) Message-Id: <199811071410.GAA04945@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: HighWind Software Information Subject: Re: kern/8500: FreeBSD 3.0 thread scheduler is broken Reply-To: HighWind Software Information Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8500; it has been noted by GNATS. From: HighWind Software Information To: peter@netplex.com.au Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/8500: FreeBSD 3.0 thread scheduler is broken Date: Sat, 7 Nov 1998 09:08:05 -0500 (EST) Okay.. I buy your explanation. FreeBSD's low level read()/write() are always blocking through the kernel when talking to UFS. That certainly will make it hard to do task switching. I think the right thing to do is to count that time and allow that time to effect when the thread switch happens. HOWEVER, I'm certainly willing to try aio_read/aio_write. WHERE IS THAT STUFF? I found "sys/aio.h", however, I can't find any library that has it. Nor can I find "aio_read" in any .c files in /usr/src. -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 09:04:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15368 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 09:04:24 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15362; Sat, 7 Nov 1998 09:04:20 -0800 (PST) (envelope-from fenner@FreeBSD.org) From: Bill Fenner Received: (from fenner@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id JAA20206; Sat, 7 Nov 1998 09:04:22 -0800 (PST) Date: Sat, 7 Nov 1998 09:04:22 -0800 (PST) Message-Id: <199811071704.JAA20206@freefall.freebsd.org> To: fenner@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: i386/8586 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: new port: misc/kmamerun Responsible-Changed-From-To: freebsd-bugs->freebsd-ports Responsible-Changed-By: fenner Responsible-Changed-When: Sat Nov 7 09:03:57 PST 1998 Responsible-Changed-Why: Port submission. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 09:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15823 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 09:10:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15815 for ; Sat, 7 Nov 1998 09:09:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id JAA20299; Sat, 7 Nov 1998 09:10:01 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15342; Sat, 7 Nov 1998 09:03:54 -0800 (PST) (envelope-from nobody) Message-Id: <199811071703.JAA15342@hub.freebsd.org> Date: Sat, 7 Nov 1998 09:03:54 -0800 (PST) From: rv@fore.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8589: incorrect spelling for "dependency" and "dependencies" in kernel code Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8589 >Category: kern >Synopsis: incorrect spelling for "dependency" and "dependencies" in kernel code >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 09:10:01 PST 1998 >Last-Modified: >Originator: Rajesh Vaidheeswarran >Organization: >Release: 3.0-current (cvsup from 3.0-RELEASE) >Environment: FreeBSD freebsd.eng.fore.com 3.0-RELEASE FreeBSD 3.0-RELEASE #2: Sun Nov 1 18:06:32 EST 1998 bash@freebsd.eng.fore.com:/usr/src/sys/compile/FB30 i386 >Description: The following files have incorrect spelling for dependenc(y|ies) boot/common/module.c kern/kern_linker.c kern/link_aout.c kern/link_elf.c sys/linker.h According to webster there is no such word as 'dependancy' or 'dependancies'. Kind of gets hard to grep sources with incorrect spelling.. of course, code works just fine :) rv>~/bin/webster dependancies No entries found that match your query. Here is a list of similar words. 4 words found. 1. dependances 2. dependences 3. Dependencies 4. dependencies rv>~/bin/webster dependancy No entries found that match your query. Here is a list of similar words. 4 words found. 1. dependance 2. dependence 3. Dependency 4. dependency >How-To-Repeat: look at the files... >Fix: *** boot/common/module.c Fri Oct 9 19:12:34 1998 --- boot/common/module.c.new Sat Nov 7 11:56:05 1998 *************** *** 169,175 **** /* * We've been asked to load (name) and give it (argc),(argv). * Start by trying to load it, and then attempt to load all of its ! * dependancies. If we fail at any point, throw them all away and * fail the entire load. * * XXX if a depended-on module requires arguments, it must be loaded --- 169,175 ---- /* * We've been asked to load (name) and give it (argc),(argv). * Start by trying to load it, and then attempt to load all of its ! * dependencies. If we fail at any point, throw them all away and * fail the entire load. * * XXX if a depended-on module requires arguments, it must be loaded *************** *** 195,201 **** return(CMD_ERROR); /* ! * Look for dependancies. */ while ((dep_name = mod_searchdep(base_mod)) != NULL) { printf("loading required module '%s'\n", dep_name); --- 195,201 ---- return(CMD_ERROR); /* ! * Look for dependencies. */ while ((dep_name = mod_searchdep(base_mod)) != NULL) { printf("loading required module '%s'\n", dep_name); *************** *** 279,285 **** /* * Load the module (name), pass it (argc),(argv). ! * Don't do any dependancy checking. */ static struct loaded_module * mod_loadmodule(char *name, int argc, char *argv[]) --- 279,285 ---- /* * Load the module (name), pass it (argc),(argv). ! * Don't do any dependency checking. */ static struct loaded_module * mod_loadmodule(char *name, int argc, char *argv[]) *************** *** 331,337 **** /* * Search the modules from (mp) onwards, and return the name of the ! * first unresolved dependancy, or NULL if none were found. */ static char * mod_searchdep(struct loaded_module *mp) --- 331,337 ---- /* * Search the modules from (mp) onwards, and return the name of the ! * first unresolved dependency, or NULL if none were found. */ static char * mod_searchdep(struct loaded_module *mp) *************** *** 356,366 **** if (deps != NULL && deplen > 0) { ! /* Iterate over dependancies */ dindex = 0; while (dindex < deplen) { /* ! * Look for a module matching the dependancy; if we don't have it, * we need it. */ if ((dmp = mod_findmodule(&deps[dindex], NULL)) == NULL) --- 356,366 ---- if (deps != NULL && deplen > 0) { ! /* Iterate over dependencies */ dindex = 0; while (dindex < deplen) { /* ! * Look for a module matching the dependency; if we don't have it, * we need it. */ if ((dmp = mod_findmodule(&deps[dindex], NULL)) == NULL) *** kern/kern_linker.c Sat Nov 7 10:52:46 1998 --- kern/kern_linker.c.new Sat Nov 7 11:56:05 1998 *************** *** 365,371 **** } int ! linker_file_add_dependancy(linker_file_t file, linker_file_t dep) { linker_file_t* newdeps; --- 365,371 ---- } int ! linker_file_add_dependency(linker_file_t file, linker_file_t dep) { linker_file_t* newdeps; *************** *** 402,408 **** file->ops->symbol_values(file, sym, &symval); if (symval.value == 0) /* ! * For commons, first look them up in the dependancies and * only allocate space if not found there. */ common_size = symval.size; --- 402,408 ---- file->ops->symbol_values(file, sym, &symval); if (symval.value == 0) /* ! * For commons, first look them up in the dependencies and * only allocate space if not found there. */ common_size = symval.size; *************** *** 424,430 **** if (common_size > 0) { /* * This is a common symbol which was not found in the ! * dependancies. We maintain a simple common symbol table in * the file object. */ struct common_symbol* cp; --- 424,430 ---- if (common_size > 0) { /* * This is a common symbol which was not found in the ! * dependencies. We maintain a simple common symbol table in * the file object. */ struct common_symbol* cp; *** kern/link_aout.c Sat Nov 7 10:52:47 1998 --- kern/link_aout.c.new Sat Nov 7 11:56:05 1998 *************** *** 77,83 **** struct _dynamic* dynamic; /* Symbol table etc. */ } *aout_file_t; ! static int load_dependancies(linker_file_t lf); static int relocate_file(linker_file_t lf); /* --- 77,83 ---- struct _dynamic* dynamic; /* Symbol table etc. */ } *aout_file_t; ! static int load_dependencies(linker_file_t lf); static int relocate_file(linker_file_t lf); /* *************** *** 165,172 **** lf->address = af->address; lf->size = ehdr->a_text + ehdr->a_data + ehdr->a_bss; ! /* Try to load dependancies */ ! if (((error = load_dependancies(lf)) != 0) || ((error = relocate_file(lf)) != 0)) { linker_file_unload(lf); return(error); --- 165,172 ---- lf->address = af->address; lf->size = ehdr->a_text + ehdr->a_data + ehdr->a_bss; ! /* Try to load dependencies */ ! if (((error = load_dependencies(lf)) != 0) || ((error = relocate_file(lf)) != 0)) { linker_file_unload(lf); return(error); *************** *** 247,253 **** lf->address = af->address; lf->size = header.a_text + header.a_data + header.a_bss; ! if ((error = load_dependancies(lf)) != 0 || (error = relocate_file(lf)) != 0) { linker_file_unload(lf); goto out; --- 247,253 ---- lf->address = af->address; lf->size = header.a_text + header.a_data + header.a_bss; ! if ((error = load_dependencies(lf)) != 0 || (error = relocate_file(lf)) != 0) { linker_file_unload(lf); goto out; *************** *** 288,294 **** #define AOUT_RELOC(af, type, off) (type*) ((af)->address + (off)) static int ! load_dependancies(linker_file_t lf) { aout_file_t af = lf->priv; linker_file_t lfdep; --- 288,294 ---- #define AOUT_RELOC(af, type, off) (type*) ((af)->address + (off)) static int ! load_dependencies(linker_file_t lf) { aout_file_t af = lf->priv; linker_file_t lfdep; *************** *** 303,315 **** */ if (linker_kernel_file) { linker_kernel_file->refs++; ! linker_file_add_dependancy(lf, linker_kernel_file); } off = LD_NEED(af->dynamic); /* ! * Load the dependancies. */ while (off != 0) { sodp = AOUT_RELOC(af, struct sod, off); --- 303,315 ---- */ if (linker_kernel_file) { linker_kernel_file->refs++; ! linker_file_add_dependency(lf, linker_kernel_file); } off = LD_NEED(af->dynamic); /* ! * Load the dependencies. */ while (off != 0) { sodp = AOUT_RELOC(af, struct sod, off); *************** *** 318,324 **** error = linker_load_file(name, &lfdep); if (error) goto out; ! error = linker_file_add_dependancy(lf, lfdep); if (error) goto out; off = sodp->sod_next; --- 318,324 ---- error = linker_load_file(name, &lfdep); if (error) goto out; ! error = linker_file_add_dependency(lf, lfdep); if (error) goto out; off = sodp->sod_next; *** kern/link_elf.c Sat Nov 7 10:52:47 1998 --- kern/link_elf.c.new Sat Nov 7 11:56:06 1998 *************** *** 108,114 **** } *elf_file_t; static int parse_dynamic(linker_file_t lf); ! static int load_dependancies(linker_file_t lf); static int relocate_file(linker_file_t lf); static int parse_module_symbols(linker_file_t lf); --- 108,114 ---- } *elf_file_t; static int parse_dynamic(linker_file_t lf); ! static int load_dependencies(linker_file_t lf); static int relocate_file(linker_file_t lf); static int parse_module_symbols(linker_file_t lf); *************** *** 373,379 **** linker_file_unload(lf); return error; } ! error = load_dependancies(lf); if (error) { linker_file_unload(lf); return error; --- 373,379 ---- linker_file_unload(lf); return error; } ! error = load_dependencies(lf); if (error) { linker_file_unload(lf); return error; *************** *** 615,621 **** error = parse_dynamic(lf); if (error) goto out; ! error = load_dependancies(lf); if (error) goto out; error = relocate_file(lf); --- 615,621 ---- error = parse_dynamic(lf); if (error) goto out; ! error = load_dependencies(lf); if (error) goto out; error = relocate_file(lf); *************** *** 727,733 **** } static int ! load_dependancies(linker_file_t lf) { elf_file_t ef = lf->priv; linker_file_t lfdep; --- 727,733 ---- } static int ! load_dependencies(linker_file_t lf) { elf_file_t ef = lf->priv; linker_file_t lfdep; *************** *** 740,746 **** */ if (linker_kernel_file) { linker_kernel_file->refs++; ! linker_file_add_dependancy(lf, linker_kernel_file); } for (dp = ef->dynamic; dp->d_tag != DT_NULL; dp++) { --- 740,746 ---- */ if (linker_kernel_file) { linker_kernel_file->refs++; ! linker_file_add_dependency(lf, linker_kernel_file); } for (dp = ef->dynamic; dp->d_tag != DT_NULL; dp++) { *************** *** 750,756 **** error = linker_load_file(name, &lfdep); if (error) goto out; ! error = linker_file_add_dependancy(lf, lfdep); if (error) goto out; } --- 750,756 ---- error = linker_load_file(name, &lfdep); if (error) goto out; ! error = linker_file_add_dependency(lf, lfdep); if (error) goto out; } *** sys/linker.h Sat Nov 7 10:52:53 1998 --- sys/linker.h.new Sat Nov 7 11:56:06 1998 *************** *** 72,78 **** linker_sym_t* sym, long* diffp); /* ! * Unload a file, releasing dependancies and freeing storage. */ void (*unload)(linker_file_t); }; --- 72,78 ---- linker_sym_t* sym, long* diffp); /* ! * Unload a file, releasing dependencies and freeing storage. */ void (*unload)(linker_file_t); }; *************** *** 91,98 **** int id; /* unique id */ caddr_t address; /* load address */ size_t size; /* size of file */ ! int ndeps; /* number of dependancies */ ! linker_file_t* deps; /* list of dependancies */ STAILQ_HEAD(, common_symbol) common; /* list of common symbols */ TAILQ_HEAD(, module) modules; /* modules in this file */ void* priv; /* implementation data */ --- 91,98 ---- int id; /* unique id */ caddr_t address; /* load address */ size_t size; /* size of file */ ! int ndeps; /* number of dependencies */ ! linker_file_t* deps; /* list of dependencies */ STAILQ_HEAD(, common_symbol) common; /* list of common symbols */ TAILQ_HEAD(, module) modules; /* modules in this file */ void* priv; /* implementation data */ *************** *** 170,181 **** int linker_file_unload(linker_file_t file); /* ! * Add a dependancy to a file. */ ! int linker_file_add_dependancy(linker_file_t file, linker_file_t dep); /* ! * Lookup a symbol in a file. If deps is TRUE, look in dependancies * if not found in file. */ caddr_t linker_file_lookup_symbol(linker_file_t file, const char* name, --- 170,181 ---- int linker_file_unload(linker_file_t file); /* ! * Add a dependency to a file. */ ! int linker_file_add_dependency(linker_file_t file, linker_file_t dep); /* ! * Lookup a symbol in a file. If deps is TRUE, look in dependencies * if not found in file. */ caddr_t linker_file_lookup_symbol(linker_file_t file, const char* name, >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 10:00:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21748 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 10:00:46 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21585; Sat, 7 Nov 1998 10:00:20 -0800 (PST) (envelope-from fenner@FreeBSD.org) From: Bill Fenner Received: (from fenner@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id KAA23278; Sat, 7 Nov 1998 10:00:07 -0800 (PST) Date: Sat, 7 Nov 1998 10:00:07 -0800 (PST) Message-Id: <199811071800.KAA23278@freefall.freebsd.org> To: avr@juniper.net, fenner@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: misc/8494 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: sbcheck is broken State-Changed-From-To: open-closed State-Changed-By: fenner State-Changed-When: Sat Nov 7 09:59:46 PST 1998 State-Changed-Why: Fixed in rev 1.40 of uipc_socket2.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 10:20:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23228 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 10:20:01 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA23197 for ; Sat, 7 Nov 1998 10:20:00 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id KAA23887; Sat, 7 Nov 1998 10:20:02 -0800 (PST) Received: (from nobody@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23186; Sat, 7 Nov 1998 10:19:54 -0800 (PST) (envelope-from nobody) Message-Id: <199811071819.KAA23186@hub.freebsd.org> Date: Sat, 7 Nov 1998 10:19:54 -0800 (PST) From: gme@caffeine.sundial.net To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: kern/8590: kernel incorrectly recognizing Maxtor 11.5gb IDE hd Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8590 >Category: kern >Synopsis: kernel incorrectly recognizing Maxtor 11.5gb IDE hd >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 10:20:01 PST 1998 >Last-Modified: >Originator: George Ellenburg >Organization: >Release: 2.2.7-RELEASE >Environment: >Description: /stand/sysintall and fdisk incorrectly detect Maxtor 11.5Gb IDE Hard Drive as only being able to support 8Gb (8063Mb) >How-To-Repeat: Install an 11.5gb Hard Drive in a system. ;-) >Fix: mailing lists archives elude to an 8gb limit in the IDE code for the kernel. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 14:29:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17163 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 14:29:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA17155 for ; Sat, 7 Nov 1998 14:29:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id OAA01351; Sat, 7 Nov 1998 14:30:00 -0800 (PST) Received: from shit.etext.org (shit.etext.org [207.24.215.147]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16493 for ; Sat, 7 Nov 1998 14:19:56 -0800 (PST) (envelope-from pauls@shit.etext.org) Received: (from pauls@localhost) by shit.etext.org (8.9.1/8.9.1) id RAA00620; Sat, 7 Nov 1998 17:19:41 -0500 (EST) (envelope-from pauls) Message-Id: <199811072219.RAA00620@shit.etext.org> Date: Sat, 7 Nov 1998 17:19:41 -0500 (EST) From: pauls@etext.org Reply-To: pauls@etext.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/8593: 'uptime' behavior varies by arg zero Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8593 >Category: bin >Synopsis: 'uptime' behavior varies by arg zero >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 14:30:00 PST 1998 >Last-Modified: >Originator: Paul Southworth >Organization: >Release: FreeBSD 3.0-RELEASE i386 >Environment: Problem occurs when using either /bin/csh or /bin/sh FreeBSD 2.2.7-RELEASE does not have this problem. >Description: If 'uptime' is invoked as 'uptime', it works properly. If 'uptime' is invoked as '/usr/bin/uptime', it behaves as 'w'. >How-To-Repeat: $ uptime 5:01PM up 29 mins, 3 users, load averages: 0.00, 0.00, 0.00 $ /usr/bin/uptime 5:01PM up 29 mins, 3 users, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT pauls p1 :0.0 4:33PM 36 -sh (csh) pauls p2 :0.0 4:33PM - /usr/bin/uptime pauls p3 :0.0 4:33PM 2days -sh (csh) $ ident /usr/bin/uptime /usr/bin/uptime: $Id: fmt.c,v 1.12 1998/06/17 11:33:10 jkoshy Exp $ $Id: pr_time.c,v 1.11 1997/12/28 17:50:10 alex Exp $ $Id: w.c,v 1.28 1998/06/09 04:35:20 imp Exp $ There is only one 'uptime' executable on the system, and 'uptime' is '/usr/bin/uptime' in my $PATH. System is 100% vanilla 3.0-RELEASE. >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 16:14:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28216 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 16:14:42 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from www.communique.no (www.communique.no [193.212.204.33]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA28210 for ; Sat, 7 Nov 1998 16:14:40 -0800 (PST) (envelope-from are@communique.no) Received: (qmail 13054 invoked by uid 1001); 8 Nov 1998 00:15:40 -0000 Date: Sun, 8 Nov 1998 01:15:40 +0100 (CET) From: Are Bryne X-Sender: are@rune.communique.no To: Joerg Wunsch cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3375 In-Reply-To: <199708241829.LAA00884@freefall.freebsd.org> Message-ID: Organization: Communique DA MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Sorry it took such a long time. The machine in question is placed in a remote, somewhat inaccesible location and seemed happy in staying up, so I didn't have a big opportunity of testing things in a jiffy. The symptoms are still there in an unpatched FreeBSD 2.2.7-STABLE #0: Thu Aug 27 22:07:28 CEST 1998 system. The patches helped though. Is this something that could be commited and turned on with a kernel option? Thank you very much for your help Best regards, Are Bryne On Sun, 24 Aug 1997, Joerg Wunsch wrote: > Synopsis: Consistent 10 min. delay at boot with REL-2.2.1 on Pentium > > State-Changed-From-To: open-feedback > State-Changed-By: joerg > State-Changed-When: Sun Aug 24 20:29:18 MEST 1997 > State-Changed-Why: > > Please tell us whether Bruce's suggestion did help you or not. > Communiqué DA Phone: +47 22 44 33 99 Parkveien 51b E-mail: admin@communique.no N-0256 Oslo URL: http://www.communique.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 16:30:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00494 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 16:30:04 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00417 for ; Sat, 7 Nov 1998 16:29:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id QAA05474; Sat, 7 Nov 1998 16:30:01 -0800 (PST) Received: from st-lcremean.tidalwave.net (st-lcremean.tidalwave.net [208.213.203.186]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29867 for ; Sat, 7 Nov 1998 16:26:02 -0800 (PST) (envelope-from root@st-lcremean.tidalwave.net) Received: (from root@localhost) by st-lcremean.tidalwave.net (8.9.1/8.8.8) id TAA00136; Sat, 7 Nov 1998 19:25:41 -0500 (EST) (envelope-from root) Message-Id: <199811080025.TAA00136@st-lcremean.tidalwave.net> Date: Sat, 7 Nov 1998 19:25:41 -0500 (EST) From: Lee Cremeans To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/8594: 3.0-RELEASE-981107 kernel refuses to see second IDE channel Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8594 >Category: i386 >Synopsis: ide_pci disables second channel in 3.0-CURRENT >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 16:30:01 PST 1998 >Last-Modified: >Originator: >Organization: THis room? Are you crazy? :) >Release: FreeBSD 3.0-CURRENT i386 >Environment: o FreeBSD 3.0-CURRENT CVSupped last night o Amptron PM-9600 motherboard, "TXTWO" (actually Acer Aladdin IV+) chipset o ide_pci.c in, with DMA enabled on my main drive, a Seagate ST39140A o Any EIDE or ATAPI device on the second ATA channel (wdc1) >Description: When I try to use any IDE device (regular or ATAPI) on my motherboard's second channel, FreeBSD tries to detect it, and fails. When I use the DISABLE_PCI_IDE option in my kernel config, devices on the second channel are detected correctly. This has been an issue with 3.0-CURRENT ever since I changed to this motherboard from a FIC PA-2007 (which has the VIA Apollo VP2 chipset, which is specfically supported in ide_pci.c). The problem on the second channel happens regardless of orientation of devices (ATAPI master, ATAPI slave no master, ATA master, ATAPI slave with ATA master). >How-To-Repeat: THe problem seems to be particular to this board, so I would try it on a board with a recent Acer chipset first. Just hook up something to the second channel, and watch it not work. >Fix: "options DISABLE_PCI_IDE" seems to work for now, but unfortunately, I need that for the main drive, so I have to keep it out. >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 20:30:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA25501 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 20:30:00 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA25493 for ; Sat, 7 Nov 1998 20:29:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id UAA11647; Sat, 7 Nov 1998 20:30:01 -0800 (PST) Received: from cassiopeia.caprica.com ([207.137.48.14]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA25041 for ; Sat, 7 Nov 1998 20:20:44 -0800 (PST) (envelope-from frank@exit.com) Received: from exit.com by cassiopeia.caprica.com (8.6.10/95022701) id SAA29832; Sat, 7 Nov 1998 18:46:25 -0800 Received: (from frank@localhost) by exit.com (8.8.8/8.7.3) id UAA00898; Sat, 7 Nov 1998 20:00:02 -0800 (PST) Message-Id: <199811080400.UAA00898@exit.com> Date: Sat, 7 Nov 1998 20:00:02 -0800 (PST) From: frank@exit.com Reply-To: frank@exit.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8596: panic: page fault in div_input(). Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8596 >Category: kern >Synopsis: panic: page fault while using ping's record-route option >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 20:30:01 PST 1998 >Last-Modified: >Originator: Frank Mayhar >Organization: N/A >Release: FreeBSD 2.2.7-STABLE i386 >Environment: Pentium 133, 64MB memory, user PPP connection to provider. FreeBSD-stable with bits up to last week or so. dmesg output: Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.7-STABLE #0: Fri Oct 23 19:05:52 PDT 1998 frank@exit.com:/usr/src/sys/compile/TINKER CPU: Pentium/P54C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 63639552 (62148K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0:0 chip1 rev 2 on pci0:7:0 chip2 rev 2 on pci0:7:1 vga0 rev 0 on pci0:9:0 ahc0 rev 0 int a irq 11 on pci0:12:0 ahc0: aic7870 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "MAXTOR LXT-340S 6.74" type 0 fixed SCSI 1 sd0(ahc0:0:0): Direct-Access 324MB (665154 512 byte sectors) (ahc0:1:0): "TOSHIBA MK538FB 6061" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 1170MB (2396970 512 byte sectors) (ahc0:2:0): "QUANTUM FIREBALL1080S 1Q09" type 0 fixed SCSI 2 sd2(ahc0:2:0): Direct-Access 1042MB (2134305 512 byte sectors) ahc0: target 8 Tagged Queuing Device (ahc0:8:0): "IBM DORS-32160W !# WA3E" type 0 fixed SCSI 2 sd3(ahc0:8:0): Direct-Access 2063MB (4226725 512 byte sectors) ahc0: target 9 Tagged Queuing Device (ahc0:9:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2 sd4(ahc0:9:0): Direct-Access 2170MB (4445380 512 byte sectors) ahc0: target 10 Tagged Queuing Device (ahc0:10:0): "QUANTUM XP32275W LXY4" type 0 fixed SCSI 2 sd5(ahc0:10:0): Direct-Access 2170MB (4445380 512 byte sectors) Probing for devices on the ISA bus: vt0 at 0x60-0x6f irq 1 on motherboard vt0: unkown s3, 80 col, color, 4 scr, mf2-kbd, [R3.20-b24] ed0 at 0x320-0x33f irq 10 on isa ed0: address 00:40:05:11:b2:70, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A qcam0 not found at 0x278 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in npx0 on motherboard npx0: INT 16 interface Intel Pentium F00F detected, installing workaround ccd0-15: Concatenated disk drivers IP packet filtering initialized, divert enabled, logging disabled >Description: I was doing a "ping -R www.mbtrading.com" when my system crashed. I saved a dump of the crash. The backtrace is: IdlePTD 21a000 current pcb at 1ffc74 panic: page fault #0 0xf0114103 in boot () (kgdb) bt #0 0xf0114103 in boot () #1 0xf01143d2 in panic () #2 0xf01c54fa in trap_fatal () #3 0xf01c4fbc in trap_pfault () #4 0xf01c4c47 in trap () #5 0xf01526c9 in div_input () #6 0xf01572c9 in ip_output () #7 0xf0158950 in rip_output () #8 0xf0158f25 in rip_usrreq () #9 0xf012b475 in old_send () #10 0xf01292ca in sosend () #11 0xf012bdc1 in sendit () #12 0xf012bea0 in sendto () #13 0xf01c5793 in syscall () #14 0x17895 in ?? () #15 0x1f6c in ?? () #16 0x107e in ?? () I'll keep the dump for a while; let me know if you need more information. >How-To-Repeat: I don't know if this is repeatable. >Fix: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 21:00:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA28652 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 21:00:03 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA28627 for ; Sat, 7 Nov 1998 21:00:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id VAA12370; Sat, 7 Nov 1998 21:00:03 -0800 (PST) Received: from mail.camalott.com (mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27641 for ; Sat, 7 Nov 1998 20:54:44 -0800 (PST) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (165.camalott.com [208.203.140.165]) by mail.camalott.com (8.8.7/8.8.7) with ESMTP id WAA04981 for ; Sat, 7 Nov 1998 22:54:57 -0600 Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id WAA29336; Sat, 7 Nov 1998 22:54:29 -0600 (CST) (envelope-from joelh) Message-Id: <199811080454.WAA29336@detlev.UUCP> Date: Sat, 7 Nov 1998 22:54:29 -0600 (CST) From: Joel Ray Holveck Reply-To: joelh@gnu.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/8597: fdisk uses obsolete "sd0" instead of "da0" [patch] Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8597 >Category: i386 >Synopsis: fdisk uses obsolete "sd0" instead of "da0" [patch] >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 21:00:02 PST 1998 >Last-Modified: >Originator: Joel Ray Holveck >Organization: None >Release: FreeBSD 3.0-BETA i386 >Environment: Any CAMified -current i386 system >Description: Unless a disk is specified on the command line, fdisk tries to access wd0, then sd0, then od0. sd0 is an obsolete name and may confuse users. Additionally, on a newly created -current system, it appears that the sd0 device does not exist. (This has only been done by examining MAKEDEV, not experimentally.) Unless there is a reason to keep this default, I propose it be changed to da0. >How-To-Repeat: On a system with no wd0, run fdisk with no parameters. The message ******* Working on device /dev/rsd0 ******* will be emitted. >Fix: ----- cut here ----- *** fdisk.c.orig Sat Nov 7 22:44:35 1998 --- fdisk.c Sat Nov 7 22:45:31 1998 *************** *** 68,72 **** const char *disks[] = { ! "/dev/rwd0", "/dev/rsd0", "/dev/rod0", 0 }; --- 68,72 ---- const char *disks[] = { ! "/dev/rwd0", "/dev/rda0", "/dev/rod0", 0 }; ----- cut here ----- >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 21:39:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA01200 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 21:39:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA01193 for ; Sat, 7 Nov 1998 21:39:59 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id VAA13471; Sat, 7 Nov 1998 21:40:01 -0800 (PST) Received: from detlev.UUCP (tex-48.camalott.com [208.229.74.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA00931 for ; Sat, 7 Nov 1998 21:36:57 -0800 (PST) (envelope-from joelh@gnu.org) Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id XAA08236; Sat, 7 Nov 1998 23:36:43 -0600 (CST) (envelope-from joelh) Message-Id: <86lnlmrbiv.fsf@detlev.UUCP> Date: Sat, 7 Nov 1998 23:25:51 -0600 (CST) From: Joel Ray Holveck Reply-To: joelh@gnu.org To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/8598: MAKEDEV fails if not run from current directory [patch] Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8598 >Category: i386 >Synopsis: MAKEDEV fails if not run from current directory [patch] >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 21:40:00 PST 1998 >Last-Modified: >Originator: Joel Ray Holveck >Organization: none >Release: FreeBSD 3.0-BETA i386 >Environment: i386 -current >Description: MAKEDEV frequently will call itself recursively using 'sh MAKEDEV'. This causes the script to fail if it is called from a different directory than where it resides. If, for instance, a dev directory from a disk not meant to hold MAKEDEV is created, and MAKEDEV is called from that directory, it will fail. As another data point, on -current, in message ID (Terry, hush unless you know of a better way to uniquely search for a message) , -current user Leif Neland had attempted to run MAKEDEV from the src directory while in /dev (the two were not in sync), and was perplexed by the error messages when the current MAKEDEV called the old MAKEDEV to generate devices that were not present in the old MAKEDEV. >How-To-Repeat: detlev# mount /dev/fd0 /mnt detlev# mkdir /mnt/dev detlev# cd /mnt/dev detlev# /dev/MAKEDEV all MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV MAKEDEV: Can't open MAKEDEV detlev# See also the aforereferenced article. >Fix: I propose to change all instances of "sh MAKEDEV" to "sh $0". Simple tests indicate correct functionality. The call "MAKEDEV local" causes me concern. I settled for calling /dev/MAKEDEV.local no matter what directory MAKEDEV was called from. ----- cut here ----- *** MAKEDEV.orig Sat Nov 7 22:44:40 1998 --- MAKEDEV Sat Nov 7 23:24:12 1998 *************** *** 188,210 **** all) ! sh MAKEDEV std # standard ! sh MAKEDEV fd0 fd1 # bdev, floppy disk ! sh MAKEDEV da0 da1 da2 da3 wd0 wd1 wd2 wd3 # bdev, ordinary disk ! sh MAKEDEV od0 # bdev, optical disk ! sh MAKEDEV wfd0 # bdev, LS-120 floppy ! sh MAKEDEV vn0 # bdev, virtual disk ! sh MAKEDEV cd0 matcd0 mcd0 scd0 wcd0 # bdev, cdrom ! sh MAKEDEV ft0 sa0 wt0 wst0 # bdev, tape ! sh MAKEDEV vty4 # cdev, virtual tty ! sh MAKEDEV cuaa0 cuaa1 cuaa2 cuaa3 # cdev, serial tty ! sh MAKEDEV pty0 # cdev, pseudo tty ! sh MAKEDEV ttyd0 ttyd1 ttyd2 ttyd3 # cdev, serial tty ! sh MAKEDEV mse0 psm0 sysmouse # cdev, mouse ! sh MAKEDEV pcaudio speaker # cdev, noise ! sh MAKEDEV lpt0 lpt1 lpt2 # cdev, printer ! sh MAKEDEV bpf0 ipl tun0 # cdev, network ! sh MAKEDEV ch0 perfmon tw0 # cdev, miscellaneous ! sh MAKEDEV apm card0 card1 # cdev, laptop ! sh MAKEDEV pass4 xpt2 # cdev, CAM ;; std) --- 188,210 ---- all) ! sh $0 std # standard ! sh $0 fd0 fd1 # bdev, floppy disk ! sh $0 da0 da1 da2 da3 wd0 wd1 wd2 wd3 # bdev, ordinary disk ! sh $0 od0 # bdev, optical disk ! sh $0 wfd0 # bdev, LS-120 floppy ! sh $0 vn0 # bdev, virtual disk ! sh $0 cd0 matcd0 mcd0 scd0 wcd0 # bdev, cdrom ! sh $0 ft0 sa0 wt0 wst0 # bdev, tape ! sh $0 vty4 # cdev, virtual tty ! sh $0 cuaa0 cuaa1 cuaa2 cuaa3 # cdev, serial tty ! sh $0 pty0 # cdev, pseudo tty ! sh $0 ttyd0 ttyd1 ttyd2 ttyd3 # cdev, serial tty ! sh $0 mse0 psm0 sysmouse # cdev, mouse ! sh $0 pcaudio speaker # cdev, noise ! sh $0 lpt0 lpt1 lpt2 # cdev, printer ! sh $0 bpf0 ipl tun0 # cdev, network ! sh $0 ch0 perfmon tw0 # cdev, miscellaneous ! sh $0 apm card0 card1 # cdev, laptop ! sh $0 pass4 xpt2 # cdev, CAM ;; std) *************** *** 460,464 **** for slicepartname in s0h s1 s2 s3 s4 do ! sh MAKEDEV $name$unit$slicepartname done ;; --- 460,464 ---- for slicepartname in s0h s1 s2 s3 s4 do ! sh $0 $name$unit$slicepartname done ;; *************** *** 1031,1035 **** name=`expr $i : 'mouse\(.*\)'` if [ ! -c $name ]; then ! $0 $name # make the appropriate device fi ln -fs $name mouse --- 1031,1035 ---- name=`expr $i : 'mouse\(.*\)'` if [ ! -c $name ]; then ! sh $0 $name # make the appropriate device fi ln -fs $name mouse *************** *** 1244,1248 **** local) umask 0 # XXX should be elsewhere ! sh MAKEDEV.local umask 77 ;; --- 1244,1248 ---- local) umask 0 # XXX should be elsewhere ! sh /dev/MAKEDEV.local umask 77 ;; ----- cut here ----- >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 22:09:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA05688 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 22:09:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA05681 for ; Sat, 7 Nov 1998 22:09:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id WAA14235; Sat, 7 Nov 1998 22:10:00 -0800 (PST) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA05030 for ; Sat, 7 Nov 1998 22:03:42 -0800 (PST) (envelope-from marcs@alive.znep.com) Received: (from marcs@localhost) by alive.znep.com (8.9.1/8.9.1) id VAA04518; Sat, 7 Nov 1998 21:59:35 -0800 (PST) (envelope-from marcs) Message-Id: <199811080559.VAA04518@alive.znep.com> Date: Sat, 7 Nov 1998 21:59:35 -0800 (PST) From: marcs@znep.com Reply-To: marcs@znep.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/8599: poll(2) sets POLLNVAL for negative descriptors Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 8599 >Category: kern >Synopsis: poll(2) sets POLLNVAL for negative descriptors >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Nov 7 22:10:00 PST 1998 >Last-Modified: >Originator: Marc Slemko >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD alive.znep.com 3.0-CURRENT FreeBSD 3.0-CURRENT #8: Sat Nov 7 21:26:59 PST 1998 marcs@alive.znep.com:/usr/src/sys/compile/ALIVE i386 3.0-current as of a few days ago. >Description: poll(2) sets POLLNVAL for descriptors passed in that are less than 0. This makes it difficult to do efficient manipulation of the struct pollfd since you can't leave a slot empty. >How-To-Repeat: Set fds[n].fd = -1 and do a poll on it. It treats it as an POLLNVAL when it should ignore it. >Fix: I have no idea why fds->fd was being cast to a u_int. Index: sys_generic.c =================================================================== RCS file: /home/ncvs/src/sys/kern/sys_generic.c,v retrieving revision 1.41 diff -u -r1.41 sys_generic.c --- sys_generic.c 1998/09/05 14:30:11 1.41 +++ sys_generic.c 1998/11/08 05:26:43 @@ -793,9 +793,11 @@ int n = 0; for (i = 0; i < nfd; i++, fds++) { - if ((u_int)fds->fd >= fdp->fd_nfiles) { + if (fds->fd >= fdp->fd_nfiles) { fds->revents = POLLNVAL; n++; + } else if (fds->fd < 0) { + fds->revents = 0; } else { fp = fdp->fd_ofiles[fds->fd]; if (fp == 0) { >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 22:59:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09027 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 22:59:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09019 for ; Sat, 7 Nov 1998 22:59:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA15592; Sat, 7 Nov 1998 23:00:00 -0800 (PST) Date: Sat, 7 Nov 1998 23:00:00 -0800 (PST) Message-Id: <199811080700.XAA15592@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bruce Evans Subject: Re: i386/8597: fdisk uses obsolete "sd0" instead of "da0" [patch] Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/8597; it has been noted by GNATS. From: Bruce Evans To: detlev!joelh@mail.camalott.com, FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: i386/8597: fdisk uses obsolete "sd0" instead of "da0" [patch] Date: Sun, 8 Nov 1998 17:51:15 +1100 >Unless a disk is specified on the command line, fdisk tries to access >wd0, then sd0, then od0. sd0 is an obsolete name and may confuse fdisk should abort if the disk is not specified on the command line. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 22:59:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09034 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 22:59:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09022 for ; Sat, 7 Nov 1998 22:59:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA15597; Sat, 7 Nov 1998 23:00:00 -0800 (PST) Date: Sat, 7 Nov 1998 23:00:00 -0800 (PST) Message-Id: <199811080700.XAA15597@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bruce Evans Subject: Re: i386/8598: MAKEDEV fails if not run from current directory [patch] Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/8598; it has been noted by GNATS. From: Bruce Evans To: detlev!joelh@FreeBSD.ORG, FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: i386/8598: MAKEDEV fails if not run from current directory [patch] Date: Sun, 8 Nov 1998 17:58:01 +1100 >MAKEDEV frequently will call itself recursively using 'sh MAKEDEV'. >This causes the script to fail if it is called from a different >directory than where it resides. If, for instance, a dev directory This is mostly a feature. >The call "MAKEDEV local" causes me concern. I settled for calling >/dev/MAKEDEV.local no matter what directory MAKEDEV was called from. This breaks running of modified MAKEDEV[.local]'s in directories other than /dev. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message From owner-freebsd-bugs Sat Nov 7 23:29:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10853 for freebsd-bugs-outgoing; Sat, 7 Nov 1998 23:29:59 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10848 for ; Sat, 7 Nov 1998 23:29:58 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA16290; Sat, 7 Nov 1998 23:30:01 -0800 (PST) Date: Sat, 7 Nov 1998 23:30:01 -0800 (PST) Message-Id: <199811080730.XAA16290@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bruce Evans Subject: Re: kern/8561: kernel inode change Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/8561; it has been noted by GNATS. From: Bruce Evans To: cys@wlc.com, FreeBSD-gnats-submit@FreeBSD.ORG Cc: Subject: Re: kern/8561: kernel inode change Date: Sun, 8 Nov 1998 18:27:21 +1100 >>Description: > > Whenever this system (-stable from Oct 26) reboots, /kernel > inode change time is altered to the time of reboot. dset always fiddles with the file flags. Fixes: - don't run dset on every boot. - change dset to not fiddle with the file flags. This also fixes its non-restoral of the file flags after an error. - don't install kernels with schg set if you want dset to unsecure them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message