From owner-freebsd-current Sun Aug 20 08:35:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA04168 for current-outgoing; Sun, 20 Aug 1995 08:35:23 -0700 Received: from palmer.demon.co.uk (palmer.demon.co.uk [158.152.50.150]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id IAA04162 ; Sun, 20 Aug 1995 08:35:10 -0700 Received: from localhost (localhost [127.0.0.1]) by palmer.demon.co.uk (8.6.11/8.6.11) with SMTP id QAA01409 ; Sun, 20 Aug 1995 16:34:59 +0100 X-Message: This is a dial-up site. Quick responses to e-mails should not be relied upon. Thanks! To: current@FreeBSD.ORG CC: jkh@time.cdrom.com, jmb@FreeBSD.ORG Subject: FreeBSD-bugs mailing list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1406.808932897.1@palmer.demon.co.uk> Date: Sun, 20 Aug 1995 16:34:58 +0100 Message-ID: <1407.808932898@palmer.demon.co.uk> From: Gary Palmer Sender: current-owner@FreeBSD.ORG Precedence: bulk Hi there. It seems like the freebsd-bugs list was truncated at the same time as the cvs-all list, and now there are only 13 people on the bugs list. We have now taken steps to try and prevent this happening again in the future. Sorry about any inconvenience caused. Yours Gary From owner-freebsd-current Sun Aug 20 16:34:28 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA27879 for current-outgoing; Sun, 20 Aug 1995 16:34:28 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id QAA27873 for ; Sun, 20 Aug 1995 16:34:26 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <19021-0@bunyip.cc.uq.oz.au>; Mon, 21 Aug 1995 09:34:05 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id JAA03147; Mon, 21 Aug 1995 09:38:46 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id XAA02690; Sun, 20 Aug 1995 23:36:53 GMT Message-Id: <199508202336.XAA02690@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6 4/21/95 To: multimedia@star-gate.com, current@freebsd.org Subject: Last Official patches (not Amancio's) & my SB16 still doesn't work Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Aug 1995 09:36:52 +1000 From: Stephen Hocking Sender: current-owner@freebsd.org Precedence: bulk With the last set of official patches, my SB16 "Value" edition still does not work. Using the /sys/i386/isa/sound & soundcard.h stuff from the 2.0.5 CD, it works fine. I've tried the stuff tarred up at Amancio's site but it doesn't work either. I'm almost at the stage where I'd like to get hold of the last CTM tarball & patch up from that, on the offchance that something I've done has screwed the DMA stuff up. Stephen I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Sun Aug 20 16:41:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA28052 for current-outgoing; Sun, 20 Aug 1995 16:41:59 -0700 Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA28044 for ; Sun, 20 Aug 1995 16:41:57 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.11/8.6.9) with ESMTP id QAA10996; Sun, 20 Aug 1995 16:40:30 -0700 Message-Id: <199508202340.QAA10996@rah.star-gate.com> X-Mailer: exmh version 1.6.2 7/18/95 To: Stephen Hocking cc: multimedia@star-gate.com, current@freebsd.org Subject: Re: Last Official patches (not Amancio's) & my SB16 still doesn't work In-reply-to: Your message of "Mon, 21 Aug 1995 09:36:52 +1000." <199508202336.XAA02690@netfl15a.devetir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Aug 1995 16:40:29 -0700 From: "Amancio Hasty Jr." Sender: current-owner@freebsd.org Precedence: bulk >>> Stephen Hocking said: > With the last set of official patches, my SB16 "Value" edition still does no t > work. Using the /sys/i386/isa/sound & soundcard.h stuff from the 2.0.5 CD, i t > works fine. I've tried the stuff tarred up at Amancio's site but it doesn't > work either. I'm almost at the stage where I'd like to get hold of the last > CTM tarball & patch up from that, on the offchance that something I've done > has screwed the DMA stuff up. > Anyone else having problems with the SB16? Amancio From owner-freebsd-current Sun Aug 20 16:46:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA28237 for current-outgoing; Sun, 20 Aug 1995 16:46:06 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA28231 for ; Sun, 20 Aug 1995 16:46:04 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id AAA25587; Mon, 21 Aug 1995 00:44:09 +0100 From: Paul Richards Message-Id: <199508202344.AAA25587@server.netcraft.co.uk> Subject: ATAPI To: vak@cronyx.ru, FreeBSD-current@FreeBSD.org (FreeBSD current mailing list) Date: Mon, 21 Aug 1995 00:44:09 +0100 (BST) Reply-to: paul@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 715 Sender: current-owner@FreeBSD.org Precedence: bulk My IDE cdrom seems to think it's a hard disk. wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, dma, iordis wdc1: ATAPI hard disks not supported It's not working anyway. It's an NEC CDR-260, claims to be ATAPI rev 1.7B compatible. -- Paul Richards, Bluebird Computer Systems. FreeBSD core team member. Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul Phone: 0370 462071 (Mobile), +44 1222 457651 (home) From owner-freebsd-current Sun Aug 20 19:22:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA03844 for current-outgoing; Sun, 20 Aug 1995 19:22:22 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id TAA03821 ; Sun, 20 Aug 1995 19:22:10 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA24224; Sun, 20 Aug 95 20:23:50 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508210223.AA24224@cs.weber.edu> Subject: KERNEL PATCHES FOR NFS LOCKING SUPPORT To: current@freebsd.org, hackers@freebsd.org, andrew.gordon@net-tel.co.uk Date: Sun, 20 Aug 95 20:23:48 MDT X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk I have uploaded the kernel pieces necessary for NFS locking support to: freefall.cdrom.com:~terry/RLOCK.tar.gz. This does NOT include the user space daemons, which I've left to Andrew, who claims to have bogus rpc.lockd and rpc.statd code (yeah, Andrew!). This is basically proxy remote lock support identical to that in SunOS implemented via the fcntl() interface. One NFS specific function is missing and depends on the NFS and Andrew as to how it needs to be implemented (it's a trivial function, but the NFS plug-in architecture will affect it). It has to be done right to allow you to still option NFS out of a kernel. The README from the tar file follows. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. ============================================================================== This set of patches is most of the kernel support required for NFS locking support. The only missing piece is the fcntl(2) command F_CNVT, which is used by a lock daemon to convert an NFS file handle into an open fd in the lock daemon, which is then used to assert the locks. This probably wants to be implemented as explicit support in the NFS server code itself and accessed via VOP_IOCTL() or some similar means. The actual cookie format and implementation of the reverse lookup are, of course, specific to the NFS code, which is currently under very active developement, or I'dimplement it myself. This does NOT implement the user space daemons required to support incoming requests -- there is work under way to support this already by Andrew Gordon per a posting in the news groups (last Saturday, 19 Aug 95). The changes for this support are rather trivial. Terry Lambert terry@cs.weber.edu ============================================================================== From owner-freebsd-current Sun Aug 20 21:22:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id VAA12733 for current-outgoing; Sun, 20 Aug 1995 21:22:21 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id VAA12718 for ; Sun, 20 Aug 1995 21:22:12 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA14290; Mon, 21 Aug 1995 06:21:57 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA19059; Mon, 21 Aug 1995 06:21:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id EAA03396; Mon, 21 Aug 1995 04:35:01 +0200 From: J Wunsch Message-Id: <199508210235.EAA03396@uriah.heep.sax.de> Subject: Re: ATAPI To: FreeBSD-current@FreeBSD.org Date: Mon, 21 Aug 1995 04:35:00 +0200 (MET DST) Cc: vak@cronyx.ru Reply-To: FreeBSD-current@FreeBSD.org In-Reply-To: <199508202344.AAA25587@server.netcraft.co.uk> from "Paul Richards" at Aug 21, 95 00:44:09 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 749 Sender: current-owner@FreeBSD.org Precedence: bulk As Paul Richards wrote: > > My IDE cdrom seems to think it's a hard disk. > > wdc1: unit 0 (atapi): , removable, dma, iordis > wdc1: ATAPI hard disks not supported > > It's not working anyway. It's an NEC CDR-260, claims to be ATAPI rev 1.7B > compatible. I'd say everything it's emitting is byte-swapped: (This has been a simple sequence of C-t and C-f commands in Emacs.) Well, and if it's also byte-swapping its ID, who'd be surprised that the driver thinks it's a hard disk? :-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Aug 20 22:57:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA26136 for current-outgoing; Sun, 20 Aug 1995 22:57:32 -0700 Received: from balboa.eng.uci.edu (balboa.eng.uci.edu [128.200.61.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id WAA26124 for ; Sun, 20 Aug 1995 22:57:28 -0700 Received: from localhost.uci.edu by balboa.eng.uci.edu with SMTP id AA02106 (5.65c/IDA-1.4.4 for current@freebsd.org); Sun, 20 Aug 1995 22:57:26 -0700 Message-Id: <199508210557.AA02106@balboa.eng.uci.edu> To: current@freebsd.org Subject: IDE CDROM Date: Sun, 20 Aug 1995 22:57:25 -0700 From: Steven Wallace Sender: current-owner@freebsd.org Precedence: bulk My ATAPI IDE CDROM is not being recognized. My config has: options ATAPI #Enable ATAPI support for IDE bus controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 device wcd0 #IDE CD-ROM And during probe all I get is wdc0 at 0x1f0-0x1f7 irq 14 on isa and that is IT. It just sits there for 10 seconds. I ONLY have an IDE CDROM drive and that is it. No other IDE drives. So the IDE CDROM is configured to be the master. Maybe that is the reason? Steven From owner-freebsd-current Sun Aug 20 23:16:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA28637 for current-outgoing; Sun, 20 Aug 1995 23:16:16 -0700 Received: (from sos@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA28627 ; Sun, 20 Aug 1995 23:16:14 -0700 Message-Id: <199508210616.XAA28627@freefall.FreeBSD.org> Subject: Re: IDE CDROM To: swallace@eng.uci.edu (Steven Wallace) Date: Sun, 20 Aug 1995 23:16:13 -0700 (PDT) Cc: current@freebsd.org In-Reply-To: <199508210557.AA02106@balboa.eng.uci.edu> from "Steven Wallace" at Aug 20, 95 10:57:25 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1021 Sender: current-owner@freebsd.org Precedence: bulk In reply to Steven Wallace who wrote: > My ATAPI IDE CDROM is not being recognized. > > My config has: > > options ATAPI #Enable ATAPI support for IDE bus > controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr > disk wd0 at wdc0 drive 0 > disk wd1 at wdc0 drive 1 > device wcd0 #IDE CD-ROM > > And during probe all I get is > wdc0 at 0x1f0-0x1f7 irq 14 on isa > and that is IT. It just sits there for 10 seconds. > > I ONLY have an IDE CDROM drive and that is it. No other IDE drives. > So the IDE CDROM is configured to be the master. Maybe that is the reason? Ahh, thats the clue, the driver currently does not support "loose" cdrom's, there has to be a disk there also. I'm looking into this in the next couble of days.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org | sos@login.dknet.dk) FreeBSD Core Team So much code to hack -- so little time From owner-freebsd-current Mon Aug 21 00:18:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id AAA02726 for current-outgoing; Mon, 21 Aug 1995 00:18:14 -0700 Received: from critter.tfs.com (critter.tfs.com [140.145.16.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id AAA02717 ; Mon, 21 Aug 1995 00:18:09 -0700 Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id WAA04018; Fri, 18 Aug 1995 22:09:52 -0700 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: paul@FreeBSD.org cc: vak@cronyx.ru, FreeBSD-current@FreeBSD.org (FreeBSD current mailing list) Subject: Re: ATAPI In-reply-to: Your message of "Mon, 21 Aug 1995 00:44:09 BST." <199508202344.AAA25587@server.netcraft.co.uk> Date: Fri, 18 Aug 1995 22:09:49 -0700 Message-ID: <4016.808808989@critter.tfs.com> From: Poul-Henning Kamp Sender: current-owner@FreeBSD.org Precedence: bulk > My IDE cdrom seems to think it's a hard disk. > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S > wdc0: unit 1 (wd1): > wd1: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S > wdc1 at 0x170-0x177 irq 15 on isa > wdc1: unit 0 (atapi): , removable, dma, Looks like there is at least a byte-swap issue... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Just that: dried leaves in boiling water ? From owner-freebsd-current Mon Aug 21 03:14:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id DAA08816 for current-outgoing; Mon, 21 Aug 1995 03:14:41 -0700 Received: from server.netcraft.co.uk (server.netcraft.co.uk [194.72.238.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id DAA08807 ; Mon, 21 Aug 1995 03:14:36 -0700 Received: (from paul@localhost) by server.netcraft.co.uk (8.6.11/8.6.9) id LAA28054; Mon, 21 Aug 1995 11:13:39 +0100 From: Paul Richards Message-Id: <199508211013.LAA28054@server.netcraft.co.uk> Subject: Re: ATAPI To: sos@freebsd.org Date: Mon, 21 Aug 1995 11:13:39 +0100 (BST) Cc: paul@freebsd.org, vak@cronyx.ru, FreeBSD-current@freebsd.org In-Reply-To: <199508210531.WAA21303@freefall.FreeBSD.org> from "sos@freebsd.org" at Aug 20, 95 10:31:41 pm Reply-to: paul@freebsd.org X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1591 Sender: current-owner@freebsd.org Precedence: bulk In reply to sos@freebsd.org who said > > In reply to Paul Richards who wrote: > > > > My IDE cdrom seems to think it's a hard disk. > > > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > wdc0: unit 0 (wd0): > > wd0: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S > > wdc0: unit 1 (wd1): > > wd1: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S > > wdc1 at 0x170-0x177 irq 15 on isa > > wdc1: unit 0 (atapi): , removable, dma, iordis > > wdc1: ATAPI hard disks not supported > > > > It's not working anyway. It's an NEC CDR-260, claims to be ATAPI rev 1.7B > > compatible. > > Oh well, you have one of the drives that doesn't byteswap its name :) > It probably has other "non-std" things as well, making the driver > fail to see it as a CDROM. This was one of the probelms that effectively > delayed my ata driver, there seems to be no clear way to deal with this > except searching through a table with known stange devices.... :-( Hmm, we're going to have to deal with this in some way. Releasing an IDE cdrom driver to all the masses waiting for one only for them to find it doesn't work with their particular cdrom would be a major PR disaster. I'll try and find the problem with my drive this week. I think we'd better try and find a lot of IDE cdrom owners out there to thoroughly shake out this driver. -- Paul Richards, Bluebird Computer Systems. FreeBSD core team member. Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul Phone: 0370 462071 (Mobile), +44 1222 457651 (home) From owner-freebsd-current Mon Aug 21 03:24:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id DAA09303 for current-outgoing; Mon, 21 Aug 1995 03:24:12 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id DAA09294 for ; Mon, 21 Aug 1995 03:24:02 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA15573; Mon, 21 Aug 1995 12:23:50 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id MAA20947 for current@freebsd.org; Mon, 21 Aug 1995 12:23:50 +0200 Received: (from uucp@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) with UUCP id MAA04693 for current@freebsd.org; Mon, 21 Aug 1995 12:02:34 +0200 Received: by bonnie.tcd-dresden.de (8.6.8/8.6.6) id MAA26738; Mon, 21 Aug 1995 12:00:48 +0200 Date: Mon, 21 Aug 1995 12:00:48 +0200 From: j@bonnie.heep.sax.de (J Wunsch) Message-Id: <199508211000.MAA26738@bonnie.tcd-dresden.de> To: current@freebsd.org, fmayhar@locus.com Subject: Re: Show-stopper crashes on 2.1-STABLE and 2.1.0-072695-SNAP. Reply-To: joerg_wunsch@uriah.heep.sax.de Newsgroups: comp.unix.bsd.freebsd.misc In-Reply-To: <410bgk$3vij@janus.la.locus.com> Organization: Private U**x site, Dresden. Sender: current-owner@freebsd.org Precedence: bulk Since Frank has apparently email problems, and i'm not sure if this report appeared in the lists, is it a known problem? In article <410bgk$3vij@janus.la.locus.com> you write: >I sent this to hackers, but since my home uucp provider has decided to >not accept any email from freefall.cdrom.com, it's doing me little good. >At the risk of injecting some hard-core technical discussion, I'm posting >this here to see if I can finally get this problem resolved. > >The (slightly modified) message as sent to hackers follows: > >My less immediately critical problem is with the XFree86 3.1.1 server; I >run the S3 server against an ISA Actix Graphics Engine Ultra +, and after >a short time, it appears to hang. A ps (from an async terminal) shows it >racking up CPU; sometimes there are visual flashes or short-lived bits of >garbage on the screen shortly before it crashes. Is there a known hardware >incompatibility between the ASUS motherboard and the Actix card? Note >that I've ordered a Number Nine GXE64Pro, so this should shortly become >a non-issue, but I thought I would mention it anyway. > >Now the critical problem: > >I just upgraded my hardware to a P100/PCI motherboard (configuration is >below), and needed to upgrade to FreeBSD 2.0.5 or better since 1.1.5.1 >(which I had been running) doesn't support my new hardware. I've had >nothing but headaches. The real problem is that I can't run News; email >works okay, but INN pounds the system hard enough that it crashes almost >immediately (if I don't run News, it crashes eventually, but it takes a >lot longer -- although I've had it crash immediately after boot). > >My configuration: > >Pentium 100, ASUS P55TP4XE motherboard, pipeline burst SRAM, 32 MB 60ns >memory, Adaptec 2940W, Maxtor LXT340sy + 2 Toshiba MK538FBs (340 MB, and >two 1.2 GB), Archive Viper 2150S tape, Actix GraphicsEngine Ultra +. > >Crash: > >Running 2.1.0-072695-SNAP, and INN 1.4 compiled with MMAP. I get a >compressed uucp newsfeed; while unpacking news, the system quickly >crashes with: > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xf81ef050 >fault code = supervisor write, page not present >instruction pointer = 0x8:0x4018679c >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def 321, gran 1 >processor eflags = interrupt enabled, resume, IOPL=0 >current process = 11503 (gzip) >interrupt mask = net tty bio >panic: page fault > >I finally got a trace courtesy of DDB (not corresponding to the above >message, but the same fault code and under the same circumstances): > >_trap_fatal(efbffb4c,c,f0c10500,efbffb4c,f0b43e00) at _trap_fatal+0x277 >_trap_pfault(efbffb4c,0,f024fb10,f01cbd60,f26db6f8) at _trap_pfault+0x158 >_trap(10,10,f26eb6f8,f01cbd60,efbffb94) at _trap+0x27b >calltrap(f01cbd60,2bfe0000,0,f26db6f8,0) at calltrap+0x15 >_vm_hold_load_pages(f26eb6f8,f2bbc000,f2bbe000,f26db6f8) at _vm_hold_load_pages+0x4c >_allocbuf(f26eb6f8,2000,efbffc98,efbffd10,ffffffff) at _allocbuf+0x8a >_getblk(f0c7cd00,b,2000,0,0) at _getblk+0x23a >_bread(f0c7cd00,b,2000,ffffffff,efbffc98) at _bread+0x21 >_ffs_blkatoff(efbffd10,f0c7cd00,efbfff0c,efbffef8,f0bf2700) at _ffs_blkatoff+0xc3 >_ufs_lookup(efbffd74,0,efbfff0c,efbffee8,1) at _ufs_lookup+0x44a >_lookup(efbffee8,0,efbfff94,602,f0277f2c) at _lookup+0x256 >_namei(efbffee8,0,efbfff94,f0c10500,f0c10500) at _namei+0x122 >_vn_open(efbffee8,602,1b4,efbfff94,f0c10500) at _vn_open+0x5a >_open(f0c10500,efbfff94,efbfff8c,842006,0) at _open+0x97 >_syscall(27,27,287d4,0,efbfd2fc) at _syscall+0x161 > >That was with 2.1.0-072695-SNAP. This is with 2.1-STABLE: > >I tried INN built with MMAP. No joy, it looked like it crashed in a page >fault due to an mmap (nothing on the stack below the _trap_pfault()). I >rebuilt INN with READ instead of MMAP. It got further this time, but >finally crashed in _cache_lookup(): > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xfccb074c >fault code = supervisor write, page not present >instruction pointer = 0x8:0xf01265f5 >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 = 4580 (innd) >interrupt mask = >panic: from debugger > >Stack trace: >_cache_lookup(f0b90e00,efbffef8,efbfff0c,f0b90e00,efbfff0c) at _cache_lookup+0x195 >_ufs_lookup(efbffd74,0,efbfff0c,efbffee8,1) at _ufs_lookup+0xdb >_lookup(efbffee8,0,efbfff94,602,f02535c4) at _lookup+0x256 >_namei(efbffee8,0,efbfff94,f0cd6d00,f0cd6d00) at _namei+0x122 >_vn_open(efbffee8,602,1b4,efbfff94,f0cdbd00) at _vn_open+0x5a >_open(f0cd6d00,efbfff94,efbfff8c,878006,0) at _open+0x97 >_syscall(26,26,286d4,0,efbfd2f4) at 0x161 > >I've poked around in cache_lookup() and ufs_lookup() looking for any obvious >errors, but found nothing I could point to as the culprit; someone more >knowledgable of the code needs to take a look at it, and maybe give me some >advice as to what to look at. > >I can reproduce these pretty much at will (and they quite often happen all >by themselves, on an only slightly loaded system), so if there's anything >else that anyone needs me to look at, let me know. If it's already solved, >so much the better (but I doubt that it is). I'm available pretty much >any time for diagnostic work, so if someone wants to get on the phone with >me and work on this thing, send me email (at home at 'frank@exit.com' or >at work at 'fmayhar@locus.com', one will get forwarded to the other >automatically) and I'll give you my number. > >Thanks in advance for any help anyone can give me. I quite understand that >everyone is very busy (join the crowd), but this is being a great aggravation, >particularly since my only other choice is to leave my $2000 worth of nice >new hardware sitting idle while I go back to running 1.1.5.1 on a crufty old >486/33 box. > >Here's my config file, and a copy of the 'dmesg' output, just for grins: ># ># GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks ># ># $Id: GENERIC,v 1.46 1995/06/11 19:31:11 rgrimes Exp $ ># > >machine "i386" >cpu "I586_CPU" >ident TINKER >maxusers 64 > >#options MATH_EMULATE #Support for x87 emulation >options INET #InterNETworking >options FFS #Berkeley Fast Filesystem >options NFS #Network Filesystem >options MFS #Memory File System >options MSDOSFS #MSDOS Filesystem >#options "CD9660" #ISO 9660 Filesystem >options PROCFS #Process filesystem >options "COMPAT_43" #Compatible with BSD 4.3 >options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device >#options BOUNCE_BUFFERS #include support for DMA bounce buffers >options UCONSOLE #Allow users to grab the console >options "NSWAPDEV=4" >options SYSVSHM >options SYSVSEM >options SYSVMSG >options KTRACE #kernel tracing > >options DDB #kernel debugger > >config kernel root on sd0 > >controller isa0 >controller pci0 > >controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr >disk fd0 at fdc0 drive 0 >disk fd1 at fdc0 drive 1 >#tape ft0 at fdc0 drive 2 > >#controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr >#disk wd0 at wdc0 drive 0 >#disk wd1 at wdc0 drive 1 > >#controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr >#disk wd2 at wdc1 drive 0 >#disk wd3 at wdc1 drive 1 > >#controller ncr0 >#controller ahc0 >controller ahc0 at pci? bio irq ? vector ahcintr > >#controller bt0 at isa? port "IO_BT0" bio irq ? vector btintr >#controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr >#controller ahc1 at isa? bio irq ? vector ahcintr >#controller ahb0 at isa? bio irq ? vector ahbintr >#controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr >#controller aic0 at isa? port 0x340 bio irq 11 vector aicintr >#controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr >#controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr >#controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr > >controller scbus0 > >device sd0 > >device st0 > >device cd0 #Only need one of these, the code dynamically grows > >device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr >#device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr >#device mcd1 at isa? port 0x340 bio irq 11 vector mcdintr > >#controller matcd0 at isa? port ? bio > >#device scd0 at isa? port 0x230 bio > ># syscons is the default console driver, resembling an SCO console >device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr ># Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver >#device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint >#options "PCVT_FREEBSD=210" # pcvt running on FreeBSD 2.1 >options XSERVER # include code for XFree86 > >device npx0 at isa? port "IO_NPX" irq 13 vector npxintr > >device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr >device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr >device sio2 at isa? port 0x338 tty irq 12 vector siointr >#device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr >#device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr > >device lpt0 at isa? port? tty irq 7 vector lptintr >#device lpt1 at isa? port? tty >#device lpt2 at isa? port? tty > ># Order is important here due to intrusive probes, do *not* alphabetize ># this list of network interfaces until the probes have been fixed. ># Right now it appears that the ie0 must be probed before ep0. See ># revision 1.20 of this file. >#device de0 >#device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr >#device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr >#device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr >#device ep0 at isa? port 0x300 net irq 10 vector epintr >#device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr >#device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr >#device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr >#device lnc1 at isa? port 0x300 net irq 10 drq 0 vector lncintr >#device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr >#device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr > >controller snd0 >device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr >device pas0 at isa? port 0x388 irq 10 drq 6 vector pasintr >device opl0 at isa? port 0x388 > >pseudo-device loop >pseudo-device ether >pseudo-device log >#pseudo-device sl 1 ># ijppp uses tun instead of ppp device >#pseudo-device ppp 1 >pseudo-device tun 2 >pseudo-device pty 16 >pseudo-device gzip # Exec gzipped a.out's >pseudo-device bpfilter 4 #Berkeley packet filter > > >FreeBSD 2.1-STABLE #0: Wed Aug 16 08:34:38 1995 > root@exit.com:/usr/src/sys/compile/TINKER >CPU: 99-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) > Origin = "GenuineIntel" Id = 0x525 Stepping=5 > Features=0x1bf >real memory = 33161216 (8096 pages) >avail memory = 31178752 (7612 pages) >Probing for devices on the ISA bus: >sc0 at 0x60-0x6f irq 1 on motherboard >sc0: VGA color <16 virtual consoles, flags=0x0> >sio0 at 0x3f8-0x3ff irq 4 on isa >sio0: type 16550A >sio1 at 0x2f8-0x2ff irq 3 on isa >sio1: type 16550A >sio2 at 0x338-0x33f irq 12 on isa >sio2: type 16450 >lpt0 at 0x378-0x37f irq 7 on isa >lpt0: Interrupt-driven port >lp0: TCP/IP capable interface >fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa >fdc0: NEC 72065B >fd0: 1.44MB 3.5in >fd1: 1.2MB 5.25in >wt0 not found at 0x300 >npx0 on motherboard >npx0: INT 16 interface >sb0 at 0x220 irq 7 drq 1 on isa >sb0: >pas0 at 0x388 irq 10 drq 6 on isa >pas0: >opl0 not probed due to I/O address conflict with pas0 at 0x388 >Probing for devices on the pci0 bus: > configuration mode 1 allows 32 devices. >chip0 rev 2 on pci0:0 >chip1 rev 2 on pci0:7 >ahc0 rev 0 int a irq 11 on pci0:12 >ahc0: reading board settings >ahc0: Reading SEEPROM...done. >ahc0: 2940 Wide Channel, SCSI Id=7, aic7870, 16 SCBs >ahc0: Downloading Sequencer Program...Done >ahc0: Probing channel A >ahc0 waiting for scsi devices to settle >ahc0: target 0 synchronous at 4.4MB/s, offset = 0xf >(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: target 1 synchronous at 6.67MB/s, offset = 0xf >(ahc0:1:0): "TOSHIBA MK538FB 6061" type 0 fixed SCSI 2 >sd1(ahc0:1:0): Direct-Access 1170MB (2396970 512 byte sectors) >ahc0: target 2 synchronous at 6.67MB/s, offset = 0xf >(ahc0:2:0): "TOSHIBA MK538FB 6030" type 0 fixed SCSI 2 >sd2(ahc0:2:0): Direct-Access 1172MB (2400302 512 byte sectors) >pci0: uses 4096 bytes of memory from fbff7000 upto fbff7fff. >pci0: uses 256 bytes of I/O space from e400 upto e4ff. >bpf: lo0 attached >bpf: tun0 attached >bpf: tun1 attached >-- >Frank Mayhar frank@exit.com > -- cheers, J"org private: joerg_wunsch@uriah.heep.sax.de http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Aug 21 03:41:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id DAA10713 for current-outgoing; Mon, 21 Aug 1995 03:41:08 -0700 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id DAA10707 ; Mon, 21 Aug 1995 03:40:57 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id LAA12051; Mon, 21 Aug 1995 11:41:19 +0100 Date: Mon, 21 Aug 1995 11:41:19 +0100 (BST) From: Doug Rabson To: sos@freebsd.org cc: Steven Wallace , current@freebsd.org Subject: Re: IDE CDROM In-Reply-To: <199508210616.XAA28627@freefall.FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On Sun, 20 Aug 1995 sos@freebsd.org wrote: > In reply to Steven Wallace who wrote: > > My ATAPI IDE CDROM is not being recognized. > > > > My config has: > > > > options ATAPI #Enable ATAPI support for IDE bus > > controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr > > disk wd0 at wdc0 drive 0 > > disk wd1 at wdc0 drive 1 > > device wcd0 #IDE CD-ROM > > > > And during probe all I get is > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > and that is IT. It just sits there for 10 seconds. > > > > I ONLY have an IDE CDROM drive and that is it. No other IDE drives. > > So the IDE CDROM is configured to be the master. Maybe that is the reason? > > Ahh, thats the clue, the driver currently does not support > "loose" cdrom's, there has to be a disk there also. > I'm looking into this in the next couble of days.. Hmm. Why does my machine work perfectly with no IDE drives? I had to tweak the source slightly to build a kernel which linked without any wd disks configured but it works perfectly. For what its worth, this is currently running WCD-1.2, not the one which was just commited. Presumably they are identical but I haven't got around to building a new kernel yet. The drive is a Mitsumi FX004 (I think) and works perfectly. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939 From owner-freebsd-current Mon Aug 21 07:42:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id HAA22903 for current-outgoing; Mon, 21 Aug 1995 07:42:54 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id HAA22891 for ; Mon, 21 Aug 1995 07:42:48 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16620(6)>; Mon, 21 Aug 1995 07:41:55 PDT Received: by crevenia.parc.xerox.com id <177475>; Mon, 21 Aug 1995 07:41:48 -0700 From: Bill Fenner To: current@freebsd.org Subject: make world fails Message-Id: <95Aug21.074148pdt.177475@crevenia.parc.xerox.com> Date: Mon, 21 Aug 1995 07:41:40 PDT Sender: current-owner@freebsd.org Precedence: bulk My very first "make world" ever fell over; since the new version of bind was just imported I'm somewhat suspicious that it's actually not something dumb that I'm doing... ===> libresolv cc -O -DDEBUG -DLIBC_SCCS -c /usr/src/lib/libresolv/../libc/net/gethostnamadr.c -o gethostnamadr.o cc -O -DDEBUG -DLIBC_SCCS -c /usr/src/lib/libresolv/../libc/net/res_mkquery.c -o res_mkquery.o /usr/src/lib/libresolv/../libc/net/res_mkquery.c:68: res_config.h: No such file or directory *** Error code 1 There is indeed a res_config.h in ../libc/net/, but no include path for it... Bill From owner-freebsd-current Mon Aug 21 10:12:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA00502 for current-outgoing; Mon, 21 Aug 1995 10:12:09 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id KAA00493 for ; Mon, 21 Aug 1995 10:12:05 -0700 Received: (from news@localhost) by haywire.DIALix.COM (8.7.Beta.11/8.7.Beta.11/DIALix) id BAA10842 for freebsd-current@freebsd.org; Tue, 22 Aug 1995 01:11:59 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 22 Aug 1995 01:11:55 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <41aeor$ain$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <95Aug21.074148pdt.177475@crevenia.parc.xerox.com> Subject: Re: make world fails Sender: current-owner@freebsd.org Precedence: bulk fenner@parc.xerox.com (Bill Fenner) writes: >My very first "make world" ever fell over; since the new version of bind >was just imported I'm somewhat suspicious that it's actually not something >dumb that I'm doing... >===> libresolv >cc -O -DDEBUG -DLIBC_SCCS -c /usr/src/lib/libresolv/../libc/net/gethostnamadr.c >-o gethostnamadr.o >cc -O -DDEBUG -DLIBC_SCCS -c /usr/src/lib/libresolv/../libc/net/res_mkquery.c -o > res_mkquery.o >/usr/src/lib/libresolv/../libc/net/res_mkquery.c:68: res_config.h: No such file >or directory >*** Error code 1 >There is indeed a res_config.h in ../libc/net/, but no include path for it... > Bill Yep. It was a braino on my part.. Very sorry.. I wasn't aware of the existance of libresolv.. Since the entire resolver was in libc, the thought never occurred to me to see if it was built elsewhere... If you rerun your sup or ctm, you'll it'll work.. As for your make world, if it got to the second pass of building the libraries, you should be able to simply continue where it left off with "make all install".. If it hasn't built a new gcc and libc yet, you'd best let it start from scratch again... :-( -Peter (hanging head in shame..) From owner-freebsd-current Mon Aug 21 10:29:04 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA01659 for current-outgoing; Mon, 21 Aug 1995 10:29:04 -0700 Received: from vax.cs.pitt.edu (vax.cs.pitt.edu [136.142.79.5]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id KAA01627 for ; Mon, 21 Aug 1995 10:28:52 -0700 Received: from w2xo.pgh.pa.us by vax.cs.pitt.edu (8.6.10/1.14) for ; id NAA23787; Mon, 21 Aug 1995 13:29:09 -0400 Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.11/8.6.9) id NAA00845; Mon, 21 Aug 1995 13:24:19 -0400 Date: Mon, 21 Aug 1995 13:24:15 -0400 (EDT) From: Jim Durham To: current@freebsd.org Subject: buffers full on 2.0.5R Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk I have: 1. An internal 28.8 modem running iijPPP to my unreliable internet provider. 2. 2 polled serial ports used by an application with select(). The application is a ham radio AX25 server that was originally written for DOS and is a giant polling loop. Yeah..I need to fix it..but no time right now.. I have noticed some strange behavior with this set-up. I *think* this is what happens... The modem PPP stuff goes nuts due to some problem at the server end and won't pass IP packets. I think this is *his* problem. iijPPP still indicates that the PPP connection is working. If you telnet to it's daemon, the PPP is still upper case. However, when this happens, I start getting thousands of overflows on the serial port reported and, if you try to ping someone out the SLIP connection, you get "buffers full" errors. The application polling the serial ports goes comatose also. It won't respond to keyboard input and it's children become zombies. It sure looks like something is scribbling on some kernel structures when the IP buffers fill up. Note that as long as the system is running normally, this doesn't happen. It's only when the network "jams up". Another thing, that happened. I was playing with the routing tables to see if that was causing a problem, as someone suggested.I managed to get a default route entry in the routing table with localhost as a gateway when there was already an entry for my slip provider's system as a default. I had two default entries. I couldn't get it to go away except by rebooting. Netstat kept telling me it was there, but route delete said it wasn't. Route flush didn't do anything at all, everything remained. It sounds like the routing tables were also lunched at the time (pointer pointing nowhere?) -Jim (If it can be broken, I'll break it) Durham From owner-freebsd-current Mon Aug 21 11:02:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA03287 for current-outgoing; Mon, 21 Aug 1995 11:02:03 -0700 Received: from kaiwan.kaiwan.com (kaiwan.kaiwan.com [198.178.203.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA03281 for ; Mon, 21 Aug 1995 11:02:01 -0700 Received: from exit.com (uucp@localhost) by kaiwan.kaiwan.com (8.6.12/8.6.12) with UUCP id LAA06459; Mon, 21 Aug 1995 11:01:24 -0700 *** KAIWAN Internet Access *** Received: (from frank@localhost) by exit.com (8.6.11/8.6.6) id LAA03399; Mon, 21 Aug 1995 11:03:02 -0700 From: Frank Mayhar Message-Id: <199508211803.LAA03399@exit.com> Subject: Re: Show-stopper crashes on 2.1-STABLE and 2.1.0-072695-SNAP. To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 21 Aug 1995 11:03:01 -0700 (PDT) Cc: current@freebsd.org, fmayhar@locus.com In-Reply-To: <199508211000.MAA26738@bonnie.tcd-dresden.de> from "J Wunsch" at Aug 21, 95 12:00:48 pm X-Mailer: ELM [version 2.4 PL24 ME5a] Content-Type: text Content-Length: 778 Sender: current-owner@freebsd.org Precedence: bulk Joerg wrote: > Since Frank has apparently email problems, and i'm not sure if this > report appeared in the lists, is it a known problem? Thanks, Joerg, but the problem appears to be hardware. I finally yanked the pipeline burst cache module, and haven't had a single crash in almost 24 hours of continuous news unbatching (I had a _lot_ of backed up news batches). I'm sending the module back today, and should have a new one by Wednesday. (The alternative is that it's a problem in the cache circuitry of the motherboard itself, but that will only become apparent if the system fails in the same way with the new PB module. I'm keeping my fingers crossed that it's the module itself.) Oh, and the email problems have been fixed. Thanks. -- Frank Mayhar frank@exit.com From owner-freebsd-current Mon Aug 21 14:11:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA11979 for current-outgoing; Mon, 21 Aug 1995 14:11:07 -0700 Received: from meter.eng.uci.edu (meter.eng.uci.edu [128.200.85.3]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA11968 for ; Mon, 21 Aug 1995 14:11:03 -0700 Received: from balboa.eng.uci.edu by meter.eng.uci.edu (8.6.12) id OAA29967; Mon, 21 Aug 1995 14:11:01 -0700 Received: from localhost.uci.edu by balboa.eng.uci.edu (5.65c) id AA08666; Mon, 21 Aug 1995 14:11:00 -0700 Message-Id: <199508212111.AA08666@balboa.eng.uci.edu> To: current@freebsd.org Subject: Re: IDE CDROM In-Reply-To: Your message of "Sun, 20 Aug 1995 22:57:25 PDT." <199508210557.AA02106@balboa.eng.uci.edu> Date: Mon, 21 Aug 1995 14:10:59 -0700 From: Steven Wallace Sender: current-owner@freebsd.org Precedence: bulk > I ONLY have an IDE CDROM drive and that is it. No other IDE drives. > So the IDE CDROM is configured to be the master. Maybe that is the reason? > Okay, I figured out a round-about way to compile the kernel and get the driver to work only with an IDE cdrom as master. Do the following steps: Add to config: options ATAPI #Enable ATAPI support for IDE bus controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr device wcd0 #IDE CD-ROM Do NOT add any disk wd0 or wd1 to the config. config cd /sys/compile/ edit the Makefile and add to the ned of the OBJS wd.o and atapi.o edit wd.h to look like: #define NWDC 1 #define NWD 1 and compile the kernel. On probe I get: wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): , removable, intr atapi0.0: controller not ready Even though it says "controller not ready" it seems to work fine. Make sure you get the new MAKEDEV and MAKEDEV wcd0 Steven From owner-freebsd-current Mon Aug 21 14:15:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA12196 for current-outgoing; Mon, 21 Aug 1995 14:15:32 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA12176 for ; Mon, 21 Aug 1995 14:15:25 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id XAA28393 for ; Mon, 21 Aug 1995 23:15:23 +0200 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id XAA15050 for freebsd-current@FreeBSD.ORG; Mon, 21 Aug 1995 23:15:22 +0200 Received: (from roberto@localhost) by keltia.frmug.fr.net (8.7.Beta.11/keltia-uucp-2.4) id XAA19567 for freebsd-current@FreeBSD.ORG; Mon, 21 Aug 1995 23:14:12 +0200 (MET DST) From: Ollivier Robert Message-Id: <199508212114.XAA19567@keltia.frmug.fr.net> Subject: Leftover file during sendmail's import To: freebsd-current@FreeBSD.ORG (FreeBSD Current Users' list) Date: Mon, 21 Aug 1995 23:14:12 +0200 (MET DST) Reply-To: roberto@keltia.freenix.fr (Ollivier Robert) X-Operating-System: FreeBSD 2.2-CURRENT ctm#1000 X-Mailer: ELM [version 2.4 PL24 ME7a] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: current-owner@FreeBSD.ORG Precedence: bulk FYI : 235 [23:07] roberto@keltia:/spare/FreeBSD-current> do_ctm 1011 Working on Expecting Global MD5 <237989466d1f70b4642f7362152afc53> Reference Global MD5 <237989466d1f70b4642f7362152afc53> > FS .ctm_status > FN CVSROOT/commitlogs/lib > FN CVSROOT/commitlogs/ports > FN CVSROOT/commitlogs/share > FN ports/net/ncftp2/Makefile,v > FM ports/net/ncftp2/files/Complete.c,v > FM ports/net/ncftp2/files/Complete.h,v > FN ports/net/ncftp2/files/md5,v > FM ports/net/ncftp2/patches/patch-ac,v > FN src/lib/libc/stdio/fgets.3,v > FN src/share/FAQ/Text/MIRROR.SITES,v > FN src/share/doc/handbook/contrib.sgml,v > FM src/usr.sbin/sendmail/src/newsrc.tar.gz ^^^^^^^^^^^^^ All done ok -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.frmug.fr.net FreeBSD keltia 2.2-CURRENT #15: Sun Aug 13 17:24:47 MET DST 1995 From owner-freebsd-current Mon Aug 21 15:27:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA15012 for current-outgoing; Mon, 21 Aug 1995 15:27:37 -0700 Received: from easynet.com ([199.2.26.10]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id PAA15006 for ; Mon, 21 Aug 1995 15:27:35 -0700 Received: from easy4.easynet.com by easynet.com with smtp (Smail3.1.28.1 #7) id m0skfJk-000rgzC; Mon, 21 Aug 95 15:27 WET DST Received: (from brian@localhost) by easy4.easynet.com (8.6.11/8.6.9) id WAA17983; Mon, 21 Aug 1995 22:29:36 GMT From: Brian Litzinger Message-Id: <199508212229.WAA17983@easy4.easynet.com> Subject: Re: Show-stopper crashes on 2.1-STABLE and 2.1.0-072695-SNAP. To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 21 Aug 1995 22:29:36 +0000 () Cc: current@freebsd.org, fmayhar@locus.com In-Reply-To: <199508211000.MAA26738@bonnie.tcd-dresden.de> from "J Wunsch" at Aug 21, 95 12:00:48 pm X-Mailer: ELM [version 2.4 PL24 ME7a] Content-Type: text Content-Length: 804 Sender: current-owner@freebsd.org Precedence: bulk > > Since Frank has apparently email problems, and i'm not sure if this > report appeared in the lists, is it a known problem? > > In article <410bgk$3vij@janus.la.locus.com> you write: > >Now the critical problem: > > > >I just upgraded my hardware to a P100/PCI motherboard (configuration is > >below), and needed to upgrade to FreeBSD 2.0.5 or better since 1.1.5.1 > >(which I had been running) doesn't support my new hardware. I've had > >nothing but headaches. The real problem is that I can't run News; email > >works okay, but INN pounds the system hard enough that it crashes almost > >immediately (if I don't run News, it crashes eventually, but it takes a > >lot longer -- although I've had it crash immediately after boot). Disable your external cache. Brian Litzinger brian@easynet.com From owner-freebsd-current Mon Aug 21 17:56:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA22279 for current-outgoing; Mon, 21 Aug 1995 17:56:43 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id RAA22270 ; Mon, 21 Aug 1995 17:56:41 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA27891; Mon, 21 Aug 95 18:58:21 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508220058.AA27891@cs.weber.edu> Subject: Changing DEV_BSIZE To: hackers@freebsd.org, current@freebsd.org Date: Mon, 21 Aug 95 18:58:20 MDT X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk From owner-freebsd-current Mon Aug 21 18:08:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA23027 for current-outgoing; Mon, 21 Aug 1995 18:08:34 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id SAA23019 for ; Mon, 21 Aug 1995 18:08:30 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA27941; Mon, 21 Aug 95 19:10:10 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508220110.AA27941@cs.weber.edu> Subject: Changing DEV_BSIZE To: current@freebsd.org Date: Mon, 21 Aug 95 19:10:10 MDT X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk Oops! Sent that one without a message body! 8-). I want to up the size of DIRBLKSIZE in ufs/ufs/dir.h to play around with some things I was playing around with before the VM changes. The dir.h code says that the DIR_BLKSIZ needs to be DEV_BSIZE to make any atomicity guarantees... this wasn't the case in the previous code. I'd like to know if making the DIRBLKSIZ 1204 (ie: DEV_BSIZE * 2) will result in problems. It seems to me that the disks are accessed in terms of pages in any case, and the comment in dir.h that says: * A directory consists of some number of blocks of DIRBLKSIZ * bytes, where DIRBLKSIZ is chosen such that it can be transferred * to disk in a single atomic operation (e.g. 512 bytes on most machines). Is in fact outdated and incorrect -- even on older pre-VM changes code, I'd think... Does anyone see a problem with this? Note that I'm not proposing this change for the generic case of everyone's UFS... just mine. If there *is* a 512 byte limit in effect here, can I up DEV_BSIZE to get around it? Is this just artificial crap to deal with frags? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Aug 21 20:24:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id UAA28341 for current-outgoing; Mon, 21 Aug 1995 20:24:26 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id UAA28322 for ; Mon, 21 Aug 1995 20:24:21 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id UAA22248 for ; Mon, 21 Aug 1995 20:24:18 -0700 To: current@freefall.FreeBSD.org Subject: Of slices and boot code.. Date: Mon, 21 Aug 1995 20:24:17 -0700 Message-ID: <22246.809061857@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk Would it be reasonable to assume that our current boot code will never have a chance of dealing with the root partition via a "slice?" It's kind of a pity since I've gotten a lot of tech support emails from people who were very confused that / showed up on `sd0a' while everything else was on a slice. It makes a somewhat confusing model (to the uninitiated) even more confusing since just when they think they're understanding it (and, in fact, ARE) that comes along to trip them up. Sigh. Jordan From owner-freebsd-current Mon Aug 21 21:02:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id VAA00585 for current-outgoing; Mon, 21 Aug 1995 21:02:43 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id VAA00576 for ; Mon, 21 Aug 1995 21:02:38 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA22246; Tue, 22 Aug 1995 14:01:03 +1000 Date: Tue, 22 Aug 1995 14:01:03 +1000 From: Bruce Evans Message-Id: <199508220401.OAA22246@godzilla.zeta.org.au> To: current@freefall.FreeBSD.org, jkh@time.cdrom.com Subject: Re: Of slices and boot code.. Sender: current-owner@FreeBSD.org Precedence: bulk >Would it be reasonable to assume that our current boot code will never >have a chance of dealing with the root partition via a "slice?" No, it wouldn't be reasonable. Bruce From owner-freebsd-current Mon Aug 21 21:15:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id VAA01047 for current-outgoing; Mon, 21 Aug 1995 21:15:27 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id VAA01041 for ; Mon, 21 Aug 1995 21:15:22 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA28518; Mon, 21 Aug 95 22:15:44 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508220415.AA28518@cs.weber.edu> Subject: Re: Of slices and boot code.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Mon, 21 Aug 95 22:15:44 MDT Cc: current@freefall.FreeBSD.org In-Reply-To: <22246.809061857@time.cdrom.com> from "Jordan K. Hubbard" at Aug 21, 95 08:24:17 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > Would it be reasonable to assume that our current boot code will never > have a chance of dealing with the root partition via a "slice?" No. That's just an implementation detail. It's a trivial change, even in the current code. I hate the idea of "partitions" vs. "slices". The terminology has become extremely muddied, which is probably the root of your callers' confusion. Device names are rarely visible enough to cause questions. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Aug 21 22:21:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA03189 for current-outgoing; Mon, 21 Aug 1995 22:21:07 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA03181 for ; Mon, 21 Aug 1995 22:21:05 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id WAA00360; Mon, 21 Aug 1995 22:20:52 -0700 To: Bruce Evans cc: current@freefall.FreeBSD.org Subject: Re: Of slices and boot code.. In-reply-to: Your message of "Tue, 22 Aug 1995 14:01:03 +1000." <199508220401.OAA22246@godzilla.zeta.org.au> Date: Mon, 21 Aug 1995 22:20:51 -0700 Message-ID: <358.809068851@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > >Would it be reasonable to assume that our current boot code will never > >have a chance of dealing with the root partition via a "slice?" > > No, it wouldn't be reasonable. > > Bruce Maybe I should have qualified that.. :-) By "current boot code" I meant "not a 3 stage boot." I was under the impression that cramped space in the current set would preclude the addition of slice-aware code to it. If I was wrong about that, then all I can say is "great! please, when!" Thanks.. Jordan From owner-freebsd-current Mon Aug 21 22:22:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA03282 for current-outgoing; Mon, 21 Aug 1995 22:22:00 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id WAA03276 for ; Mon, 21 Aug 1995 22:21:58 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA24405; Tue, 22 Aug 1995 07:21:56 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id HAA02716 for current@freefall.FreeBSD.org; Tue, 22 Aug 1995 07:21:56 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id HAA09966 for current@freefall.FreeBSD.org; Tue, 22 Aug 1995 07:17:37 +0200 From: J Wunsch Message-Id: <199508220517.HAA09966@uriah.heep.sax.de> Subject: Re: Of slices and boot code.. To: current@freefall.FreeBSD.org Date: Tue, 22 Aug 1995 07:17:37 +0200 (MET DST) Reply-To: current@freefall.FreeBSD.org In-Reply-To: <9508220415.AA28518@cs.weber.edu> from "Terry Lambert" at Aug 21, 95 10:15:44 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 617 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > No. That's just an implementation detail. > > It's a trivial change, even in the current code. Except for the space issues. > I hate the idea of "partitions" vs. "slices". The terminology has become > extremely muddied, which is probably the root of your callers' confusion. > Device names are rarely visible enough to cause questions. They are visible in the `df' or `mount' list. (The root file system has been mounted automatically.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Mon Aug 21 22:32:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA04023 for current-outgoing; Mon, 21 Aug 1995 22:32:49 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA04017 for ; Mon, 21 Aug 1995 22:32:48 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id WAA00428; Mon, 21 Aug 1995 22:32:24 -0700 To: Bruce Evans , current@freefall.FreeBSD.org Subject: Re: Of slices and boot code.. In-reply-to: Your message of "Mon, 21 Aug 1995 22:20:51 PDT." <358.809068851@time.cdrom.com> Date: Mon, 21 Aug 1995 22:32:24 -0700 Message-ID: <426.809069544@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > If I was wrong about that, then all I can say is "great! please, when!" And just to follow up on THAT, let me say that I'm not just raving here for the sake of being a pedant. I had to turn some real handsprings in sysinstall to deal with the compat-slice being mandatory for just root and I'd like to see that band-aid go away. I'm also receiving the aformentioned tech support for it as well, just to make things worse. That's my perspective on this. Jordan From owner-freebsd-current Mon Aug 21 22:48:10 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA04529 for current-outgoing; Mon, 21 Aug 1995 22:48:10 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA04517 for ; Mon, 21 Aug 1995 22:47:58 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA25256; Tue, 22 Aug 1995 15:43:27 +1000 Date: Tue, 22 Aug 1995 15:43:27 +1000 From: Bruce Evans Message-Id: <199508220543.PAA25256@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Subject: Re: Of slices and boot code.. Cc: current@freefall.FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >By "current boot code" I meant "not a 3 stage boot." I was under the >impression that cramped space in the current set would preclude the >addition of slice-aware code to it. It already passes the slice number to the kernel, but the kernel ignores it. I forget why. It may be just because you would need to create all device nodes for all slices in case someone boots from one. The boot code is missing only support for parsing slice numbers and for booting from extended partitions, e.g., sd(0,s5,a)/kernel. Supporting booting from 30 different slices would require a lot of device nodes. Here are my diffs to implement looking at and reporting the slice number in the kernel. The diffs also remove the kludges to support the current bogus floppy minor numbering. The floppy driver, MAKDEV, and everyone's /dev/fd?* need to be updated before the kludges can be removed. Bruce *** autoconf.c~ Mon Jul 17 15:15:30 1995 --- autoconf.c Sat Aug 19 07:27:15 1995 *************** *** 48,54 **** #include #include #include ! #include #include #include #include --- 48,55 ---- #include #include #include ! #include ! #include #include #include #include *************** *** 57,62 **** --- 58,67 ---- #include #include + int find_cdrom_root __P((void)); + void configure_start __P((void)); + void configure_finish __P((void)); + static void setroot(void); /* *************** *** 259,269 **** {'s','d'}, /* 4 = sd -- new SCSI system */ }; - #define PARTITIONMASK 0x7 - #define PARTITIONSHIFT 3 - #define FDUNITSHIFT 6 - #define RAW_PART 2 - /* * Attempt to find the device from which we were booted. * If we can do so, and not instructed not to do so, --- 264,269 ---- *************** *** 272,308 **** static void setroot() { ! int majdev, mindev, unit, part, adaptor; ! dev_t temp = 0, orootdev; ! struct swdevt *swp; ! ! /*printf("howto %x bootdev %x ", boothowto, bootdev);*/ ! if (boothowto & RB_DFLTROOT || ! (bootdev & B_MAGICMASK) != (u_long)B_DEVMAGIC) return; ! majdev = (bootdev >> B_TYPESHIFT) & B_TYPEMASK; if (majdev > sizeof(devname) / sizeof(devname[0])) return; ! adaptor = (bootdev >> B_ADAPTORSHIFT) & B_ADAPTORMASK; ! unit = (bootdev >> B_UNITSHIFT) & B_UNITMASK; ! if (majdev == FDMAJOR) { ! part = RAW_PART; ! mindev = unit << FDUNITSHIFT; ! } ! else { ! part = (bootdev >> B_PARTITIONSHIFT) & B_PARTITIONMASK; ! mindev = (unit << PARTITIONSHIFT) + part; ! } ! orootdev = rootdev; ! rootdev = makedev(majdev, mindev); ! /* ! * If the original rootdev is the same as the one ! * just calculated, don't need to adjust the swap configuration. ! */ ! if (rootdev == orootdev) return; ! printf("changing root device to %c%c%d%c\n", ! devname[majdev][0], devname[majdev][1], ! mindev >> (majdev == FDMAJOR ? FDUNITSHIFT : PARTITIONSHIFT), ! part + 'a'); } --- 272,304 ---- static void setroot() { ! int majdev, mindev, adaptor, controller, unit, slice, part; ! dev_t newrootdev; ! char partname[2]; ! char *sname; ! ! if (boothowto & RB_DFLTROOT || (bootdev & B_MAGICMASK) != B_DEVMAGIC) return; ! majdev = B_TYPE(bootdev); if (majdev > sizeof(devname) / sizeof(devname[0])) return; ! adaptor = B_ADAPTOR(bootdev); ! controller = B_CONTROLLER(bootdev); ! unit = B_UNIT(bootdev); ! #if 1 ! slice = (adaptor << 4) | controller; /* XXX */ ! #else ! slice = COMPATIBILITY_SLICE; ! #endif ! part = B_PARTITION(bootdev); ! if (majdev == FDMAJOR && slice == COMPATIBILITY_SLICE) ! part = RAW_PART; /* XXX */ ! mindev = dkmakeminor(unit, slice, part); ! newrootdev = makedev(majdev, mindev); ! if (newrootdev == rootdev) return; ! rootdev = newrootdev; ! sname = dsname("", unit, slice, part, partname); ! printf("changing root device to %c%c%s%s\n", ! devname[majdev][0], devname[majdev][1], sname, partname); } From owner-freebsd-current Tue Aug 22 03:11:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id DAA18479 for current-outgoing; Tue, 22 Aug 1995 03:11:49 -0700 Received: from phoenix.csie.nctu.edu.tw (phoenix.csie.nctu.edu.tw [140.113.17.171]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id DAA18461 for ; Tue, 22 Aug 1995 03:11:37 -0700 Received: from ccsun30.csie.nctu.edu.tw (jdli@ccsun30.csie.nctu.edu.tw [140.113.17.157]) by phoenix.csie.nctu.edu.tw (8.6.11/8.6.4) with SMTP id SAA09279 for ; Tue, 22 Aug 1995 18:11:35 +0800 From: jdli@csie.nctu.edu.tw (Chien-Ta Lee) Message-Id: <199508221011.SAA09279@phoenix.csie.nctu.edu.tw> Subject: AHA2940 Tag Queueing Problem... To: freebsd-current@FreeBSD.ORG Date: Tue, 22 Aug 1995 18:10:42 +0800 (CST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2162 Sender: current-owner@FreeBSD.ORG Precedence: bulk Hi : I tried to enable AHC_TAGENABLE on FreeBSD-2.2-CURRENT-950820, but still failed as 2.0.5-RELEASE... May anyone help me or tell me how to provide debug informations ? Hardware : AHA2940, IBM DPES-31080S, Quantum LPS 240S (no tag) Here is the console messages..... Probing for devices on the pci0 bus: configuration mode 1 allows 32 devices. chip0 rev 1 on pci0:0 chip1 rev 2 on pci0:7 vga0 rev 0 on pci0:17 ahc0 rev 0 int a irq 11 on pci0:20 ahc0: reading board settings ahc0: Reading SEEPROM...done. ahc0: 2940 Single Channel, SCSI Id=7, aic7870, 16 SCBs ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0 waiting for scsi devices to settle ahc0: target 0 synchronous at 10.0MB/s, offset = 0xf ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "IBM DPES-31080 S31K" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access ahc0:A:0: Warning - message rejected by target: 0x20 ahc0:A:0: Tagged message rejected. Disabling tagged commands for this target ahc0: board not responding cmd fail cmd fail sd0(ahc0:0:0): BUS DEVICE RESET message queued ahc0: board not responding cmd fail cmd fail sd0(ahc0:0:0): BUS DEVICE RESET message queued 0MB (1 512 byte sectors) sd0(ahc0:0:0): with 0 cyls, 64 heads, and an average 32 sectors/track ahc0: board not responding cmd fail cmd fail ahc0: board not responding cmd fail cmd fail ahc0: Issued Channel A Bus Reset #3, 0SCBs aborted Normal dmesg (without AHC_TAGENABLE): ahc0: target 0 synchronous at 10.0MB/s, offset = 0xf (ahc0:0:0): "IBM DPES-31080 S31K" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 1034MB (2118144 512 byte sectors) ahc0: target 1 synchronous at 10.0MB/s, offset = 0x8 (ahc0:1:0): "QUANTUM LPS270S 5909" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 258MB (528808 512 byte sectors) pci0: uses 8392704 bytes of memory from f0000000 upto f0800fff. pci0: uses 256 bytes of I/O space from 6000 upto 60ff. -- §õ «Ø ¹F (Adonis) ¥æ¤j¸ê¤u Mail: jdli@csie.nctu.edu.tw From owner-freebsd-current Tue Aug 22 04:28:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id EAA21264 for current-outgoing; Tue, 22 Aug 1995 04:28:20 -0700 Received: from haywire.DIALix.COM (haywire.DIALix.COM [192.203.228.65]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id EAA21258 for ; Tue, 22 Aug 1995 04:28:17 -0700 Received: (from news@localhost) by haywire.DIALix.COM (8.7.Beta.11/8.7.Beta.11/DIALix) id TAA28430 for freebsd-current@freebsd.org; Tue, 22 Aug 1995 19:27:41 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-current@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-current@freebsd.org Date: 22 Aug 1995 19:27:36 +0800 From: peter@haywire.dialix.com (Peter Wemm) Message-ID: <41cev8$rob$1@haywire.DIALix.COM> Organization: DIALix Services, Perth, Australia. References: <199508212114.XAA19567@keltia.frmug.fr.net> Subject: Re: Leftover file during sendmail's import Sender: current-owner@freebsd.org Precedence: bulk roberto@keltia.frmug.fr.net (Ollivier Robert) writes: >FYI : >> FM src/usr.sbin/sendmail/src/newsrc.tar.gz > ^^^^^^^^^^^^^ >All done ok Sorry.. That was an accident with ncftp, which "helpfully" decided to return to the last directory I was in.. (when I grabbed a new conf.c,v) It wasn't a file from the import, it was a prototype implementation of a new build-system that I had uploaded to show Rod.. -Peter From owner-freebsd-current Tue Aug 22 06:14:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id GAA24662 for current-outgoing; Tue, 22 Aug 1995 06:14:48 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id GAA24646 for ; Tue, 22 Aug 1995 06:14:10 -0700 Received: by Sysiphos id AA01823 (5.67b/IDA-1.5 for current@freebsd.org); Tue, 22 Aug 1995 15:12:58 +0200 Date: Tue, 22 Aug 1995 15:12:58 +0200 Message-Id: <199508221312.AA01823@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Subject: Re: Matrox Meteor Video Capture Card Driver To: tinguely@plains.nodak.edu (Mark Tinguely) Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk In article , Mark Tinguely writes: * Warning: the Meteor does not work with all PCI chipsets. A MERCURY chipset motherboard is almost certain to NOT work with the Meteor. A NEPTUNE chipset motherboard with a PCI video card may hang with heavy Meteor use. So it is wise to use a "SATURN" or "TRITON" chipset motherboard and also limit the number of PCI bus-mastering devices on that bus. We had difficulties getting the Meteor capture card to work with systems that also use the NCR PCI SCSI boards. It is also wise to have 16 or more Megabytes of RAM in the computer. Since I'm currently maintaining the PCI and NCR code, we might try to get the Matrox Meteor supported on more motherboards ... Do you have a complete set of technical documents for the Meteor, especially regarding the PCI bus interface ? I currently do not have much time to spend on this, but if you have some idea what prevents the Meteor from working, I might be able to change the PCI or NCR code accordingly ... There have been problems with PCI bursts of more than one cache line of data with the NCR, but I had thought the Saturn was one of the chip sets that need more attention than other Intel chip sets. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Tue Aug 22 07:29:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id HAA27522 for current-outgoing; Tue, 22 Aug 1995 07:29:52 -0700 Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.35.13]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id HAA27516 for ; Tue, 22 Aug 1995 07:29:48 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id JAA10539; Tue, 22 Aug 1995 09:29:46 -0500 Date: Tue, 22 Aug 1995 09:29:46 -0500 From: Jim Lowe Message-Id: <199508221429.JAA10539@miller.cs.uwm.edu> To: se@zpr.uni-koeln.de, tinguely@plains.nodak.edu Subject: Re: Matrox Meteor Video Capture Card Driver Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk > From: se@zpr.uni-koeln.de (Stefan Esser) > Subject: Re: Matrox Meteor Video Capture Card Driver > > Do you have a complete set of technical documents for > the Meteor, especially regarding the PCI bus interface ? The PCI interface is a Phillips SAA7116. The specs for it are in the Desktop Video Data Handbook that Phillips publishes. The document order number is 98-1900-000-04. There are a bunch of phone number in the back of the book. The one for Germany is in Hamburg. The number is (040) 3296-0. > > I currently do not have much time to spend on this, but > if you have some idea what prevents the Meteor from > working, I might be able to change the PCI or NCR code > accordingly ... I think it might be a motherboard problem more than anything else. -Jim From owner-freebsd-current Tue Aug 22 07:44:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id HAA28308 for current-outgoing; Tue, 22 Aug 1995 07:44:49 -0700 Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id HAA28299 ; Tue, 22 Aug 1995 07:44:44 -0700 Message-Id: <199508221444.HAA28299@freefall.FreeBSD.org> X-Authentication-Warning: freefall.FreeBSD.org: Host localhost.cdrom.com didn't use HELO protocol To: jdli@csie.nctu.edu.tw (Chien-Ta Lee) cc: freebsd-current@freebsd.org Subject: Re: AHA2940 Tag Queueing Problem... In-reply-to: Your message of "Tue, 22 Aug 95 18:10:42 +0800." <199508221011.SAA09279@phoenix.csie.nctu.edu.tw> Date: Tue, 22 Aug 1995 07:44:42 -0700 From: "Justin T. Gibbs" Sender: current-owner@freebsd.org Precedence: bulk > > Hi : > > I tried to enable AHC_TAGENABLE on FreeBSD-2.2-CURRENT-950820, > but still failed as 2.0.5-RELEASE... > May anyone help me or tell me how to provide debug informations ? > >(ahc0:0:0): "IBM DPES-31080 S31K" type 0 fixed SCSI 2 >sd0(ahc0:0:0): Direct-Access ahc0:A:0: Warning - message rejected by target: 0 >x20 >ahc0:A:0: Tagged message rejected. Disabling tagged commands for this target >ahc0: board not responding This drive is basically broken when it comes to tagged queuing. I would suggest calling IBM and seeing if they have a firmware upgrade for it. As your dmesg showed, the target goes "out to lunch" when you send a tagged message to it. :( >-- > §õ «Ø ¹F (Adonis) ¥æ¤j¸ê¤u > Mail: jdli@csie.nctu.edu.tw -- Justin T. Gibbs =========================================== Software Developer - Walnut Creek CDROM FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-current Tue Aug 22 07:50:24 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id HAA28614 for current-outgoing; Tue, 22 Aug 1995 07:50:24 -0700 Received: from Wit401402.student.utwente.nl (Wit401402.student.utwente.nl [130.89.236.162]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id HAA28605 for ; Tue, 22 Aug 1995 07:50:16 -0700 Received: (from alain@localhost) by Wit401402.student.utwente.nl (8.6.12/8.6.9) id QAA25914; Tue, 22 Aug 1995 16:48:01 +0200 Date: Tue, 22 Aug 1995 16:48:01 +0200 (MET DST) From: Alain Kalker Reply-To: A.C.P.M.Kalker@student.utwente.nl To: "Jordan K. Hubbard" cc: current@freefall.FreeBSD.org Subject: Re: Of slices and boot code.. In-Reply-To: <22246.809061857@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@FreeBSD.org Precedence: bulk On Mon, 21 Aug 1995, Jordan K. Hubbard wrote: > Would it be reasonable to assume that our current boot code will never > have a chance of dealing with the root partition via a "slice?" > > It's kind of a pity since I've gotten a lot of tech support emails > from people who were very confused that / showed up on `sd0a' while > everything else was on a slice. It makes a somewhat confusing model > (to the uninitiated) even more confusing since just when they think > they're understanding it (and, in fact, ARE) that comes along to trip > them up. Sigh. > > Jordan > Perhaps this confusion can be traced back to a probable mix-up of the terms 'partition' and 'slice' in the documentation. Both in the documentation on partitioning your disk on the installation disk (file '.../partition.hlp') and in '/usr/share/FAQ/Text/diskspace.FAQ' the terms are interchanged. The people that Jordan gets mail from might be confused by what is referred to as the "compatibility slice" in '.../partition.hlp'. The question IMHO really is then: is there a chance of _that_ going away..? -- PS: to Jordan: Could you please forward this to the documentation people? Greetings, Alain From owner-freebsd-current Tue Aug 22 08:55:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA02383 for current-outgoing; Tue, 22 Aug 1995 08:55:41 -0700 Received: from plains.nodak.edu (plains.NoDak.edu [134.129.111.64]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id IAA02373 for ; Tue, 22 Aug 1995 08:55:37 -0700 Received: (from tinguely@localhost) by plains.nodak.edu (8.6.11/8.6.10) id KAA00117; Tue, 22 Aug 1995 10:55:32 -0500 Date: Tue, 22 Aug 1995 10:55:32 -0500 From: Mark Tinguely Message-Id: <199508221555.KAA00117@plains.nodak.edu> To: james@miller.cs.uwm.edu, se@zpr.uni-koeln.de Subject: Re: Matrox Meteor Video Capture Card Driver Cc: current@freebsd.org Content-Length: 602 Sender: current-owner@freebsd.org Precedence: bulk > > I currently do not have much time to spend on this, but > > if you have some idea what prevents the Meteor from > > working, I might be able to change the PCI or NCR code > > accordingly ... > > I think it might be a motherboard problem more than anything else. Jim had problems with a motherboard with NCR SCSI and I also had problems on completely different motherboard with NCR SCSI (DEC 90MHz PC). maybe it is the PCI chipsets. Even Matrox put a general disclaimer that their card may not work in some machines and then list a couple machines they did try and it succeeded. --mark. From owner-freebsd-current Tue Aug 22 08:56:36 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA02498 for current-outgoing; Tue, 22 Aug 1995 08:56:36 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id IAA02482 for ; Tue, 22 Aug 1995 08:56:29 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA16722; Tue, 22 Aug 1995 17:55:48 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA06008 for current@freebsd.org; Tue, 22 Aug 1995 17:55:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id RAA10940 for current@freebsd.org; Tue, 22 Aug 1995 17:37:34 +0200 From: J Wunsch Message-Id: <199508221537.RAA10940@uriah.heep.sax.de> Subject: Request for bumping OSRELDATE To: current@freebsd.org Date: Tue, 22 Aug 1995 17:37:34 +0200 (MET DST) Reply-To: current@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1568 Sender: current-owner@freebsd.org Precedence: bulk When trying to compile the recently offered upgrade of the xperfmon port to a -current system, it wouldn't compile. The reason is the massive internal restructuring caused by the NFSv3 upgrade. In an attempt to get the port compile on either -stable or -current, i've took it from the FreeBSD_version example that i should include and differentiate from it. Anyway: j@uriah 223% cvs co -Q -P -rRELEASE_2_0 sys_conf j@uriah 224% fgrep -i reld sys_conf/newvers.sh echo "int osreldate = 199411;" >> vers.c j@uriah 225% cvs co -Q -P -rRELENG_2_0_5 sys_conf j@uriah 226% fgrep -i reld sys_conf/newvers.sh RELDATE="199504" echo "int osreldate = ${RELDATE};" >> vers.c j@uriah 227% cvs co -Q -P -rRELENG_2_1_0 sys_conf j@uriah 228% fgrep -i reld sys_conf/newvers.sh RELDATE="199504" echo "int osreldate = ${RELDATE};" >> vers.c j@uriah 229% cvs co -Q -P -rHEAD sys_conf j@uriah 230% fgrep -i reld sys_conf/newvers.sh RELDATE="199504" echo "int osreldate = ${RELDATE};" >> vers.c j@uriah 231% cvs release -dQ sys_conf The osreldate has been changed between 2.0 and 2.0.5, but not afterwards. I desperately need a new version number now... Perhaps we should bump it now ``just in case'', to have a means of testing against `` > 199504'', and correct it to the actual release date right in time? (I think it's ok to leave it as it is for 2.1 since only bug fixes are included, and no interface changes.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Aug 22 10:59:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA06834 for current-outgoing; Tue, 22 Aug 1995 10:59:14 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id KAA06828 for ; Tue, 22 Aug 1995 10:59:12 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00894; Tue, 22 Aug 95 12:00:52 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508221800.AA00894@cs.weber.edu> Subject: Re: Of slices and boot code.. To: current@freefall.FreeBSD.org Date: Tue, 22 Aug 95 12:00:52 MDT In-Reply-To: <199508220517.HAA09966@uriah.heep.sax.de> from "J Wunsch" at Aug 22, 95 07:17:37 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > No. That's just an implementation detail. > > > > It's a trivial change, even in the current code. > > Except for the space issues. I'm confused -- you mean name-space issues? The root device name is a uniformity of naming issue when the mounted device name is copied into the superblock. > > I hate the idea of "partitions" vs. "slices". The terminology has become > > extremely muddied, which is probably the root of your callers' confusion. > > Device names are rarely visible enough to cause questions. > > They are visible in the `df' or `mount' list. (The root file system > has been mounted automatically.) I can't believe someone who runs 'df' and 'mount' would find *any* device name confusing -- a device is a device, it's the major and minor numbers that are important. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Aug 22 11:23:23 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA08436 for current-outgoing; Tue, 22 Aug 1995 11:23:23 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id LAA08429 for ; Tue, 22 Aug 1995 11:23:20 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA01010; Tue, 22 Aug 95 12:24:45 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508221824.AA01010@cs.weber.edu> Subject: Re: Of slices and boot code.. To: bde@zeta.org.au (Bruce Evans) Date: Tue, 22 Aug 95 12:24:44 MDT Cc: bde@zeta.org.au, jkh@time.cdrom.com, current@freefall.FreeBSD.org In-Reply-To: <199508220543.PAA25256@godzilla.zeta.org.au> from "Bruce Evans" at Aug 22, 95 03:43:27 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > Here are my diffs to implement looking at and reporting the slice number > in the kernel. The diffs also remove the kludges to support the current > bogus floppy minor numbering. The floppy driver, MAKDEV, and everyone's > /dev/fd?* need to be updated before the kludges can be removed. Where are the MAKEDEV diffs? 8-). Actually, has any consideration been given to having MAKEDEV use sysctl in user land to ask the kernl what devices there are, and make them? The actual soloution is a devfs, where the nodes "just are" (except the cloners, of course). Where is the current devfs code? If it's not currently being hacked, I'd like to hack on it. It will help in porting by reducing the dependencies for an MFS. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Aug 22 12:15:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id MAA11230 for current-outgoing; Tue, 22 Aug 1995 12:15:54 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id MAA11218 for ; Tue, 22 Aug 1995 12:15:50 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id MAA07292; Tue, 22 Aug 1995 12:13:56 -0700 From: "Rodney W. Grimes" Message-Id: <199508221913.MAA07292@gndrsh.aac.dev.com> Subject: Re: Matrox Meteor Video Capture Card Driver To: se@ZPR.Uni-Koeln.DE (Stefan Esser) Date: Tue, 22 Aug 1995 12:13:56 -0700 (PDT) Cc: tinguely@plains.nodak.edu, current@freebsd.org In-Reply-To: <199508221312.AA01823@Sysiphos> from "Stefan Esser" at Aug 22, 95 03:12:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3367 Sender: current-owner@freebsd.org Precedence: bulk > > In article , Mark Tinguely writes: > * Warning: the Meteor does not work with all PCI chipsets. A MERCURY chipset > motherboard is almost certain to NOT work with the Meteor. A NEPTUNE chipset > motherboard with a PCI video card may hang with heavy Meteor use. So it is > wise to use a "SATURN" or "TRITON" chipset motherboard and also limit the > number of PCI bus-mastering devices on that bus. We had difficulties getting > the Meteor capture card to work with systems that also use the NCR PCI SCSI > boards. It is also wise to have 16 or more Megabytes of RAM in the computer. > > Since I'm currently maintaining the PCI and NCR code, > we might try to get the Matrox Meteor supported on > more motherboards ... I doubt you are going to fix the ``hardware'' bugs in the Mercury chipset that causes the problems with boards like the Meteor. > Do you have a complete set of technical documents for > the Meteor, especially regarding the PCI bus interface ? > > I currently do not have much time to spend on this, but > if you have some idea what prevents the Meteor from > working, I might be able to change the PCI or NCR code > accordingly ... > > There have been problems with PCI bursts of more than one > cache line of data with the NCR, but I had thought the > Saturn was one of the chip sets that need more attention > than other Intel chip sets. Saturn-I may have some problems here, don't know, don't have access to a Saturn-I based machine. Saturn-II seems to handle 4 bus masters without any problem, and I suspect a Saturn-II can run the Meteor just fine. But then, doing video capture on a 486 class machine does not make a whole lot of since given the CPU demand needed to do mpeg. Of the Intel PCI chip sets the following is a list of brokenness from worst to best and a short description of brokenness. a) Mercury - Cache coherency problems, especially if there are ISA bus masters behind the ISA to PCI bridge chip. Hardware flaw, only known work around is to turn the cache off. b) Saturn-I (ie, 82424ZX at rev 0, 1 or 2) - write back cache coherency problems. Hardware flaw, only known work around is to set the external cache to write-through mode. Upgrade to Saturn-II. c) Saturn-II (ie 82424ZX at rev 3 or 4) - works fine, but many MB manufactures leave out the external dirty bit SRAM needed for write back operation. Work arounds are either run it in write through mode, or get the dirty bit SRAM installed. (I have these for the ASUS PCI/I-486SP3G rev 1.6 and later boards). d) Neptune - Can not run more than 2 bus master devices. Admitted Intel design flaw. Workarounds include don't run more than 2 bus masters, special hardware design to replace the PCI bus arbiter (appears on Intel Altair board and several other Intel server group MB's). And of course Intel's official answer, move to the Triton chip set, we ``fixed it there''. e) Triton - No known cache coherency or bus master problems, chip set does not implement parity checking. Workaround for parity issue - wait for Triton-II :-(. f) Triton-II - Unknown, not yet shipping :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Tue Aug 22 13:02:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA14204 for current-outgoing; Tue, 22 Aug 1995 13:02:43 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA14186 for ; Tue, 22 Aug 1995 13:02:36 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA20779; Wed, 23 Aug 1995 06:00:21 +1000 Date: Wed, 23 Aug 1995 06:00:21 +1000 From: Bruce Evans Message-Id: <199508222000.GAA20779@godzilla.zeta.org.au> To: alain@Wit401402.student.utwente.nl, jkh@time.cdrom.com Subject: Re: Of slices and boot code.. Cc: current@freefall.FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >> It's kind of a pity since I've gotten a lot of tech support emails >> from people who were very confused that / showed up on `sd0a' while >> everything else was on a slice. It makes a somewhat confusing model >> ... >Both in the documentation on partitioning your disk on the installation >disk (file '.../partition.hlp') and in '/usr/share/FAQ/Text/diskspace.FAQ' >the terms are interchanged. They seem to be quite consistent. BSD partitions are named partitions and DOS partitions are named slices. The native partitions have to be named partitions for political reasons and the foreign partitions have to be named something different to avoid confusion. >The people that Jordan gets mail from might be confused by what is >referred to as the "compatibility slice" in '.../partition.hlp'. The They are confused that it gets, and perhaps that it doesn't get used in all cases. It only needs to be used for the boot partition (sd0a, perhaps). For the usr partition on sd0, you could use sd0e on the compatibility slice, or equivalently, sd0s2e if sd0s2 is the compatibility slice, or differently, sd0s3a if sd0s2 is the compatibility slice that you don't want to put usr on for some reason and sd0s3 is another FreeBSD slice. >question IMHO really is then: is there a chance of _that_ going away..? Low. sd0[a-h] is the native name. The compatibility slice may become unused on systems that can run DOS. Bruce From owner-freebsd-current Tue Aug 22 13:03:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA14347 for current-outgoing; Tue, 22 Aug 1995 13:03:46 -0700 Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.35.13]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA14341 for ; Tue, 22 Aug 1995 13:03:45 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id PAA26113; Tue, 22 Aug 1995 15:03:43 -0500 Date: Tue, 22 Aug 1995 15:03:43 -0500 From: Jim Lowe Message-Id: <199508222003.PAA26113@miller.cs.uwm.edu> To: rgrimes@gndrsh.aac.dev.com, se@ZPR.Uni-Koeln.DE Subject: Re: Matrox Meteor Video Capture Card Driver Cc: current@freebsd.org, tinguely@plains.nodak.edu Sender: current-owner@freebsd.org Precedence: bulk > > Since I'm currently maintaining the PCI and NCR code, > > we might try to get the Matrox Meteor supported on > > more motherboards ... > > I doubt you are going to fix the ``hardware'' bugs in the Mercury > chipset that causes the problems with boards like the Meteor. I just tried the meteor card in an ASUS triton box with the NCR controller in it. The machine locked up on large frame transfers. It seemed to work just fine as long as I kept the PCI data transfer down with small frame sizes. If I remove the NCR controller and use a different one, the machine works just fine. For some reason, the NCR seems to lock up when the PCI bus gets real busy. I am not sure why. -Jim From owner-freebsd-current Tue Aug 22 14:29:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA18242 for current-outgoing; Tue, 22 Aug 1995 14:29:48 -0700 Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA18235 for ; Tue, 22 Aug 1995 14:29:41 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id QAA07240 for ; Tue, 22 Aug 1995 16:28:58 -0500 Message-Id: <199508222128.QAA07240@chrome.onramp.net> X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol To: freebsd-current@freebsd.org Subject: Building and World Order Reply-To: jdl@chromatic.com Date: Tue, 22 Aug 1995 16:28:58 -0500 From: Jon Loeliger Sender: current-owner@freebsd.org Precedence: bulk Folks, So I just installed and booted a 2.1.0-950726-SNAP over here. It worked great! (Thanks, Jordan!) Then, I sup'ed in a -current and slammed it down on /usr/src. Worked great! So, naturally, I wanted to build it all... Went searching for the FAQ and all, and the closest I came was to this paragraph from current-policy.FAQ: 4. Before compiling current, read the Makefile in /usr/src carefully. You'll see one-time targets like `bootstrapld' which *MUST* be run as part of the upgrading process. Reading freebsd-hackers will keep you up-to-date on other bootstrapping procedures that sometimes become necessary as we move towards the next release. I couldn't find a 'bootstrapld' target, so I just 'make world'ed. Seems to be humming along nicely (still). (After I moved it all to a bigger partition. :-) So, where do I go from here? What are the valid (and pertinent) make targets? Is 'install' up next? I don't see the semi-traditional 'clean' and 'realclean', just 'cleandist'. Will all of my local utilities get updated to be the utilities that I just build at some point? Do I even want or need to do this step in order to run the -current kernel I just built? Also, when I sup in a new update, how much of the world will I need to rebuild? Do I need to start at /usr/src and make 'world' again? I hope I don't have to do all the 'world' again for a while... I should be able to build kernels in isolation now, right? Thanks, jdl From owner-freebsd-current Tue Aug 22 17:54:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA28258 for current-outgoing; Tue, 22 Aug 1995 17:54:13 -0700 Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id RAA28252 for ; Tue, 22 Aug 1995 17:54:11 -0700 Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id CAA16158 ; Wed, 23 Aug 1995 02:54:03 +0200 Received: from (roberto@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) id CAA19610 ; Wed, 23 Aug 1995 02:54:02 +0200 From: roberto@blaise.ibp.fr (Ollivier Robert) Message-Id: <199508230054.CAA19610@blaise.ibp.fr> Subject: Re: Building and World Order To: jdl@chromatic.com Date: Wed, 23 Aug 1995 02:54:02 +0200 (MET DST) Cc: freebsd-current@freebsd.org In-Reply-To: <199508222128.QAA07240@chrome.onramp.net> from "Jon Loeliger" at Aug 22, 95 04:28:58 pm X-Operating-System: FreeBSD 2.2-CURRENT ctm#880 X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 433 Sender: current-owner@freebsd.org Precedence: bulk > > I couldn't find a 'bootstrapld' target, so I just 'make world'ed. > Seems to be humming along nicely (still). (After I moved it all to > a bigger partition. :-) This paragraph is outdated. It was meant for the 1.0.2 to 1.1 transition for shared libraries if my memory serves me well... -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@FreeBSD.ORG FreeBSD 2.2-CURRENT #5: Fri Jul 14 12:28:04 MET DST 1995 From owner-freebsd-current Tue Aug 22 20:57:42 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id UAA07004 for current-outgoing; Tue, 22 Aug 1995 20:57:42 -0700 Received: from irbs.irbs.com (irbs.com [199.182.75.129]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id UAA06990 for ; Tue, 22 Aug 1995 20:57:38 -0700 Received: (from jc@localhost) by irbs.irbs.com (8.6.11/8.6.6) id XAA04601 for freebsd-current@freefall.cdrom.com; Tue, 22 Aug 1995 23:57:34 -0400 From: John Capo Message-Id: <199508230357.XAA04601@irbs.irbs.com> Subject: CLOCAL and CRTSCTS in -current and -stable To: freebsd-current@freefall.FreeBSD.org (freebsd-current) Date: Tue, 22 Aug 1995 23:57:33 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 705 Sender: current-owner@FreeBSD.org Precedence: bulk I upgraded an old 1.1.5.1 system to -stable a few days ago and had trouble convincing cu to talk to a port that only has TX and RX. I had to stop cu and turn off crtscts to get cu to output. Input works OK. Once I understood the problem, I tried the locking/initial mechanism but -crtscts would not stick. -current from last month cu defaults to: cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf -stable from last week: cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -dsrflow -dtrflow -mdmbuf Has cu changed or have the kernel defaults changed? Is the locking/initial scheme broken in -stable? John Capo IRBS Engineering From owner-freebsd-current Tue Aug 22 21:20:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id VAA07832 for current-outgoing; Tue, 22 Aug 1995 21:20:52 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id VAA07824 for ; Tue, 22 Aug 1995 21:20:50 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA04768; Wed, 23 Aug 1995 06:20:47 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA13883 for current@freefall.FreeBSD.org; Wed, 23 Aug 1995 06:20:47 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id VAA13331 for current@freefall.FreeBSD.org; Tue, 22 Aug 1995 21:42:20 +0200 From: J Wunsch Message-Id: <199508221942.VAA13331@uriah.heep.sax.de> Subject: Re: Of slices and boot code.. To: current@freefall.FreeBSD.org Date: Tue, 22 Aug 1995 21:42:20 +0200 (MET DST) Reply-To: current@freefall.FreeBSD.org In-Reply-To: <9508221800.AA00894@cs.weber.edu> from "Terry Lambert" at Aug 22, 95 12:00:52 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 464 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > > It's a trivial change, even in the current code. > > > > Except for the space issues. > > I'm confused -- you mean name-space issues? No. I shoul have written `space constraints'. Our current boot code is overloaded. (Don't tell me about /boot: ``...even in the current code.'' :) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Aug 22 21:20:55 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id VAA07845 for current-outgoing; Tue, 22 Aug 1995 21:20:55 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id VAA07826 for ; Tue, 22 Aug 1995 21:20:51 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA04772; Wed, 23 Aug 1995 06:20:49 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA13884 for current@freefall.FreeBSD.org; Wed, 23 Aug 1995 06:20:48 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id VAA13344 for current@freefall.FreeBSD.org; Tue, 22 Aug 1995 21:43:08 +0200 From: J Wunsch Message-Id: <199508221943.VAA13344@uriah.heep.sax.de> Subject: Re: Of slices and boot code.. To: current@freefall.FreeBSD.org Date: Tue, 22 Aug 1995 21:43:08 +0200 (MET DST) Reply-To: current@freefall.FreeBSD.org In-Reply-To: <9508221824.AA01010@cs.weber.edu> from "Terry Lambert" at Aug 22, 95 12:24:44 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 357 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > Where is the current devfs code? If it's not currently being hacked, I'd > like to hack on it. It will help in porting by reducing the dependencies > for an MFS. /sys/miscfs/devfs. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Tue Aug 22 22:48:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA12147 for current-outgoing; Tue, 22 Aug 1995 22:48:21 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA12137 for ; Tue, 22 Aug 1995 22:48:13 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA05299; Wed, 23 Aug 1995 15:43:31 +1000 Date: Wed, 23 Aug 1995 15:43:31 +1000 From: Bruce Evans Message-Id: <199508230543.PAA05299@godzilla.zeta.org.au> To: freebsd-current@freefall.FreeBSD.org, jc@irbs.com Subject: Re: CLOCAL and CRTSCTS in -current and -stable Sender: current-owner@FreeBSD.org Precedence: bulk >I upgraded an old 1.1.5.1 system to -stable a few days ago and had >trouble convincing cu to talk to a port that only has TX and RX. >I had to stop cu and turn off crtscts to get cu to output. Input >works OK. Once I understood the problem, I tried the locking/initial >mechanism but -crtscts would not stick. This part of the driver hasn't changed since 1.1.5. >-current from last month cu defaults to: >cflags: cread cs8 -parenb -parodd hupcl clocal -cstopb -crtscts -dsrflow > -dtrflow -mdmbuf >-stable from last week: >cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -dsrflow > -dtrflow -mdmbuf This must be with -current utilities and a -stable kernel (the -stable stty doesn't report -dsrflow). Applications should be compatible, howver. >Has cu changed or have the kernel defaults changed? Is the >locking/initial scheme broken in -stable? No bugs are known. Devices names have changed since 1.1.5, so a 1.1.5 script to set the locks would probably not work now. Bruce From owner-freebsd-current Tue Aug 22 22:50:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA12316 for current-outgoing; Tue, 22 Aug 1995 22:50:12 -0700 Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA12305 for ; Tue, 22 Aug 1995 22:50:10 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id AAA09875 for ; Wed, 23 Aug 1995 00:49:30 -0500 Message-Id: <199508230549.AAA09875@chrome.onramp.net> X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol To: freebsd-current@freebsd.org Subject: make world falling down on 'zic' Reply-To: jdl@chromatic.com Date: Wed, 23 Aug 1995 00:49:30 -0500 From: Jon Loeliger Sender: current-owner@freebsd.org Precedence: bulk I apologize in advance for repeating something that I'm pretty sure just got mentioned a couple days ago. I tried to Netscrape through the mail archives but they appeared to be out of order. Rats. So, my 'make world' came to a screaching halt with: umask 022; cd /usr/src/share/zoneinfo; zic -d /usr/share/zoneinfo -p America/New_York -L /dev/null -y /usr/src/share/zoneinfo/obj/yearistype africa antarctica asia australasia etcetera europe factory northamerica southamerica systemv "europe", line 717: invalid time of day "europe", line 718: invalid time of day "europe", line 719: invalid time of day "europe", line 760: invalid time of day "europe", line 761: invalid time of day "europe", line 762: invalid time of day "europe", line 763: invalid time of day "europe", line 764: invalid time of day "europe", line 765: invalid time of day I'm pretty sure someone mentioned something like this a day or three ago. If they could gently remind those of us with short memories, it'd be greatly appreciated. And, what's the right 'make' to retart this build in place without totally starting over? Is 'make depend all install' good enough? Thanks, jdl From owner-freebsd-current Tue Aug 22 22:52:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA12664 for current-outgoing; Tue, 22 Aug 1995 22:52:11 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id WAA12626 for ; Tue, 22 Aug 1995 22:52:03 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.11/8.6.9) with SMTP id WAA10314 for ; Tue, 22 Aug 1995 22:51:30 -0700 Message-Id: <199508230551.WAA10314@precipice.shockwave.com> To: current@freebsd.org Subject: pedantic paul on compilation warnings Date: Tue, 22 Aug 1995 22:51:29 -0700 From: Paul Traina Sender: current-owner@freebsd.org Precedence: bulk As I was going through my make log listings tonight, looking at errors, I noticed that the number of warnings and problems with code have gone up again. This makes it a serious pain in the ass to determine if you've broken something while playing with system definitions. In other words, there are so many warnings, it's hard to sort the wheat from the chaffe. I've taken a whack at some of the simple obvious mistakes, but there's still quite a bit left to do, especially in the documentation department. A quick summary shows that there are problems still left in the following directories: ===> gnu/usr.bin/as ===> gnu/usr.bin/cc/cc ===> gnu/usr.bin/gdb/gdb ===> usr.bin/tn3270/tn3270 ===> usr.bin/vi/common ===> usr.sbin/amd/amd ===> usr.sbin/xntpd/parse ===> usr.sbin/xntpd/xntpd ===> usr.sbin/xntpd/util ===> lkm/ibcs2 <-- bleah! these should be clean! :-( ===> lkm/linux <-- bleah! these should be clean! :-( ...and most disturbingly, something has either gone very wrong with groff and its macro packages, or we're getting really sloppy in the documentation. Now I realize that most of this stuff came from other places, but if we can't even make our own documentation, we don't look so hot. If I knew anything about ms and me macros, I'd be fixing this stuff myself, but the best I can do is try to replace some of this stuff with Lite-2 originated documents if they're in better shape. If YOU would like to take a stab at these, please do so. ===> share/doc/12.make ===> share/doc/19.curses ===> share/doc/22.rpcgen ===> share/doc/23.rpc ===> share/doc/24.xdr ===> share/doc/25.xdrrfc ===> share/doc/26.rpcrfc ===> share/doc/27.nfsrpc ===> share/doc/title ===> share/doc/12.timed ===> share/doc/04.csh ===> share/doc/10.exref ===> share/doc/11.vitut ===> share/doc/12.vi ===> share/doc/13.viref ===> share/doc/20.meref ===> share/doc/30.rogue ===> share/doc/31.trek ===> share/doc/beyond4.3 ===> share/doc/diskperf ===> share/doc/fsinterface ===> share/doc/kernmalloc ===> share/doc/kerntune ===> share/doc/memfs ===> share/doc/newvm ===> share/doc/nqnfs ===> share/doc/px ===> share/doc/relengr ===> share/doc/sysperf ===> share/doc/title ===> share/doc/contents ===> share/doc/12.make ===> share/doc/18.gprof ===> share/doc/19.curses ===> share/doc/20.ipctut ===> share/doc/21.ipc ===> share/doc/22.rpcgen ===> share/doc/23.rpc ===> share/doc/24.xdr ===> share/doc/25.xdrrfc ===> share/doc/26.rpcrfc ===> share/doc/27.nfsrpc ===> share/doc/title ===> share/doc/01.setup ===> share/doc/02.config ===> share/doc/05.fastfs ===> share/doc/12.timed ===> share/doc/04.csh ===> share/doc/10.exref ===> share/doc/11.vitut ===> share/doc/12.vi ===> share/doc/13.viref ===> share/doc/20.meref ===> share/doc/30.rogue ===> share/doc/31.trek ===> share/doc/diskperf ===> share/doc/fsinterface ===> share/doc/kernmalloc ===> share/doc/kerntune ===> share/doc/memfs ===> share/doc/px ===> share/doc/relengr ===> share/doc/sysperf Here is the full listing of warnings left: ===> gnu/usr.bin/as cc -O -DNON_BROKEN_WORDS -DPIC -I/usr/src/gnu/usr.bin/as -I/usr/src/gnu/usr.bin/as/obj -I/usr/src/gnu/usr.bin/as/config -DOLD_GAS -DSIGTY=void -Derror=as_fatal -DSUB_SEGMENT_ALIGN=4 -DFREEBSD_AOUT -c /usr/src/gnu/usr.bin/as/config/atof-ieee.c /usr/src/gnu/usr.bin/as/config/atof-ieee.c: In function `make_invalid_floating_point_number': /usr/src/gnu/usr.bin/as/config/atof-ieee.c:131: warning: large integer implicitly truncated to unsigned type ===> gnu/usr.bin/cc/cc cc -O -I/usr/src/gnu/usr.bin/cc/cc -I/usr/src/gnu/usr.bin/cc/cc/../include -Dbsd4_4 -DGCC_INCLUDE_DIR=\"FOO\" -DTOOL_INCLUDE_DIR=\"FOO\" -DGPLUSPLUS_INCLUDE_DIR=\"FOO\" -DDEFAULT_TARGET_VERSION=\"2.6.3\" -DDEFAULT_TARGET_MACHINE=\"i386--freebsd\" -DSTANDARD_EXEC_PREFIX=\"/usr/libexec/\" -DSTANDARD_STARTFILE_PREFIX=\"/usr/lib/\" -DHAVE_PUTENV -DGCC_NAME=\"cc\" -DLINK_LIBGCC_SPECIAL_1 -I/usr/src/gnu/usr.bin/cc/cc -I/usr/src/gnu/usr.bin/cc/cc/../include -Dbsd4_4 -DGCC_INCLUDE_DIR=\"FOO\" -DTOOL_INCLUDE_DIR=\"FOO\" -DGPLUSPLUS_INCLUDE_DIR=\"FOO\" -DDEFAULT_TARGET_VERSION=\"2.6.3\" -DDEFAULT_TARGET_MACHINE=\"i386--freebsd\" -DSTANDARD_EXEC_PREFIX=\"/usr/libexec/\" -DSTANDARD_STARTFILE_PREFIX=\"/usr/lib/\" -DHAVE_PUTENV -DGCC_NAME=\"cc\" -DLINK_LIBGCC_SPECIAL_1 -c /usr/src/gnu/usr.bin/cc/cc/gcc.c /usr/src/gnu/usr.bin/cc/cc/gcc.c: In function `pfatal_with_name': /usr/src/gnu/usr.bin/cc/cc/gcc.c:4681: warning: passing arg 2 of `concat' discards `const' from pointer target type /usr/src/gnu/usr.bin/cc/cc/gcc.c: In function `perror_with_name': /usr/src/gnu/usr.bin/cc/cc/gcc.c:4694: warning: passing arg 2 of `concat' discards `const' from pointer target type /usr/src/gnu/usr.bin/cc/cc/gcc.c: In function `perror_exec': /usr/src/gnu/usr.bin/cc/cc/gcc.c:4707: warning: passing arg 2 of `concat' discards `const' from pointer target type ===> gnu/usr.bin/gdb/gdb cc -O -I/usr/src/gnu/usr.bin/gdb/gdb/. -I/usr/include/readline -I/usr/src/gnu/usr.bin/gdb/gdb/../bfd -c c-exp.tab.c In file included from /usr/src/gnu/usr.bin/gdb/gdb/c-exp.y:41: /usr/src/gnu/usr.bin/gdb/gdb/parser-defs.h:111: warning: `struct minimal_symbol' declared inside parameter list /usr/src/gnu/usr.bin/gdb/gdb/parser-defs.h:111: warning: its scope is only this definition or declaration, /usr/src/gnu/usr.bin/gdb/gdb/parser-defs.h:111: warning: which is probably not what you want. cc -O -I/usr/src/gnu/usr.bin/gdb/gdb/. -I/usr/include/readline -I/usr/src/gnu/usr.bin/gdb/gdb/../bfd -c ch-exp.tab.c /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:72: warning: `yyparse' redefined ch-exp.tab.c:10: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:73: warning: `yylex' redefined ch-exp.tab.c:11: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:74: warning: `yyerror' redefined ch-exp.tab.c:12: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:75: warning: `yylval' redefined ch-exp.tab.c:15: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:76: warning: `yychar' redefined ch-exp.tab.c:13: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:77: warning: `yydebug' redefined ch-exp.tab.c:16: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:86: warning: `yyerrflag' redefined ch-exp.tab.c:18: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:87: warning: `yynerrs' redefined ch-exp.tab.c:17: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/gdb/gdb/ch-exp.y:96: warning: `yyval' redefined ch-exp.tab.c:14: warning: this is the location of the previous definition ===> usr.bin/tn3270/tn3270 cc -O -I/usr/src/usr.bin/tn3270/tn3270 -I. -DTERMCAP -DSRCRT -DKLUDGELINEMODE -DUSE_TERMIO -DTN3270 -DTERMCAP -DSRCRT -DKLUDGELINEMODE -DUSE_TERMIO -DTN3270 -c /usr/src/usr.bin/tn3270/tn3270/../sys_curses/termout.c /usr/src/usr.bin/tn3270/tn3270/../sys_curses/termout.c: In function `InitTerminal': /usr/src/usr.bin/tn3270/tn3270/../sys_curses/termout.c:661: warning: comparison is always 0 due to limited range of data type ===> usr.bin/vi/common cc -O -I. -I/usr/src/usr.bin/vi/common -c /usr/src/usr.bin/vi/common/../ex/ex_argv.c /usr/src/usr.bin/vi/common/../ex/ex_argv.c: In function `argv_exp3': /usr/src/usr.bin/vi/common/../ex/ex_argv.c:297: warning: comparison is always 1 due to limited range of data type cc -O -I. -I/usr/src/usr.bin/vi/common -c /usr/src/usr.bin/vi/common/../sex/sex_refresh.c /usr/src/usr.bin/vi/common/../sex/sex_refresh.c: In function `Xvidattr': /usr/src/usr.bin/vi/common/../sex/sex_refresh.c:130: warning: passing arg 3 of `tputs' from incompatible pointer type /usr/src/usr.bin/vi/common/../sex/sex_refresh.c:133: warning: passing arg 3 of `tputs' from incompatible pointer type cc -O -I. -I/usr/src/usr.bin/vi/common -c /usr/src/usr.bin/vi/common/../svi/svi_refresh.c /usr/src/usr.bin/vi/common/../svi/svi_refresh.c: In function `svi_modeline': /usr/src/usr.bin/vi/common/../svi/svi_refresh.c:755: warning: comparison is always 1 due to limited range of data type /usr/src/usr.bin/vi/common/../svi/svi_refresh.c:756: warning: comparison is always 1 due to limited range of data type cc -O -I. -I/usr/src/usr.bin/vi/common -c /usr/src/usr.bin/vi/common/../svi/svi_util.c /usr/src/usr.bin/vi/common/../svi/svi_util.c: In function `svi_bell': /usr/src/usr.bin/vi/common/../svi/svi_util.c:78: warning: passing arg 3 of `tputs' from incompatible pointer type /usr/src/usr.bin/vi/common/../svi/svi_util.c: In function `svi_keypad': /usr/src/usr.bin/vi/common/../svi/svi_util.c:166: warning: passing arg 3 of `tputs' from incompatible pointer type /usr/src/usr.bin/vi/common/../svi/svi_util.c: In function `svi_suspend': /usr/src/usr.bin/vi/common/../svi/svi_util.c:251: warning: passing arg 3 of `tputs' from incompatible pointer type /usr/src/usr.bin/vi/common/../svi/svi_util.c:254: warning: passing arg 3 of `tputs' from incompatible pointer type /usr/src/usr.bin/vi/common/../svi/svi_util.c:296: warning: passing arg 3 of `tputs' from incompatible pointer type /usr/src/usr.bin/vi/common/../svi/svi_util.c:299: warning: passing arg 3 of `tputs' from incompatible pointer type cc -O -I. -I/usr/src/usr.bin/vi/common -c /usr/src/usr.bin/vi/common/../xaw/xaw_screen.c ===> usr.sbin/amd/amd cc -O -I/usr/src/usr.sbin/amd/amd/../rpcx -I/usr/src/usr.sbin/amd/amd/../config -I/usr/src/usr.sbin/amd/amd/../include -DARCH_REP=\"i386\" -DOS_REP=\"bsd44\" -DOS_HDR=\"os-bsd44.h\" -DHAS_FILE_MAPS -DHAS_PASSWD_MAPS -DHAS_UNION_MAPS -DHAS_REGEXP -c /usr/src/usr.sbin/amd/amd/afs_ops.c /usr/src/usr.sbin/amd/amd/afs_ops.c: In function `mount_toplvl': /usr/src/usr.sbin/amd/amd/afs_ops.c:146: warning: assignment from incompatible pointer type cc -O -I/usr/src/usr.sbin/amd/amd/../rpcx -I/usr/src/usr.sbin/amd/amd/../config -I/usr/src/usr.sbin/amd/amd/../include -DARCH_REP=\"i386\" -DOS_REP=\"bsd44\" -DOS_HDR=\"os-bsd44.h\" -DHAS_FILE_MAPS -DHAS_PASSWD_MAPS -DHAS_UNION_MAPS -DHAS_REGEXP -c /usr/src/usr.sbin/amd/amd/misc_rpc.c /usr/src/usr.sbin/amd/amd/misc_rpc.c: In function `make_rpc_packet': /usr/src/usr.sbin/amd/amd/misc_rpc.c:137: warning: passing arg 2 of `xdr_enum' from incompatible pointer type cc -O -I/usr/src/usr.sbin/amd/amd/../rpcx -I/usr/src/usr.sbin/amd/amd/../config -I/usr/src/usr.sbin/amd/amd/../include -DARCH_REP=\"i386\" -DOS_REP=\"bsd44\" -DOS_HDR=\"os-bsd44.h\" -DHAS_FILE_MAPS -DHAS_PASSWD_MAPS -DHAS_UNION_MAPS -DHAS_REGEXP -c /usr/src/usr.sbin/amd/amd/nfs_ops.c /usr/src/usr.sbin/amd/amd/nfs_ops.c: In function `mount_nfs_fh': /usr/src/usr.sbin/amd/amd/nfs_ops.c:531: warning: assignment from incompatible pointer type cc -O -I/usr/src/usr.sbin/amd/amd/../rpcx -I/usr/src/usr.sbin/amd/amd/../config -I/usr/src/usr.sbin/amd/amd/../include -DARCH_REP=\"i386\" -DOS_REP=\"bsd44\" -DOS_HDR=\"os-bsd44.h\" -DHAS_FILE_MAPS -DHAS_PASSWD_MAPS -DHAS_UNION_MAPS -DHAS_REGEXP -c /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_fattr': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:113: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_attrstat': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:223: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_diropres': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:295: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_readlinkres': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:316: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_readres': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:377: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_readdirres': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:569: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c: In function `xdr_statfsres': /usr/src/usr.sbin/amd/amd/../rpcx/nfs_prot_xdr.c:616: warning: passing arg 2 of `xdr_enum' from incompatible pointer type /usr/src/usr.sbin/amd/amq/../rpcx/amq_xdr.c: In function `xdr_time_type': /usr/src/usr.sbin/amd/amq/../rpcx/amq_xdr.c:67: warning: passing arg 2 of `xdr_long' from incompatible pointer type cc -O -I/usr/src/usr.sbin/amd/amq/../include -I/usr/src/usr.sbin/amd/amq/../rpcx -I/usr/src/usr.sbin/amd/amq/../config -DARCH_REP=\"i386\" -DOS_REP=\"bsd44\" -DOS_HDR=\"os-bsd44.h\" -c /usr/src/usr.sbin/amd/amq/../amd/misc_rpc.c /usr/src/usr.sbin/amd/amq/../amd/misc_rpc.c: In function `make_rpc_packet': /usr/src/usr.sbin/amd/amq/../amd/misc_rpc.c:137: warning: passing arg 2 of `xdr_enum' from incompatible pointer type ===> usr.sbin/xntpd/parse cc -O -I/usr/src/usr.sbin/xntpd/parse/../include -DCLOCK_SCHMID -DCLOCK_DCF7000 -DCLOCK_MEINBERG -DCLOCK_RAWDCF -DCLOCK_TRIMSV6 -DSYS_FREEBSD -DSYS_44BSD -DREFCLOCK -DPARSE -DMD5 -DDES -DLOCAL_CLOCK -DPST -DWWVB -DAS2201 -DGOES -DGPSTM -DOMEGA -DLEITCH -DTRAK -DACTS -DATOM -DDATUM -DHEATH -DMSFEES -DMX4200 -DNMEA -DBOEDER -c /usr/src/usr.sbin/xntpd/parse/clk_trimble.c -o clk_trimble.o /usr/src/usr.sbin/xntpd/parse/clk_trimble.c:45: warning: initialization from incompatible pointer type /usr/src/usr.sbin/xntpd/parse/clk_trimble.c:46: warning: initialization from incompatible pointer type /usr/src/usr.sbin/xntpd/parse/clk_trimble.c:50: warning: initialization makes pointer from integer without a cast /usr/src/usr.sbin/xntpd/parse/clk_trimble.c:52: warning: braces around scalar initializer for `clock_trimsv6.flags' /usr/src/usr.sbin/xntpd/parse/clk_trimble.c:52: warning: excess elements in scalar initializer after `clock_trimsv6.flags' ===> usr.sbin/xntpd/xntpd cc -O -I/usr/src/usr.sbin/xntpd/xntpd/../include -DSYS_FREEBSD -DSYS_44BSD -DREFCLOCK -DPARSE -DMD5 -DDES -DLOCAL_CLOCK -DPST -DWWVB -DAS2201 -DGOES -DGPSTM -DOMEGA -DLEITCH -DTRAK -DACTS -DATOM -DDATUM -DHEATH -DMSFEES -DMX4200 -DNMEA -DBOEDER -DSYS_FREEBSD -DSYS_44BSD -DREFCLOCK -DPARSE -DMD5 -DDES -DLOCAL_CLOCK -DPST -DWWVB -DAS2201 -DGOES -DGPSTM -DOMEGA -DLEITCH -DTRAK -DACTS -DATOM -DDATUM -DHEATH -DMSFEES -DMX4200 -DNMEA -DBOEDER -c /usr/src/usr.sbin/xntpd/xntpd/ntp_loopfilter.c /usr/src/usr.sbin/xntpd/xntpd/ntp_loopfilter.c: In function `loop_config': /usr/src/usr.sbin/xntpd/xntpd/ntp_loopfilter.c:678: warning: assignment from incompatible pointer type ===> usr.sbin/xntpd/util cc -O -I/usr/src/usr.sbin/xntpd/util/../include -DSYS_FREEBSD -DSYS_44BSD -DREFCLOCK -DPARSE -DMD5 -DDES -DLOCAL_CLOCK -DPST -DWWVB -DAS2201 -DGOES -DGPSTM -DOMEGA -DLEITCH -DTRAK -DACTS -DATOM -DDATUM -DHEATH -DMSFEES -DMX4200 -DNMEA -DBOEDER -DSYS_FREEBSD -DSYS_44BSD -DREFCLOCK -DPARSE -DMD5 -DDES -DLOCAL_CLOCK -DPST -DWWVB -DAS2201 -DGOES -DGPSTM -DOMEGA -DLEITCH -DTRAK -DACTS -DATOM -DDATUM -DHEATH -DMSFEES -DMX4200 -DNMEA -DBOEDER -c /usr/src/usr.sbin/xntpd/util/tickadj.c /usr/src/usr.sbin/xntpd/util/tickadj.c: In function `getoffsets': /usr/src/usr.sbin/xntpd/util/tickadj.c:448: warning: assignment makes pointer from integer without a cast ===> lkm/ibcs2 cc -O -DLKM -I. -DCOMPAT_IBCS2 -DKERNEL -I/usr/src/lkm/ibcs2/../../sys -W -Wcomment -Wredundant-decls -c /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_file.c /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_file.c: In function `ibcs2_close': /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_file.c:66: warning: passing arg 2 of `close' from incompatible pointer type cc -O -DLKM -I. -DCOMPAT_IBCS2 -DKERNEL -I/usr/src/lkm/ibcs2/../../sys -W -Wcomment -Wredundant-decls -c /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_ioctl.c /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_ioctl.c: In function `ibcs2_ioctl': /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_ioctl.c:550: warning: `error' might be used uninitialized in this function cc -O -DLKM -I. -DCOMPAT_IBCS2 -DKERNEL -I/usr/src/lkm/ibcs2/../../sys -W -Wcomment -Wredundant-decls -c /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c: In function `ibcs2_exec': /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c:220: warning: passing arg 2 of `execve' from incompatible pointer type /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c: In function `ibcs2_exece': /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c:234: warning: passing arg 2 of `execve' from incompatible pointer type /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c: In function `ibcs2_wait': /usr/src/lkm/ibcs2/../../sys/i386/ibcs2/ibcs2_misc.c:955: warning: passing arg 2 of `wait1' from incompatible pointer type ===> lkm/linux cc -O -DLKM -I. -DCOMPAT_LINUX -DSYSVSHM -DKERNEL -I/usr/src/lkm/linux/../../sys -W -Wcomment -Wredundant-decls -c /usr/src/lkm/linux/../../sys/i386/linux/linux_sysent.c /usr/src/lkm/linux/../../sys/i386/linux/linux_sysent.c:51: warning: redundant redeclaration of `close' in same scope /usr/src/lkm/linux/../../sys/sys/systm.h:210: warning: previous declaration of `close' /usr/src/lkm/linux/../../sys/i386/linux/linux_sysent.c:57: warning: redundant redeclaration of `execve' in same scope /usr/src/lkm/linux/../../sys/sys/systm.h:216: warning: previous declaration of `execve' /usr/src/lkm/linux/../../sys/i386/linux/linux_sysent.c:156: warning: redundant redeclaration of `sync' in same scope /usr/src/lkm/linux/../../sys/sys/systm.h:224: warning: previous declaration of `sync' ===> share/doc/12.make (cd /usr/src/share/doc/psd/12.make/../../../../usr.bin/make/PSD.doc; groff -Tps -ms -o1- tutorial.ms) | gzip -c > paper.ps.gz grops::562: unrecognised drawing command `s' grops::594: unrecognised drawing command `s' tutorial.ms:172: warning: `Ix' not defined grops::3327: unrecognised drawing command `s' grops::3359: unrecognised drawing command `s' grops::4583: unrecognised drawing command `s' grops::4615: unrecognised drawing command `s' grops::5995: unrecognised drawing command `s' grops::6027: unrecognised drawing command `s' grops::6312: unrecognised drawing command `s' grops::6344: unrecognised drawing command `s' grops::7622: unrecognised drawing command `s' grops::7654: unrecognised drawing command `s' tutorial.ms:741: warning: `Rd' not defined grops::11227: unrecognised drawing command `s' grops::11260: unrecognised drawing command `s' tutorial.ms:1085: warning: `Rm' not defined ===> share/doc/19.curses for a in Master appen.A c_macros ex1.gr ex2.gr fns.doc intro.0 intro.1 intro.2.tbl intro.3 intro.4 intro.5 intro.6 macros twinkle1.gr; do test -e $a || ln -s /usr/src/share/doc/psd/19.curses/../../../../lib/libcurses/PSD.doc/$a .; done (cd /usr/src/share/doc/psd/19.curses/obj; groff -Tps -me -o1- Master) | gzip -c > paper.ps.gz /usr/src/share/doc/psd/19.curses/../../../../lib/libcurses/PSD.doc/intro.2:76: environment stack underflow ===> share/doc/22.rpcgen (cd /usr/src/share/doc/psd/22.rpcgen/../../../../lib/libc/rpc/PSD.doc; groff -Tps -t -ms -o1- rpcgen.ms) | gzip -c > paper.ps.gz rpcgen.ms:13: warning: missing closing delimiter rpcgen \fIrpcgen\fP ... 1 RPC \fIrpcgen\fP ... 1 rpcgen local procedures \fIrpcgen\fP ... 1 rpcgen remote procedures \fIrpcgen\fP ... 1 client handle, used by rpcgen client handle, used by \fIrpcgen\fP ... 6 RPC generating XDR routines ... 7 debugging with rpcgen debugging with \fIrpcgen\fP ... 10 rpcgen C-preprocessor \fIrpcgen\fP ... 11 rpcgen.ms:778: warning: can't find font `L' rpcgen other operations \fIrpcgen\fP ... 11 rpcgen timeout changes \fIrpcgen\fP ... 11 broadcast RPC ... 12 rpcgen broadcast RPC \fIrpcgen\fP ... 12 RPCL ... 13 rpcgen RPC Language \fIrpcgen\fP ... 13 rpcgen definitions \fIrpcgen\fP ... 13 rpcgen structures \fIrpcgen\fP ... 13 rpcgen unions \fIrpcgen\fP ... 13 rpcgen enumerations \fIrpcgen\fP ... 14 rpcgen typedef \fIrpcgen\fP ... 15 rpcgen constants \fIrpcgen\fP ... 15 rpcgen programs \fIrpcgen\fP ... 15 rpcgen declarations \fIrpcgen\fP ... 16 rpcgen special cases \fIrpcgen\fP ... 17 ===> share/doc/23.rpc (cd /usr/src/share/doc/psd/23.rpc/../../../../lib/libc/rpc/PSD.doc; groff -Tps -t -p -ms -o1- rpc.prog.ms) | gzip -c > paper.ps.gz Network Programming ... rpc.prog.ms:8: warning: number register `PN' not defined 0 RPC Programming Guide ... 1 rpcgen \fIrpcgen\fP ... 1 layers of RPC ... 1 RPC layers ... 1 RPC The Highest Layer ... 1 RPC The Middle Layer ... 1 RPC The Lowest Layer ... 1 RPC paradigm ... 1 highest layer of RPC ... 2 RPC highest layer ... 2 RPC Services ... 3 rpc.prog.ms:226: warning: missing name rpc.prog.ms:234: warning: can't find font `L' rpc.prog.ms:233: warning: space required between `sp' and argument intermediate layer of RPC ... 3 RPC intermediate layer ... 3 enum clnt_stat (in RPC programming) \fIenum clnt_stat\fP (in RPC programming) ... 4 UDP 8K warning ... 5 program number assignment ... 6 assigning program numbers ... 6 RPC administration ... 6 administration of RPC ... 6 rpc.prog.ms:526: warning: space required between `sp' and argument arbitrary data types ... 7 RPC built-in routines ... 7 lowest layer of RPC ... 9 RPC lowest layer ... 9 RPC server side ... 10 memory allocation with XDR ... 12 XDR memory allocation ... 12 RPC calling side ... 13 RPC miscellaneous features ... 15 miscellaneous RPC features ... 15 RPC select() RPC \fIselect()\fP ... 15 select() \fIselect()\fP on the server side ... 15 select() \fIselect()\fP ... 16 broadcast RPC ... 16 RPC broadcast ... 16 broadcast RPC synopsis ... 16 RPC broadcast synopsis ... 16 batching ... 17 RPC batching ... 17 authentication ... 21 RPC authentication ... 21 UNIX Authentication ... 21 RPC guarantees ... 22 RPC DES ... 24 RPC authentication ... 24 rpc.prog.ms:1942: warning: `/"' not defined rpc.prog.ms:2064: warning: number register `"' not defined inetd using \fIinetd\fP ... 26 versions ... 26 RPC versions ... 26 TCP ... 27 RPC callback procedures ... 31 ===> share/doc/24.xdr (cd /usr/src/share/doc/psd/24.xdr/../../../../lib/libc/rpc/PSD.doc; groff -Tps -e -ms -o1- xdr.nts.ms) | gzip -c > paper.ps.gz xdr.nts.ms:16: warning: missing closing delimiter XDR Sun technical notes ... 1 XDR system routines ... 1 XDR justification ... 1 xdr.nts.ms:85: warning: space required between `sp' and argument xdr.nts.ms:89: warning: space required between `sp' and argument xdr.nts.ms:105: warning: space required between `sp' and argument xdr.nts.ms:109: warning: space required between `sp' and argument xdr.nts.ms:185: warning: space required between `sp' and argument xdr.nts.ms:190: warning: space required between `sp' and argument xdr.nts.ms:208: warning: space required between `sp' and argument xdr.nts.ms:213: warning: space required between `sp' and argument XDR portable data ... 3 XDR canonical standard ... 4 XDR library ... 4 xdrstdio_create() \fIxdrstdio_create()\fP ... 4 xdr_long() \fIxdr_long()\fP ... 5 library primitives for XDR ... 6 XDR library primitives ... 6 XDR library number filters ... 6 xdr.nts.ms:506: warning: space required between `sp' and argument xdr.nts.ms:510: warning: space required between `sp' and argument xdr.nts.ms:514: warning: space required between `sp' and argument xdr.nts.ms:518: warning: space required between `sp' and argument xdr.nts.ms:522: warning: space required between `sp' and argument xdr.nts.ms:526: warning: space required between `sp' and argument xdr.nts.ms:530: warning: space required between `sp' and argument XDR library floating point filters ... 6 xdr.nts.ms:556: warning: space required between `sp' and argument XDR library enumeration filters ... 7 xdr.nts.ms:596: warning: space required between `sp' and argument xdr.nts.ms:598: warning: space required between `sp' and argument xdr.nts.ms:602: warning: space required between `sp' and argument XDR library no data ... 7 XDR library constructed data type filters ... 7 XDR library strings ... 7 xdr_string() \fIxdr_string()\fP ... 7 xdr_string() \fIxdr_string()\fP ... 8 XDR library byte arrays ... 8 xdr_bytes() \fIxdr_bytes()\fP ... 8 XDR library arrays ... 8 xdr_array() \fIxdr_array()\fP ... 8 xdr_element() \fIxdr_element()\fP ... 9 xdr.nts.ms:875: warning: space required between `sp' and argument xdr.nts.ms:904: warning: space required between `sp' and argument XDR library opaque data ... 11 xdr_opaque() \fIxdr_opaque()\fP ... 11 XDR library fixed sized arrays ... 11 xdr.nts.ms:1025: warning: space required between `sp' and argument xdr.nts.ms:1031: warning: space required between `sp' and argument xdr.nts.ms:1038: warning: space required between `sp' and argument XDR library discriminated unions ... 12 xdr.nts.ms:1064: warning: space required between `sp' and argument xdr.nts.ms:1115: warning: space required between `sp' and argument xdr.nts.ms:1137: warning: space required between `sp' and argument XDR library pointers ... 13 xdr_reference() \fIxdr_reference()\fP ... 13 pointer semantics and XDR ... 13 xdr_reference() \fIxdr_reference()\fP ... 13 XDR non-filter primitives ... 14 xdr.nts.ms:1329: warning: space required between `sp' and argument xdr.nts.ms:1333: warning: space required between `sp' and argument xdr_getpos() \fIxdr_getpos()\fP ... 14 xdr_setpos() \fIxdr_setpos()\fP ... 14 xdr_destroy() \fIxdr_destroy()\fP ... 14 XDR operation directions ... 14 direction of XDR operations ... 14 XDR stream access ... 14 XDR standard I/O streams ... 14 xdrstdio_create() \fIxdrstdio_create()\fP ... 14 xdr.nts.ms:1411: warning: space required between `sp' and argument XDR memory streams ... 15 xdr.nts.ms:1437: warning: space required between `sp' and argument xdrmem_create() \fIxdrmem_create()\fP ... 15 XDR record (TCP/IP) streams ... 15 xdr.nts.ms:1475: warning: space required between `sp' and argument xdr.nts.ms:1554: warning: space required between `sp' and argument xdr.nts.ms:1558: warning: space required between `sp' and argument xdrrec_endofrecord() \fIxdrrec_endofrecord()\fP ... 16 xdrrec_skiprecord() \fIxdrrec_skiprecord()\fP ... 16 xdrrec_eof() \fIxdrrec_eof()\fP ... 16 XDR stream implementation ... 16 stream implementation in XDR ... 16 XDR object ... 16 xdr.nts.ms:1608: warning: space required between `sp' and argument XDR advanced topics ... 17 XDR linked lists ... 17 xdr.nts.ms:1751: warning: space required between `sp' and argument ===> share/doc/25.xdrrfc (cd /usr/src/share/doc/psd/25.xdrrfc/../../../../lib/libc/rpc/PSD.doc; groff -Tps -t -ms -o1- xdr.rfc.ms) | gzip -c > paper.ps.gz External Data Representation ... xdr.rfc.ms:13: warning: number register `PN' not defined 0 xdr.rfc.ms:14: warning: missing closing delimiter XDR RFC ... 1 XDR protocol specification ... 1 XDR RFC status ... 1 XDR basic block size ... 1 XDR block size ... 1 XDR data types ... 1 XDR data types ... 1 XDR integer ... 2 XDR unsigned integer ... 2 XDR integer, unsigned ... 2 XDR enumeration ... 2 XDR boolean ... 2 XDR hyper integer ... 2 XDR integer, hyper ... 2 XDR integer, floating point ... 3 XDR floating-point integer ... 3 XDR integer, double-precision floating point ... 3 XDR double-precision floating-point integer ... 3 XDR fixed-length opaque data ... 4 XDR opaque data, fixed length ... 4 XDR variable-length opaque data ... 4 XDR opaque data, variable length ... 4 XDR string ... 5 XDR fixed-length array ... 5 XDR array, fixed length ... 5 XDR variable-length array ... 6 XDR array, variable length ... 6 XDR structure ... 6 XDR discriminated union ... 6 XDR union discriminated ... 6 XDR void ... 7 XDR constant ... 7 XDR typedef ... 7 XDR optional data ... 8 XDR data, optional ... 8 XDR futures ... 9 XDR language ... 9 XDR byte order ... 9 XDR variable-length data ... 10 XDR language ... 10 XDR language notation ... 10 XDR language syntax ... 11 XDR language syntax ... 12 xdr.rfc.ms:1031: warning: can't find font `L' ===> share/doc/26.rpcrfc (cd /usr/src/share/doc/psd/26.rpcrfc/../../../../lib/libc/rpc/PSD.doc; groff -Tps -t -ms -o1- rpc.rfc.ms) | gzip -c > paper.ps.gz rpc.rfc.ms:13: warning: missing closing delimiter rpc.rfc.ms:295: warning: can't find font `L' ===> share/doc/27.nfsrpc (cd /usr/src/share/doc/psd/27.nfsrpc/../../../../lib/libc/rpc/PSD.doc; groff -Tps -t -ms -o1- nfs.rfc.ms) | gzip -c > paper.ps.gz nfs.rfc.ms:13: warning: missing closing delimiter NFS ... 1 Network File System ... 1 NFS version-2 protocol specification ... 1 Network File System version-2 protocol specification ... 1 NFS introduction ... 1 Remote Procedure Call ... 1 External Data Representation ... 1 stateless servers ... 1 servers stateless ... 1 NFS protocol definition ... 1 NFS protocol ... 1 filesystem model ... 2 NFS RPC information ... 2 XDR structure sizes ... 2 NFS data types ... 2 NFS basic data types ... 2 NFS data types stat \fIstat\fP ... 2 NFS data types ftype \fIftype\fP ... 4 NFS data types fhandle \fIfhandle\fP ... 4 NFS data types timeval \fItimeval\fP ... 4 NFS data types fattr \fIfattr\fP ... 4 nfs.rfc.ms:395: warning: can't find font `L' NFS data types sattr \fIsattr\fP ... 6 NFS data types filename \fIfilename\fP ... 6 NFS data types path \fIpath\fP ... 6 NFS data types attrstat \fIattrstat\fP ... 6 NFS data types diropargs \fIdiropargs\fP ... 6 NFS data types diropres \fIdiropres\fP ... 7 NFS server procedures ... 7 NFS server procedures NFSPROC_NULL() \fINFSPROC_NULL()\fP ... 7 NFS server procedures NFSPROC_GETATTR() \fINFSPROC_GETATTR()\fP ... 8 NFS server procedures NFSPROC_SETATTR() \fINFSPROC_SETATTR()\fP ... 8 NFS server procedures NFSPROC_ROOT \fINFSPROC_ROOT\fP ... 8 NFS server procedures NFSPROC_LOOKUP() \fINFSPROC_LOOKUP()\fP ... 8 NFS server procedures NFSPROC_READLINK() \fINFSPROC_READLINK()\fP ... 8 NFS server procedures NFSPROC_READ \fINFSPROC_READ\fP ... 9 NFS server procedures NFSPROC_WRITECACHE() \fINFSPROC_WRITECACHE()\fP ... 9 NFS server procedures NFSPROC_WRITE() \fINFSPROC_WRITE()\fP ... 9 NFS server procedures NFSPROC_CREATE() \fINFSPROC_CREATE()\fP ... 10 NFS server procedures NFSPROC_REMOVE() \fINFSPROC_REMOVE()\fP ... 10 NFS server procedures NFSPROC_RENAME() \fINFSPROC_RENAME()\fP ... 10 NFS server procedures NFSPROC_LINK() \fINFSPROC_LINK()\fP ... 11 NFS server procedures NFSPROC_SYMLINK() \fINFSPROC_SYMLINK()\fP ... 11 NFS server procedures NFSPROC_MKDIR() \fINFSPROC_MKDIR()\fP ... 11 NFS server procedures NFSPROC_RMDIR() \fINFSPROC_RMDIR()\fP ... 11 NFS server procedures NFSPROC_READDIR() \fINFSPROC_READDIR()\fP ... 12 NFS server procedures NFSPROC_STATFS() \fINFSPROC_STATFS()\fP ... 12 NFS implementation ... 13 NFS server/client relationship ... 13 NFS pathname interpretation ... 14 NFS permission issues ... 14 NFS setting RPC parameters ... 14 mount protocol ... 14 mount protocol introduction ... 14 mount protocol RPC information ... 15 mount protocol XDR structure sizes ... 15 mount protocol basic data types ... 15 mount data types ... 15 mount data types fhandle \fIfhandle\fP ... 15 mount data types fhstatus \fIfhstatus\fP ... 15 mount data types dirpath \fIdirpath\fP ... 16 mount data types name \fIname\fP ... 16 mount server procedures ... 16 mount server procedures MNTPROC_NULL() \fIMNTPROC_NULL()\fP ... 16 mount server procedures MNTPROC_MNT() \fIMNTPROC_MNT()\fP ... 16 mount server procedures MNTPROC_DUMP() \fIMNTPROC_DUMP()\fP ... 17 mount server procedures MNTPROC_UMNT() \fIMNTPROC_UMNT()\fP ... 17 mount server procedures MNTPROC_UMNTALL() \fIMNTPROC_UMNTALL()\fP ... 17 mount server procedures MNTPROC_EXPORT() \fIMNTPROC_EXPORT()\fP ... 17 ===> share/doc/title (cd /usr/src/share/doc/smm/title; groff -Tps -o1- /usr/src/share/doc/smm/title/Title) | gzip -c > Title.ps.gz /usr/src/share/doc/smm/title/Title:199: can't open `/usr/src/share/man/man0/toc8': No such file or directory ===> share/doc/12.timed (cd /usr/src/share/doc/smm/12.timed/../../../../usr.sbin/timed/SMM.doc/timed; groff -Tps -t -s -ms -o1- timed.ms) | gzip -c > paper.ps.gz :239: macro error: automatically terminating display :251: macro error: DE without DS, ID, CD, LD or BD :308: macro error: automatically terminating display :317: macro error: DE without DS, ID, CD, LD or BD :374: macro error: automatically terminating display :382: macro error: DE without DS, ID, CD, LD or BD :439: macro error: automatically terminating display :446: macro error: DE without DS, ID, CD, LD or BD :503: macro error: automatically terminating display :516: macro error: DE without DS, ID, CD, LD or BD :573: macro error: automatically terminating display :581: macro error: DE without DS, ID, CD, LD or BD :638: macro error: automatically terminating display :646: macro error: DE without DS, ID, CD, LD or BD :703: macro error: automatically terminating display :711: macro error: DE without DS, ID, CD, LD or BD :768: macro error: automatically terminating display :777: macro error: DE without DS, ID, CD, LD or BD :834: macro error: automatically terminating display :843: macro error: DE without DS, ID, CD, LD or BD :900: macro error: automatically terminating display :907: macro error: DE without DS, ID, CD, LD or BD :964: macro error: automatically terminating display :971: macro error: DE without DS, ID, CD, LD or BD :1028: macro error: automatically terminating display :1039: macro error: DE without DS, ID, CD, LD or BD :1096: macro error: automatically terminating display :1105: macro error: DE without DS, ID, CD, LD or BD :1162: macro error: automatically terminating display :1169: macro error: DE without DS, ID, CD, LD or BD :1226: macro error: automatically terminating display :1236: macro error: DE without DS, ID, CD, LD or BD :1293: macro error: automatically terminating display :1301: macro error: DE without DS, ID, CD, LD or BD :1358: macro error: automatically terminating display :1366: macro error: DE without DS, ID, CD, LD or BD :1423: macro error: automatically terminating display :1430: macro error: DE without DS, ID, CD, LD or BD :1487: macro error: automatically terminating display :1496: macro error: DE without DS, ID, CD, LD or BD :1553: macro error: automatically terminating display :1561: macro error: DE without DS, ID, CD, LD or BD :1620: macro error: automatically terminating display :1628: macro error: DE without DS, ID, CD, LD or BD ===> share/doc/04.csh (cd /usr/src/share/doc/usd/04.csh/../../../../bin/csh/USD.doc; groff -Tps -ms -o1- tabs csh.1 csh.2 csh.3 csh.4 /usr/src/share/doc/usd/04.csh/../../../../bin/csh/USD.doc/csh.a csh.g) | gzip -c > paper.ps.gz /usr/src/share/doc/usd/04.csh/../../../../bin/csh/USD.doc/csh.a:60: warning: `1.6' not defined ===> share/doc/10.exref (cd /usr/src/share/doc/usd/10.exref/../../../../usr.bin/vi/USD.doc/exref; groff -Tps -t -ms -o1- ex.rm) | gzip -c > paper.ps.gz ex.rm:632: warning: number register `)P' not defined (cd /usr/src/share/doc/usd/10.exref/../../../../usr.bin/vi/USD.doc/exref; groff -Tps -t -ms -o1- ex.summary) | gzip -c > summary.ps.gz ex.summary:58: warning: missing number tbl:ex.summary:405: excess data entry `\^' discarded tbl:ex.summary:416: excess data entry `\^' discarded ex.summary:418: warning: `LF' not defined ex.summary:418: warning: `CF' not defined ex.summary:418: warning: `RF' not defined ===> share/doc/11.vitut (cd /usr/src/share/doc/usd/11.vitut/../../../../usr.bin/vi/USD.doc/edit; groff -Tps -t -ms -o1- edittut.ms) | gzip -c > paper.ps.gz edittut.ms:92: warning: escape character ignored before `4' edittut.ms:95: warning: escape character ignored before `4' edittut.ms:98: warning: escape character ignored before `5' edittut.ms:104: warning: escape character ignored before `7' tbl:edittut.ms:1038: `.' not last character on line tbl:edittut.ms:1038: giving up on this table ===> share/doc/12.vi (cd /usr/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -Tps -t -ms -o1- vi.in vi.chars) | gzip -c > paper.ps.gz vi.in:1490: bad font number tbl:vi.in:1839: unrecognised format `b' tbl:vi.in:1839: giving up on this table vi.in:1813: warning: escape character ignored before `+' vi.chars:35: warning: `.pn' not defined (cd /usr/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -Tps -t -ms -o1- vi.summary) | gzip -c > summary.ps.gz vi.summary:76: warning: number register `1T' not defined vi.summary:437: warning: escape character ignored before `=' vi.summary:437: warning: escape character ignored before `=' (cd /usr/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -Tps -t -ms -o1- vi.apwh.ms) | gzip -c > viapwh.ps.gz vi.apwh.ms:40: warning: `CB' not defined vi.apwh.ms:86: warning: `VL' not defined vi.apwh.ms:107: warning: `LE' not defined ===> share/doc/13.viref # Build index.so, side-effect of building the paper. (cd /usr/src/share/doc/usd/13.viref/../../../../usr.bin/vi/USD.doc/vi.ref; soelim vi.ref) | tbl | groff -Tps -t -s -me -o1- > /dev/null tbl::1385: `.' not last character on line tbl::1385: giving up on this table index.so: No such file or directory index.so: No such file or directory :7565: can't open `index.so': No such file or directory sed -e 's/MINUSSIGN/\\-/' -e 's/DOUBLEQUOTE/""/' -e "s/SQUOTE/'/" -e 's/ /__SPACE/g' < index | sort -u '-t ' +0 -1 +1n | awk -f /usr/src/share/doc/usd/13.viref/../../../../usr.bin/vi/USD.doc/vi.ref/merge.awk | sed -e 's/__SPACE/ /g' > index.so rm -f index (cd /usr/src/share/doc/usd/13.viref/../../../../usr.bin/vi/USD.doc/vi.ref; groff -Tps -t -s -me -o1- vi.ref /usr/src/share/doc/usd/13.viref/obj/index.so) | gzip -c > paper.ps.gz index.so: No such file or directory :7140: can't open `index.so': No such file or directory ===> share/doc/20.meref (cd /usr/src/share/doc/usd/20.meref; groff -Tps -me -o1- /usr/src/share/doc/usd/20.meref/ref.me) | gzip -c > paper.ps.gz /usr/src/share/doc/usd/20.meref/ref.me:1953: a space character is not allowed in an escape name ===> share/doc/30.rogue (cd /usr/src/share/doc/usd/30.rogue/../../../../games/rogue/USD.doc; groff -Tps -t -me -o1- rogue.me) | gzip -c > paper.ps.gz ===> share/doc/31.trek (cd /usr/src/share/doc/usd/31.trek/../../../../games/trek/USD.doc; groff -Tps -t -me -o1- trek.me) | gzip -c > paper.ps.gz tbl:trek.me:436: column separation specified for last column tbl:trek.me:436: column separation specified for last column tbl:trek.me:445: column separation specified for last column tbl:trek.me:445: column separation specified for last column trek.me:314: environment stack underflow ===> share/doc/beyond4.3 (cd /usr/src/share/doc/papers/beyond4.3; groff -Tps -t -ms -o1- /usr/src/share/doc/papers/beyond4.3/beyond43.ms) | gzip -c > beyond43.ps.gz ===> share/doc/diskperf (cd /usr/src/share/doc/papers/diskperf; groff -Tps -t -ms -o1- /usr/src/share/doc/papers/diskperf/abs.ms /usr/src/share/doc/papers/diskperf/motivation.ms /usr/src/share/doc/papers/diskperf/equip.ms /usr/src/share/doc/papers/diskperf/methodology.ms /usr/src/share/doc/papers/diskperf/tests.ms /usr/src/share/doc/papers/diskperf/results.ms /usr/src/share/doc/papers/diskperf/conclusions.ms /usr/src/share/doc/papers/diskperf/appendix.ms) | gzip -c > diskperf.ps.gz ===> share/doc/fsinterface (cd /usr/src/share/doc/papers/fsinterface; groff -Tps -t -ms -o1- /usr/src/share/doc/papers/fsinterface/fsinterface.ms) | gzip -c > fsinterface.ps.gz /usr/src/share/doc/papers/fsinterface/fsinterface.ms:34: warning: number register `v' not defined /usr/src/share/doc/papers/fsinterface/fsinterface.ms:59: warning: number register `UX' not defined ===> share/doc/kernmalloc (cd /usr/src/share/doc/papers/kernmalloc; soelim kernmalloc.t) > kernmalloc.ms vgrind -f < /usr/src/share/doc/papers/kernmalloc/appendix.t > appendix.ms (cd /usr/src/share/doc/papers/kernmalloc/obj; groff -Tps -e -t -p -ms -o1- kernmalloc.ms appendix.ms) | gzip -c > kernmalloc.ps.gz kernmalloc.ms:65: warning: number register `d' not defined kernmalloc.ms:406: warning: number register `OI' not defined appendix.ms:3: warning: only `z' and `u' scale indicators valid in this context appendix.ms:14: warning: number register `v' not defined appendix.ms:107: warning: `vS' not defined appendix.ms:254: warning: `vE' not defined ===> share/doc/kerntune (cd /usr/src/share/doc/papers/kerntune; groff -Tps -e -t -p -s -ms -o1- /usr/src/share/doc/papers/kerntune/0.t /usr/src/share/doc/papers/kerntune/1.t /usr/src/share/doc/papers/kerntune/2.t /usr/src/share/doc/papers/kerntune/3.t /usr/src/share/doc/papers/kerntune/4.t) | gzip -c > kerntune.ps.gz ===> share/doc/memfs indxbib -o ref.bib /usr/src/share/doc/papers/memfs/ref.bib vgrind -f < /usr/src/share/doc/papers/memfs/A.t > A.gt refer -n -e -l -s -p /usr/src/share/doc/papers/memfs/ref.bib /usr/src/share/doc/papers/memfs/0.t /usr/src/share/doc/papers/memfs/1.t A.gt > paper.t (cd /usr/src/share/doc/papers/memfs/obj; groff -Tps -ms -o1- /usr/src/share/doc/papers/memfs/tmac.srefs paper.t) | gzip -c > memfs.ps.gz /usr/src/share/doc/papers/memfs/1.t:390: warning: number register `rS' not defined /usr/src/share/doc/papers/memfs/1.t:390: warning: `Li' not defined /usr/src/share/doc/papers/memfs/1.t:390: warning: number register `Ns' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `FS' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `[G' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `[O' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `FE' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[V' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[N' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[I' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[O' not defined /usr/src/share/doc/papers/memfs/1.t:427: warning: `[I' not defined /usr/src/share/doc/papers/memfs/1.t:427: warning: `[O' not defined /usr/src/share/doc/papers/memfs/1.t:441: warning: `[I' not defined /usr/src/share/doc/papers/memfs/1.t:441: warning: `[O' not defined A.gt:3: warning: only `z' and `u' scale indicators valid in this context A.gt:14: warning: number register `v' not defined A.gt:110: warning: `vS' not defined A.gt:190: warning: number register `x' not defined A.gt:343: warning: `vE' not defined ===> share/doc/newvm (cd /usr/src/share/doc/papers/newvm; groff -Tps -t -ms -o1- /usr/src/share/doc/papers/newvm/0.t /usr/src/share/doc/papers/newvm/1.t /usr/src/share/doc/papers/newvm/a.t) | gzip -c > newvm.ps.gz ===> share/doc/nqnfs (cd /usr/src/share/doc/papers/nqnfs; groff -Tps -t -p -me -o1- /usr/src/share/doc/papers/nqnfs/nqnfs.me) | gzip -c > nqnfs.ps.gz ===> share/doc/px (cd /usr/src/share/doc/papers/px; groff -Tps -t -s -o1- /usr/src/share/doc/papers/px/pxin0.n /usr/src/share/doc/papers/px/pxin1.n /usr/src/share/doc/papers/px/pxin2.n /usr/src/share/doc/papers/px/pxin3.n /usr/src/share/doc/papers/px/pxin4.n) | gzip -c > px.ps.gz obj/fig2.3.n: No such file or directory :1140: can't open `obj/fig2.3.n': No such file or directory :2435: warning: `FK' not defined :2457: macro error: KE without KS or KF ===> share/doc/relengr (cd /usr/src/share/doc/papers/relengr; groff -Tps -ms -o1- /usr/src/share/doc/papers/relengr/0.t /usr/src/share/doc/papers/relengr/1.t /usr/src/share/doc/papers/relengr/2.t /usr/src/share/doc/papers/relengr/3.t) | gzip -c > releng.ps.gz /usr/src/share/doc/papers/relengr/1.t:67: warning: `[' not defined /usr/src/share/doc/papers/relengr/1.t:69: warning: `]' not defined ===> share/doc/sysperf (cd /usr/src/share/doc/papers/sysperf; tbl 0.t 1.t 2.t 3.t 4.t 5.t 6.t 7.t) > paper.tmp vgrind -f -f /usr/src/share/doc/papers/sysperf/a1.t | awk '/\.\(\)/{ cnt = 2 } { if (cnt) cnt -= 1; else print $0; } ' > appendix.tmp vgrind -f -f -lcsh /usr/src/share/doc/papers/sysperf/a2.t | awk '/\.\(\)/{ cnt = 2 } { if (cnt) cnt -= 1; else print $0; } ' >> appendix.tmp (cd /usr/src/share/doc/papers/sysperf/obj; groff -Tps -e -ms -o1- paper.tmp appendix.tmp) | gzip -c > sysperf.ps.gz appendix.tmp:3: warning: only `z' and `u' scale indicators valid in this context appendix.tmp:14: warning: number register `v' not defined appendix.tmp:134: warning: number register `x' not defined appendix.tmp:848: warning: only `z' and `u' scale indicators valid in this context ====> Making ASCII documents ===> share/doc/title (cd /usr/src/share/doc/psd/title; groff -mtty-char -Tascii -o1- /usr/src/share/doc/psd/title/Title) | gzip -c > Title.ascii.gz ===> share/doc/contents (cd /usr/src/share/doc/psd/contents; groff -mtty-char -Tascii -ms -o1- /usr/src/share/doc/psd/contents/contents.ms) | gzip -c > contents.ascii.gz ===> share/doc/12.make (cd /usr/src/share/doc/psd/12.make/../../../../usr.bin/make/PSD.doc; groff -mtty-char -Tascii -ms -o1- tutorial.ms) | gzip -c > paper.ascii.gz tutorial.ms:172: warning: `Ix' not defined tutorial.ms:741: warning: `Rd' not defined tutorial.ms:1085: warning: `Rm' not defined ===> share/doc/18.gprof (cd /usr/src/share/doc/psd/18.gprof/../../../../usr.bin/gprof/PSD.doc; groff -mtty-char -Tascii -e -t -p -s -me -o1- header.me abstract.me intro.me profiling.me gathering.me postp.me present.me refs.me) | gzip -c > paper.ascii.gz ===> share/doc/19.curses for a in Master appen.A c_macros ex1.gr ex2.gr fns.doc intro.0 intro.1 intro.2.tbl intro.3 intro.4 intro.5 intro.6 macros twinkle1.gr; do test -e $a || ln -s /usr/src/share/doc/psd/19.curses/../../../../lib/libcurses/PSD.doc/$a .; done (cd /usr/src/share/doc/psd/19.curses/obj; groff -mtty-char -Tascii -me -o1- Master) | gzip -c > paper.ascii.gz intro.1:133: warning: can't find font `CB' /usr/src/share/doc/psd/19.curses/../../../../lib/libcurses/PSD.doc/intro.2:76: environment stack underflow ===> share/doc/20.ipctut (cd /usr/src/share/doc/psd/20.ipctut; groff -mtty-char -Tascii -t -p -s -me -o1- /usr/src/share/doc/psd/20.ipctut/tutor.me) | gzip -c > paper.ascii.gz ===> share/doc/21.ipc (cd /usr/src/share/doc/psd/21.ipc; groff -mtty-char -Tascii -t -ms -o1- /usr/src/share/doc/psd/21.ipc/0.t /usr/src/share/doc/psd/21.ipc/1.t /usr/src/share/doc/psd/21.ipc/2.t /usr/src/share/doc/psd/21.ipc/3.t /usr/src/share/doc/psd/21.ipc/4.t /usr/src/share/doc/psd/21.ipc/5.t) | gzip -c > paper.ascii.gz /usr/src/share/doc/psd/21.ipc/3.t:339: warning: indent cannot be negative /usr/src/share/doc/psd/21.ipc/4.t:352: warning: indent cannot be negative ===> share/doc/22.rpcgen (cd /usr/src/share/doc/psd/22.rpcgen/../../../../lib/libc/rpc/PSD.doc; groff -mtty-char -Tascii -t -ms -o1- rpcgen.ms) | gzip -c > paper.ascii.gz rpcgen.ms:13: warning: missing closing delimiter rpcgen \fIrpcgen\fP ... 1 RPC \fIrpcgen\fP ... 1 rpcgen local procedures \fIrpcgen\fP ... 2 rpcgen remote procedures \fIrpcgen\fP ... 2 client handle, used by rpcgen client handle, used by \fIrpcgen\fP ... 7 RPC generating XDR routines ... 8 debugging with rpcgen debugging with \fIrpcgen\fP ... 14 rpcgen C-preprocessor \fIrpcgen\fP ... 15 rpcgen other operations \fIrpcgen\fP ... 16 rpcgen timeout changes \fIrpcgen\fP ... 16 broadcast RPC ... 16 rpcgen broadcast RPC \fIrpcgen\fP ... 16 RPCL ... 18 rpcgen RPC Language \fIrpcgen\fP ... 18 rpcgen definitions \fIrpcgen\fP ... 18 rpcgen structures \fIrpcgen\fP ... 18 rpcgen unions \fIrpcgen\fP ... 19 rpcgen enumerations \fIrpcgen\fP ... 19 rpcgen typedef \fIrpcgen\fP ... 20 rpcgen constants \fIrpcgen\fP ... 20 rpcgen programs \fIrpcgen\fP ... 21 rpcgen declarations \fIrpcgen\fP ... 21 rpcgen special cases \fIrpcgen\fP ... 23 ===> share/doc/23.rpc (cd /usr/src/share/doc/psd/23.rpc/../../../../lib/libc/rpc/PSD.doc; groff -mtty-char -Tascii -t -p -ms -o1- rpc.prog.ms) | gzip -c > paper.ascii.gz Network Programming ... rpc.prog.ms:8: warning: number register `PN' not defined 0 RPC Programming Guide ... 1 rpcgen \fIrpcgen\fP ... 1 layers of RPC ... 1 RPC layers ... 1 RPC The Highest Layer ... 1 RPC The Middle Layer ... 2 RPC The Lowest Layer ... 2 RPC paradigm ... 2 highest layer of RPC ... 3 RPC highest layer ... 3 RPC Services ... 4 rpc.prog.ms:226: warning: missing name rpc.prog.ms:233: warning: space required between `sp' and argument intermediate layer of RPC ... 5 RPC intermediate layer ... 5 enum clnt_stat (in RPC programming) \fIenum clnt_stat\fP (in RPC programming) ... 7 UDP 8K warning ... 8 program number assignment ... 8 assigning program numbers ... 8 RPC administration ... 9 administration of RPC ... 9 rpc.prog.ms:526: warning: space required between `sp' and argument arbitrary data types ... 10 RPC built-in routines ... 11 lowest layer of RPC ... 13 RPC lowest layer ... 13 RPC server side ... 14 memory allocation with XDR ... 17 XDR memory allocation ... 17 RPC calling side ... 19 RPC miscellaneous features ... 21 miscellaneous RPC features ... 21 RPC select() RPC \fIselect()\fP ... 21 select() \fIselect()\fP on the server side ... 21 select() \fIselect()\fP ... 22 broadcast RPC ... 22 RPC broadcast ... 22 broadcast RPC synopsis ... 23 RPC broadcast synopsis ... 23 batching ... 24 RPC batching ... 24 authentication ... 28 RPC authentication ... 28 UNIX Authentication ... 28 RPC guarantees ... 30 RPC DES ... 32 RPC authentication ... 32 rpc.prog.ms:1942: warning: `/"' not defined rpc.prog.ms:2064: warning: number register `"' not defined inetd using \fIinetd\fP ... 35 versions ... 35 RPC versions ... 35 TCP ... 36 RPC callback procedures ... 41 ===> share/doc/24.xdr (cd /usr/src/share/doc/psd/24.xdr/../../../../lib/libc/rpc/PSD.doc; groff -mtty-char -Tascii -e -ms -o1- xdr.nts.ms) | gzip -c > paper.ascii.gz xdr.nts.ms:16: warning: missing closing delimiter XDR Sun technical notes ... 1 XDR system routines ... 1 XDR justification ... 2 xdr.nts.ms:85: warning: space required between `sp' and argument xdr.nts.ms:89: warning: space required between `sp' and argument xdr.nts.ms:105: warning: space required between `sp' and argument xdr.nts.ms:109: warning: space required between `sp' and argument xdr.nts.ms:185: warning: space required between `sp' and argument xdr.nts.ms:190: warning: space required between `sp' and argument xdr.nts.ms:208: warning: space required between `sp' and argument xdr.nts.ms:213: warning: space required between `sp' and argument XDR portable data ... 4 XDR canonical standard ... 4 XDR library ... 5 xdrstdio_create() \fIxdrstdio_create()\fP ... 6 xdr_long() \fIxdr_long()\fP ... 6 library primitives for XDR ... 8 XDR library primitives ... 8 XDR library number filters ... 8 xdr.nts.ms:506: warning: space required between `sp' and argument xdr.nts.ms:510: warning: space required between `sp' and argument xdr.nts.ms:514: warning: space required between `sp' and argument xdr.nts.ms:518: warning: space required between `sp' and argument xdr.nts.ms:522: warning: space required between `sp' and argument xdr.nts.ms:526: warning: space required between `sp' and argument xdr.nts.ms:530: warning: space required between `sp' and argument XDR library floating point filters ... 9 xdr.nts.ms:556: warning: space required between `sp' and argument XDR library enumeration filters ... 9 xdr.nts.ms:596: warning: space required between `sp' and argument xdr.nts.ms:598: warning: space required between `sp' and argument xdr.nts.ms:602: warning: space required between `sp' and argument XDR library no data ... 10 XDR library constructed data type filters ... 10 XDR library strings ... 10 xdr_string() \fIxdr_string()\fP ... 10 xdr_string() \fIxdr_string()\fP ... 11 XDR library byte arrays ... 11 xdr_bytes() \fIxdr_bytes()\fP ... 11 XDR library arrays ... 11 xdr_array() \fIxdr_array()\fP ... 12 xdr_element() \fIxdr_element()\fP ... 12 xdr.nts.ms:875: warning: space required between `sp' and argument xdr.nts.ms:904: warning: space required between `sp' and argument XDR library opaque data ... 15 xdr_opaque() \fIxdr_opaque()\fP ... 15 XDR library fixed sized arrays ... 15 xdr.nts.ms:1025: warning: space required between `sp' and argument xdr.nts.ms:1031: warning: space required between `sp' and argument xdr.nts.ms:1038: warning: space required between `sp' and argument XDR library discriminated unions ... 15 xdr.nts.ms:1064: warning: space required between `sp' and argument xdr.nts.ms:1115: warning: space required between `sp' and argument xdr.nts.ms:1137: warning: space required between `sp' and argument XDR library pointers ... 17 xdr_reference() \fIxdr_reference()\fP ... 17 pointer semantics and XDR ... 18 xdr_reference() \fIxdr_reference()\fP ... 18 XDR non-filter primitives ... 19 xdr.nts.ms:1329: warning: space required between `sp' and argument xdr.nts.ms:1333: warning: space required between `sp' and argument xdr_getpos() \fIxdr_getpos()\fP ... 19 xdr_setpos() \fIxdr_setpos()\fP ... 19 xdr_destroy() \fIxdr_destroy()\fP ... 19 XDR operation directions ... 19 direction of XDR operations ... 19 XDR stream access ... 20 XDR standard I/O streams ... 20 xdrstdio_create() \fIxdrstdio_create()\fP ... 20 xdr.nts.ms:1411: warning: space required between `sp' and argument XDR memory streams ... 20 xdr.nts.ms:1437: warning: space required between `sp' and argument xdrmem_create() \fIxdrmem_create()\fP ... 20 XDR record (TCP/IP) streams ... 20 xdr.nts.ms:1475: warning: space required between `sp' and argument xdr.nts.ms:1554: warning: space required between `sp' and argument xdr.nts.ms:1558: warning: space required between `sp' and argument xdrrec_endofrecord() \fIxdrrec_endofrecord()\fP ... 22 xdrrec_skiprecord() \fIxdrrec_skiprecord()\fP ... 22 xdrrec_eof() \fIxdrrec_eof()\fP ... 22 XDR stream implementation ... 22 stream implementation in XDR ... 22 XDR object ... 22 xdr.nts.ms:1608: warning: space required between `sp' and argument XDR advanced topics ... 24 XDR linked lists ... 24 xdr.nts.ms:1751: warning: space required between `sp' and argument ===> share/doc/25.xdrrfc (cd /usr/src/share/doc/psd/25.xdrrfc/../../../../lib/libc/rpc/PSD.doc; groff -mtty-char -Tascii -t -ms -o1- xdr.rfc.ms) | gzip -c > paper.ascii.gz External Data Representation ... xdr.rfc.ms:13: warning: number register `PN' not defined 0 xdr.rfc.ms:14: warning: missing closing delimiter XDR RFC ... 1 XDR protocol specification ... 1 XDR RFC status ... 1 XDR basic block size ... 1 XDR block size ... 1 XDR data types ... 2 XDR data types ... 2 XDR integer ... 2 XDR unsigned integer ... 3 XDR integer, unsigned ... 3 XDR enumeration ... 3 XDR boolean ... 3 XDR hyper integer ... 3 XDR integer, hyper ... 3 XDR integer, floating point ... 4 XDR floating-point integer ... 4 XDR integer, double-precision floating point ... 5 XDR double-precision floating-point integer ... 5 XDR fixed-length opaque data ... 6 XDR opaque data, fixed length ... 6 XDR variable-length opaque data ... 6 XDR opaque data, variable length ... 6 XDR string ... 7 XDR fixed-length array ... 8 XDR array, fixed length ... 8 XDR variable-length array ... 8 XDR array, variable length ... 8 XDR structure ... 9 XDR discriminated union ... 9 XDR union discriminated ... 9 XDR void ... 10 XDR constant ... 10 XDR typedef ... 11 XDR optional data ... 11 XDR data, optional ... 11 XDR futures ... 13 XDR language ... 13 XDR byte order ... 13 XDR variable-length data ... 14 XDR language ... 14 XDR language notation ... 14 XDR language syntax ... 15 XDR language syntax ... 17 ===> share/doc/26.rpcrfc (cd /usr/src/share/doc/psd/26.rpcrfc/../../../../lib/libc/rpc/PSD.doc; groff -mtty-char -Tascii -t -ms -o1- rpc.rfc.ms) | gzip -c > paper.ascii.gz rpc.rfc.ms:13: warning: missing closing delimiter ===> share/doc/27.nfsrpc (cd /usr/src/share/doc/psd/27.nfsrpc/../../../../lib/libc/rpc/PSD.doc; groff -mtty-char -Tascii -t -ms -o1- nfs.rfc.ms) | gzip -c > paper.ascii.gz nfs.rfc.ms:13: warning: missing closing delimiter NFS ... 1 Network File System ... 1 NFS version-2 protocol specification ... 1 Network File System version-2 protocol specification ... 1 NFS introduction ... 1 Remote Procedure Call ... 1 External Data Representation ... 1 stateless servers ... 2 servers stateless ... 2 NFS protocol definition ... 2 NFS protocol ... 2 filesystem model ... 2 NFS RPC information ... 3 XDR structure sizes ... 3 NFS data types ... 4 NFS basic data types ... 4 NFS data types stat \fIstat\fP ... 4 NFS data types ftype \fIftype\fP ... 6 NFS data types fhandle \fIfhandle\fP ... 6 NFS data types timeval \fItimeval\fP ... 6 NFS data types fattr \fIfattr\fP ... 6 NFS data types sattr \fIsattr\fP ... 8 NFS data types filename \fIfilename\fP ... 8 NFS data types path \fIpath\fP ... 9 NFS data types attrstat \fIattrstat\fP ... 9 NFS data types diropargs \fIdiropargs\fP ... 9 NFS data types diropres \fIdiropres\fP ... 9 NFS server procedures ... 10 NFS server procedures NFSPROC_NULL() \fINFSPROC_NULL()\fP ... 11 NFS server procedures NFSPROC_GETATTR() \fINFSPROC_GETATTR()\fP ... 11 NFS server procedures NFSPROC_SETATTR() \fINFSPROC_SETATTR()\fP ... 11 NFS server procedures NFSPROC_ROOT \fINFSPROC_ROOT\fP ... 12 NFS server procedures NFSPROC_LOOKUP() \fINFSPROC_LOOKUP()\fP ... 12 NFS server procedures NFSPROC_READLINK() \fINFSPROC_READLINK()\fP ... 12 NFS server procedures NFSPROC_READ \fINFSPROC_READ\fP ... 13 NFS server procedures NFSPROC_WRITECACHE() \fINFSPROC_WRITECACHE()\fP ... 13 NFS server procedures NFSPROC_WRITE() \fINFSPROC_WRITE()\fP ... 14 NFS server procedures NFSPROC_CREATE() \fINFSPROC_CREATE()\fP ... 14 NFS server procedures NFSPROC_REMOVE() \fINFSPROC_REMOVE()\fP ... 14 NFS server procedures NFSPROC_RENAME() \fINFSPROC_RENAME()\fP ... 15 NFS server procedures NFSPROC_LINK() \fINFSPROC_LINK()\fP ... 15 NFS server procedures NFSPROC_SYMLINK() \fINFSPROC_SYMLINK()\fP ... 15 NFS server procedures NFSPROC_MKDIR() \fINFSPROC_MKDIR()\fP ... 16 NFS server procedures NFSPROC_RMDIR() \fINFSPROC_RMDIR()\fP ... 16 NFS server procedures NFSPROC_READDIR() \fINFSPROC_READDIR()\fP ... 17 NFS server procedures NFSPROC_STATFS() \fINFSPROC_STATFS()\fP ... 17 NFS implementation ... 18 NFS server/client relationship ... 19 NFS pathname interpretation ... 19 NFS permission issues ... 19 NFS setting RPC parameters ... 20 mount protocol ... 21 mount protocol introduction ... 21 mount protocol RPC information ... 21 mount protocol XDR structure sizes ... 21 mount protocol basic data types ... 22 mount data types ... 22 mount data types fhandle \fIfhandle\fP ... 22 mount data types fhstatus \fIfhstatus\fP ... 22 mount data types dirpath \fIdirpath\fP ... 22 mount data types name \fIname\fP ... 22 mount server procedures ... 23 mount server procedures MNTPROC_NULL() \fIMNTPROC_NULL()\fP ... 23 mount server procedures MNTPROC_MNT() \fIMNTPROC_MNT()\fP ... 23 mount server procedures MNTPROC_DUMP() \fIMNTPROC_DUMP()\fP ... 23 mount server procedures MNTPROC_UMNT() \fIMNTPROC_UMNT()\fP ... 24 mount server procedures MNTPROC_UMNTALL() \fIMNTPROC_UMNTALL()\fP ... 24 mount server procedures MNTPROC_EXPORT() \fIMNTPROC_EXPORT()\fP ... 24 ===> share/doc/title (cd /usr/src/share/doc/smm/title; groff -mtty-char -Tascii -o1- /usr/src/share/doc/smm/title/Title) | gzip -c > Title.ascii.gz /usr/src/share/doc/smm/title/Title:199: can't open `/usr/src/share/man/man0/toc8': No such file or directory ===> share/doc/01.setup (cd /usr/src/share/doc/smm/01.setup; groff -mtty-char -Tascii -t -ms -o1- /usr/src/share/doc/smm/01.setup/0.t /usr/src/share/doc/smm/01.setup/1.t /usr/src/share/doc/smm/01.setup/2.t /usr/src/share/doc/smm/01.setup/3.t /usr/src/share/doc/smm/01.setup/4.t /usr/src/share/doc/smm/01.setup/5.t /usr/src/share/doc/smm/01.setup/6.t) | gzip -c > paper.ascii.gz /usr/src/share/doc/smm/01.setup/2.t:1378: warning: indent cannot be negative /usr/src/share/doc/smm/01.setup/2.t:1422: warning: indent cannot be negative /usr/src/share/doc/smm/01.setup/6.t:672: warning: indent cannot be negative ===> share/doc/02.config (cd /usr/src/share/doc/smm/02.config/../../../../usr.sbin/config/SMM.doc; groff -mtty-char -Tascii -t -ms -o1- 0.t 1.t 2.t 3.t 4.t 5.t 6.t a.t b.t c.t d.t e.t) | gzip -c > paper.ascii.gz 5.t:73: warning: indent cannot be negative ===> share/doc/05.fastfs (cd /usr/src/share/doc/smm/05.fastfs; groff -mtty-char -Tascii -e -t -ms -o1- /usr/src/share/doc/smm/05.fastfs/0.t /usr/src/share/doc/smm/05.fastfs/1.t /usr/src/share/doc/smm/05.fastfs/2.t /usr/src/share/doc/smm/05.fastfs/3.t /usr/src/share/doc/smm/05.fastfs/4.t /usr/src/share/doc/smm/05.fastfs/5.t /usr/src/share/doc/smm/05.fastfs/6.t) | gzip -c > paper.ascii.gz /usr/src/share/doc/smm/05.fastfs/3.t:159: warning: indent cannot be negative /usr/src/share/doc/smm/05.fastfs/3.t:194: warning: indent cannot be negative /usr/src/share/doc/smm/05.fastfs/4.t:117: warning: indent cannot be negative ===> share/doc/12.timed (cd /usr/src/share/doc/smm/12.timed/../../../../usr.sbin/timed/SMM.doc/timed; groff -mtty-char -Tascii -t -s -ms -o1- timed.ms) | gzip -c > paper.ascii.gz :239: macro error: automatically terminating display :251: macro error: DE without DS, ID, CD, LD or BD :308: macro error: automatically terminating display :317: macro error: DE without DS, ID, CD, LD or BD :374: macro error: automatically terminating display :382: macro error: DE without DS, ID, CD, LD or BD :439: macro error: automatically terminating display :446: macro error: DE without DS, ID, CD, LD or BD :503: macro error: automatically terminating display :516: macro error: DE without DS, ID, CD, LD or BD :573: macro error: automatically terminating display :581: macro error: DE without DS, ID, CD, LD or BD :638: macro error: automatically terminating display :646: macro error: DE without DS, ID, CD, LD or BD :703: macro error: automatically terminating display :711: macro error: DE without DS, ID, CD, LD or BD :768: macro error: automatically terminating display :777: macro error: DE without DS, ID, CD, LD or BD :834: macro error: automatically terminating display :843: macro error: DE without DS, ID, CD, LD or BD :900: macro error: automatically terminating display :907: macro error: DE without DS, ID, CD, LD or BD :964: macro error: automatically terminating display :971: macro error: DE without DS, ID, CD, LD or BD :1028: macro error: automatically terminating display :1039: macro error: DE without DS, ID, CD, LD or BD :1096: macro error: automatically terminating display :1105: macro error: DE without DS, ID, CD, LD or BD :1162: macro error: automatically terminating display :1169: macro error: DE without DS, ID, CD, LD or BD :1226: macro error: automatically terminating display :1236: macro error: DE without DS, ID, CD, LD or BD :1293: macro error: automatically terminating display :1301: macro error: DE without DS, ID, CD, LD or BD :1358: macro error: automatically terminating display :1366: macro error: DE without DS, ID, CD, LD or BD :1423: macro error: automatically terminating display :1430: macro error: DE without DS, ID, CD, LD or BD :1487: macro error: automatically terminating display :1496: macro error: DE without DS, ID, CD, LD or BD :1553: macro error: automatically terminating display :1561: macro error: DE without DS, ID, CD, LD or BD :1620: macro error: automatically terminating display :1628: macro error: DE without DS, ID, CD, LD or BD ===> share/doc/04.csh (cd /usr/src/share/doc/usd/04.csh/../../../../bin/csh/USD.doc; groff -mtty-char -Tascii -ms -o1- tabs csh.1 csh.2 csh.3 csh.4 /usr/src/share/doc/usd/04.csh/../../../../bin/csh/USD.doc/csh.a csh.g) | gzip -c > paper.ascii.gz /usr/src/share/doc/usd/04.csh/../../../../bin/csh/USD.doc/csh.a:60: warning: `1.6' not defined ===> share/doc/10.exref (cd /usr/src/share/doc/usd/10.exref/../../../../usr.bin/vi/USD.doc/exref; groff -mtty-char -Tascii -t -ms -o1- ex.rm) | gzip -c > paper.ascii.gz ex.rm:632: warning: number register `)P' not defined (cd /usr/src/share/doc/usd/10.exref/../../../../usr.bin/vi/USD.doc/exref; groff -mtty-char -Tascii -t -ms -o1- ex.summary) | gzip -c > summary.ascii.gz ex.summary:58: warning: missing number tbl:ex.summary:405: excess data entry `\^' discarded tbl:ex.summary:416: excess data entry `\^' discarded ex.summary:397: warning: `LF' not defined ex.summary:397: warning: `CF' not defined ex.summary:397: warning: `RF' not defined ===> share/doc/11.vitut (cd /usr/src/share/doc/usd/11.vitut/../../../../usr.bin/vi/USD.doc/edit; groff -mtty-char -Tascii -t -ms -o1- edittut.ms) | gzip -c > paper.ascii.gz edittut.ms:92: warning: escape character ignored before `4' edittut.ms:95: warning: escape character ignored before `4' edittut.ms:98: warning: escape character ignored before `5' edittut.ms:104: warning: escape character ignored before `7' tbl:edittut.ms:1038: `.' not last character on line tbl:edittut.ms:1038: giving up on this table ===> share/doc/12.vi (cd /usr/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -mtty-char -Tascii -t -ms -o1- vi.in vi.chars) | gzip -c > paper.ascii.gz vi.in:1490: bad font number tbl:vi.in:1839: unrecognised format `b' tbl:vi.in:1839: giving up on this table vi.in:1813: warning: escape character ignored before `+' vi.chars:35: warning: `.pn' not defined (cd /usr/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -mtty-char -Tascii -t -ms -o1- vi.summary) | gzip -c > summary.ascii.gz vi.summary:76: warning: number register `1T' not defined vi.summary:437: warning: escape character ignored before `=' vi.summary:437: warning: escape character ignored before `=' (cd /usr/src/share/doc/usd/12.vi/../../../../usr.bin/vi/USD.doc/vitut; groff -mtty-char -Tascii -t -ms -o1- vi.apwh.ms) | gzip -c > viapwh.ascii.gz vi.apwh.ms:40: warning: `CB' not defined vi.apwh.ms:86: warning: `VL' not defined vi.apwh.ms:107: warning: `LE' not defined ===> share/doc/13.viref (cd /usr/src/share/doc/usd/13.viref/../../../../usr.bin/vi/USD.doc/vi.ref; groff -mtty-char -Tascii -t -s -me -o1- vi.ref /usr/src/share/doc/usd/13.viref/obj/index.so) | gzip -c > paper.ascii.gz index.so: No such file or directory :7140: can't open `index.so': No such file or directory ===> share/doc/20.meref (cd /usr/src/share/doc/usd/20.meref; groff -mtty-char -Tascii -me -o1- /usr/src/share/doc/usd/20.meref/ref.me) | gzip -c > paper.ascii.gz /usr/src/share/doc/usd/20.meref/ref.me:1953: a space character is not allowed in an escape name ===> share/doc/30.rogue (cd /usr/src/share/doc/usd/30.rogue/../../../../games/rogue/USD.doc; groff -mtty-char -Tascii -t -me -o1- rogue.me) | gzip -c > paper.ascii.gz ===> share/doc/31.trek (cd /usr/src/share/doc/usd/31.trek/../../../../games/trek/USD.doc; groff -mtty-char -Tascii -t -me -o1- trek.me) | gzip -c > paper.ascii.gz tbl:trek.me:436: column separation specified for last column tbl:trek.me:436: column separation specified for last column tbl:trek.me:445: column separation specified for last column tbl:trek.me:445: column separation specified for last column trek.me:314: environment stack underflow ===> share/doc/diskperf (cd /usr/src/share/doc/papers/diskperf; groff -mtty-char -Tascii -t -ms -o1- /usr/src/share/doc/papers/diskperf/abs.ms /usr/src/share/doc/papers/diskperf/motivation.ms /usr/src/share/doc/papers/diskperf/equip.ms /usr/src/share/doc/papers/diskperf/methodology.ms /usr/src/share/doc/papers/diskperf/tests.ms /usr/src/share/doc/papers/diskperf/results.ms /usr/src/share/doc/papers/diskperf/conclusions.ms /usr/src/share/doc/papers/diskperf/appendix.ms) | gzip -c > diskperf.ascii.gz /usr/src/share/doc/papers/diskperf/results.ms:231: warning: indent cannot be negative /usr/src/share/doc/papers/diskperf/results.ms:413: warning: indent cannot be negative ===> share/doc/fsinterface (cd /usr/src/share/doc/papers/fsinterface; groff -mtty-char -Tascii -t -ms -o1- /usr/src/share/doc/papers/fsinterface/fsinterface.ms) | gzip -c > fsinterface.ascii.gz /usr/src/share/doc/papers/fsinterface/fsinterface.ms:34: warning: number register `v' not defined /usr/src/share/doc/papers/fsinterface/fsinterface.ms:59: warning: number register `UX' not defined ===> share/doc/kernmalloc (cd /usr/src/share/doc/papers/kernmalloc/obj; groff -mtty-char -Tascii -e -t -p -ms -o1- kernmalloc.ms appendix.ms) | gzip -c > kernmalloc.ascii.gz kernmalloc.ms:65: warning: number register `d' not defined kernmalloc.ms:406: warning: number register `OI' not defined appendix.ms:3: warning: only `z' and `u' scale indicators valid in this context appendix.ms:14: warning: number register `v' not defined appendix.ms:107: warning: `vS' not defined appendix.ms:254: warning: `vE' not defined ===> share/doc/kerntune (cd /usr/src/share/doc/papers/kerntune; groff -mtty-char -Tascii -e -t -p -s -ms -o1- /usr/src/share/doc/papers/kerntune/0.t /usr/src/share/doc/papers/kerntune/1.t /usr/src/share/doc/papers/kerntune/2.t /usr/src/share/doc/papers/kerntune/3.t /usr/src/share/doc/papers/kerntune/4.t) | gzip -c > kerntune.ascii.gz :330: warning: indent cannot be negative ===> share/doc/memfs (cd /usr/src/share/doc/papers/memfs/obj; groff -mtty-char -Tascii -ms -o1- /usr/src/share/doc/papers/memfs/tmac.srefs paper.t) | gzip -c > memfs.ascii.gz /usr/src/share/doc/papers/memfs/1.t:390: warning: number register `rS' not defined /usr/src/share/doc/papers/memfs/1.t:390: warning: `Li' not defined /usr/src/share/doc/papers/memfs/1.t:390: warning: number register `Ns' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `FS' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `[G' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `[O' not defined /usr/src/share/doc/papers/memfs/1.t:401: warning: `FE' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[V' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[N' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[I' not defined /usr/src/share/doc/papers/memfs/1.t:413: warning: `[O' not defined /usr/src/share/doc/papers/memfs/1.t:427: warning: `[I' not defined /usr/src/share/doc/papers/memfs/1.t:427: warning: `[O' not defined /usr/src/share/doc/papers/memfs/1.t:441: warning: `[I' not defined /usr/src/share/doc/papers/memfs/1.t:441: warning: `[O' not defined A.gt:3: warning: only `z' and `u' scale indicators valid in this context A.gt:14: warning: number register `v' not defined A.gt:110: warning: `vS' not defined A.gt:190: warning: number register `x' not defined A.gt:343: warning: `vE' not defined ===> share/doc/px (cd /usr/src/share/doc/papers/px; groff -mtty-char -Tascii -t -s -o1- /usr/src/share/doc/papers/px/pxin0.n /usr/src/share/doc/papers/px/pxin1.n /usr/src/share/doc/papers/px/pxin2.n /usr/src/share/doc/papers/px/pxin3.n /usr/src/share/doc/papers/px/pxin4.n) | gzip -c > px.ascii.gz obj/fig2.3.n: No such file or directory :1112: warning: indent cannot be negative :1140: can't open `obj/fig2.3.n': No such file or directory :2435: warning: `FK' not defined :2457: macro error: KE without KS or KF ===> share/doc/relengr (cd /usr/src/share/doc/papers/relengr; groff -mtty-char -Tascii -ms -o1- /usr/src/share/doc/papers/relengr/0.t /usr/src/share/doc/papers/relengr/1.t /usr/src/share/doc/papers/relengr/2.t /usr/src/share/doc/papers/relengr/3.t) | gzip -c > releng.ascii.gz /usr/src/share/doc/papers/relengr/1.t:67: warning: `[' not defined /usr/src/share/doc/papers/relengr/1.t:69: warning: `]' not defined ===> share/doc/sysperf (cd /usr/src/share/doc/papers/sysperf/obj; groff -mtty-char -Tascii -e -ms -o1- paper.tmp appendix.tmp) | gzip -c > sysperf.ascii.gz 3.t:203: warning: indent cannot be negative 3.t:363: warning: indent cannot be negative 3.t:626: warning: indent cannot be negative 3.t:769: warning: indent cannot be negative 4.t:645: warning: indent cannot be negative appendix.tmp:3: warning: only `z' and `u' scale indicators valid in this context appendix.tmp:14: warning: number register `v' not defined appendix.tmp:134: warning: number register `x' not defined appendix.tmp:848: warning: only `z' and `u' scale indicators valid in this context From owner-freebsd-current Tue Aug 22 23:38:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA13934 for current-outgoing; Tue, 22 Aug 1995 23:38:00 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA13911 for ; Tue, 22 Aug 1995 23:37:41 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id IAA00804; Wed, 23 Aug 1995 08:36:38 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.11/8.6.9) with SMTP id IAA02392; Wed, 23 Aug 1995 08:36:37 +0200 Message-Id: <199508230636.IAA02392@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: jdl@chromatic.com cc: freebsd-current@freebsd.org Subject: Re: make world falling down on 'zic' Date: Wed, 23 Aug 1995 08:36:37 +0200 From: Mark Murray Sender: current-owner@freebsd.org Precedence: bulk Hi Go to src/usr.sbin/zic and do a `make clean all install'. You'll be OK then! M > I apologize in advance for repeating something that I'm > pretty sure just got mentioned a couple days ago. I tried > to Netscrape through the mail archives but they appeared to > be out of order. Rats. > > So, my 'make world' came to a screaching halt with: > > umask 022; cd /usr/src/share/zoneinfo; zic -d /usr/share/zoneinfo -p America /New_York -L /dev/null -y /usr/src/share/zoneinfo/obj/yearistype africa antarc tica asia australasia etcetera europe factory northamerica southamerica system v > "europe", line 717: invalid time of day > "europe", line 718: invalid time of day > "europe", line 719: invalid time of day > "europe", line 760: invalid time of day > "europe", line 761: invalid time of day > "europe", line 762: invalid time of day > "europe", line 763: invalid time of day > "europe", line 764: invalid time of day > "europe", line 765: invalid time of day > > I'm pretty sure someone mentioned something like this a day or three ago. > If they could gently remind those of us with short memories, it'd be > greatly appreciated. And, what's the right 'make' to retart this build > in place without totally starting over? Is 'make depend all install' > good enough? > > Thanks, > jdl -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key From owner-freebsd-current Wed Aug 23 01:02:34 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id BAA17595 for current-outgoing; Wed, 23 Aug 1995 01:02:34 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id BAB17589 for ; Wed, 23 Aug 1995 01:02:29 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id AAA03755; Wed, 23 Aug 1995 00:59:46 -0700 To: Bruce Evans cc: alain@Wit401402.student.utwente.nl, current@freefall.FreeBSD.org Subject: Re: Of slices and boot code.. In-reply-to: Your message of "Wed, 23 Aug 1995 06:00:21 +1000." <199508222000.GAA20779@godzilla.zeta.org.au> Date: Wed, 23 Aug 1995 00:59:46 -0700 Message-ID: <3753.809164786@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > They seem to be quite consistent. BSD partitions are named partitions > and DOS partitions are named slices. The native partitions have to be > named partitions for political reasons and the foreign partitions have > to be named something different to avoid confusion. Well, perhaps we can indeed do something about this even so.. What if a "slice" referred only to an MBR entry, e.g. one of the 4 entries configured by the fdisk editor - sd0s1, sd0s2 and so on. A "partition" always referred to a subsection of a slice (a slice of a slice? gah!), that is something modified by the disklabel editor - sd0s1a, sd0s2d and so on. Note that this would hold true even for extended DOS partitions and such - there would be no distinction drawn for "BSD partitions" and any other subsectioning of a slice. Once we get a working ext2fs we'll only have the situation complicated even further as people want to deal with their "Linux slice" as a set of "Linux partitions". Drawing a clear line now will only make our lives easier then. As I said before, the compatibility slice only complicates things since it introduces these hybrid "sd0a" sorts of names and mixes them in among the "real" partition names. On my own system you see: Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0a 59454 30724 23972 56% / /dev/sd0s2e 2980222 2204714 537090 80% /usr /dev/sd0s2f 4357562 551324 3457632 14% /a /dev/sd1s1e 3858078 1891204 1658226 53% /b And it makes people look at that first entry and say "huh? it's not in the second slice? where is it then??" I'm still not clear on whether or not those last patches of yours will enable me to yank the "compatibility hacks" out of sysinstall. I surely would like to as it would actually simplify the code considerably! Jordan From owner-freebsd-current Wed Aug 23 02:07:00 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id CAA21724 for current-outgoing; Wed, 23 Aug 1995 02:07:00 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id CAA21713 for ; Wed, 23 Aug 1995 02:06:50 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id CAA04074; Wed, 23 Aug 1995 02:06:30 -0700 To: jdl@chromatic.com cc: freebsd-current@freebsd.org Subject: Re: Building and World Order In-reply-to: Your message of "Tue, 22 Aug 1995 16:28:58 CDT." <199508222128.QAA07240@chrome.onramp.net> Date: Wed, 23 Aug 1995 02:06:30 -0700 Message-ID: <4072.809168790@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > 4. Before compiling current, read the Makefile in /usr/src > carefully. You'll see one-time targets like `bootstrapld' > which *MUST* be run as part of the upgrading process. Reading > freebsd-hackers will keep you up-to-date on other bootstrapping > procedures that sometimes become necessary as we move towards > the next release. Ye gods, is THAT out of date! Thanks for bringing it to our attention! > So, where do I go from here? What are the valid (and pertinent) make > targets? Is 'install' up next? I don't see the semi-traditional > 'clean' and 'realclean', just 'cleandist'. No, world does it all. > Will all of my local utilities get updated to be the utilities that > I just build at some point? Do I even want or need to do this step > in order to run the -current kernel I just built? No, your local utilities remain untouched. If you want to update them, it's up to you. > Also, when I sup in a new update, how much of the world will I need > to rebuild? Do I need to start at /usr/src and make 'world' again? "That depends" Sorry, but that's all I can say. Sometimes you need to, sometimes you don't. The only way to know for sure is to read the -current mailing list. Jordan From owner-freebsd-current Wed Aug 23 02:12:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id CAA22135 for current-outgoing; Wed, 23 Aug 1995 02:12:09 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id CAA22100 for ; Wed, 23 Aug 1995 02:11:40 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA11758; Wed, 23 Aug 1995 18:51:36 +1000 Date: Wed, 23 Aug 1995 18:51:36 +1000 From: Bruce Evans Message-Id: <199508230851.SAA11758@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Subject: Re: Of slices and boot code.. Cc: alain@Wit401402.student.utwente.nl, current@freefall.FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >What if a "slice" referred only to an MBR entry, e.g. one of the 4 >entries configured by the fdisk editor - sd0s1, sd0s2 and so on. >A "partition" always referred to a subsection of a slice (a slice of a >slice? gah!), that is something modified by the disklabel editor - >sd0s1a, sd0s2d and so on. >Note that this would hold true even for extended DOS partitions and >such - there would be no distinction drawn for "BSD partitions" and >any other subsectioning of a slice. Then you would have to call what is now sd0s5a a "BSD partition within a partition within a slice" and name it something like "sd0s4e1a" (where "s4" is the slice (an extended partition in DOS-speak), "e1" is the second partition within the slice (a logical drive in DOS-speak) and "a" is the first BSD partition within that first partition). Gak. FreeBSD may have to be put on sd0s4e1 because DOS is on sd0s1, Linux-root is on sd0s2, Linux-usr is on sd0s3, sd0s4 is an extended slice and Linux-swap is on sd0s4e0. >Once we get a working ext2fs we'll only have the situation complicated >even further as people want to deal with their "Linux slice" as a set >of "Linux partitions". Drawing a clear line now will only make our >lives easier then. Linux doesn't have its own partitions. It uses DOS partitions er slices. That's what I do for FreeBSD file systems when there are plenty of spare primary partitions: newfs /dev/rsd1s2. This currently requires putting a label on the slice. >I'm still not clear on whether or not those last patches of yours will >enable me to yank the "compatibility hacks" out of sysinstall. I >surely would like to as it would actually simplify the code >considerably! It would also simplify the kernel code considerably. Bruce From owner-freebsd-current Wed Aug 23 03:27:02 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id DAA27178 for current-outgoing; Wed, 23 Aug 1995 03:27:02 -0700 Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.125.68.130]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id DAA26841 for ; Wed, 23 Aug 1995 03:20:56 -0700 Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id NAA22016 for current@freebsd.org; Wed, 23 Aug 1995 13:17:06 +0300 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.6.9) with ESMTP id MAA29696 for ; Wed, 23 Aug 1995 12:43:11 +0300 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.6.9) id MAA12265; Wed, 23 Aug 1995 12:43:10 +0300 From: "Andrew V. Stesin" Message-Id: <199508230943.MAA12265@office.elvisti.kiev.ua> Subject: Terms (was: Re: Of slices... To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 23 Aug 1995 12:43:10 +0300 (EET DST) Cc: current@freebsd.org In-Reply-To: <3753.809164786@time.cdrom.com> from "Jordan K. Hubbard" at Aug 23, 95 00:59:46 am X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Content-Length: 620 Sender: current-owner@freebsd.org Precedence: bulk # Well, perhaps we can indeed do something about this even so.. # # What if a "slice" referred only to an MBR entry, e.g. one of the 4 # entries configured by the fdisk editor - sd0s1, sd0s2 and so on. # # A "partition" always referred to a subsection of a slice (a slice of a # slice? gah!), that is something modified by the disklabel editor - # sd0s1a, sd0s2d and so on. # Will it be wise to make terms like "partition" obsolete (to avoid confusion for ex-dos people who Really Know What Partition Is :-) and introduce the term 'subslice'? -- With best wishes -- Andrew Stesin, Elvisti.Kiev.UA sysadmin. From owner-freebsd-current Wed Aug 23 03:37:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id DAB27649 for current-outgoing; Wed, 23 Aug 1995 03:37:18 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id DAA27643 for ; Wed, 23 Aug 1995 03:37:15 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id DAA04712; Wed, 23 Aug 1995 03:35:25 -0700 To: Bruce Evans cc: alain@Wit401402.student.utwente.nl, current@freefall.FreeBSD.org Subject: Re: Of slices and boot code.. In-reply-to: Your message of "Wed, 23 Aug 1995 18:51:36 +1000." <199508230851.SAA11758@godzilla.zeta.org.au> Date: Wed, 23 Aug 1995 03:35:24 -0700 Message-ID: <4710.809174124@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > Then you would have to call what is now sd0s5a a "BSD partition within a > partition within a slice" and name it something like "sd0s4e1a" (where > "s4" is the slice (an extended partition in DOS-speak), "e1" is the > second partition within the slice (a logical drive in DOS-speak) and "a" > is the first BSD partition within that first partition). Gak. FreeBSD > may have to be put on sd0s4e1 because DOS is on sd0s1, Linux-root is on > sd0s2, Linux-usr is on sd0s3, sd0s4 is an extended slice and Linux-swap > is on sd0s4e0. Well, you must admit that this example is a little contrived and if such insane nesting were required because the user was trying to shoe-horn FreeBSD into a system already so dedicated to DOS and Linux, well, then so be it. I'm trying to keep the most common scenarios as simple and clean as possible and, truth be told, if someone REALLY wanted to install FreeBSD in such a convoluted environment then I'd say that the naming would be the least of their worries! More to the point, I have yet to get a single tech-support query from someone with all 4 MBR slots filled. It just doesn't seem to happen that way. I think that my proposal still has merit. > Linux doesn't have its own partitions. It uses DOS partitions er > slices. That's what I do for FreeBSD file systems when there are > plenty of spare primary partitions: newfs /dev/rsd1s2. This currently > requires putting a label on the slice. Hmm. Well, I wasn't exactly suggesting that FreeBSD filesystems had to ONLY go into a partition - I can see putting one straight into a slice, as you suggest, but I still think that it should be called a slice. > >I'm still not clear on whether or not those last patches of yours will > >enable me to yank the "compatibility hacks" out of sysinstall. I > >surely would like to as it would actually simplify the code > >considerably! > > It would also simplify the kernel code considerably. So. Um. You're saying that this is planned/done/on the way? I'm still a little unclear on that.. :-) Jordan From owner-freebsd-current Wed Aug 23 05:01:16 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id FAA29551 for current-outgoing; Wed, 23 Aug 1995 05:01:16 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id FAA29528 for ; Wed, 23 Aug 1995 05:00:34 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id VAA18265; Wed, 23 Aug 1995 21:37:59 +1000 Date: Wed, 23 Aug 1995 21:37:59 +1000 From: Bruce Evans Message-Id: <199508231137.VAA18265@godzilla.zeta.org.au> To: bde@zeta.org.au, jkh@time.cdrom.com Subject: Re: Of slices and boot code.. Cc: alain@Wit401402.student.utwente.nl, current@freefall.FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk >Well, you must admit that this example is a little contrived and if >such insane nesting were required because the user was trying to >shoe-horn FreeBSD into a system already so dedicated to DOS and Linux, >well, then so be it. I'm trying to keep the most common scenarios as >simple and clean as possible and, truth be told, if someone REALLY >wanted to install FreeBSD in such a convoluted environment then I'd >say that the naming would be the least of their worries! Another try. The following naming schemes for slices exist or are being considered: DOS FreeBSD Linux what you asked for -- ------ ---- ----- C: sd0s1 sda1 sd0s1 ### assume there is only one drive so that some DOS drive letters ### aren't for other drives D: sd0s2 sda2 sd0s2 E: sd0s3 sda3 sd0s3 F: sd0s4 sda4 sd0s4 ### end of slices on MBR ### assume sd0s4 is an extended slice and the only extended slice G: sd0s5 sda5 sd0s4e0 H: sd0s6 sda6 sd0s4e1 I: sd0s7 sda7 sd0s4e2 J: sd0s8 sda8 sd0s4e3 K: sd0s9 sda9 sd0s4e4 L: sd0s10 sda10 sd0s4e5 M: sd0s11 sda11 sd0s4e6 N: sd0s12 sda12 sd0s4e7 O: sd0s13 sda13 sd0s4e8 P: sd0s14 sda14 sd0s4e9 Q: sd0s15 sda15 sd0s4e10 R: sd0s16 can't handle sd0s4e11 S: sd0s17 " sd0s4e12 T: sd0s18 " sd0s4e13 U: sd0s19 " sd0s4e14 V: sd0s20 " sd0s4e15 W: sd0s21 " sd0s4e16 X: sd0s22 " sd0s4e17 Y: sd0s23 " sd0s4e18 Z: sd0s24 " sd0s4e19 can't handle sd0s25 " sd0s4e20 " sd0s26 " sd0s4e21 " sd0s27 " sd0s4e22 " sd0s28 " sd0s4e23 " sd0s29 " sd0s4e24 " sd0s30 " sd0s4e25 Which do you prefer? :-) Which is the least consistent? >More to the point, I have yet to get a single tech-support query from >someone with all 4 MBR slots filled. It just doesn't seem to happen >that way. I think that my proposal still has merit. This is probably because people with 4 MBR slots filled have probably practiced running fdisk at least 3 times more than people with 1 MBR slot filled. >> >I'm still not clear on whether or not those last patches of yours will >> >enable me to yank the "compatibility hacks" out of sysinstall. I >> >surely would like to as it would actually simplify the code >> >considerably! >> >> It would also simplify the kernel code considerably. >So. Um. You're saying that this is planned/done/on the way? I'm >still a little unclear on that.. :-) I didn't have the compatibility hacks originally, but it became obvious that there would be too many problems getting everyone converted without them. Bruce From owner-freebsd-current Wed Aug 23 05:23:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id FAA00459 for current-outgoing; Wed, 23 Aug 1995 05:23:54 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id FAA00395 for ; Wed, 23 Aug 1995 05:23:16 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA17493; Wed, 23 Aug 1995 14:22:04 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id OAA16924; Wed, 23 Aug 1995 14:22:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id NAA15851; Wed, 23 Aug 1995 13:38:04 +0200 From: J Wunsch Message-Id: <199508231138.NAA15851@uriah.heep.sax.de> Subject: Re: Building and World Order To: jdl@chromatic.com Date: Wed, 23 Aug 1995 13:38:03 +0200 (MET DST) Cc: freebsd-current@freebsd.org In-Reply-To: <199508222128.QAA07240@chrome.onramp.net> from "Jon Loeliger" at Aug 22, 95 04:28:58 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 469 Sender: current-owner@freebsd.org Precedence: bulk As Jon Loeliger wrote: > > So, where do I go from here? What are the valid (and pertinent) make > targets? Is 'install' up next? I don't see the semi-traditional > 'clean' and 'realclean', just 'cleandist'. `install' will be next. It doesn't install _anything_ in /etc however, you are expected to update /etc by hand. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Aug 23 05:28:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id FAA00761 for current-outgoing; Wed, 23 Aug 1995 05:28:12 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id FAA00755 for ; Wed, 23 Aug 1995 05:28:08 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id FAA09180; Wed, 23 Aug 1995 05:22:51 -0700 From: "Rodney W. Grimes" Message-Id: <199508231222.FAA09180@gndrsh.aac.dev.com> Subject: Re: Matrox Meteor Video Capture Card Driver To: james@miller.cs.uwm.edu (Jim Lowe) Date: Wed, 23 Aug 1995 05:22:51 -0700 (PDT) Cc: se@ZPR.Uni-Koeln.DE, current@freebsd.org, tinguely@plains.nodak.edu In-Reply-To: <199508222003.PAA26113@miller.cs.uwm.edu> from "Jim Lowe" at Aug 22, 95 03:03:43 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1279 Sender: current-owner@freebsd.org Precedence: bulk > > > > Since I'm currently maintaining the PCI and NCR code, > > > we might try to get the Matrox Meteor supported on > > > more motherboards ... > > > > I doubt you are going to fix the ``hardware'' bugs in the Mercury > > chipset that causes the problems with boards like the Meteor. > > I just tried the meteor card in an ASUS triton box with the NCR controller in > it. The machine locked up on large frame transfers. It seemed to work > just fine as long as I kept the PCI data transfer down with small frame > sizes. If I remove the NCR controller and use a different one, the > machine works just fine. > > For some reason, the NCR seems to lock up when the PCI bus gets real > busy. I am not sure why. The NCR runs it's firmware from the host memory, try cranking the PCI latency timer down for the NCR card and see if that helps. (This is in the PCI bios setup screen). Depending on motherboards (I happen to know what ``Triton'' board Jim just tried this in) there maybe 1 setting for all slots, or each slot may have it's own setting. Either way, crank it down to about 40 (default should be 80). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 05:39:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id FAA01215 for current-outgoing; Wed, 23 Aug 1995 05:39:06 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id FAA01209 for ; Wed, 23 Aug 1995 05:39:03 -0700 Received: by Sysiphos id AA10257 (5.67b/IDA-1.5 for current@freebsd.org); Wed, 23 Aug 1995 14:38:23 +0200 Message-Id: <199508231238.AA10257@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Wed, 23 Aug 1995 14:38:22 +0200 In-Reply-To: Jim Lowe "Re: Matrox Meteor Video Capture Card Driver" (Aug 22, 15:03) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jim Lowe Subject: Re: Matrox Meteor Video Capture Card Driver Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk On Aug 22, 15:03, Jim Lowe wrote: } Subject: Re: Matrox Meteor Video Capture Card Driver } I just tried the meteor card in an ASUS triton box with the NCR controller in } it. The machine locked up on large frame transfers. It seemed to work } just fine as long as I kept the PCI data transfer down with small frame } sizes. If I remove the NCR controller and use a different one, the } machine works just fine. Which controller did you use instead ? } For some reason, the NCR seems to lock up when the PCI bus gets real } busy. I am not sure why. Did you try lower values of the "PCI Latency Timer" of the slot the Matrox has been put in ? (This timer determines the number of bus clocks a PCI card may claim ownerchip of the PCI bus, if another card wants to start a transfer. The NCR executes its instruction stream from host RAM, and it may get into trouble if it can only get another instruction every 10us ...) A latency timer setting of some 0x20 for the matrox should allow the NCR to access the bus once per micro second. Guess this is a good value ... (The latency timer doesn't force the PCI device to give up bus ownership if there is no request from another device and thus doesn't slow down the Matrox unless it makes the NCR starve ...) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Wed Aug 23 06:02:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id GAA01730 for current-outgoing; Wed, 23 Aug 1995 06:02:01 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id GAA01722 for ; Wed, 23 Aug 1995 06:01:58 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id GAA06527 for ; Wed, 23 Aug 1995 06:01:56 -0700 To: current@freebsd.org Subject: Recent mount patches.. Date: Wed, 23 Aug 1995 06:01:55 -0700 Message-ID: <6525.809182915@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk You'll need to rebuild all your mount_foo execs due to the change in mount.h. Just FYI. I decided to take the patch because I myself am tired of the system refusing to come up just because I don't have a CD in the drive, yet it's silly to have to type the whole mount command spec in as the only alternative. Jordan From owner-freebsd-current Wed Aug 23 08:37:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA09302 for current-outgoing; Wed, 23 Aug 1995 08:37:32 -0700 Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.35.13]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id IAA09296 for ; Wed, 23 Aug 1995 08:37:31 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id KAA26926; Wed, 23 Aug 1995 10:37:28 -0500 Date: Wed, 23 Aug 1995 10:37:28 -0500 From: Jim Lowe Message-Id: <199508231537.KAA26926@miller.cs.uwm.edu> To: rgrimes@gndrsh.aac.dev.com Subject: Re: Matrox Meteor Video Capture Card Driver Cc: current@freebsd.org, se@ZPR.Uni-Koeln.DE, tinguely@plains.nodak.edu Sender: current-owner@freebsd.org Precedence: bulk > From: "Rodney W. Grimes" > > The NCR runs it's firmware from the host memory, try cranking the PCI > latency timer down for the NCR card and see if that helps. (This is > in the PCI bios setup screen). Depending on motherboards (I happen > to know what ``Triton'' board Jim just tried this in) there maybe > 1 setting for all slots, or each slot may have it's own setting. > > Either way, crank it down to about 40 (default should be 80). > > From: se@zpr.uni-koeln.de (Stefan Esser) > > Did you try lower values of the "PCI Latency > Timer" of the slot the Matrox has been put in ? > > (This timer determines the number of bus clocks > a PCI card may claim ownerchip of the PCI bus, > if another card wants to start a transfer. > The NCR executes its instruction stream from > host RAM, and it may get into trouble if it > can only get another instruction every 10us ...) > > A latency timer setting of some 0x20 for the > matrox should allow the NCR to access the bus > once per micro second. Guess this is a good > value ... > > (The latency timer doesn't force the PCI device > to give up bus ownership if there is no request > from another device and thus doesn't slow down > the Matrox unless it makes the NCR starve ...) > I tried lowering the PCI latency timer from 80 to 40, then to 20, then 1, then 0. It helped me get a few frames at 640x480 before the machine hung. I also tried disabling the cpu to pci burst mode. I have been running the meteor in a machine with and adaptec controller for 5 days and it never hung. I am still not sure why the machine hangs with the ncr controller. -Jim From owner-freebsd-current Wed Aug 23 08:49:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA10207 for current-outgoing; Wed, 23 Aug 1995 08:49:53 -0700 Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id IAA10194 for ; Wed, 23 Aug 1995 08:49:36 -0700 Received: by Sysiphos id AA18689 (5.67b/IDA-1.5 for current@freebsd.org); Wed, 23 Aug 1995 17:49:07 +0200 Message-Id: <199508231549.AA18689@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Wed, 23 Aug 1995 17:49:07 +0200 In-Reply-To: Jim Lowe "Re: Matrox Meteor Video Capture Card Driver" (Aug 23, 10:37) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Jim Lowe Subject: Re: Matrox Meteor Video Capture Card Driver Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk On Aug 23, 10:37, Jim Lowe wrote: } Subject: Re: Matrox Meteor Video Capture Card Driver } > From: "Rodney W. Grimes" } I tried lowering the PCI latency timer from 80 to 40, then to 20, then 1, } then 0. It helped me get a few frames at 640x480 before the machine } hung. I also tried disabling the cpu to pci burst mode. It takes some 10 cycles to arbitrate for the PCI bus and to send the first data word. Numbers less than 10 (decimal) are not too useful for this reason. Is there any error message or other fault indication than the system freezing ? } I have been running the meteor in a machine with and adaptec controller } for 5 days and it never hung. I am still not sure why the machine } hangs with the ncr controller. I take it the Adaptec above is an 2940 ? Could you please try having "ncrconsole -v -p 1" run in another window. Watch the "pre" and "post" times, which account for the time to initiate a transfer and to retrieve the SCSI status. The lower limits for these numbers are the NCR and disk drive SCSI overhead. The command overhead of the NCR depends on its instruction execution rate (usually in the low MIPS range). Do you have a NCR 53c815 or 825 to compare the 810 results with ? One of the differences between the 8x0 and 8x5 is the reading of instructions in burst mode, which might help. -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/staff/esser/esser.html From owner-freebsd-current Wed Aug 23 09:50:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id JAA12640 for current-outgoing; Wed, 23 Aug 1995 09:50:40 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id JAA12633 for ; Wed, 23 Aug 1995 09:50:31 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA26237; Wed, 23 Aug 1995 18:48:06 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id SAA19302 for current@freebsd.org; Wed, 23 Aug 1995 18:48:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id SAA17655 for current@freebsd.org; Wed, 23 Aug 1995 18:25:46 +0200 From: J Wunsch Message-Id: <199508231625.SAA17655@uriah.heep.sax.de> Subject: Re: Recent mount patches.. To: current@freebsd.org Date: Wed, 23 Aug 1995 18:25:45 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: <6525.809182915@time.cdrom.com> from "Jordan K. Hubbard" at Aug 23, 95 06:01:55 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1728 Sender: current-owner@freebsd.org Precedence: bulk As Jordan K. Hubbard wrote: > > You'll need to rebuild all your mount_foo execs due to the change in > mount.h. Just FYI. Ick. This should have been discussed before. > I decided to take the patch because I myself am tired of the system > refusing to come up just because I don't have a CD in the drive, yet > it's silly to have to type the whole mount command spec in as the > only alternative. See my other reply. And, btw, /usr/local/bin/do-mount: #!/usr/bin/suidperl # $ENV{'PATH'} = "/sbin:/usr/sbin:/bin:/usr/bin"; $cmd = "mount"; while($_ = $ARGV[0], /^-/) { shift; $verb=1, next if /^-v/ || /^-verbose/; $cmd = "umount", next if /^-u/ || /^-umount/; last if /^--/; &usage; } &usage unless $#ARGV == 0; if($ARGV[0] eq "od") { $type = "ufs"; $src = "/dev/od0a"; $dst = "/od"; } elsif($ARGV[0] eq "cd") { $type = "cd9660"; $src = "/dev/cd0a"; $dst = "/cd"; } elsif ($ARGV[0] eq "dos") { $type = "msdosfs"; $src = "/dev/fd0"; $dst = "/dos"; } elsif ($ARGV[0] =~ "^fd[0-9][.0-9]*") { $type = "msdosfs"; $src = "/dev/$ARGV[0]"; $dst = "/dos"; } else { &usage; } print "gonna $cmd $src " . ($cmd eq "mount"? "to": "from") . " $dst, type $type\n" if $verb; if($cmd eq "mount") {exec "/sbin/mount", "-t", $type, $src, $dst;} else {exec "/sbin/umount", $dst;} sub usage { die "usage: do-mount [-v[erbose]] [-u[mount]] cd|dos|fd*\n"; } Make it setuid root and simply say ``do-mount cd'' or ``do-mount -u cd''. Don't need to be root. (Yeah, i know, it has security holes. The drives should be mounted noexec,nosuid.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Aug 23 09:54:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id JAA12788 for current-outgoing; Wed, 23 Aug 1995 09:54:13 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id JAA12601 for ; Wed, 23 Aug 1995 09:48:29 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA26251; Wed, 23 Aug 1995 18:48:11 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id SAA19307 for current@freebsd.org; Wed, 23 Aug 1995 18:48:10 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id SAA17779 for current@freebsd.org; Wed, 23 Aug 1995 18:43:57 +0200 From: J Wunsch Message-Id: <199508231643.SAA17779@uriah.heep.sax.de> Subject: Re: Recent mount patches.. To: current@freebsd.org Date: Wed, 23 Aug 1995 18:43:55 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: from "j" at Aug 23, 95 06:25:45 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 861 Sender: current-owner@freebsd.org Precedence: bulk As I wrote: > > I decided to take the patch because I myself am tired of the system > > refusing to come up just because I don't have a CD in the drive, yet > > it's silly to have to type the whole mount command spec in as the > > only alternative. > > See my other reply. Update: I'm not running the default /etc/rc. Instead of tweaking the kernel, why didn't you simply convert: mount -u -o rw / if [ $? != 0 ]; then echo "Filesystem mount failed, startup aborted" exit 1 fi into mount -u -o rw -t nocd9660,msdos / if [ $? != 0 ]; then echo "Filesystem mount failed, startup aborted" exit 1 fi mount -a -t cd9660,msdos ??? As i wrote: should have been discussed before. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Aug 23 11:04:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA15456 for current-outgoing; Wed, 23 Aug 1995 11:04:51 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA15449 for ; Wed, 23 Aug 1995 11:04:46 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA09805; Wed, 23 Aug 1995 11:03:20 -0700 From: "Rodney W. Grimes" Message-Id: <199508231803.LAA09805@gndrsh.aac.dev.com> Subject: Re: Matrox Meteor Video Capture Card Driver To: james@miller.cs.uwm.edu (Jim Lowe) Date: Wed, 23 Aug 1995 11:03:19 -0700 (PDT) Cc: current@freebsd.org, se@ZPR.Uni-Koeln.DE, tinguely@plains.nodak.edu In-Reply-To: <199508231537.KAA26926@miller.cs.uwm.edu> from "Jim Lowe" at Aug 23, 95 10:37:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2063 Sender: current-owner@freebsd.org Precedence: bulk > > > From: "Rodney W. Grimes" > > > > The NCR runs it's firmware from the host memory, try cranking the PCI > > latency timer down for the NCR card and see if that helps. (This is > > in the PCI bios setup screen). Depending on motherboards (I happen > > to know what ``Triton'' board Jim just tried this in) there maybe > > 1 setting for all slots, or each slot may have it's own setting. > > > > Either way, crank it down to about 40 (default should be 80). > > > > From: se@zpr.uni-koeln.de (Stefan Esser) > > > > Did you try lower values of the "PCI Latency > > Timer" of the slot the Matrox has been put in ? > > > > (This timer determines the number of bus clocks > > a PCI card may claim ownerchip of the PCI bus, > > if another card wants to start a transfer. > > The NCR executes its instruction stream from > > host RAM, and it may get into trouble if it > > can only get another instruction every 10us ...) > > > > A latency timer setting of some 0x20 for the > > matrox should allow the NCR to access the bus > > once per micro second. Guess this is a good > > value ... > > > > (The latency timer doesn't force the PCI device > > to give up bus ownership if there is no request > > from another device and thus doesn't slow down > > the Matrox unless it makes the NCR starve ...) > > > > I tried lowering the PCI latency timer from 80 to 40, then to 20, then 1, > then 0. It helped me get a few frames at 640x480 before the machine > hung. I also tried disabling the cpu to pci burst mode. > > I have been running the meteor in a machine with and adaptec controller > for 5 days and it never hung. I am still not sure why the machine > hangs with the ncr controller. I am affraid to get a real picture of just what is going on here is going to require the use of a PCI bus analyzer :-(. I don't happen to have one of them, double :-(, :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 11:11:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA15901 for current-outgoing; Wed, 23 Aug 1995 11:11:49 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA15895 for ; Wed, 23 Aug 1995 11:11:45 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA09847; Wed, 23 Aug 1995 11:08:45 -0700 From: "Rodney W. Grimes" Message-Id: <199508231808.LAA09847@gndrsh.aac.dev.com> Subject: Re: Matrox Meteor Video Capture Card Driver To: se@ZPR.Uni-Koeln.DE (Stefan Esser) Date: Wed, 23 Aug 1995 11:08:45 -0700 (PDT) Cc: james@miller.cs.uwm.edu, current@freebsd.org In-Reply-To: <199508231549.AA18689@Sysiphos> from "Stefan Esser" at Aug 23, 95 05:49:07 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2116 Sender: current-owner@freebsd.org Precedence: bulk > > On Aug 23, 10:37, Jim Lowe wrote: > } Subject: Re: Matrox Meteor Video Capture Card Driver > } > From: "Rodney W. Grimes" > > } I tried lowering the PCI latency timer from 80 to 40, then to 20, then 1, > } then 0. It helped me get a few frames at 640x480 before the machine > } hung. I also tried disabling the cpu to pci burst mode. > > It takes some 10 cycles to arbitrate for the PCI bus > and to send the first data word. Numbers less than > 10 (decimal) are not too useful for this reason. Arbitration cycle counts occur _after_ latency timer expire. Numbers lower than 10 do help (but should not be need unless someone has left a fifo out of a high data rate card). A PCI latency timer of 0 says if someone says they would like to get on the bus and I am on the bus I get off _NOW_. Jim, when we talked on the phone the other day you said this board had a bunch of fifo's on it, how deep are they? Can you program depth and bus requests thresholds? > Is there any error message or other fault indication > than the system freezing ? > > } I have been running the meteor in a machine with and adaptec controller > } for 5 days and it never hung. I am still not sure why the machine > } hangs with the ncr controller. > > I take it the Adaptec above is an 2940 ? > > Could you please try having "ncrconsole -v -p 1" > run in another window. Watch the "pre" and "post" > times, which account for the time to initiate a > transfer and to retrieve the SCSI status. > > The lower limits for these numbers are the NCR and > disk drive SCSI overhead. The command overhead of > the NCR depends on its instruction execution rate > (usually in the low MIPS range). > > Do you have a NCR 53c815 or 825 to compare the 810 > results with ? > > One of the differences between the 8x0 and 8x5 is > the reading of instructions in burst mode, which > might help. If he ran this is Georges box it has an 825 in it. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 11:15:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA16280 for current-outgoing; Wed, 23 Aug 1995 11:15:45 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id LAA16274 for ; Wed, 23 Aug 1995 11:15:43 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA04797; Wed, 23 Aug 95 12:17:18 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508231817.AA04797@cs.weber.edu> Subject: Re: Recent mount patches.. To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 23 Aug 95 12:17:17 MDT Cc: current@freebsd.org In-Reply-To: <6525.809182915@time.cdrom.com> from "Jordan K. Hubbard" at Aug 23, 95 06:01:55 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > You'll need to rebuild all your mount_foo execs due to the change in > mount.h. Just FYI. > > I decided to take the patch because I myself am tired of the system > refusing to come up just because I don't have a CD in the drive, yet > it's silly to have to type the whole mount command spec in as the > only alternative. What did you change in mount.h? This is probably suboptimal... Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Aug 23 11:30:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA17023 for current-outgoing; Wed, 23 Aug 1995 11:30:31 -0700 Received: from Wit401402.student.utwente.nl (Wit401402.student.utwente.nl [130.89.236.162]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA17015 for ; Wed, 23 Aug 1995 11:30:27 -0700 Received: (from alain@localhost) by Wit401402.student.utwente.nl (8.6.12/8.6.9) id UAA00268; Wed, 23 Aug 1995 20:30:18 +0200 Date: Wed, 23 Aug 1995 20:30:18 +0200 (MET DST) From: Alain Kalker Reply-To: A.C.P.M.Kalker@student.utwente.nl To: current@freebsd.org Subject: IDE CDROM not working Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk Hi all. While trying to find out why my IDE CD-ROM isn't recognized, even though I am running a recent (Aug 21) -current kernel, I found this: - Even though the atapi and wcd drivers are compiled, they don't show up in the device list. - In the file /sys/i386/i386/autoconf.c, in structure try_cdrom[], there is no mention of the wcd device. (Hopefully this explains some of the problems people are having) Can anyone help me with this? -x- Alain From owner-freebsd-current Wed Aug 23 11:47:31 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA17687 for current-outgoing; Wed, 23 Aug 1995 11:47:31 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA17672 for ; Wed, 23 Aug 1995 11:47:28 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id LAA10129; Wed, 23 Aug 1995 11:45:57 -0700 From: "Rodney W. Grimes" Message-Id: <199508231845.LAA10129@gndrsh.aac.dev.com> Subject: Re: Recent mount patches.. To: terry@cs.weber.edu (Terry Lambert) Date: Wed, 23 Aug 1995 11:45:56 -0700 (PDT) Cc: jkh@time.cdrom.com, current@freebsd.org In-Reply-To: <9508231817.AA04797@cs.weber.edu> from "Terry Lambert" at Aug 23, 95 12:17:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 931 Sender: current-owner@freebsd.org Precedence: bulk > > > You'll need to rebuild all your mount_foo execs due to the change in > > mount.h. Just FYI. > > > > I decided to take the patch because I myself am tired of the system > > refusing to come up just because I don't have a CD in the drive, yet > > it's silly to have to type the whole mount command spec in as the > > only alternative. > > What did you change in mount.h? > > This is probably suboptimal... Bug #1, the include file sys/mount.h is a kernel interface definition file, the kernel has no need, nor does it care about -noall (currently bug #2 caused this to be missnamed -noauto). Bug #3 (not related to patch) -a is undocumented in the man page, it is listed in the SYNOPSIS section though, and referenced at least once in the man page in an example. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 11:51:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA17923 for current-outgoing; Wed, 23 Aug 1995 11:51:45 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id LAA17916 for ; Wed, 23 Aug 1995 11:51:43 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id LAA08857; Wed, 23 Aug 1995 11:51:40 -0700 To: current@freebsd.org, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Recent mount patches.. In-reply-to: Your message of "Wed, 23 Aug 1995 18:25:45 +0200." <199508231625.SAA17655@uriah.heep.sax.de> Date: Wed, 23 Aug 1995 11:51:40 -0700 Message-ID: <8854.809203900@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > Make it setuid root and simply say ``do-mount cd'' or ``do-mount -u > cd''. Don't need to be root. (Yeah, i know, it has security holes. > The drives should be mounted noexec,nosuid.) Very nice, but that's not what noauto tries to do! :) Jordan From owner-freebsd-current Wed Aug 23 12:38:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id MAA20042 for current-outgoing; Wed, 23 Aug 1995 12:38:18 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id MAA20035 for ; Wed, 23 Aug 1995 12:38:17 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA05078; Wed, 23 Aug 95 13:39:39 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508231939.AA05078@cs.weber.edu> Subject: Re: Recent mount patches.. To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Wed, 23 Aug 95 13:39:38 MDT Cc: jkh@time.cdrom.com, current@freebsd.org In-Reply-To: <199508231845.LAA10129@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Aug 23, 95 11:45:56 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > > > > > > You'll need to rebuild all your mount_foo execs due to the change in > > > mount.h. Just FYI. > > > > > > I decided to take the patch because I myself am tired of the system > > > refusing to come up just because I don't have a CD in the drive, yet > > > it's silly to have to type the whole mount command spec in as the > > > only alternative. > > > > What did you change in mount.h? > > > > This is probably suboptimal... > > Bug #1, the include file sys/mount.h is a kernel interface definition file, > the kernel has no need, nor does it care about -noall (currently bug #2 > caused this to be missnamed -noauto). > > Bug #3 (not related to patch) -a is undocumented in the man page, it > is listed in the SYNOPSIS section though, and referenced at least once > in the man page in an example. You didn't identify what you were responding to... this isn't a list of changes -- can I gather that this is a list of what you see as bugs in the changes? I assume this supports the contention that mount.h changes are not necessary to provide the described behaviour? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Aug 23 12:39:19 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id MAA20108 for current-outgoing; Wed, 23 Aug 1995 12:39:19 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id MAA20093 for ; Wed, 23 Aug 1995 12:39:17 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id MAA09251; Wed, 23 Aug 1995 12:38:26 -0700 To: terry@cs.weber.edu (Terry Lambert) cc: current@freebsd.org Subject: Re: Recent mount patches.. In-reply-to: Your message of "Wed, 23 Aug 1995 12:17:17 MDT." <9508231817.AA04797@cs.weber.edu> Date: Wed, 23 Aug 1995 12:38:26 -0700 Message-ID: <9249.809206706@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > What did you change in mount.h? > > This is probably suboptimal... See updated mail - the rebuild of mount_foo is NO LONGER necessary.. Jordan From owner-freebsd-current Wed Aug 23 14:18:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA24310 for current-outgoing; Wed, 23 Aug 1995 14:18:40 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA24302 for ; Wed, 23 Aug 1995 14:18:37 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA10457; Wed, 23 Aug 1995 14:16:57 -0700 From: "Rodney W. Grimes" Message-Id: <199508232116.OAA10457@gndrsh.aac.dev.com> Subject: Re: Recent mount patches.. To: terry@cs.weber.edu (Terry Lambert) Date: Wed, 23 Aug 1995 14:16:57 -0700 (PDT) Cc: jkh@time.cdrom.com, current@freebsd.org In-Reply-To: <9508231939.AA05078@cs.weber.edu> from "Terry Lambert" at Aug 23, 95 01:39:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1387 Sender: current-owner@freebsd.org Precedence: bulk > > > > > > > > > > You'll need to rebuild all your mount_foo execs due to the change in > > > > mount.h. Just FYI. > > > > > > > > I decided to take the patch because I myself am tired of the system > > > > refusing to come up just because I don't have a CD in the drive, yet > > > > it's silly to have to type the whole mount command spec in as the > > > > only alternative. > > > > > > What did you change in mount.h? > > > > > > This is probably suboptimal... > > > > Bug #1, the include file sys/mount.h is a kernel interface definition file, > > the kernel has no need, nor does it care about -noall (currently bug #2 > > caused this to be missnamed -noauto). > > > > Bug #3 (not related to patch) -a is undocumented in the man page, it > > is listed in the SYNOPSIS section though, and referenced at least once > > in the man page in an example. > > You didn't identify what you were responding to... this isn't a list > of changes -- can I gather that this is a list of what you see as bugs > in the changes? Yes. > > I assume this supports the contention that mount.h changes are not > necessary to provide the described behaviour? Yes. [I am being extreamly breif, too much to do, too little time to do it]. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 15:13:59 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA27575 for current-outgoing; Wed, 23 Aug 1995 15:13:59 -0700 Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA27569 for ; Wed, 23 Aug 1995 15:13:57 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id QAA13015 for ; Wed, 23 Aug 1995 16:54:57 -0500 Message-Id: <199508232154.QAA13015@chrome.onramp.net> X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol To: freebsd-current@freebsd.org Subject: State of the IDE CD ROM code Reply-To: jdl@chromatic.com Date: Wed, 23 Aug 1995 16:54:56 -0500 From: Jon Loeliger Sender: current-owner@freebsd.org Precedence: bulk Hi! Mail from Steve Schwarz (schwarz@alpharel.com) recently indicated that a while ago he placed some patches for the CDROM drive in ftp://ftp.freebsd.org/incoming/wcd11.tgz. Can someone confirm or deny that these patches were or were not applied to what is in the -current code? Not knowing the content of the patches (to inspect -current), nor being able to look into incoming, I've got no idea... Thanks, jdl From owner-freebsd-current Wed Aug 23 15:57:27 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA29106 for current-outgoing; Wed, 23 Aug 1995 15:57:27 -0700 Received: from fieber-john.campusview.indiana.edu (Fieber-John.campusview.indiana.edu [149.159.1.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA29100 for ; Wed, 23 Aug 1995 15:57:23 -0700 Received: (from jfieber@localhost) by fieber-john.campusview.indiana.edu (8.6.11/8.6.9) id RAA06762; Wed, 23 Aug 1995 17:57:06 -0500 From: John Fieber Message-Id: <199508232257.RAA06762@fieber-john.campusview.indiana.edu> Subject: Re: pedantic paul on compilation warnings To: pst@shockwave.com (Paul Traina) Date: Wed, 23 Aug 1995 17:57:05 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199508230551.WAA10314@precipice.shockwave.com> from "Paul Traina" at Aug 22, 95 10:51:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 675 Sender: current-owner@freebsd.org Precedence: bulk Paul Traina writes: > ...and most disturbingly, something has either gone very wrong with groff > and its macro packages, or we're getting really sloppy in the documentation. Either the documentation was bad from the beginning, or something is up with groff/macros. I don't think anybody has touched the docs. I'm not a [gtn]roff expert, (or even novice to be truthful) so I wouldn't bee too good at debugging. However, a quick scan would indicate that a great bulk of the warnings fall in just a few problem categories so it may not be quite as big of a job... (but then again, it might) -john === jfieber@cs.smith.edu ========== Come up and be a kite! --K. Bush === From owner-freebsd-current Wed Aug 23 16:07:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA29506 for current-outgoing; Wed, 23 Aug 1995 16:07:09 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA29500 for ; Wed, 23 Aug 1995 16:07:06 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id QAA10616; Wed, 23 Aug 1995 16:05:31 -0700 From: "Rodney W. Grimes" Message-Id: <199508232305.QAA10616@gndrsh.aac.dev.com> Subject: Re: pedantic paul on compilation warnings To: jfieber@grendel.csc.smith.edu (John Fieber) Date: Wed, 23 Aug 1995 16:05:31 -0700 (PDT) Cc: pst@shockwave.com, current@freebsd.org In-Reply-To: <199508232257.RAA06762@fieber-john.campusview.indiana.edu> from "John Fieber" at Aug 23, 95 05:57:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 976 Sender: current-owner@freebsd.org Precedence: bulk > > Paul Traina writes: > > ...and most disturbingly, something has either gone very wrong with groff > > and its macro packages, or we're getting really sloppy in the documentation. > > Either the documentation was bad from the beginning, or something > is up with groff/macros. I don't think anybody has touched the docs. > I'm not a [gtn]roff expert, (or even novice to be truthful) so I > wouldn't bee too good at debugging. However, a quick scan would > indicate that a great bulk of the warnings fall in just a few > problem categories so it may not be quite as big of a job... > (but then again, it might) Major part of the problem here is some one replaced the 4.4BSD provided macro sets with the groff ones. The groff ones are not up to snuff for the BSD documentation, which used BSD specific hacks :-(. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 16:38:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA00561 for current-outgoing; Wed, 23 Aug 1995 16:38:18 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA00554 for ; Wed, 23 Aug 1995 16:38:12 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id QAA03805; Wed, 23 Aug 1995 16:36:24 -0700 Message-Id: <199508232336.QAA03805@precipice.shockwave.com> To: "Rodney W. Grimes" cc: jfieber@grendel.csc.smith.edu (John Fieber), current@freebsd.org Subject: Re: pedantic paul on compilation warnings In-reply-to: Your message of "Wed, 23 Aug 1995 16:05:31 PDT." <199508232305.QAA10616@gndrsh.aac.dev.com> Date: Wed, 23 Aug 1995 16:36:24 -0700 From: Paul Traina Sender: current-owner@freebsd.org Precedence: bulk From: "Rodney W. Grimes" Subject: Re: pedantic paul on compilation warnings Major part of the problem here is some one replaced the 4.4BSD provided macro sets with the groff ones. The groff ones are not up to snuff for the BSD documentation, which used BSD specific hacks :-(. You're 1/2 right. 4.4BSD-Lite did NOT provide -ms macros, only -me macros, which is why we went through contortions to import groff-1.09 in time for FreeBSD 2.0. Paul From owner-freebsd-current Wed Aug 23 17:27:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA01815 for current-outgoing; Wed, 23 Aug 1995 17:27:38 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id RAA01808 for ; Wed, 23 Aug 1995 17:27:36 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id RAA10693; Wed, 23 Aug 1995 17:26:03 -0700 From: "Rodney W. Grimes" Message-Id: <199508240026.RAA10693@gndrsh.aac.dev.com> Subject: Re: pedantic paul on compilation warnings To: pst@shockwave.com (Paul Traina) Date: Wed, 23 Aug 1995 17:26:03 -0700 (PDT) Cc: jfieber@grendel.csc.smith.edu, current@freebsd.org In-Reply-To: <199508232336.QAA03805@precipice.shockwave.com> from "Paul Traina" at Aug 23, 95 04:36:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1079 Sender: current-owner@freebsd.org Precedence: bulk > > > From: "Rodney W. Grimes" > Subject: Re: pedantic paul on compilation warnings > > Major part of the problem here is some one replaced the 4.4BSD provided > macro sets with the groff ones. The groff ones are not up to snuff for > the BSD documentation, which used BSD specific hacks :-(. > > You're 1/2 right. > > 4.4BSD-Lite did NOT provide -ms macros, only -me macros, which is why > we went through contortions to import groff-1.09 in time for FreeBSD 2.0. You're 1/2 right too: .\" @@(#)tmac.s 8.1 (Berkeley) 6/8/93 .\" .\" If groff, use groff -ms, else use local -ms (w/ditroff, troff, nroff) .ie \n(.g \{\ . so /usr/share/tmac/tmac.groff_ms .\} .el \{\ . so /usr/old/lib/tmac/tmac.s .\} @ This is from the Attic of ~ncvs/src/share/tmac. Now, what happened to tmac.groff_ms??? gndrsh# locate tmac.groff /usr/share/tmac/tmac.groff_an gndrsh# -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Wed Aug 23 18:32:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA04310 for current-outgoing; Wed, 23 Aug 1995 18:32:08 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id SAA04302 for ; Wed, 23 Aug 1995 18:32:06 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <00911-0@bunyip.cc.uq.oz.au>; Thu, 24 Aug 1995 11:30:58 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id LAA00837 for ; Thu, 24 Aug 1995 11:35:28 +1000 Received: from localhost by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id BAA26345 for ; Thu, 24 Aug 1995 01:33:56 GMT Message-Id: <199508240133.BAA26345@netfl15a.devetir.qld.gov.au> X-Mailer: exmh version 1.6 4/21/95 To: current@freebsd.org Subject: How to add another disk (or slice/partitions/disklabels - confusion) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Aug 1995 11:33:55 +1000 From: Stephen Hocking Sender: current-owner@freebsd.org Precedence: bulk I'm having a lousy time trying to add another disk. The beast in question is a Quantum P105S, as SCSI ID 1. I have fdisk'd it, but cannot put a disklabel on it. I'm using disklabel -r -e /dev/rsd1, it pulls up something reasonable, and after filling in all the details it complains about not being able to write it back to the device. Any clues? Stephen I do not speak for the Worker's Compensation Board of Queensland - They don't pay me enough for that! From owner-freebsd-current Wed Aug 23 19:24:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA06356 for current-outgoing; Wed, 23 Aug 1995 19:24:51 -0700 Received: from unix10.pressimage.fr (unix10.pressimage.fr [194.2.222.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id TAA06350 for ; Wed, 23 Aug 1995 19:24:48 -0700 Received: from [194.150.2.33] (mon3-01.planete.net [194.150.2.33]) by unix10.pressimage.fr (8.6.12/8.6.12) with SMTP id EAA19050; Thu, 24 Aug 1995 04:24:11 +0200 X-Sender: jc@mail.pressimage.fr Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-NCC-RegID: fr.pressimage Date: Thu, 24 Aug 1995 04:24:10 +0200 To: Stephen Hocking From: jcaron@pressimage.net (Jacques Caron) Subject: Re: How to add another disk (or slice/partitions/disklabels - confusion) Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk At 11:33 24/08/95, Stephen Hocking wrote: >I'm having a lousy time trying to add another disk. The beast in question is a >Quantum P105S, as SCSI ID 1. I have fdisk'd it, but cannot put a disklabel on >it. I'm using disklabel -r -e /dev/rsd1, it pulls up something reasonable, and >after filling in all the details it complains about not being able to write it >back to the device. Any clues? Write to /dev/rsd1sx where x is the fdisk partition you use. I remember having lost quite a while (and some hair) trying to figure this out :-( And if disklabel spits out warnings about revolutions and whatever (equal to 0), just take those lines out in the file. Hope that helps, Jacques. +-------------------------+------------------------+ |Jacques Caron | Pressimage Telematique | |jcaron@pressimage.net | 5/7 rue Raspail | |Tel: +33 (1) 49 88 63 56 | 93108 Montreuil Cedex | |Fax: +33 (1) 49 88 63 64 | France | +-------------------------+------------------------+ From owner-freebsd-current Wed Aug 23 22:22:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id WAA14379 for current-outgoing; Wed, 23 Aug 1995 22:22:29 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id WAA14354 for ; Wed, 23 Aug 1995 22:22:25 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA01136; Thu, 24 Aug 1995 07:22:23 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id GAA03104 for freebsd-current@FreeBSD.org; Thu, 24 Aug 1995 06:24:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id XAA19879 for freebsd-current@FreeBSD.org; Wed, 23 Aug 1995 23:16:16 +0200 From: J Wunsch Message-Id: <199508232116.XAA19879@uriah.heep.sax.de> Subject: Re: Recent mount patches.. To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Wed, 23 Aug 1995 23:16:15 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <8854.809203900@time.cdrom.com> from "Jordan K. Hubbard" at Aug 23, 95 11:51:40 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 576 Sender: current-owner@FreeBSD.org Precedence: bulk As Jordan K. Hubbard wrote: > > > Make it setuid root and simply say ``do-mount cd'' or ``do-mount -u > > cd''. Don't need to be root. (Yeah, i know, it has security holes. > > The drives should be mounted noexec,nosuid.) > > Very nice, but that's not what noauto tries to do! :) But should suffice your (and my, of course :) laziness in that you don't have to enter that long command line (and don't even have to `su' first). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Aug 23 23:46:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA20533 for current-outgoing; Wed, 23 Aug 1995 23:46:18 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id XAA20271 for ; Wed, 23 Aug 1995 23:45:04 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA03034; Thu, 24 Aug 1995 08:43:16 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA03668; Thu, 24 Aug 1995 08:43:15 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA21971; Thu, 24 Aug 1995 08:32:44 +0200 From: J Wunsch Message-Id: <199508240632.IAA21971@uriah.heep.sax.de> Subject: Re: How to add another disk (or slice/partitions/disklabels - confusion) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Thu, 24 Aug 1995 08:32:44 +0200 (MET DST) Cc: sysseh@devetir.qld.gov.au Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: from "Jacques Caron" at Aug 24, 95 04:24:10 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 935 Sender: current-owner@FreeBSD.org Precedence: bulk As Jacques Caron wrote: > > >I'm using disklabel -r -e /dev/rsd1, it pulls up something reasonable,... > Write to /dev/rsd1sx where x is the fdisk partition you use. Always use the disklabel command with a simple disk name (`sd1'), and let it up to the command to figure out which device node to use. Btw., for drives that are dedicated to FreeBSD, the `old way' works quite well: don't care for the fdisk entries, setup an entry in /etc/disktab (start the partition at sector 0), and finally: disklabel -r -w sd1 mydiskname disklabel -B sd1 (The latter is needed to supress the ``Invalid partition table: no magic'' warning.) libdisk (that is used by sysinstall) should learn how to do this, too, so people with dedicated drives wouldn't have to undergo that damn DOS geometry hell. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Wed Aug 23 23:49:26 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA21255 for current-outgoing; Wed, 23 Aug 1995 23:49:26 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA21185 for ; Wed, 23 Aug 1995 23:49:09 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA21054; Thu, 24 Aug 1995 16:46:34 +1000 Date: Thu, 24 Aug 1995 16:46:34 +1000 From: Bruce Evans Message-Id: <199508240646.QAA21054@godzilla.zeta.org.au> To: current@freebsd.org, sysseh@devetir.qld.gov.au Subject: Re: How to add another disk (or slice/partitions/disklabels - confusion) Sender: current-owner@freebsd.org Precedence: bulk >I'm having a lousy time trying to add another disk. The beast in question is a >Quantum P105S, as SCSI ID 1. I have fdisk'd it, but cannot put a disklabel on >it. I'm using disklabel -r -e /dev/rsd1, it pulls up something reasonable, and >after filling in all the details it complains about not being able to write it >back to the device. Any clues? You can't put a label on the whole disk device. Labels can only be put on FreeBSD slices. The "whole" device for the first FreeBSD slice is /dev/rsd1c, which has a different minor number than /dev/rsd1, although it may cover the same area. /dev/rsd1 didn't exist before 2.0.5. The whole disk device was named /dev/rsd1c. The whole FreeBSD slice is still named /dev/rsd1c and everything internal to it works the same as before. All the examples in the disklabel man page are of the form disklabel ... sd1 ... ^ no dev disklabel ... /dev/rsd1c ... ^^^^^ ^ disklabel adds the `/dev/' and the `c' automatically if and only if the original device name is absolute (i.e., doesn't contain a slash). Don't use an absolute device name unless you want to override the default. Bruce From owner-freebsd-current Thu Aug 24 14:08:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA07073 for current-outgoing; Thu, 24 Aug 1995 14:08:03 -0700 Received: from po2.transarc.com (po2.transarc.com [192.54.226.2]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id OAA07067 for ; Thu, 24 Aug 1995 14:08:00 -0700 Received: by po2.transarc.com (5.54/3.15) id for current@freebsd.org; Thu, 24 Aug 95 17:07:55 EDT Received: via switchmail; Thu, 24 Aug 1995 17:07:54 -0400 (EDT) Received: from unix3 via qmail ID ; Thu, 24 Aug 1995 17:06:59 -0400 (EDT) Received: from unix3 via qmail ID ; Thu, 24 Aug 1995 17:06:52 -0400 (EDT) Received: from BatMail.robin.v2.12.CUILIB.3.45.SNAP.NOT.LINKED.unix3.sun4.40 via MS.5.6.unix3.sun4_40; Thu, 24 Aug 1995 17:06:51 -0400 (EDT) Message-Id: Date: Thu, 24 Aug 1995 17:06:51 -0400 (EDT) From: Pat_Barron@transarc.com To: current@freebsd.org Subject: "make -DCLOBBER world" broken again? Sender: current-owner@freebsd.org Precedence: bulk I just tried this for the first time in a while. It dies at this point: -------------------------------------------------------------- Rebuilding tools needed to build the libraries -------------------------------------------------------------- cd /usr/src/gnu/usr.bin/ld && make depend all install cleandir obj rm -f .depend files=""; if [ "$files" != "" ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 $files; fi files="/usr/src/gnu/usr.bin/ld/ld.c /usr/src/gnu/usr.bin/ld/symbol.c /usr/src/gnu/usr.bin/ld/lib.c /usr/src/gnu/usr.bin/ld/shlib.c /usr/src/gnu/usr.bin/ld/warnings.c /usr/src/gnu/usr.bin/ld/etc.c /usr/src/gnu/usr.bin/ld/rrs.c /usr/src/gnu/usr.bin/ld/xbits.c /usr/src/gnu/usr.bin/ld/i386/md.c"; if [ "$files" != "" ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 $files; fi files=" "; if [ "$files" != " " ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 $files; fi ===> ldconfig rm -f .depend files=""; if [ "$files" != "" ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld/ldconfig/.. -I/usr/src/gnu/usr.bin/ld/ldconfig -I/usr/src/gnu/usr.bin/ld/ldconfig/../i386 $files; fi files="/usr/src/gnu/usr.bin/ld/ldconfig/ldconfig.c /usr/src/gnu/usr.bin/ld/ldconfig/../shlib.c /usr/src/gnu/usr.bin/ld/ldconfig/../etc.c"; if [ "$files" != "" ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld/ldconfig/.. -I/usr/src/gnu/usr.bin/ld/ldconfig -I/usr/src/gnu/usr.bin/ld/ldconfig/../i386 $files; fi files=" "; if [ "$files" != " " ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld/ldconfig/.. -I/usr/src/gnu/usr.bin/ld/ldconfig -I/usr/src/gnu/usr.bin/ld/ldconfig/../i386 $files; fi ===> ldd rm -f .depend files=""; if [ "$files" != "" ]; then mkdep -a $files; fi files="/usr/src/gnu/usr.bin/ld/ldd/ldd.c"; if [ "$files" != "" ]; then mkdep -a $files; fi files=" "; if [ "$files" != " " ]; then mkdep -a $files; fi ===> rtld rm -f .depend files="/usr/src/gnu/usr.bin/ld/rtld/../i386/mdprologue.S"; if [ "$files" != "" ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld/rtld/.. -I/usr/src/gnu/usr.bin/ld/rtld -I/usr/src/gnu/usr.bin/ld/rtld/../i386 -DRTLD $files; fi files="/usr/src/gnu/usr.bin/ld/rtld/rtld.c /usr/src/gnu/usr.bin/ld/rtld/malloc.c /usr/src/gnu/usr.bin/ld/rtld/../shlib.c /usr/src/gnu/usr.bin/ld/rtld/../etc.c /usr/src/gnu/usr.bin/ld/rtld/../i386/md.c"; if [ "$files" != "" ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld/rtld/.. -I/usr/src/gnu/usr.bin/ld/rtld -I/usr/src/gnu/usr.bin/ld/rtld/../i386 -DRTLD $files; fi files=" "; if [ "$files" != " " ]; then mkdep -a -I/usr/src/gnu/usr.bin/ld/rtld/.. -I/usr/src/gnu/usr.bin/ld/rtld -I/usr/src/gnu/usr.bin/ld/rtld/../i386 -DRTLD $files; fi cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/ld.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/symbol.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/lib.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/shlib.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/warnings.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/etc.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/rrs.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/xbits.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -c /usr/src/gnu/usr.bin/ld/i386/md.c cc -O2 -m486 -pipe -I/usr/src/gnu/usr.bin/ld -I/usr/src/gnu/usr.bin/ld/i386 -Xlinker -Bstatic -o ld ld.o symbol.o lib.o shlib.o warnings.o etc.o rrs.o xbits.o md.o -lgnumalloc ld: -lgnumalloc: no match *** Error code 1 Stop. *** Error code 1 Stop. From owner-freebsd-current Thu Aug 24 16:32:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA11537 for current-outgoing; Thu, 24 Aug 1995 16:32:18 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id QAA11531 ; Thu, 24 Aug 1995 16:32:16 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA09192; Thu, 24 Aug 95 16:36:58 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508242236.AA09192@cs.weber.edu> Subject: sys/malloc.h To: hackers@FreeBSD.org, current@FreeBSD.org Date: Thu, 24 Aug 95 16:36:57 MDT X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk Some kernel memory allocation issues: 1) Does it seem to anyone else as if the statistic's gathering macros on the MALLOC/FREE are rather bizarre? 2) Has anyone else noticed the mixing of FREE/free on cn_pnbuf elements of nameidata structures? Doesn't this seem broken, considering the use of MALLOC in the non-'HASBUF' case for allocation in all cases in vfs_lookup.c? Won't this fail for the case of a kernel without either KMEMSTATS or DIAGNOSTIC defined? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Thu Aug 24 19:08:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA16509 for current-outgoing; Thu, 24 Aug 1995 19:08:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id TAA16490 ; Thu, 24 Aug 1995 19:08:24 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA25813; Fri, 25 Aug 1995 12:06:52 +1000 Date: Fri, 25 Aug 1995 12:06:52 +1000 From: Bruce Evans Message-Id: <199508250206.MAA25813@godzilla.zeta.org.au> To: current@FreeBSD.org, hackers@FreeBSD.org, terry@cs.weber.edu Subject: Re: sys/malloc.h Sender: current-owner@FreeBSD.org Precedence: bulk >1) Does it seem to anyone else as if the statistic's gathering > macros on the MALLOC/FREE are rather bizarre? The seem normal. The NON-statistics gathering parts have probably suffered from bitrot since they haven't been the default for so long. If splhigh() is necessary in malloc(), then splimp() is a bug in MALLOC()... >2) Has anyone else noticed the mixing of FREE/free on cn_pnbuf > elements of nameidata structures? Doesn't this seem broken, There are many other cases where they are mixed. This should not be a problem, since the two versions are supposed to be equivalent. The macro versions are supposed to be faster. Bruce From owner-freebsd-current Thu Aug 24 23:29:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA28564 for current-outgoing; Thu, 24 Aug 1995 23:29:45 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id XAA28556 for ; Thu, 24 Aug 1995 23:29:27 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA17848; Fri, 25 Aug 1995 08:27:00 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA13544 for freebsd-current@FreeBSD.org; Fri, 25 Aug 1995 08:27:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA01027 for freebsd-current@FreeBSD.org; Fri, 25 Aug 1995 08:04:44 +0200 From: J Wunsch Message-Id: <199508250604.IAA01027@uriah.heep.sax.de> Subject: Cron sh -c 'umask 0002; /usr/sbin/ctm /home/ctm/cvs-cur.*' (fwd) To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Fri, 25 Aug 1995 08:04:43 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1045 Sender: current-owner@FreeBSD.org Precedence: bulk Anyone else seen this? As Cron Daemon wrote: > Date: Fri, 25 Aug 1995 03:10:02 +0200 > Message-Id: <199508250110.DAA27649@uriah.heep.sax.de> > From: root (Cron Daemon) > To: j > Subject: Cron sh -c 'umask 0002; /usr/sbin/ctm /home/ctm/cvs-cur.*' (cvs-cur.1032.gz) > FN: src/sys/i386/isa/sio.c,v md5 mismatch. > FN: src/sys/i386/isa/sio.c,v edit fails. > Exit(104) > My sio.c,v has been last modified Aug 2, 1995: MD5 (/home/cvs/src/sys/i386/isa/sio.c,v) = e592b6a3d5e220c109276567aa76b02b ...and: 1.109 date 95.07.31.21.10.36; author bde; state Exp; branches; next 1.108; but CTM expects: CTMFN src/sys/i386/isa/sio.c,v 545 552 444 3943a32b14dce742c03447a030c04230 7353 d1 1 a1 1 head 1.111; a32 5 1.111 date 95.08.24.08.55.57; author phk; state Exp; branches; next 1.110; So two revisions are missing, even though the CTM sequence is ok??? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Thu Aug 24 23:48:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA00391 for current-outgoing; Thu, 24 Aug 1995 23:48:11 -0700 Received: from Tiger2.dorm10.nctu.edu.tw (Tiger2.Dorm10.NCTU.edu.tw [140.113.190.65]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA00376 for ; Thu, 24 Aug 1995 23:48:05 -0700 From: jdli@Tiger2.dorm10.nctu.edu.tw Received: (from jdli@localhost) by Tiger2.dorm10.nctu.edu.tw (8.6.12/8.6.9) id OAA13087 for freebsd-current@FreeBSD.ORG; Fri, 25 Aug 1995 14:48:55 +0800 Message-Id: <199508250648.OAA13087@Tiger2.dorm10.nctu.edu.tw> Subject: 2.2-current crash To: freebsd-current@FreeBSD.ORG Date: Fri, 25 Aug 1995 14:48:55 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 934 Sender: current-owner@FreeBSD.ORG Precedence: bulk FreeBSD FreeBSD 2.2-CURRENT #0: Fri Aug 25 01:14:25 CST 1995 Script started on Fri Aug 25 14:41:48 1995 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 1a4000 current pcb at 1941dc panic: page fault #0 0xf01670b5 in boot () (kgdb) where #0 0xf01670b5 in boot () #1 0xf010fca3 in panic () #2 0xf016c18e in trap_fatal () #3 0xf016bd00 in trap_pfault () #4 0xf016b9b7 in trap () #5 0xf0164b4d in calltrap () #6 0xf12244f8 in end () #7 0xf0127831 in getfsstat () #8 0xf016c377 in syscall () #9 0xf0164b9b in Xsyscall () #10 0x1c98 in ?? () #11 0x186e in ?? () #12 0x10e8 in ?? () (kgdb) quit exit Script done on Fri Aug 25 14:42:07 1995 From owner-freebsd-current Thu Aug 24 23:53:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA01077 for current-outgoing; Thu, 24 Aug 1995 23:53:21 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA01067 for ; Thu, 24 Aug 1995 23:53:19 -0700 Received: from corbin.Root.COM (corbin [198.145.90.34]) by Root.COM (8.6.11/8.6.5) with ESMTP id XAA10735; Thu, 24 Aug 1995 23:52:17 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id XAA14064; Thu, 24 Aug 1995 23:54:12 -0700 Message-Id: <199508250654.XAA14064@corbin.Root.COM> To: jdli@tiger2.dorm10.nctu.edu.tw cc: freebsd-current@freebsd.org Subject: Re: 2.2-current crash In-reply-to: Your message of "Fri, 25 Aug 95 14:48:55 +0800." <199508250648.OAA13087@Tiger2.dorm10.nctu.edu.tw> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 24 Aug 1995 23:54:06 -0700 Sender: current-owner@freebsd.org Precedence: bulk >#4 0xf016b9b7 in trap () >#5 0xf0164b4d in calltrap () >#6 0xf12244f8 in end () >#7 0xf0127831 in getfsstat () >#8 0xf016c377 in syscall () >#9 0xf0164b9b in Xsyscall () That looks like it is inside a VFS LKM. I suggest rebuilding/installing all of your LKM's, or better, building your kernel with all FS types static. -DG From owner-freebsd-current Fri Aug 25 00:02:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id AAA03443 for current-outgoing; Fri, 25 Aug 1995 00:02:40 -0700 Received: from mailhub.cts.com (mailhub.cts.com [192.188.72.25]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id AAA03434 for ; Fri, 25 Aug 1995 00:02:39 -0700 Received: from io.cts.com by mailhub.cts.com with smtp (Smail3.1.29.1 #18) id m0slsmj-000V0iC; Fri, 25 Aug 95 00:02 PDT Received: (from root@localhost) by io.cts.com (8.6.12/8.6.9) id AAA00370 for current@freebsd.org; Fri, 25 Aug 1995 00:02:35 -0700 From: Morgan Davis Message-Id: <199508250702.AAA00370@io.cts.com> Subject: PAS + Trantor CD-ROM Problems To: current@freebsd.org Date: Fri, 25 Aug 1995 00:02:35 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1703 Sender: current-owner@freebsd.org Precedence: bulk Looks like trouble with the PAS + Trantor SCSI CD-ROM support. I can mount data discs, but cannot play music CDs with cdplay, cdcontrol, etc. They keep dumping core. Here's a system profile if this helps: FreeBSD 2.2-CURRENT #0: Thu Aug 24 20:20:11 PDT 1995 root@io.cts.com:/usr/src/sys/compile/IO CPU: i486 DX2 (486-class CPU) Origin = "GenuineIntel" Id = 0x435 Stepping=5 Features=0x3 avail memory = 15097856 (3686 pages) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <5 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 9 on isa ed0: address 00:c0:0c:20:3f:80, type NE2000 (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 sio2 at 0x3e8-0x3ef irq 5 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 7 on isa sio3: type 16550A nca0 at 0x1f88-0x1f8b irq 12 on isa nca0: type ProAudioSpectrum-16 (nca0:1:0): "MEDIAVIS CDR-H93MV 1.41" type 5 removable SCSI 2 cd0(nca0:1:0): CD-ROM cd0(nca0:1:0): UNIT ATTENTION asc:28,0 cd0(nca0:1:0): Not ready to ready transition, medium may have changed cd present.[400000 x 2048 byte records] wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 406MB (832608 sectors), 826 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 406MB (832608 sectors), 826 cyls, 16 heads, 63 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in npx0 on motherboard npx0: INT 16 interface pas0 at 0x388 irq 10 drq 3 on isa pas0: opl0 at 0x38a on isa opl0: bpf: lo0 attached From owner-freebsd-current Fri Aug 25 00:07:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id AAA03903 for current-outgoing; Fri, 25 Aug 1995 00:07:57 -0700 Received: from mailhub.cts.com (mailhub.cts.com [192.188.72.25]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id AAA03897 for ; Fri, 25 Aug 1995 00:07:56 -0700 Received: from io.cts.com by mailhub.cts.com with smtp (Smail3.1.29.1 #18) id m0slsrr-000UzxC; Fri, 25 Aug 95 00:07 PDT Received: (from root@localhost) by io.cts.com (8.6.12/8.6.9) id AAA00382 for current@freebsd.org; Fri, 25 Aug 1995 00:07:53 -0700 From: Morgan Davis Message-Id: <199508250707.AAA00382@io.cts.com> Subject: Error in netstart To: current@freebsd.org Date: Fri, 25 Aug 1995 00:07:52 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 168 Sender: current-owner@freebsd.org Precedence: bulk There's an unterminated quote in /usr/src/etc/netstart: if [ "x$gateway" != "xNO ]; then echo 'configuring host as a gateway.' sysctl -w net.inet.ip.forwarding=1 fi From owner-freebsd-current Fri Aug 25 00:56:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id AAA07951 for current-outgoing; Fri, 25 Aug 1995 00:56:21 -0700 Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id AAA07920 for ; Fri, 25 Aug 1995 00:56:08 -0700 Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.6.11/8.6.9) id JAA00831 for freebsd-current@FreeBSD.org; Fri, 25 Aug 1995 09:54:08 +0200 From: John Hay Message-Id: <199508250754.JAA00831@zibbi.mikom.csir.co.za> Subject: Re: Cron sh -c 'umask 0002; /usr/sbin/ctm /home/ctm/cvs-cur.*' (fwd) To: freebsd-current@FreeBSD.org Date: Fri, 25 Aug 1995 09:54:08 +0200 (SAT) In-Reply-To: <199508250604.IAA01027@uriah.heep.sax.de> from "J Wunsch" at Aug 25, 95 08:04:43 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 701 Sender: current-owner@FreeBSD.org Precedence: bulk > > Anyone else seen this? > > As Cron Daemon wrote: > > Date: Fri, 25 Aug 1995 03:10:02 +0200 > > Message-Id: <199508250110.DAA27649@uriah.heep.sax.de> > > From: root (Cron Daemon) > > To: j > > Subject: Cron sh -c 'umask 0002; /usr/sbin/ctm /home/ctm/cvs-cur.*' > > (cvs-cur.1032.gz) > > > FN: src/sys/i386/isa/sio.c,v md5 mismatch. > > FN: src/sys/i386/isa/sio.c,v edit fails. > > Exit(104) > > Mine is OK. | 1995-08-25 07:28 ctm: > FN src/sys/i386/ibcs2/imgact_coff.c,v | 1995-08-25 07:28 ctm: > FN src/sys/i386/isa/sio.c,v | 1995-08-25 07:28 ctm: > FN src/sys/i386/linux/imgact_linux.c,v Maybe you did something to your cvs repository? -- John Hay -- jhay@mikom.csir.co.za From owner-freebsd-current Fri Aug 25 08:21:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA07432 for current-outgoing; Fri, 25 Aug 1995 08:21:09 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id IAA07424 for ; Fri, 25 Aug 1995 08:21:04 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA04001 for ; Fri, 25 Aug 1995 17:20:55 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id RAA15902 for freebsd-current@FreeBSD.org; Fri, 25 Aug 1995 17:20:54 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id OAA02041 for freebsd-current@FreeBSD.org; Fri, 25 Aug 1995 14:44:16 +0200 From: J Wunsch Message-Id: <199508251244.OAA02041@uriah.heep.sax.de> Subject: Re: Cron sh -c 'umask 0002; /usr/sbin/ctm /home/ctm/cvs-cur.*' (fwd) To: freebsd-current@FreeBSD.org Date: Fri, 25 Aug 1995 14:44:16 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org In-Reply-To: <199508250754.JAA00831@zibbi.mikom.csir.co.za> from "John Hay" at Aug 25, 95 09:54:08 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 699 Sender: current-owner@FreeBSD.org Precedence: bulk As John Hay wrote: > > > > FN: src/sys/i386/isa/sio.c,v md5 mismatch. > > > FN: src/sys/i386/isa/sio.c,v edit fails. > > > Exit(104) > > > > Mine is OK. > | 1995-08-25 07:28 ctm: > FN src/sys/i386/ibcs2/imgact_coff.c,v > | 1995-08-25 07:28 ctm: > FN src/sys/i386/isa/sio.c,v > | 1995-08-25 07:28 ctm: > FN src/sys/i386/linux/imgact_linux.c,v > Maybe you did something to your cvs repository? Not that i knew of. It must have been by accident, but _reverting_ revisions? Unlikely. Can somebody track which CTM deltas have recently changed sio.c? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 08:48:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id IAA09748 for current-outgoing; Fri, 25 Aug 1995 08:48:33 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id IAA09742 for ; Fri, 25 Aug 1995 08:48:29 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.11/8.6.9) with SMTP id IAA22485; Fri, 25 Aug 1995 08:47:09 -0700 To: Morgan Davis cc: current@freebsd.org Subject: Re: Error in netstart In-reply-to: Your message of "Fri, 25 Aug 1995 00:07:52 PDT." <199508250707.AAA00382@io.cts.com> Date: Fri, 25 Aug 1995 08:47:08 -0700 Message-ID: <22483.809365628@time.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@freebsd.org Precedence: bulk > There's an unterminated quote in /usr/src/etc/netstart: Yeargh! I *hate* that! Well, someone seems to have beaten me to the commit anyway, but thanks for pointing it out! Jordan From owner-freebsd-current Fri Aug 25 10:45:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA20131 for current-outgoing; Fri, 25 Aug 1995 10:45:09 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id KAA20106 for ; Fri, 25 Aug 1995 10:44:45 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA08582 for ; Fri, 25 Aug 1995 19:43:31 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA17588 for current@freebsd.org; Fri, 25 Aug 1995 19:43:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id TAA04434 for current@freebsd.org; Fri, 25 Aug 1995 19:40:34 +0200 From: J Wunsch Message-Id: <199508251740.TAA04434@uriah.heep.sax.de> Subject: Re: Request for bumping OSRELDATE To: current@freebsd.org Date: Fri, 25 Aug 1995 19:40:33 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: from "j" at Aug 22, 95 05:37:34 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 675 Sender: current-owner@freebsd.org Precedence: bulk As j wrote: > > The osreldate has been changed between 2.0 and 2.0.5, but not > afterwards. I desperately need a new version number now... > > Perhaps we should bump it now ``just in case'', to have a means of > testing against `` > 199504'', and correct it to the actual release > date right in time? (I think it's ok to leave it as it is for 2.1 > since only bug fixes are included, and no interface changes.) No reaction? If nobody objects, i would bump it to 199512 (certainly nobody would expect 2.2 before this point). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 15:20:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA05260 for current-outgoing; Fri, 25 Aug 1995 15:20:03 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA05254 for ; Fri, 25 Aug 1995 15:20:02 -0700 Received: from [171.69.56.246] (sj-f-2-dyn21.cisco.com [171.69.56.246]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id PAA10576; Fri, 25 Aug 1995 15:19:25 -0700 X-Sender: pst@precipice.shockwave.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Aug 1995 15:19:34 -0700 To: current@freebsd.org From: pst@shockwave.com (Paul Traina) Subject: Re: Request for bumping OSRELDATE Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk >No reaction? If nobody objects, i would bump it to 199512 (certainly >nobody would expect 2.2 before this point). No, that's the whole point of the osreldate. Bump it to TODAY please, and we can always bump it again before we ship. Comparisons are supposed to be <= and >=. Paul From owner-freebsd-current Fri Aug 25 16:18:30 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA08379 for current-outgoing; Fri, 25 Aug 1995 16:18:30 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id QAA08361 ; Fri, 25 Aug 1995 16:18:25 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13133; Fri, 25 Aug 95 17:20:05 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508252320.AA13133@cs.weber.edu> Subject: UNIFIED FILE SYSTEM PATCHES, PLEASE APPLY To: current@freebsd.org, hackers@freebsd.org Date: Fri, 25 Aug 95 17:20:04 MDT X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk I have just uploaded a set of patches that are general cleanup patches for file system related code, with special emphasis on cleanup of the use of the namei() interface. freefall.cdrom.com:~terry/UNI.diff.gz There is no README for this patch set. Mostly, these patches deal with using NDINIT() rather than manually initializing the equivalent pieves of the nameidata structure before passing the data to namei(). The biggest offenders in this area are the binary compatability modules. There are several places where the credentials were initialized from the proc being passed before namei was called. This is broken, since the first thing namei does is set the credentials from the process passed in anyway. These patches also prereserve two manifest constants for use in multibyte aware/capable file systems. This reservation has no effect on the operation of the code, though it does cause some integer bit values to be recoded as hexadecimal values. This is, in general, a good thing in any case. I've also patched flags checking of the mnt_maxsymlinklen field to use the macro for format detection, and renames the FSFMT to OFSFMT (apropriate, considering it returns "true" when the file system format is old and "false" when it is new). Finally, there are patches to dir.h to make the DIRSIZ macro independent of compiler structure alignment, internal changes to the dirent/direct structures, and support for sizing of non-struct direct objects. This last resolves a subtle bug in ufs_lookup.c regarding a possible 4 byte discrepancy in directory entries during compaction on mounts of pre-4.4 (FreeBSD 1.x) file systems. I went looking for it when my NetBSD 0.8 -> FreeBSD 2.x upgraded system started showing occasional directory corruption for files renamed from some name to some other name where newnamelen % 4 == 3. The change in the DIRSIZ macro results in *exactly the same assembly code* as the previous macro definition for an unmodified struct direct. THIS IS NOT ADDITIONAL OVERHEAD, EVEN THOUGH IT LOOKS LIKE IT IS -- THE COMPILER GENERATES THE SAME ASSEMBLY, SINCE A MULTIPLY BY A MANIFEST CONSTANT ONE IS ELIMINATED! Please commit these patches. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Aug 25 16:20:07 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA08571 for current-outgoing; Fri, 25 Aug 1995 16:20:07 -0700 Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA08550 for ; Fri, 25 Aug 1995 16:20:04 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id SAA21812 for ; Fri, 25 Aug 1995 18:19:39 -0500 Message-Id: <199508252319.SAA21812@chrome.onramp.net> X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol To: freebsd-current@freebsd.org Subject: That IDE CD ROM thang again... Reply-To: jdl@chromatic.com Date: Fri, 25 Aug 1995 18:19:39 -0500 From: Jon Loeliger Sender: current-owner@freebsd.org Precedence: bulk Well, I was never able to get my wdc1 controller recognized at all. Don't know why yet. However, with some cable re-routing, I placed the CD ROM on wdc0 as the slave device and I got: wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S atapi0.1 at 0x1f0: attach called wdc0: unit 1 (atapi): , removable, cmd16 wdc0: ATAPI hard disks not supported Turns out, I *did* have to byte-pair shuffle the ID string in order to get real "english"here. Naturally though, it's not a hard disk. Apparently the "type" of device is returned from an insw() call, vaguely like: char tb [DEV_BSIZE]; /* Obtain parameters. */ insw (port + AR_DATA, tb, sizeof(tb) / sizeof(short)); ap = malloc (sizeof *ap, M_TEMP, M_NOWAIT); bcopy (tb, ap, sizeof *ap); return (ap); Just after that we use ap->devtype, expecting it to be AT_TYPE_DIRECT (hard disk) or AT_TYPE_CDROM. Where can I find the description of what should be coming back from the insw() call to determine why it's not a CDROM drive? Sure I see: struct atapi_params { unsigned devtype : 5; /* packet command size */ #define AT_TYPE_DIRECT 0 /* direct-access (magnetic disk) */ #define AT_TYPE_TAPE 1 /* streaming tape (QIC-121 model) */ #define AT_TYPE_CDROM 5 /* CD-ROM device */ #define AT_TYPE_OPTICAL 7 /* optical disk */ } But it looks like the insw() causes the devtype to be a lie somehow... The obvious serious hack is to slam ap->devtype to be AT_TYPE_CDROM at some point, but that doesn't strike me as being reliable or long term. Anyone fix this or get further? Thanks, jdl From owner-freebsd-current Fri Aug 25 16:24:08 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA08940 for current-outgoing; Fri, 25 Aug 1995 16:24:08 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA08921 for ; Fri, 25 Aug 1995 16:23:57 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA14844 for ; Sat, 26 Aug 1995 01:22:37 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA20558 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 01:22:36 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id BAA06388 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 01:17:41 +0200 From: J Wunsch Message-Id: <199508252317.BAA06388@uriah.heep.sax.de> Subject: another 2.0.5 installation report To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 26 Aug 1995 01:17:40 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2329 Sender: current-owner@FreeBSD.org Precedence: bulk Well, after getting a new disk for my notebook -- it's actually second-hand, and it does already contain a working Linux installation. I've decided to keep the Linux by now, and rather install FreeBSD into that part of the disk that used to be /usr2 under Linux. Ok, fine, with the advent of the slice code, i should even be able to share Linux' swap slice. A few quirks with the installation procedure however: o Sharing a foreign slice and assigning it as swap seems to be impossible, even in wizard mode. o Using the existing swap slice by using two FreeBSD slices failed, since the original layout was: wd0s1: Linux root wd0s2: Linux swap ==> first FreeBSD slice (wd0s2b for swap) wd0s3: second FreeBSD slice (wd0s3a as /) The installation program didn't complain, but it failed to create the root file system since it's using the ``compat slice'' wd0a to create the root (hence it tried to newfs /dev/rwd0s2a). o I decided to shuffle the slices around in wizard mode (with the idea in mind to move Linux' idea of the swap from hda2 to hda4 finally), so the intented FreeBSD root comes first in the fdisk table. Bummer: since i wanted to keep the existing swap at the same location (well, for no good reason :), i've first created wd0s2 in wizard mode, but used the region of the disk physically located at the end, and i've finally assigned the remaining (intervening) sectors as wd0s3 (so it wouldn't become the compat slice). *Now* sysinstall complained that i could not use this region for a root file system. Strange. This decision has not been made based on the fdisk slot #, but on the physical location on the disk. (I've finally convinced it by deleting that slice, assigning /, and re-establishing the swap region.) My wishes: o it should be possible (at least in wizard mode) to assign an arbitrary region of the disk for swapping; in particular, the Linux swap is identifiable (ID 0x81) and could be offered as a valid swap slice in the first place :) o the decision whether a file system is acceptable as a root fs should be made based on the fdisk slot #, and not on the physical location on the disk -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 16:26:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id QAA09141 for current-outgoing; Fri, 25 Aug 1995 16:26:54 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id QAA09109 for ; Fri, 25 Aug 1995 16:26:43 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA14898 for ; Sat, 26 Aug 1995 01:26:18 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA20573 for current@freebsd.org; Sat, 26 Aug 1995 01:26:18 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id BAA06656 for current@freebsd.org; Sat, 26 Aug 1995 01:25:47 +0200 From: J Wunsch Message-Id: <199508252325.BAA06656@uriah.heep.sax.de> Subject: Re: Request for bumping OSRELDATE To: current@freebsd.org Date: Sat, 26 Aug 1995 01:25:45 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: from "Paul Traina" at Aug 25, 95 03:19:34 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 494 Sender: current-owner@freebsd.org Precedence: bulk As Paul Traina wrote: > > >No reaction? If nobody objects, i would bump it to 199512 (certainly > >nobody would expect 2.2 before this point). > No, that's the whole point of the osreldate. Bump it to TODAY please, and we > can always bump it again before we ship. Just to avoid misunderstanding: you mean i should make it 199508 (or ...09) now? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 17:04:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA10491 for current-outgoing; Fri, 25 Aug 1995 17:04:03 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id RAA10474 for ; Fri, 25 Aug 1995 17:03:26 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id KAA06264 for freebsd-current@freebsd.org; Sat, 26 Aug 1995 10:01:22 +1000 Date: Sat, 26 Aug 1995 10:01:22 +1000 From: Bruce Evans Message-Id: <199508260001.KAA06264@godzilla.zeta.org.au> To: freebsd-current@freebsd.org Subject: Re: another 2.0.5 installation report Sender: current-owner@freebsd.org Precedence: bulk >with the advent of the slice code, i should even be able to share >Linux' swap slice. >A few quirks with the installation procedure however: >o Sharing a foreign slice and assigning it as swap seems to be > impossible, even in wizard mode. I think swap still has to go on a labeled slice, perhaps even on the 'b' partition. You probably wouldn't want to label the foreign partition because the foreign swapper might overwrite the label. Labeling of foreign partitions is supported at the driver level. The only things special about "386BSD" partitions is that the first one becomes the compatibitity slice and a warning is printed for unlabeled ones. >o Using the existing swap slice by using two FreeBSD slices failed, > since the original layout was: > wd0s1: Linux root > wd0s2: Linux swap ==> first FreeBSD slice (wd0s2b for swap) > wd0s3: second FreeBSD slice (wd0s3a as /) > The installation program didn't complain, but it failed to create > the root file system since it's using the ``compat slice'' wd0a to > create the root (hence it tried to newfs /dev/rwd0s2a). If Linux swapping doesn't clobber the label then you can probably get this to work by first installing just a label on wd0s2 and then changing the partition type back to non-386BSD so that wd0s2 doesn't become the compatibility slice. >o I decided to shuffle the slices around in wizard mode (with the idea Anyway, this method will better when the bugs are fixed. >o it should be possible (at least in wizard mode) to assign an > arbitrary region of the disk for swapping; in particular, the Linux > swap is identifiable (ID 0x81) and could be offered as a valid swap > slice in the first place :) Linux swap is 0x82. The partition type indicator is not very reliable. Bruce From owner-freebsd-current Fri Aug 25 17:13:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA10984 for current-outgoing; Fri, 25 Aug 1995 17:13:57 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id RAA10978 for ; Fri, 25 Aug 1995 17:13:56 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13420; Fri, 25 Aug 95 18:15:36 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508260015.AA13420@cs.weber.edu> Subject: Re: another 2.0.5 installation report To: freebsd-current@FreeBSD.org Date: Fri, 25 Aug 95 18:15:35 MDT In-Reply-To: <199508252317.BAA06388@uriah.heep.sax.de> from "J Wunsch" at Aug 26, 95 01:17:40 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > o the decision whether a file system is acceptable as a root fs should > be made based on the fdisk slot #, and not on the physical location > on the disk That's impossible. You must always consider a file system unacceptable as a root fs if it spans or exceeds BIOS cylinder 1023. This is because the BIOS must read the kernel, and to do that, the kernel's blocks must be located in an area of the disk addressable by BIOS. If you are willing to throw out the ROM firmware for booting on your PC and replaces it with something that uses absolute sector rather than C/H/S values, well then, the limit goes up to 2^32 512 blocks, or at-or-below the 2TB range. If you do replace the boot firmware, may I suggest you implement OpenFirmware or Motorolla's "BUG" firmware? 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Aug 25 18:55:37 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA13165 for current-outgoing; Fri, 25 Aug 1995 18:55:37 -0700 Received: from randomc.com (ra1.randomc.com [205.160.16.20]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id SAA13159 ; Fri, 25 Aug 1995 18:55:35 -0700 Received: from masinter.randomc.com (masinter.randomc.com [205.160.21.159]) by randomc.com (8.6.10/8.6.10) with SMTP id VAA01264; Fri, 25 Aug 1995 21:55:15 -0400 Date: Sat, 26 Aug 95 01:46:39 EST From: "John F. Masinter" Subject: How do I quit this mail subscription? To: hackers-owner@freebsd.org, jkh@time.cdrom.com, hackers-owner@freebsd.org, hackers-owner@freebsd.org, hackers@freebsd.org, current@freebsd.org X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk Help! How do I quit this mail subscription? John F. Masinter From owner-freebsd-current Fri Aug 25 18:56:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA13376 for current-outgoing; Fri, 25 Aug 1995 18:56:51 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id SAA13370 for ; Fri, 25 Aug 1995 18:56:50 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13784; Fri, 25 Aug 95 19:58:30 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508260158.AA13784@cs.weber.edu> Subject: Re: Re(4): KERNEL PATCHES FOR NFS LOCKING SUPPORT (fwd) To: current@freebsd.org Date: Fri, 25 Aug 95 19:58:29 MDT X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk Andrew, who's working on the hard part of NFS locking, has pointed out some errors in my NFS locking patches. Here are the patches to correct the errors. They assume the previous patches have been applied. The comments or the if statements were correct, depending on your point of view. ---- Rats. I switched the copyin's -- you missed the "suser" returns 0 or EPERM -- 0 if it's root. And I missed 2 value compares and 2 copyin and 1 copyout swap. The point was for a non-root call or for a call with the non "remote" versions to use the old structure for the copyin/copyout for binary compatability with old root and non-root code, and to protect against proxy calls from non-root users. I knew I was going to out-clever myself here... I combined the cases at the last minute, and didn't save before generating the patch. 8-(. Here is a patch that fixes the oversights (3 of them!): ============================================================================== *** kern_descrip.c.BAD Fri Aug 25 18:38:20 1995 --- kern_descrip.c Fri Aug 25 18:45:51 1995 *************** *** 263,274 **** vp = (struct vnode *)fp->f_data; if( suser(p->p_ucred, &p->p_acflag) || ( uap->cmd == F_SETLKW) || ( uap->cmd == F_SETLK)) { /* Copy in the lock structure */ - error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof(flk)); - } else { /* non-root/non-remote*/ - /* Copy in the lock structure */ error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof(struct oflock)); flk.l_rsys = FLOCK_LOCAL_LOCK; flk.l_rpid = FLOCK_LOCAL_LOCK; } if (error) return (error); --- 263,274 ---- vp = (struct vnode *)fp->f_data; if( suser(p->p_ucred, &p->p_acflag) || ( uap->cmd == F_SETLKW) || ( uap->cmd == F_SETLK)) { /* Copy in the lock structure */ error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof(struct oflock)); flk.l_rsys = FLOCK_LOCAL_LOCK; flk.l_rpid = FLOCK_LOCAL_LOCK; + } else { /* root & remote*/ + /* Copy in the lock structure */ + error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof(flk)); } if (error) return (error); *************** *** 301,314 **** if (fp->f_type != DTYPE_VNODE) return (EBADF); vp = (struct vnode *)fp->f_data; ! if( suser(p->p_ucred, &p->p_acflag)) { ! /* Copy in the lock structure */ ! error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof (flk)); ! } else { /* non-root/non-remote*/ /* Copy in the lock structure */ error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof(struct oflock)); flk.l_rsys = FLOCK_LOCAL_LOCK; flk.l_rpid = FLOCK_LOCAL_LOCK; } if (error) return (error); --- 301,314 ---- if (fp->f_type != DTYPE_VNODE) return (EBADF); vp = (struct vnode *)fp->f_data; ! if( suser(p->p_ucred, &p->p_acflag) || ( uap->cmd == F_GETLK)) { /* Copy in the lock structure */ error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof(struct oflock)); flk.l_rsys = FLOCK_LOCAL_LOCK; flk.l_rpid = FLOCK_LOCAL_LOCK; + } else { /* root & remote*/ + /* Copy in the lock structure */ + error = copyin((caddr_t)uap->arg, (caddr_t)&flk, sizeof (flk)); } if (error) return (error); *************** *** 316,325 **** flk.l_start += fp->f_offset; if ((error = VOP_ADVLOCK(vp,(caddr_t)p,F_GETLK,&flk,F_POSIX))) return (error); ! if( suser(p->p_ucred, &p->p_acflag)) { ! return (copyout((caddr_t)&flk, (caddr_t)uap->arg, sizeof(flk))); ! } else { /* non-root/local*/ return (copyout((caddr_t)&flk, (caddr_t)uap->arg, sizeof(struct oflock))); } default: --- 316,325 ---- flk.l_start += fp->f_offset; if ((error = VOP_ADVLOCK(vp,(caddr_t)p,F_GETLK,&flk,F_POSIX))) return (error); ! if( suser(p->p_ucred, &p->p_acflag) || ( uap->cmd == F_GETLK)) { return (copyout((caddr_t)&flk, (caddr_t)uap->arg, sizeof(struct oflock))); + } else { /* root & remote*/ + return (copyout((caddr_t)&flk, (caddr_t)uap->arg, sizeof(flk))); } default: ============================================================================== Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Aug 25 19:00:41 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA13552 for current-outgoing; Fri, 25 Aug 1995 19:00:41 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id TAA13546 ; Fri, 25 Aug 1995 19:00:39 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13804; Fri, 25 Aug 95 20:02:05 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508260202.AA13804@cs.weber.edu> Subject: Re: How do I quit this mail subscription? To: masinter@randomc.com (John F. Masinter) Date: Fri, 25 Aug 95 20:02:04 MDT Cc: hackers-owner@freebsd.org, jkh@time.cdrom.com, hackers@freebsd.org, current@freebsd.org In-Reply-To: from "John F. Masinter" at Aug 26, 95 01:46:39 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > > Help! How do I quit this mail subscription? > > > John F. Masinter You should have received a message like the following for each of the lists you subscribed to: ====================================================================== Welcome to the freebsd-current mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "Majordomo@freebsd.org": unsubscribe freebsd-current masinter@randomc.com (John F. Masinter) Here's the general information for the list you've subscribed to, in case you don't already have it: [ ... ] ====================================================================== The "unsubscribe" line above assumes you provided the correct information in your mail message. Note that you *must* unsubscribe from the machine you subscribed from (for obvious reasons). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Fri Aug 25 19:21:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA14219 for current-outgoing; Fri, 25 Aug 1995 19:21:06 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id TAA14213 for ; Fri, 25 Aug 1995 19:21:04 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.12/8.6.12) with SMTP id TAA10889; Fri, 25 Aug 1995 19:20:29 -0700 Message-Id: <199508260220.TAA10889@precipice.shockwave.com> To: current@freebsd.org, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Request for bumping OSRELDATE In-reply-to: Your message of "Sat, 26 Aug 1995 01:25:45 +0200." <199508252325.BAA06656@uriah.heep.sax.de> Date: Fri, 25 Aug 1995 19:20:29 -0700 From: Paul Traina Sender: current-owner@freebsd.org Precedence: bulk From: J Wunsch Subject: Re: Request for bumping OSRELDATE As Paul Traina wrote: > > >No reaction? If nobody objects, i would bump it to 199512 (certainly > >nobody would expect 2.2 before this point). > No, that's the whole point of the osreldate. Bump it to TODAY please, and >>we > can always bump it again before we ship. Just to avoid misunderstanding: you mean i should make it 199508 (or ...09) now? Yes, exactly. Make it 08, NEVER make it higher than "today". -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 19:29:57 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id TAA14797 for current-outgoing; Fri, 25 Aug 1995 19:29:57 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id TAA14791 for ; Fri, 25 Aug 1995 19:29:55 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA04071; Fri, 25 Aug 1995 19:29:37 -0700 From: "Rodney W. Grimes" Message-Id: <199508260229.TAA04071@gndrsh.aac.dev.com> Subject: Re: Request for bumping OSRELDATE To: pst@shockwave.com (Paul Traina) Date: Fri, 25 Aug 1995 19:29:36 -0700 (PDT) Cc: current@freebsd.org, joerg_wunsch@uriah.heep.sax.de In-Reply-To: <199508260220.TAA10889@precipice.shockwave.com> from "Paul Traina" at Aug 25, 95 07:20:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 894 Sender: current-owner@freebsd.org Precedence: bulk > > > From: J Wunsch > Subject: Re: Request for bumping OSRELDATE > As Paul Traina wrote: > > > > >No reaction? If nobody objects, i would bump it to 199512 (certainly > > >nobody would expect 2.2 before this point). > > No, that's the whole point of the osreldate. Bump it to TODAY please, and > >>we > > can always bump it again before we ship. > > Just to avoid misunderstanding: you mean i should make it 199508 > (or ...09) now? > > Yes, exactly. Make it 08, NEVER make it higher than "today". I will affirm this possition. Setting OSRELDATE to the future is a really nasty thing to do. As is doing #ifdef's based upon an unassigned numbers (something in pcvt comes to mind). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Fri Aug 25 23:46:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA23387 for current-outgoing; Fri, 25 Aug 1995 23:46:09 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA23381 for ; Fri, 25 Aug 1995 23:46:07 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01624 for ; Sat, 26 Aug 1995 08:46:04 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA23941 for current@freebsd.org; Sat, 26 Aug 1995 08:46:04 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id HAA09356 for current@freebsd.org; Sat, 26 Aug 1995 07:55:53 +0200 From: J Wunsch Message-Id: <199508260555.HAA09356@uriah.heep.sax.de> Subject: Re: Request for bumping OSRELDATE To: current@freebsd.org Date: Sat, 26 Aug 1995 07:55:52 +0200 (MET DST) Reply-To: current@freebsd.org In-Reply-To: <199508260229.TAA04071@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Aug 25, 95 07:29:36 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1373 Sender: current-owner@freebsd.org Precedence: bulk As Rodney W. Grimes wrote: > > > Yes, exactly. Make it 08, NEVER make it higher than "today". ok. > I will affirm this possition. Setting OSRELDATE to the future is > a really nasty thing to do. As is doing #ifdef's based upon an > unassigned numbers (something in pcvt comes to mind). 2.0.5 has been an "assigned number" by the time when i've started to put the #ifdef's there -- remember, it has even been CVS tagged. The error was to remove a CVS tag (which should IMHO never be done, even if the tag remains unused since the release never happens). CVS(1) CVS(1) NAME cvs - Concurrent Versions System ... tag [-lQqR] [-b] [-d] symbolic_tag [files...] ... If you use `cvs tag -d symbolic_tag...', the sym- bolic tag you specify is deleted instead of being added. Warning: Be very certain of your ground ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ before you delete a tag; doing this effectively ^^^^^^^^^^^^^^^^^^^^^^^^^^^ discards some historical information, which may later turn out to have been valuable. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 23:47:35 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA23486 for current-outgoing; Fri, 25 Aug 1995 23:47:35 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA23478 for ; Fri, 25 Aug 1995 23:47:33 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01663; Sat, 26 Aug 1995 08:47:29 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA23955; Sat, 26 Aug 1995 08:47:29 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA09444; Sat, 26 Aug 1995 08:13:28 +0200 From: J Wunsch Message-Id: <199508260613.IAA09444@uriah.heep.sax.de> Subject: Re: That IDE CD ROM thang again... To: jdl@chromatic.com Date: Sat, 26 Aug 1995 08:13:27 +0200 (MET DST) Cc: freebsd-current@freebsd.org Reply-To: freebsd-current@freebsd.org In-Reply-To: <199508252319.SAA21812@chrome.onramp.net> from "Jon Loeliger" at Aug 25, 95 06:19:39 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 987 Sender: current-owner@freebsd.org Precedence: bulk As Jon Loeliger wrote: > > Well, I was never able to get my wdc1 controller recognized at all. > Don't know why yet. Since it's not a controller? Usually, a wdc "controller" will only be recognized if there's a disk attached, since it's actually the disk that is answering on the bus. > Turns out, I *did* have to byte-pair shuffle the ID string in order > to get real "english"here. > > Naturally though, it's not a hard disk. Apparently the "type" of > device is returned from an insw() call, vaguely like: I think it's in error to byte-shuffle only the ID string. Everything from the drive must be byte-swapped, including the ID word and all data. (Of course, you have to make a distinction whether to swap or not before.) Disclaimer: i don't own an ATAPI CD, and the only wdc-style drive i'm still operating sits in my notebook. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 23:47:38 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA23508 for current-outgoing; Fri, 25 Aug 1995 23:47:38 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA23485 for ; Fri, 25 Aug 1995 23:47:35 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01673 for ; Sat, 26 Aug 1995 08:47:32 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA23957 for freebsd-current@freebsd.org; Sat, 26 Aug 1995 08:47:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA09489 for freebsd-current@freebsd.org; Sat, 26 Aug 1995 08:31:43 +0200 From: J Wunsch Message-Id: <199508260631.IAA09489@uriah.heep.sax.de> Subject: Re: another 2.0.5 installation report To: freebsd-current@freebsd.org Date: Sat, 26 Aug 1995 08:31:43 +0200 (MET DST) Reply-To: freebsd-current@freebsd.org In-Reply-To: <199508260001.KAA06264@godzilla.zeta.org.au> from "Bruce Evans" at Aug 26, 95 10:01:22 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 817 Sender: current-owner@freebsd.org Precedence: bulk As Bruce Evans wrote: > > I think swap still has to go on a labeled slice, perhaps even on the 'b' > partition. You probably wouldn't want to label the foreign partition > because the foreign swapper might overwrite the label. Hmm. By now, it works... let's see. > Linux swap is 0x82. The partition type indicator is not very reliable. Yes. Yes. :) ...yup, you're right. The swaps cannot be shared without workarounds. Sigh, so i have to write an fdisk/disklabel command in FreeBSD's /etc/rc, and a mkswap command in Linux' /etc/rc. (I don't have an idea why they do wanna know the `length' parameter for this command, even when applied to a physical partition.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Fri Aug 25 23:47:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA23521 for current-outgoing; Fri, 25 Aug 1995 23:47:40 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA23500 for ; Fri, 25 Aug 1995 23:47:37 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA01681 for ; Sat, 26 Aug 1995 08:47:34 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA23959 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 08:47:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA09535 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 08:36:51 +0200 From: J Wunsch Message-Id: <199508260636.IAA09535@uriah.heep.sax.de> Subject: Re: another 2.0.5 installation report To: freebsd-current@FreeBSD.org Date: Sat, 26 Aug 1995 08:36:50 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org In-Reply-To: <9508260015.AA13420@cs.weber.edu> from "Terry Lambert" at Aug 25, 95 06:15:35 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 559 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > o the decision whether a file system is acceptable as a root fs should > > be made based on the fdisk slot #, and not on the physical location > > on the disk > > That's impossible. > > You must always consider a file system unacceptable as a root fs if it > spans or exceeds BIOS cylinder 1023. No point here, the disk fakes to have 1024 cylinders. The above is really a bug. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Aug 26 06:48:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id GAA18473 for current-outgoing; Sat, 26 Aug 1995 06:48:20 -0700 Received: from chrome.onramp.net (chrome.onramp.net [199.1.166.202]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id GAA18467 for ; Sat, 26 Aug 1995 06:48:18 -0700 Received: from localhost.jdl.com (localhost.jdl.com [127.0.0.1]) by chrome.onramp.net (8.6.11/8.6.9) with SMTP id IAA25153; Sat, 26 Aug 1995 08:47:50 -0500 Message-Id: <199508261347.IAA25153@chrome.onramp.net> X-Authentication-Warning: chrome.onramp.net: Host localhost.jdl.com didn't use HELO protocol To: freebsd-current@freebsd.org, joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: That IDE CD ROM thang again... In-reply-to: Your message of "Sat, 26 Aug 1995 08:13:27 +0200." <199508260613.IAA09444@uriah.heep.sax.de> Reply-To: jdl@chromatic.com Clarity-Index: null Threat-Level: none Software-Engineering-Dead-Seriousness: There's no excuse for unreadable code. Net-thought: If you meet the Buddha on the net, put him in your Kill file. Date: Sat, 26 Aug 1995 08:47:50 -0500 From: Jon Loeliger Sender: current-owner@freebsd.org Precedence: bulk Apparently, J Wunsch scribbled: > As Jon Loeliger wrote: > > > > Well, I was never able to get my wdc1 controller recognized at all. > > Don't know why yet. > > Since it's not a controller? Usually, a wdc "controller" will only be > recognized if there's a disk attached, since it's actually the disk > that is answering on the bus. Well, yea, I think I understand that, but I used to have: controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus device wcd0 #IDE CD-ROM My boot logs showed it trying the CDROM on wdc0 even before wdc1 was reported NOT present. Aug 24 09:08:07 zinc /kernel: wdc0 at 0x1f0-0x1f7 irq 14 on isa Aug 24 09:08:07 zinc /kernel: wdc0: unit 0 (wd0): Aug 24 09:08:07 zinc /kernel: wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S Aug 24 09:08:07 zinc /kernel: atapi0.1 at 0x1f0: attach called Aug 24 09:08:07 zinc /kernel: atapi.1 at 0x1f0: identify not ready, status=1 Aug 24 09:08:08 zinc /kernel: wdc1 not found at 0x170 Steve Wallace and I mumbled about it like this: Apparently, Steven Wallace scribbled: > > Umm, you only have ONE IDE hard disk and ONE IDE CDROM? > I was under the impression you had two ide hard disks. > So you have one on each controller, eh? That should be okay, me: Well, I might have confused you some.... (Nah!) I actually have occasion to use two drives on this machine, so the second comes and goes as needed. It currently wasn't present, but the kernel silently allowed for it and just didn't find it. So, thinking that it might be confusing things, I did a round where I removed the second disk entry from the kernel to more accurately reflect the expected hardware. > but I notieced your prob: > wdc1 not found at 0x170 > > It should still recognize the controller, even if it has probs > on the atapi. Check your port and IRQ settings. Will do. I know that I can use this full configuration under lovely 'doze 95, so I'm pretty sure that the hardware itself is all playing together nicely. I'm NOT sure that I've correctly converted it to FreeBSD config lingo... The 'doze 95 poking reveals this: IDE controller (PCI) IRQ 14 0x1f0-1f7, 0x3f6-3f6 IDE controller standard IRQ 15 0x170-177, 0x376-376 I think I converted this to: controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr He then suggested the approach of making the CD ROM a slave drive, which has worked and gotten me this far... > I think it's in error to byte-shuffle only the ID string. Everything > from the drive must be byte-swapped, including the ID word and all > data. Oh my! OK, I'll give this a hack attack and see what I get. Any chance you can give me a one minute pointer to *where* that might take place? Like, where the buffers coming back from the drive are filled? I see the one in _probe() that's obtained with the insw(). Will they all look like that? > (Of course, you have to make a distinction whether to swap or > not before.) Yea, this is curious. I get the feeling that some people are able to get the IDE CD drives to work and others aren't. Is there some reasonable distinction separating the two camps? Do we need to start a collection of working/not-working drives and form the basis of a boot time lookup table (ick) to determine byte-swapping needs? > Disclaimer: i don't own an ATAPI CD, and the only wdc-style drive > i'm still operating sits in my notebook. OK, so you're lucky. :-) jdl From owner-freebsd-current Sat Aug 26 13:15:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA29212 for current-outgoing; Sat, 26 Aug 1995 13:15:06 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id NAA29198 for ; Sat, 26 Aug 1995 13:15:04 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA15822; Sat, 26 Aug 95 14:16:44 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508262016.AA15822@cs.weber.edu> Subject: Re: another 2.0.5 installation report To: freebsd-current@FreeBSD.org Date: Sat, 26 Aug 95 14:16:43 MDT In-Reply-To: <199508260636.IAA09535@uriah.heep.sax.de> from "J Wunsch" at Aug 26, 95 08:36:50 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > > > o the decision whether a file system is acceptable as a root fs should > > > be made based on the fdisk slot #, and not on the physical location > > > on the disk > > > > That's impossible. > > > > You must always consider a file system unacceptable as a root fs if it > > spans or exceeds BIOS cylinder 1023. > > No point here, the disk fakes to have 1024 cylinders. > > The above is really a bug. 1) Not all BIOS does translation. 2) Not all translation is equal. 3) You can't pound 9G of 512B sectors into 24 bits, no way, no how; the max is, and will remain, 8G, assuming you burn all C/H/S bits available to you. 4) Some BIOS are going to make the decision for you. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Aug 26 13:42:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA00340 for current-outgoing; Sat, 26 Aug 1995 13:42:40 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA00330 for ; Sat, 26 Aug 1995 13:42:36 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA18046 for ; Sat, 26 Aug 1995 22:42:32 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA28085 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 22:42:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id WAA16990 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 22:29:32 +0200 From: J Wunsch Message-Id: <199508262029.WAA16990@uriah.heep.sax.de> Subject: my Linux swap partition again To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sat, 26 Aug 1995 22:29:31 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 636 Sender: current-owner@FreeBSD.org Precedence: bulk Well, trying to automate the swap partition sharing... Funny: fdisk -i /dev/rwd0 >/dev/null 2>&1 < always fails: disklabel: ioctl DIOCSDINFO: Label magic number or checksum is wrong! (disklabel or kernel is out of date?) Any hints? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Aug 26 13:53:14 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA00982 for current-outgoing; Sat, 26 Aug 1995 13:53:14 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA00970 for ; Sat, 26 Aug 1995 13:53:05 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA18211 for ; Sat, 26 Aug 1995 22:52:55 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA28154 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 22:52:55 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id WAA17362 for freebsd-current@FreeBSD.org; Sat, 26 Aug 1995 22:52:26 +0200 From: J Wunsch Message-Id: <199508262052.WAA17362@uriah.heep.sax.de> Subject: Re: another 2.0.5 installation report To: freebsd-current@FreeBSD.org Date: Sat, 26 Aug 1995 22:52:26 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org In-Reply-To: <9508262016.AA15822@cs.weber.edu> from "Terry Lambert" at Aug 26, 95 02:16:43 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1280 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > You must always consider a file system unacceptable as a root fs if it > > > spans or exceeds BIOS cylinder 1023. > > > > No point here, the disk fakes to have 1024 cylinders. > > > > The above is really a bug. > > 1) Not all BIOS does translation. It's an IDE translation, btw. Anyway, you've been missing my point. In one occasion, sysinstall errouneously prevented me from using the inner partition as root, even though it would have been possible. In another case, it didn't tell me anything, but i finally got stuck with an unusable root file system, since it was in the second FreeBSD slice, and sysinstall attempted to newfs in the `compatibility' slice (which is the same the boot loader would use). I guess the above is totally unrelated to the magic 1024 cylinder number, sysinstall _intents_ to be smart about the problems with the compat slice, but it's got it wrong (decision being made based on the location of the data cylinders on the disk, instead of based on the fdisk slot # as it ought to be -- remember, the compat slice it the first FreeBSD slice as seen in the fdisk table). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Aug 26 14:05:49 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA01699 for current-outgoing; Sat, 26 Aug 1995 14:05:49 -0700 Received: from silver.sms.fi (silver.sms.fi [194.111.122.1]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA01690 for ; Sat, 26 Aug 1995 14:05:47 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id AAA24293; Sun, 27 Aug 1995 00:05:44 +0300 Date: Sun, 27 Aug 1995 00:05:44 +0300 Message-Id: <199508262105.AAA24293@silver.sms.fi> From: Petri Helenius To: freebsd-current@freebsd.org Subject: traceroute fix Sender: current-owner@freebsd.org Precedence: bulk Is there any opinions on bringing the traceroute-timer fix also to 2.1-stable? It's really not essistential but definetly a non-feature bugfix. Pete From owner-freebsd-current Sat Aug 26 14:09:18 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA01888 for current-outgoing; Sat, 26 Aug 1995 14:09:18 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA01871 for ; Sat, 26 Aug 1995 14:08:56 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA17016; Sun, 27 Aug 1995 07:06:11 +1000 Date: Sun, 27 Aug 1995 07:06:11 +1000 From: Bruce Evans Message-Id: <199508262106.HAA17016@godzilla.zeta.org.au> To: current@freebsd.org Subject: nfs panic after changing cd's Cc: dfr@render.com Sender: current-owner@freebsd.org Precedence: bulk My nfs client paniced with a null pointer somewhere in nfs_statfs() or thereabouts. The server printed: Aug 26 23:13:48 alphplex /kernel: fhtovp: file start miss 142213208 vs 60 Aug 26 23:13:51 alphplex last message repeated 2 times This message is from cd9660_vfsops.c (which prints a lot of similar messages without identifying itself). My cdrom had been changed. Usually I mount it at boot time and export it and never change it and have no problems with cd9660 vs nfs. I think this bug is known. It maybe the same as the one reported a day or two ago where the panic occurred in an lkm'ed file system so that it wasn't obvious what it was for. Bruce From owner-freebsd-current Sat Aug 26 14:33:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA02696 for current-outgoing; Sat, 26 Aug 1995 14:33:51 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA02655 for ; Sat, 26 Aug 1995 14:33:42 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA17541; Sun, 27 Aug 1995 07:28:28 +1000 Date: Sun, 27 Aug 1995 07:28:28 +1000 From: Bruce Evans Message-Id: <199508262128.HAA17541@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, j@uriah.heep.sax.de Subject: Re: my Linux swap partition again Sender: current-owner@freebsd.org Precedence: bulk >Well, trying to automate the swap partition sharing... >fdisk -i /dev/rwd0 >/dev/null 2>&1 <... >Does here somebody say we'd need a command-line modus for fdisk? :--) And a robust version of fdisk... >Anyway, i can succesfully re-convert Linux' swap partition into a >valid FreeBSD slice by the above, but >disklabel -r -w wd0s3 >always fails: >disklabel: ioctl DIOCSDINFO: Label magic number or checksum is wrong! >(disklabel or kernel is out of date?) fdisk doesn't synchronize the changes with the kernel, so there are problems if wd0s3 doesn't already exist or if you changed its size. sysinstall uses the DIOCSYNCSLICEINFO ioctl to sync. You can also sync by closing all minors on the disk, but this is impossible if the device has root or swap on it. wd0s3 must have existed for disklabel to get as far as the DIOCSDINFO attempt, so perhaps you gave the wrong size to fdisk, or is inconsistent. The fdisk step shouldn't be necessary. Just write a label. Bruce From owner-freebsd-current Sat Aug 26 14:37:54 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA03139 for current-outgoing; Sat, 26 Aug 1995 14:37:54 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id OAA03124 for ; Sat, 26 Aug 1995 14:37:50 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA16296; Sat, 26 Aug 95 15:39:30 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508262139.AA16296@cs.weber.edu> Subject: Re: another 2.0.5 installation report To: freebsd-current@FreeBSD.org Date: Sat, 26 Aug 95 15:39:29 MDT In-Reply-To: <199508262052.WAA17362@uriah.heep.sax.de> from "J Wunsch" at Aug 26, 95 10:52:26 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk > It's an IDE translation, btw. Anyway, you've been missing my point. > In one occasion, sysinstall errouneously prevented me from using the > inner partition as root, even though it would have been possible. I guess the question here is "how is FreeBSD supposed to know the BIOS translation being used so that it can enforce the right behaviour". The answer is "it can't unless it does it's own I/O via the BIOS instead of a protected mode driver -- it can only guess". Your problem seems to be that it is guessing wrong for you; any suggestions on how it can be made to guess correctly? The only one I can see is providing a VM86() fallback driver, doing INT 13 AH=0x8n for all drives, and then MD5 checksumming areas of each disk so that they can be matches to the same areas checksummed after having been read by the protected mode driver. Even then, some of the techniques described below would be needed to avoid potentially confusing the driver with backup partitions that MD5 out to the same numbers. Remember that the BSD driver can't convert the C/H/S values from the partition table into sector offsets -- or convert a setor offset into a C/H/S value -- without knowing the translation being applied by the controller to C/H/S values presented by the BIOS. Remember further that though the BIOS geometry of the drive can be potentially determined from the drive paramter area in low core or elsewhere, there is no way to ensure that the INT 13 hook order for the drives is the same as the protected mode driver probe order. That is, I can find out the translation for drive 0x80, or even 0x8n for an INT 13 AH=8 call to the BIOS that hooks for the particular drive ID I am interested in, but there is no way for me to match that up with the drives that respond to BSD's probe requests from the protected mode driver. The INT 13 hook order for, for instance, two AHA1542CF controllers, or an IDE controller and a 1542CF controller (which is what determines the BIOS drive ID's attached to each controller) is dependent on POST routine card initialization order. The order BSD's protected mode drivers present to the kernel is based on the probe order, which is base on the order the controllers appear in the conf file used to build the kernel. Further, even if the orders were identical, and controllers in the config were put there in slot initialization order (which is not identical from motherboard to motherboard), there are some controllers that would hook INT 13 and have BIOS support for which there are no BSD drivers available. Now although Adaptec allows otherwise, the boot order in BIOS by default without tweaking the factory defaults on your Adaptec will be BIOS drive ID 0x80 followed by ID 0x81. This is the same problem with the "boot from second drive" that the MBR replacements face. Once the kernel is up, how can it identify the drive that it was loaded from other than via BIOS drive ID? The typical approach is to go through the attached controllers attached drives one by one until you find a BSD partition ID and assume that that's the one. An extra "fix" of making sure the partition is marked active is probably a good idea. Actually, a date stamp in the disklabel written by the MBR replacement when it is used to boot a BSD drive would probably be best, with a probe search that goes through all possible BSD partitions looking for the most recent timestamp. This isn't done currently, and still would not work in all cases anyway; see below for "why not?". > In another case, it didn't tell me anything, but i finally got stuck > with an unusable root file system, since it was in the second FreeBSD > slice, and sysinstall attempted to newfs in the `compatibility' slice > (which is the same the boot loader would use). I don't recognize the term "compatability slice". I assume you mean that it newfs'ed the DOS slice or something? The above linear search and disklabel timestamp would mostly fix this case, though you would potentially be screwed on a reinstall. > I guess the above is totally unrelated to the magic 1024 cylinder > number, sysinstall _intents_ to be smart about the problems with the > compat slice, but it's got it wrong (decision being made based on the > location of the data cylinders on the disk, instead of based on the > fdisk slot # as it ought to be -- remember, the compat slice it the > first FreeBSD slice as seen in the fdisk table). The fdisk slot number is supposedly meaningless (ie: the DL register is not loaded for all BIOS'es). Perhaps you have a POST initialization order that hooks INT 13 in a different order than the BSD probe order, or you have one of these badly behaved (usually AMI, I think) BIOS implementations for the default controller? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Aug 26 14:47:45 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id OAA03410 for current-outgoing; Sat, 26 Aug 1995 14:47:45 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id OAA03404 for ; Sat, 26 Aug 1995 14:47:42 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id OAA06136 for current@freebsd.org; Sat, 26 Aug 1995 14:47:23 -0700 From: "Rodney W. Grimes" Message-Id: <199508262147.OAA06136@gndrsh.aac.dev.com> Subject: Re: Request for bumping OSRELDATE To: current@freebsd.org Date: Sat, 26 Aug 1995 14:47:23 -0700 (PDT) In-Reply-To: <199508260555.HAA09356@uriah.heep.sax.de> from "J Wunsch" at Aug 26, 95 07:55:52 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 773 Sender: current-owner@freebsd.org Precedence: bulk > > As Rodney W. Grimes wrote: > > > > > Yes, exactly. Make it 08, NEVER make it higher than "today". > > ok. > > > I will affirm this possition. Setting OSRELDATE to the future is > > a really nasty thing to do. As is doing #ifdef's based upon an > > unassigned numbers (something in pcvt comes to mind). > > 2.0.5 has been an "assigned number" by the time when i've started to > put the #ifdef's there -- remember, it has even been CVS tagged. The > error was to remove a CVS tag (which should IMHO never be done, even > if the tag remains unused since the release never happens). No cvs tag was deleted. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-current Sat Aug 26 15:04:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA04062 for current-outgoing; Sat, 26 Aug 1995 15:04:46 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id PAA04047 for ; Sat, 26 Aug 1995 15:04:43 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA16363; Sat, 26 Aug 95 16:04:15 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508262204.AA16363@cs.weber.edu> Subject: Re: nfs panic after changing cd's To: bde@zeta.org.au (Bruce Evans) Date: Sat, 26 Aug 95 16:04:14 MDT Cc: current@freebsd.org, dfr@render.com In-Reply-To: <199508262106.HAA17016@godzilla.zeta.org.au> from "Bruce Evans" at Aug 27, 95 07:06:11 am X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > My nfs client paniced with a null pointer somewhere in nfs_statfs() or > thereabouts. The server printed: > > Aug 26 23:13:48 alphplex /kernel: fhtovp: file start miss 142213208 vs 60 > Aug 26 23:13:51 alphplex last message repeated 2 times > > This message is from cd9660_vfsops.c (which prints a lot of similar > messages without identifying itself). > > My cdrom had been changed. Usually I mount it at boot time and export > it and never change it and have no problems with cd9660 vs nfs. > > I think this bug is known. It maybe the same as the one reported a day > or two ago where the panic occurred in an lkm'ed file system so that it > wasn't obvious what it was for. If you look at the cd9660_vfsops code, the cd9660_fhtovp() code does a lot more work than the ffs_vfsops.c code. In reality, the ufs_check_export() type checks being done in the UFS code in the FFS should be done BEFORE this failure opportunity exists; that is, the ordering of the checks is wrong. The cd9660 has glossed over the idea of a generation count; in point of fact, the generation count on an inode for a cdromfs is *exactly* what is needed to fix this problem. This is what the UFS uses on a remount on the same mountpoint of another FS to cause it to return ESTALE. The ESTALE should be returned before a lot of the crap dereferences in the cd9660 FS take place. I would suggest that if you are serious about this, then the correct thing to do is to maintain a monotonically increasing 32 bit counter for the generation count. Specifically, the system time should be stored in the mount point at mount time, with a guarantee that multiple CDROM mounts will be delayed to avoid identical time stamps. The timeval rollover isn't a problem, since systems don't remain up that long. 8-). This number should the be used as the generation number for inodes allocated for the in core inodes for the cd9660fs. The generation of all inodes owned by a cd9660 will be the same for each mount instance and different for subsequent mounts on the same mount point (the source of your problem). At which point you return ESTALE before hitting the bitchy code in the first place. Really, many aspects of the cd9660fs want to be rewritten. The major one is the use of mount options rather than examination of the CDROM itself in order to determine CDROM format at all. This turns out to be a much more critical problem, since it prevents clean root mounts of different CDROM formats without user intervention on the command line. THere is code in the FS to force a rollover to High Sierra, but there are still options and a lot of legacy code there, and it's not that hard to "do the right thing" for Rock Ridge extensions as well (though one might want a namespace switch for exporting the FS as a net server to DOS machines). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Sat Aug 26 15:31:29 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id PAA04641 for current-outgoing; Sat, 26 Aug 1995 15:31:29 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id PAA04634 for ; Sat, 26 Aug 1995 15:31:15 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id IAA19347; Sun, 27 Aug 1995 08:25:36 +1000 Date: Sun, 27 Aug 1995 08:25:36 +1000 From: Bruce Evans Message-Id: <199508262225.IAA19347@godzilla.zeta.org.au> To: freebsd-current@freebsd.org, terry@cs.weber.edu Subject: Re: another 2.0.5 installation report Sender: current-owner@freebsd.org Precedence: bulk >I guess the question here is "how is FreeBSD supposed to know the BIOS >translation being used so that it can enforce the right behaviour". The >answer is "it can't unless it does it's own I/O via the BIOS instead of >a protected mode driver -- it can only guess". Nope. It knows the BIOS geometry, sort of (+). The BIOS geometry is stored in bootinfo.bi_bios_geometry[] (*). The main problem is that this can't be used reliably until the mapping of BIOS drive numbers to FreeBSD devices is known. (+) Only the results of the int 0x13 BIOS call are known. This call only allows 10 cylinder bits, so the cylinder count is always wrong if there are more than 1024 cylinders. Some BIOSes truncate the count 1024. Others truncate it to 1023. The int 0x41 and int 0x46 vectors point to standard tables that allow up to 16 bits for the cylinder count, at least for the first 2 IDE drives. I think they work the first couple of SCSI drives too. (*) netboot doesn't initialize much of the bootinfo, in particular it doesn't initialize bi_bios_geometry[]. >Your problem seems to be that it is guessing wrong for you; any >suggestions on how it can be made to guess correctly? The only one I >can see is providing a VM86() fallback driver, doing INT 13 AH=0x8n for >all drives, and then MD5 checksumming areas of each disk so that they >can be matches to the same areas checksummed after having been read by >the protected mode driver. Even then, some of the techniques described This can be done in the boot loader. The boot loader needs to do it anyway, since it should handle your request to boot from sd127 when you have 128 SCSI drives and want to boot from the last one :-). >An extra "fix" of making sure the partition is marked active is probably >a good idea. Actually, a date stamp in the disklabel written by the MBR >replacement when it is used to boot a BSD drive would probably be best, >with a probe search that goes through all possible BSD partitions looking >for the most recent timestamp. No thanks. I don't like unnecessary writes to key metadata, and I'd like to allow readonly root drives. >I don't recognize the term "compatability slice". I assume you mean >that it newfs'ed the DOS slice or something? The above linear search >and disklabel timestamp would mostly fix this case, though you would >potentially be screwed on a reinstall. Nope. See partition.hlp. Bruce From owner-freebsd-current Sat Aug 26 17:41:09 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id RAA10613 for current-outgoing; Sat, 26 Aug 1995 17:41:09 -0700 Received: from gem.kern.com (gem.kern.com [204.212.36.5]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id RAA10604 for ; Sat, 26 Aug 1995 17:41:08 -0700 Received: (from bpk@localhost) by gem.kern.com (8.6.12/8.6.12) id RAA32610 for freebsd-current@freebsd.org; Sat, 26 Aug 1995 17:58:42 -0700 From: Brian Koehmstedt Message-Id: <199508270058.RAA32610@gem.kern.com> Subject: MULTIPORT flow control problems To: freebsd-current@freebsd.org Date: Sat, 26 Aug 1995 17:58:39 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1046 Sender: current-owner@freebsd.org Precedence: bulk I'm using a 16 port BOCA multiport serial board on my FreeBSD (950726) machine. There seems to be a bad flow control problem (drops about 50% of the characters) with any modem I put on the BOCA board. I put the modem on com port 1, and it worked fine. I've played with stty and it didn't seem to help at all. The boca board is on irq 10 and starts at port 0x100. This is what I have in my kernel config file: options COM_MULTIPORT device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr # 16 port BOCA board device sio2 at isa? port 0x100 tty flags 0x1001 vector siointr device sio3 at isa? port 0x108 tty flags 0x1001 vector siointr ... device sio15 at isa? port 0x168 tty flags 0x1001 vector siointr device sio16 at isa? port 0x170 tty flags 0x1001 vector siointr device sio17 at isa? port 0x178 tty flags 0x1001 irq 10 vector siointr Any suggestions? -- Brian Koehmstedt bpk@kern.com From owner-freebsd-current Sat Aug 26 18:29:53 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA12966 for current-outgoing; Sat, 26 Aug 1995 18:29:53 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id SAA12959 for ; Sat, 26 Aug 1995 18:29:47 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA24474; Sun, 27 Aug 1995 11:27:58 +1000 Date: Sun, 27 Aug 1995 11:27:58 +1000 From: Bruce Evans Message-Id: <199508270127.LAA24474@godzilla.zeta.org.au> To: bpk@kern.com, freebsd-current@freebsd.org Subject: Re: MULTIPORT flow control problems Sender: current-owner@freebsd.org Precedence: bulk > I'm using a 16 port BOCA multiport serial board on my FreeBSD >(950726) machine. There seems to be a bad flow control problem (drops about >50% of the characters) with any modem I put on the BOCA board. I put the >modem on com port 1, and it worked fine. I've played with stty and it >didn't seem to help at all. Flow control problems are not likely to cause that many dropped characters. Perhaps interrupts don't work right. Then the board might by accident up to about 1000 bps with 16450s and 15000 bps with 16550s. Polled mode (which you get by not putting an irq in the config) is designed to work up to these speeds. ># 16 port BOCA board >device sio2 at isa? port 0x100 tty flags 0x1001 vector siointr >device sio3 at isa? port 0x108 tty flags 0x1001 vector siointr >... Boca boards require 0x0004 in the flags. Bit 0x0004 off means that the board is AST/4 compatible. See the sio man page. I didn't know exactly what happens for Boca boards when bit 0x0004 is off. Now I do :-). Interrupts are disabled. The AST/4 uses the normal IRQ enable bit to control the compatibility mode, and the sio turns it the bit off for AST/4's to get native AST/4 mode. In -current, by default polling "by accident" is done 100 times less often, so the problem would be more obvious. Bruce From owner-freebsd-current Sat Aug 26 19:00:21 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id SAA12966 for current-outgoing; Sat, 26 Aug 1995 18:29:53 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id SAA12959 for ; Sat, 26 Aug 1995 18:29:47 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id LAA24474; Sun, 27 Aug 1995 11:27:58 +1000 Date: Sun, 27 Aug 1995 11:27:58 +1000 From: Bruce Evans Message-Id: <199508270127.LAA24474@godzilla.zeta.org.au> To: bpk@kern.com, freebsd-current@freebsd.org Subject: Re: MULTIPORT flow control problems Sender: current-owner@freebsd.org Precedence: bulk > I'm using a 16 port BOCA multiport serial board on my FreeBSD >(950726) machine. There seems to be a bad flow control problem (drops about >50% of the characters) with any modem I put on the BOCA board. I put the >modem on com port 1, and it worked fine. I've played with stty and it >didn't seem to help at all. Flow control problems are not likely to cause that many dropped characters. Perhaps interrupts don't work right. Then the board might by accident up to about 1000 bps with 16450s and 15000 bps with 16550s. Polled mode (which you get by not putting an irq in the config) is designed to work up to these speeds. ># 16 port BOCA board >device sio2 at isa? port 0x100 tty flags 0x1001 vector siointr >device sio3 at isa? port 0x108 tty flags 0x1001 vector siointr >... Boca boards require 0x0004 in the flags. Bit 0x0004 off means that the board is AST/4 compatible. See the sio man page. I didn't know exactly what happens for Boca boards when bit 0x0004 is off. Now I do :-). Interrupts are disabled. The AST/4 uses the normal IRQ enable bit to control the compatibility mode, and the sio turns it the bit off for AST/4's to get native AST/4 mode. In -current, by default polling "by accident" is done 100 times less often, so the problem would be more obvious. Bruce From owner-freebsd-current Sat Aug 26 23:22:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA09913 for current-outgoing; Sat, 26 Aug 1995 23:22:39 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA09906 for ; Sat, 26 Aug 1995 23:22:36 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25903 for ; Sun, 27 Aug 1995 08:22:33 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA01612 for freebsd-current@freebsd.org; Sun, 27 Aug 1995 08:22:33 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id HAA21547 for freebsd-current@freebsd.org; Sun, 27 Aug 1995 07:41:33 +0200 From: J Wunsch Message-Id: <199508270541.HAA21547@uriah.heep.sax.de> Subject: Re: my Linux swap partition again To: freebsd-current@freebsd.org Date: Sun, 27 Aug 1995 07:41:33 +0200 (MET DST) Reply-To: freebsd-current@freebsd.org In-Reply-To: <199508262128.HAA17541@godzilla.zeta.org.au> from "Bruce Evans" at Aug 27, 95 07:28:28 am Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 768 Sender: current-owner@freebsd.org Precedence: bulk As Bruce Evans wrote: > > fdisk doesn't synchronize the changes with the kernel, so there are > problems if wd0s3 doesn't already exist or if you changed its size. This seems to be the problem. > wd0s3 must have existed for disklabel to get as far as the DIOCSDINFO > attempt, so perhaps you gave the wrong size to fdisk, or > is inconsistent. It's consistent. > The fdisk step shouldn't be necessary. Just write a label. It has been a slice type ``Linux swap'' previously. You mean, i don't have to convert it to 0xa5 in order to disklabel it? (That's all the mysterious fdisk crap did actually do.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Aug 26 23:22:40 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA09925 for current-outgoing; Sat, 26 Aug 1995 23:22:40 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA09907 for ; Sat, 26 Aug 1995 23:22:37 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25907 for ; Sun, 27 Aug 1995 08:22:35 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA01613 for freebsd-current@FreeBSD.org; Sun, 27 Aug 1995 08:22:34 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id HAA21575 for freebsd-current@FreeBSD.org; Sun, 27 Aug 1995 07:51:07 +0200 From: J Wunsch Message-Id: <199508270551.HAA21575@uriah.heep.sax.de> Subject: Re: another 2.0.5 installation report To: freebsd-current@FreeBSD.org Date: Sun, 27 Aug 1995 07:51:07 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org In-Reply-To: <9508262139.AA16296@cs.weber.edu> from "Terry Lambert" at Aug 26, 95 03:39:29 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1781 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > > It's an IDE translation, btw. > > I guess the question here is "how is FreeBSD supposed to know the BIOS > translation being used so that it can enforce the right behaviour". The > answer is "it can't unless it does it's own I/O via the BIOS instead of > a protected mode driver -- it can only guess". No, it does this part totally right. The only translation happens inside the disk, any geometry data as seen outside the disk are consistent (BIOS, Linux, FreeBSD, nonexistent DOS). The notebook is several years old, it does not have any mystics here. Terry, this is _not_ a geometry problem... > I don't recognize the term "compatability slice". I assume you mean Yeah, that's your (and sysinstall's) problem. > that it newfs'ed the DOS slice or something? The above linear search > and disklabel timestamp would mostly fix this case, though you would > potentially be screwed on a reinstall. It refers to the `shortcut' device names: sliced name for the root device: wd0s2a sliced name for my intented swap: wd0s3b compat name: wd0a (no compat name for swap available, it's not on the compat slice) The first slice with ID 0xa5 becomes the `compat slice', and our current boot code can only load from there (so the root file system will always be mounted from the compat slice). Sysinstall apparently knows this and wants to tell me that i could not place my root file system on wd0s3a (since there has been a FreeBSD wd0s2 slice). Anyway, it got its decision wrong, it did it based on the order of the tracks on the disk, instead of the order in the fdisk slots. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sat Aug 26 23:24:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id XAA09994 for current-outgoing; Sat, 26 Aug 1995 23:24:06 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id XAA09971 for ; Sat, 26 Aug 1995 23:24:03 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25958 for ; Sun, 27 Aug 1995 08:24:00 +0200 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA01621 for freebsd-current@FreeBSD.org; Sun, 27 Aug 1995 08:24:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id IAA21777 for freebsd-current@FreeBSD.org; Sun, 27 Aug 1995 08:19:11 +0200 From: J Wunsch Message-Id: <199508270619.IAA21777@uriah.heep.sax.de> Subject: Re: nfs panic after changing cd's To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 27 Aug 1995 08:19:10 +0200 (MET DST) Reply-To: freebsd-current@FreeBSD.org (FreeBSD-current users) In-Reply-To: <9508262204.AA16363@cs.weber.edu> from "Terry Lambert" at Aug 26, 95 04:04:14 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 875 Sender: current-owner@FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > The cd9660 has glossed over the idea of a generation count; in point of > fact, the generation count on an inode for a cdromfs is *exactly* what is > needed to fix this problem. This is what the UFS uses on a remount on > the same mountpoint of another FS to cause it to return ESTALE. The > ESTALE should be returned before a lot of the crap dereferences in the > cd9660 FS take place. Sorry, i cannot entirely follow you. :) I think the idea behind the decision as it's done now was to allow the remount of an identical CD without returning ESTALE. It has been discussed here that computing some MD5 checksum for the CD is probably the best way to base a decision for stale NFS file handles on. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)