From owner-freebsd-current Sun May 31 00:10:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16291 for freebsd-current-outgoing; Sun, 31 May 1998 00:10:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from aldan.ziplink.net (mi@kot.ne.mediaone.net [24.128.29.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16279 for ; Sun, 31 May 1998 00:10:37 -0700 (PDT) (envelope-from mi@rtfm.ziplink.net) Received: from rtfm.ziplink.net (rtfm [199.232.255.52]) by aldan.ziplink.net (8.8.8/8.8.7) with ESMTP id HAA19636 for ; Sun, 31 May 1998 07:10:23 GMT (envelope-from mi@rtfm.ziplink.net) Received: (from mi@localhost) by rtfm.ziplink.net (8.8.8/8.8.5) id DAA18304 for current@freebsd.org; Sun, 31 May 1998 03:10:25 -0400 (EDT) From: Mikhail Teterin Message-Id: <199805310710.DAA18304@rtfm.ziplink.net> Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199805310154.SAA08633@antipodes.cdrom.com> from "Mike Smith" at "May 30, 98 06:54:47 pm" To: current@FreeBSD.ORG Date: Sun, 31 May 1998 03:10:25 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" May be this should be the semantics of `rm' on the DEVFS? => Removal of the driver, or telling it to stop driving a => particular device? (If possible, otherwise, rm fails?) mknod => (or, `touch'!!) can then be used to load the driver back (if => possible). =Not useful. You want to poke a single entity (the driver) and =have it remove all it's nodes, rather than have to guess at all =the nodes everywhere that it might own and run around deleting =them all. Not necessarily. By removing /dev/lpt1 I may be telling the lpt driver to stop driving the second lport, but the lpt0 may continue to work. There are plenty of possible interpretations of rm in this case, I wonder if any other OS has DEVFS already and how do they deal with this... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 00:14:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16793 for freebsd-current-outgoing; Sun, 31 May 1998 00:14:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16787 for ; Sun, 31 May 1998 00:14:21 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA24659; Sun, 31 May 1998 00:12:47 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd024657; Sun May 31 07:12:44 1998 Date: Sun, 31 May 1998 00:12:41 -0700 (PDT) From: Julian Elischer To: Tom Jackson cc: FreeBSD Current Subject: Re: IP Packet Aliasing Broke? In-Reply-To: <19980530210320.35350@TOJ.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I made changes to ipfw and DIVERT that should have been transparent but may not have been if natd didn't do things quite "by the book". I assume you are saying that natd is broken? julian On Sat, 30 May 1998, Tom Jackson wrote: > On May 28 packet forwarding was working, on the 29 it was *not*. > Any ideas or did I miss something? All I have done is make world > and kernel rebuid. > > -- > Tom > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 00:14:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16840 for freebsd-current-outgoing; Sun, 31 May 1998 00:14:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16833 for ; Sun, 31 May 1998 00:14:28 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA24534; Sun, 31 May 1998 00:05:25 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd024532; Sun May 31 07:05:16 1998 Date: Sun, 31 May 1998 00:05:13 -0700 (PDT) From: Julian Elischer To: Brian Feldman cc: freebsd-current@FreeBSD.ORG Subject: Re: fd crash (in isa_dmastart) In-Reply-To: <19980531042432.16101.qmail@m2.findmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id AAA16835 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not sure what causes this but it should be easy enough to reproduce.. I'll add it to my list of things to clean up... Interestingly enoungh the stack trace shows no softupdates related functions. I will guess however that the softupdate code may not fully appreciate the subtlties of bounce buffers as they are a FreeBSD oddity. (I can actually think of a few things to check out.) this may be a problem with aha1542 scsi systems too. julian On 31 May 1998, Brian Feldman wrote: > Well, out of curiousity, I wanted to try SoftUpdates on a floppy. Let's just say that SoftUpdates on a floppy is a Bad Thing, causing Too Much Disk Access and A Bad Panic. (out out evil capitals!) Here's the bt, for those interested, and I'll delete this huge vmcore tomorrow if noone tells me not to and we don't want to try to get any more info out of it: > (kgdb) bt > #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 > #1 0xf0118fc7 in panic (fmt=0xf01f1f56 "isa_dmastart: bad bounce buffer") > at ../../kern/kern_shutdown.c:421 > #2 0xf01f1fcf in isa_dmastart (flags=587333684, addr=0xf2d4d014 "ð\004", > nbytes=4096, chan=2) at ../../i386/isa/isa.c:767 > #3 0xf01ec1fd in fdstate (fdcu=0, fdc=0xf02622d4) at ../../i386/isa/fd.c:1640 > #4 0xf01ebcb3 in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 > #5 0xf01ebc75 in fd_pseudointr (arg1=0x0) at ../../i386/isa/fd.c:1425 > #6 0xf011d203 in softclock () at ../../kern/kern_timeout.c:124 > #7 0xf01d6cc7 in doreti_swi () > Cannot access memory at address 0x274e35f8. > > Now I'm relatively certain that this was specifically caused by way to much disk access on SoftUpdates' part; any idea how we should fix this? > > Cheers, > Brian Feldman > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 00:56:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA20062 for freebsd-current-outgoing; Sun, 31 May 1998 00:56:57 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles307.castles.com [208.214.167.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA20057 for ; Sun, 31 May 1998 00:56:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id XAA09881; Sat, 30 May 1998 23:52:38 -0700 (PDT) Message-Id: <199805310652.XAA09881@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mikhail Teterin cc: current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Sun, 31 May 1998 03:10:25 EDT." <199805310710.DAA18304@rtfm.ziplink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 May 1998 23:52:38 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith once stated: > > => May be this should be the semantics of `rm' on the DEVFS? > => Removal of the driver, or telling it to stop driving a > => particular device? (If possible, otherwise, rm fails?) mknod > => (or, `touch'!!) can then be used to load the driver back (if > => possible). > > =Not useful. You want to poke a single entity (the driver) and > =have it remove all it's nodes, rather than have to guess at all > =the nodes everywhere that it might own and run around deleting > =them all. > > Not necessarily. By removing /dev/lpt1 I may be telling the > lpt driver to stop driving the second lport, but the lpt0 may > continue to work. As I said, it's not useful. You can't guarantee that there aren't other instances of the device that you haven't/can't remove. Sure, it's one possible interpretation - it's just not a good one. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 00:58:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA20243 for freebsd-current-outgoing; Sun, 31 May 1998 00:58:45 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from isua2.iastate.edu (isua2.iastate.edu [129.186.1.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA20234 for ; Sun, 31 May 1998 00:58:43 -0700 (PDT) (envelope-from graphix@iastate.edu) Received: (from graphix@localhost) by isua2.iastate.edu (8.8.5/8.8.5) id CAA14778 for current@freebsd.org; Sun, 31 May 1998 02:58:42 -0500 (CDT) Date: Sun, 31 May 1998 02:58:42 -0500 (CDT) From: Kent A Vander Velden Message-Id: <199805310758.CAA14778@isua2.iastate.edu> To: current@FreeBSD.ORG Subject: kernel config Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Do the -current kernels have a way to automatically enter a few configuration commands on startup? At the moment whenever I install a new kernel I must type these lines at the kernel config prompt: pnp 1 0 os enable port0 0x220 irq0 5 drq0 1 drq1 5 port1 0x330 port2 0x388 pnp 1 1 os enable port0 0x208 pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 to enable the soundcard. I have tried to put these lines in /kernel.config but that did not seem to change anything. The file kernel.config does not seem to be documentated anywhere that I could find so perhaps I am using the wrong syntex. I assume that the this functionality is available since typing these commands get really old :) Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 01:34:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA23291 for freebsd-current-outgoing; Sun, 31 May 1998 01:34:24 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from tortuga.com.au (issi.tortuga.com.au [203.101.253.28]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA23272 for ; Sun, 31 May 1998 01:34:08 -0700 (PDT) (envelope-from ianh@tortuga.com.au) Received: from frabjous.tortuga.com.au by tortuga.com.au (SMI-8.6/SMI-SVR4) id SAA22502; Sun, 31 May 1998 18:31:02 +1000 Received: (from ianh@localhost) by frabjous.tortuga.com.au (8.8.7/8.8.5) id SAA18663 for current@FreeBSD.ORG; Sun, 31 May 1998 18:29:12 +1000 (EST) From: Ian Holland Message-Id: <199805310829.SAA18663@frabjous.tortuga.com.au> Subject: bootstrap in make buildworld To: current@FreeBSD.ORG Date: Sun, 31 May 1998 18:29:10 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -current (CTM cvs-cur 4339) During a "make buildworld" on the aforementioned source view, the make failed with a syntax error on "yacc". Specifically, the "-o" option was not recognised. It appeared that the local (installed) version of "yacc" was being used: ie "yacc" from FreeBSD 2.2.5. My assumption was that "yacc" needs to be bootstraped a la "lex", "xinstall", etc. So, based on that assumption, I applied the following patch: *** Makefile.orig Sun May 31 17:54:22 1998 --- Makefile Sun May 31 18:02:18 1998 *************** *** 488,493 **** --- 488,496 ---- cd ${.CURDIR}/usr.bin/xinstall; ${MAKE} ${MK_FLAGS} ${_DEPEND}; \ ${MAKE} ${MK_FLAGS} all; \ ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} + cd ${.CURDIR}/usr.bin/yacc; ${MAKE} ${MK_FLAGS} ${_DEPEND}; \ + ${MAKE} ${MK_FLAGS} all; \ + ${MAKE} ${MK_FLAGS} -B install ${CLEANDIR} ${OBJDIR} cd ${.CURDIR}/usr.bin/lex; ${MAKE} bootstrap; \ ${MAKE} ${MK_FLAGS} ${_DEPEND}; \ ${MAKE} ${MK_FLAGS} -DNOLIB all; \ The version of the unadulterated Makefile was 1.190. Caveat: this is my first run at -current, so I may be completely off base. Feel free to point and chuckle. -- Ian Holland In a world without fences, ianh@tortuga.com.au Who needs Gates? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 02:31:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA27369 for freebsd-current-outgoing; Sun, 31 May 1998 02:31:48 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from thing.dyn.ml.org (root@dyn1-tnt12-47.detroit.mi.ameritech.net [209.18.31.47]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA27358 for ; Sun, 31 May 1998 02:31:45 -0700 (PDT) (envelope-from mcdougall@ameritech.net) Received: from ameritech.net (user1@bsdx [192.168.1.2]) by thing.dyn.ml.org (8.8.8/8.8.7) with ESMTP id FAA18865; Sun, 31 May 1998 05:30:38 -0400 (EDT) (envelope-from mcdougall@ameritech.net) Message-ID: <3571233A.DF5852A7@ameritech.net> Date: Sun, 31 May 1998 05:30:34 -0400 From: Adam McDougall Reply-To: mcdougall@ameritech.net X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Kent A Vander Velden CC: current@FreeBSD.ORG Subject: Re: kernel config References: <199805310758.CAA14778@isua2.iastate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kent A Vander Velden wrote: > Do the -current kernels have a way to automatically enter a few configuration > commands on startup? At the moment whenever I install a new kernel I must > type these lines at the kernel config prompt: > > pnp 1 0 os enable port0 0x220 irq0 5 drq0 1 drq1 5 port1 0x330 port2 0x388 > pnp 1 1 os enable port0 0x208 > pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 > > to enable the soundcard. I have tried to put these lines in /kernel.config > but that did not seem to change anything. The file kernel.config > does not seem to be documentated anywhere that I could find so perhaps > I am using the wrong syntex. > > I assume that the this functionality is available since typing these > commands get really old :) > > Thanks. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message yup, add this to the kernel options USERCONFIG_BOOT and edit /kernel.config; here's mine for an example: # cat /kernel.config USERCONFIG pnp 1 0 os disable pnp 1 1 irq0 10 os enable port0 0x534 port2 0x220 port3 0xe0d drq0 1 drq1 3 pnp 1 2 os disable pnp 1 3 os disable quit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 03:03:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA00929 for freebsd-current-outgoing; Sun, 31 May 1998 03:03:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA00918 for ; Sun, 31 May 1998 03:03:13 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id DAA22341; Sun, 31 May 1998 03:03:03 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp04.primenet.com, id smtpd022324; Sun May 31 03:03:02 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id DAA20637; Sun, 31 May 1998 03:03:01 -0700 (MST) From: Terry Lambert Message-Id: <199805311003.DAA20637@usr04.primenet.com> Subject: Re: Fix for undefined "__error" and discussion of shared object To: rkw@dataplex.net (Richard Wackerbarth) Date: Sun, 31 May 1998 10:03:00 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: from "Richard Wackerbarth" at May 30, 98 04:15:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >It also means that one "ports" CDROM will work for FreeBSD 3.x and > >FreeBSD 235.x. > > How can you make this claim? The individual ports may well rely on some feature > of FreeBSD 235.x that was not present in FreeBSD 3.x. Similarly, a port > for 3.x may rely on a feature that was removed before 5.0. > > As much as we might like to think otherwise, assumptions about the structure > of the underlying OS and "hardcoded" into the source of the program. :-( The point is to make a port for FreeBSD 3.x work on FreeBSD 235.x, not the reverse. In other words, "compile once, run anywhere". The binary compatability from FreeBSD 3.x to FreeBSD 235.x is a problem for the XANDF processor during the install. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 03:05:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA01318 for freebsd-current-outgoing; Sun, 31 May 1998 03:05:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA01294 for ; Sun, 31 May 1998 03:05:29 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id DAA19627; Sun, 31 May 1998 03:05:29 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd019615; Sun May 31 03:05:28 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id DAA20689; Sun, 31 May 1998 03:05:27 -0700 (MST) From: Terry Lambert Message-Id: <199805311005.DAA20689@usr04.primenet.com> Subject: Re: I see one major problem with DEVFS... To: julian@whistle.com Date: Sun, 31 May 1998 10:05:27 +0000 (GMT) Cc: phk@critter.freebsd.dk, current@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at May 30, 98 03:53:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Just to get peace over the land again, I think you should implement > > it so that one can mknod a device again, but discard the dev_t, > > and use whatever DEVFS knows (better). This is a security hole. If a device is removed from a chroot environment, it should be impossible to recreate it. The reasoning should be obvious. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 03:08:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA02224 for freebsd-current-outgoing; Sun, 31 May 1998 03:08:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA02219 for ; Sun, 31 May 1998 03:08:34 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id DAA19970; Sun, 31 May 1998 03:08:29 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd019946; Sun May 31 03:08:22 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id DAA20780; Sun, 31 May 1998 03:08:18 -0700 (MST) From: Terry Lambert Message-Id: <199805311008.DAA20780@usr04.primenet.com> Subject: Re: I see one major problem with DEVFS... To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 31 May 1998 10:08:18 +0000 (GMT) Cc: phk@critter.freebsd.dk, jkh@time.cdrom.com, mike@smith.net.au, eivind@yes.no, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at May 31, 98 08:14:10 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Devfs is synthetic and maybe we shouldn't even allow removes in the > > first place but a whiteout/undelete solution is the "POLA" choice. > > > > Alternatively devfs could allow mknod, but ignore the major/minor > > numbers given and just "DTRT", that would work also after we have > > killed dev_t. > > I agree with either of these options. The whiteout solution would mean a > lot of hacking on a devfs_lookup(). The use of whiteout is best implemented in the lookup code. This is why the directory name lookup cache should be in the namei code instead of in the underlying code. This implies a "non-cacheable" bit on a per FS basis. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 03:21:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA04153 for freebsd-current-outgoing; Sun, 31 May 1998 03:21:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA04147 for ; Sun, 31 May 1998 03:21:08 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.8/8.8.8) with ESMTP id LAA01961; Sun, 31 May 1998 11:20:58 +0100 (BST) (envelope-from kpielorz@tdx.co.uk) Message-ID: <35712F0A.58921DFD@tdx.co.uk> Date: Sun, 31 May 1998 11:20:58 +0100 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: obrien@NUXI.com CC: current@FreeBSD.ORG Subject: Re: problems with SCSI drives over sd9? References: <35654168.F0F30C3@tdx.co.uk> <19980530135635.A8548@nuxi.com> <35707571.68F99E96@tdx.co.uk> <19980530143148.E3610@nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > But my drives are NOT continuiously numbered. Currently I've got > sd0,sd1,sd2,sd3 on one controler, and > sd10,sd11,sd12,sd13,sd14,sd15,sd18 on another one. (the last digit > matches the SCSI id). Mine are continuosly numbered... > All of sd1X was done with ``disklabel -Brw sd1X auto'' and all use the > "c" partition. Although, last month most of the sd1X used the "e" > partition (if any of this helps). Yes, this fails on my system - it works in the sense of no errors reported, but I can't read the label back properly afterwards (my suspicion is it was never written properly)... > What is your setup? I have 11 SCSI drives split accross 2 controllers (sounds familiar ;-) You say it works with 2.2-STABLE - have you done this with 3.0-CURRENT? I can post (by private mail) all the gory details, it comes to around 200 lines (for dmesg, disklabel output, things I've done etc...) Regards, Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 03:54:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA07237 for freebsd-current-outgoing; Sun, 31 May 1998 03:54:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA07214 for ; Sun, 31 May 1998 03:54:00 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id SAA02491 for ; Sun, 31 May 1998 18:53:56 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199805311053.SAA02491@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: current@FreeBSD.ORG Subject: jumbo nfs commit comming up soon... (ie: in a few hours) Date: Sun, 31 May 1998 18:53:55 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got a series of large NFS commits coming up shortly. 'cvs diff -u | wc -l sys/nfs' is in the order of 6000 lines, so I'll try and break it up into smaller components where practical. This means that while things are in transit, the kernel and/or utilities may well not compile. Don't be too suprised if your world falls over if you try and build from sources mid-commit. (I have not checked all the userland stuff yet, amd in particular). One of the bigger components is a long -> int32_t change for Alpha and other 64 bit support. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 04:00:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA08902 for freebsd-current-outgoing; Sun, 31 May 1998 04:00:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA08673; Sun, 31 May 1998 04:00:36 -0700 (PDT) (envelope-from paulz@trantor.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <1466-9473>; Sun, 31 May 1998 13:00:19 +0200 Received: from trantor.stuyts.nl (uucp@localhost) by terminus.stuyts.nl (8.8.8/8.8.8) with UUCP id MAA28182; Sun, 31 May 1998 12:07:27 +0200 (MET DST) (envelope-from paulz@trantor.stuyts.nl) Received: from trantor.stuyts.nl (localhost [127.0.0.1]) by trantor.stuyts.nl (8.8.8/8.8.5) with ESMTP id MAA00139; Sun, 31 May 1998 12:06:20 +0200 (MET DST) Message-Id: <199805311006.MAA00139@trantor.stuyts.nl> X-Mailer: exmh version 2.0.2 2/24/98 To: Kent A Vander Velden Subject: Re: Undefined symbols referenced In-reply-to: Your message of "Sat, 30 May 1998 21:04:53 CDT." <199805310204.VAA03255@isua1.iastate.edu> cc: jmacd@FreeBSD.ORG, current@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 12:06:20 +0200 From: Paul van der Zwan Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > While compiling xdelta and gimp-devel on a semi-current system I started > to notice many of applications failing to link. The messages that ld > generated were of the form: > > 2 -pipe -Wall -o .libs/xd xd.o -R/usr/X11R6/lib -lgimpui -L/usr/local/lib -R/usr > /X11R6/lib -lgimp -L/usr/local/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -lgtk -lgdk > -lglib -lXext -lX11 -lm -lxdelta -lglib -lgdbm -lc -L/usr/local/lib > xd.o: Undefined symbol `_unlink' referenced (use -lc ?) > xd.o: Undefined symbol `_stat' referenced (use -lc ?) > /usr/local/lib/libgdbm.a(gdbmstore.o): Undefined symbol `_write' referenced (use > -lc ?) > /usr/local/lib/libgdbm.a(bucket.o): Undefined symbol `_read' referenced (use -lc > ?) > /usr/local/lib/libgdbm.a(bucket.o): Undefined symbol `_write' referenced (use -l > c ?) > > I noticed a message in the current-digest about __error being undefined > but got in on the end of the thread. > > What must I change inorder to have these applications link properly? > I had the same problem a week or so ago. The xdelta port will not build on current ( cvsupped and make world this weekend) even rebuilding the gdbm port and reinstalling that does not work. Gimp will now build because the maintainer removed the dependency on xdelta but the xdelta port looks broken on current. Paul -- Paul van der Zwan paulz @ trantor.stuyts.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 04:24:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA11806 for freebsd-current-outgoing; Sun, 31 May 1998 04:24:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11800 for ; Sun, 31 May 1998 04:24:39 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id EAA28745; Sun, 31 May 1998 04:21:29 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028743; Sun May 31 11:21:24 1998 Date: Sun, 31 May 1998 04:21:22 -0700 (PDT) From: Julian Elischer To: Karl Pielorz cc: obrien@NUXI.com, current@FreeBSD.ORG Subject: Re: problems with SCSI drives over sd9? In-Reply-To: <35712F0A.58921DFD@tdx.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is not directly related, but I keep having to yell at people to STOP USING C as a normal partition.. make some other partition the same size and use it instead, a, e, whatever, but not C C has voodoo involved and you may be relying on the voodoo without knowing it, then when we remove the voodoo, in a year or so, (or right now if you have DEVFS and -current) tehn things may break for you. julian On Sun, 31 May 1998, Karl Pielorz wrote: > David O'Brien wrote: > > > > But my drives are NOT continuiously numbered. Currently I've got > > sd0,sd1,sd2,sd3 on one controler, and > > sd10,sd11,sd12,sd13,sd14,sd15,sd18 on another one. (the last digit > > matches the SCSI id). > > Mine are continuosly numbered... > > > All of sd1X was done with ``disklabel -Brw sd1X auto'' and all use the > > "c" partition. Although, last month most of the sd1X used the "e" > > partition (if any of this helps). > > Yes, this fails on my system - it works in the sense of no errors reported, > but I can't read the label back properly afterwards (my suspicion is it was > never written properly)... > > > What is your setup? > > I have 11 SCSI drives split accross 2 controllers (sounds familiar ;-) > > You say it works with 2.2-STABLE - have you done this with 3.0-CURRENT? > > I can post (by private mail) all the gory details, it comes to around 200 > lines (for dmesg, disklabel output, things I've done etc...) > > Regards, > > Karl > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 04:36:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA12934 for freebsd-current-outgoing; Sun, 31 May 1998 04:36:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12927 for ; Sun, 31 May 1998 04:36:31 -0700 (PDT) (envelope-from michael_class@hp.com) Received: from hpbbse.bbn.hp.com (hpbbse.bbn.hp.com [15.136.26.26]) by atlrel2.hp.com (8.8.6/8.8.5tis) with ESMTP id HAA00650 for ; Sun, 31 May 1998 07:35:45 -0400 (EDT) Received: from hp.com (apc1mc10.bbn.hp.com [15.124.134.10]) by hpbbse.bbn.hp.com with ESMTP (8.7.6/8.7.3) id MAA03925 for ; Sun, 31 May 1998 12:36:17 +0100 (MEZ) Message-ID: <3571407E.D3D078E1@hp.com> Date: Sun, 31 May 1998 13:35:26 +0200 From: Micha Class X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: scsi-uk and DEVFS Content-Type: multipart/mixed; boundary="------------3EC78750E2ECE13AA8EFF14B" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------3EC78750E2ECE13AA8EFF14B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I just found that the uk-driver which I am using for my scanner (together with sane), does not include devicenodes when DEVFS is used. The following patch fixes that for me (mostly stolen from pt.c) If someone with commit-privileges could check and possibly commit this, this would be nice. Michael -- ------------------------------------------------------------------------- michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: michael_class@hp.com Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) ------------------------------------------------------------------------- --------------3EC78750E2ECE13AA8EFF14B Content-Type: text/plain; charset=us-ascii; name="uk.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="uk.diff" *** src/sys/scsi/uk.c Sat Aug 2 16:33:16 1997 --- src/sys/scsi/uk.c.NEW Sun May 31 13:27:15 1998 *************** *** 8,13 **** --- 8,15 ---- * at putting it in "scsi_driver.c" instead. */ + #include + #include #include #include *************** *** 18,23 **** --- 20,31 ---- #include #include + struct scsi_data { + #ifdef DEVFS + void *devfs_data_tok; + #endif + }; + static d_open_t ukopen; static d_close_t ukclose; static d_ioctl_t ukioctl; *************** *** 40,49 **** 0, {0, 0}, SDEV_ONCE_ONLY|SDEV_UK, /* Only one open allowed */ ! 0, "Unknown", ukopen, ! 0, T_UNKNOWN, 0, 0, --- 48,57 ---- 0, {0, 0}, SDEV_ONCE_ONLY|SDEV_UK, /* Only one open allowed */ ! ukattach, "Unknown", ukopen, ! sizeof(struct scsi_data), T_UNKNOWN, 0, 0, *************** *** 55,60 **** --- 63,84 ---- static uk_devsw_installed = 0; + + static errval + ukattach(struct scsi_link *sc_link) + { + #ifdef DEVFS + struct scsi_data *uk = sc_link->sd; + + uk->devfs_data_tok = devfs_add_devswf(&uk_cdevsw, + sc_link->dev_unit, + DV_CHR, + UID_ROOT, GID_WHEEL, 0600, + "uk%d", sc_link->dev_unit); + #endif + return 0; + } + static void uk_drvinit(void *unused) { --------------3EC78750E2ECE13AA8EFF14B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 04:52:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14601 for freebsd-current-outgoing; Sun, 31 May 1998 04:52:25 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mexcom.net (ver1-38.uninet.net.mx [200.38.135.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA14595; Sun, 31 May 1998 04:52:20 -0700 (PDT) (envelope-from eculp@ver1.telmex.net.mx) Received: from mc.mexcom.net (telmex@ppp-7.mexcom.net [206.103.65.199]) by ns.mexcom.net (8.8.8/8.8.7) with SMTP id GAA15751; Sun, 31 May 1998 06:48:19 -0500 (CDT) Message-ID: <35714510.7843D910@ver1.telmex.net.mx> Date: Sun, 31 May 1998 06:54:56 -0500 From: Edwin Culp Organization: Mexico Communicates, S.A. de C.V. X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.18 i586) MIME-Version: 1.0 To: Paul van der Zwan CC: Kent A Vander Velden , jmacd@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Undefined symbols referenced References: <199805311006.MAA00139@trantor.stuyts.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Paul van der Zwan wrote: > > > > > While compiling xdelta and gimp-devel on a semi-current system I started > > to notice many of applications failing to link. The messages that ld > > generated were of the form: > > > > 2 -pipe -Wall -o .libs/xd xd.o -R/usr/X11R6/lib -lgimpui -L/usr/local/lib -R/usr > > /X11R6/lib -lgimp -L/usr/local/lib -L/usr/X11R6/lib -L/usr/X11R6/lib -lgtk -lgdk > > -lglib -lXext -lX11 -lm -lxdelta -lglib -lgdbm -lc -L/usr/local/lib > > xd.o: Undefined symbol `_unlink' referenced (use -lc ?) > > xd.o: Undefined symbol `_stat' referenced (use -lc ?) > > /usr/local/lib/libgdbm.a(gdbmstore.o): Undefined symbol `_write' referenced (use > > -lc ?) > > /usr/local/lib/libgdbm.a(bucket.o): Undefined symbol `_read' referenced (use -lc > > ?) > > /usr/local/lib/libgdbm.a(bucket.o): Undefined symbol `_write' referenced (use -l > > c ?) > > > > I noticed a message in the current-digest about __error being undefined > > but got in on the end of the thread. > > > > What must I change inorder to have these applications link properly? > > > I had the same problem a week or so ago. The xdelta port will not build on > current ( cvsupped and make world this weekend) even rebuilding the gdbm port > and reinstalling that does not work. > Gimp will now build because the maintainer removed the dependency on xdelta > but the xdelta port looks broken on current. > > Paul > Just yesterday, I compiled gimp-0.99.31 from ports on two different machines running current from may 5 with ports updated, with no problems. I also changed to gtk-1.03. First I cleaned up all previous installations of both. ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 05:14:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA17513 for freebsd-current-outgoing; Sun, 31 May 1998 05:14:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from critter.freebsd.dk ([195.8.133.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA17482 for ; Sun, 31 May 1998 05:14:05 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id OAA03356; Sun, 31 May 1998 14:12:13 +0200 (CEST) To: Terry Lambert cc: julian@whistle.com, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Sun, 31 May 1998 10:05:27 -0000." <199805311005.DAA20689@usr04.primenet.com> Date: Sun, 31 May 1998 14:11:37 +0200 Message-ID: <3354.896616697@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199805311005.DAA20689@usr04.primenet.com>, Terry Lambert writes: >> > Just to get peace over the land again, I think you should implement >> > it so that one can mknod a device again, but discard the dev_t, >> > and use whatever DEVFS knows (better). > >This is a security hole. > >If a device is removed from a chroot environment, it should be impossible >to recreate it. > >The reasoning should be obvious. But the argument is nontheless badly flawed. This should be done by disallowing mknods by chrooted processes if such security is desired. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 07:13:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26525 for freebsd-current-outgoing; Sun, 31 May 1998 07:13:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sanewo.ba2.so-net.ne.jp (root@p84b44a.sng2.ap.so-net.ne.jp [210.132.180.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26518 for ; Sun, 31 May 1998 07:13:44 -0700 (PDT) (envelope-from sanewo@ba2.so-net.ne.jp) Received: (from sanewo@localhost) by sanewo.ba2.so-net.ne.jp (8.8.8/8.7.3) id TAA02504; Sun, 31 May 1998 19:55:29 +0900 (JST) To: current@FreeBSD.ORG Subject: Re: top -osize References: <19980528211849.A10559@rtfm.net> <19980528212002.A11468@emsphone.com> From: Takanori Saneto In-Reply-To: Dan Nelson's message of "Thu, 28 May 1998 21:20:02 -0500" X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA) MIME-Version: 1.0 (generated by SEMI 1.4.5 - "Tomari") Content-Type: text/plain; charset=ISO-2022-JP Date: 31 May 1998 19:55:28 +0900 Message-ID: <87n2byso9r.fsf@sanewo.ba2.so-net.ne.jp> Lines: 295 X-Mailer: Semi-gnus 6.3.1 (based on Gnus 5.6.9; for SEMI 1.4) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19980528212002.A11468@emsphone.com>, Dan Nelson writes: >> Is there a real reason for it not being able to do this or is >> something just mildly broken? >The only reason is that no one's wanted to write the sort routines. >Out of the 40 platforms supported by top 3.5b7, only 5 (aix32, aix41, >sunos4, sunos5, and untrix4) even implemented -o. Here's a patch to make sorting option work for -current, which is based on Solaris' machine.c. I've been using this patched version of top since it was in ports tree. -- $B$5$M$r(B Index: usr.bin/top/Makefile =================================================================== RCS file: /sd0/FreeBSD/cvs/src/usr.bin/top/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- Makefile 1997/07/21 16:06:00 1.4 +++ Makefile 1997/07/31 16:59:17 @@ -5,6 +5,8 @@ CFLAGS+= -DHAVE_GETOPT -I${.CURDIR} -I${TOPDIR} +CFLAGS+= -DORDER + # # The table size should be a prime number approximately twice as # large as the number of lines in /etc/passwd. The default number Index: usr.bin/top/machine.c =================================================================== RCS file: /sd0/FreeBSD/cvs/src/usr.bin/top/machine.c,v retrieving revision 1.10 diff -u -r1.10 machine.c --- machine.c 1998/05/28 09:29:48 1.10 +++ machine.c 1998/05/28 17:27:52 @@ -13,6 +13,8 @@ * * LIBS: -lkvm * + * CFLAGS: -DHAVE_GETOPT -DORDER + * * AUTHOR: Christos Zoulas * Steven Wallace * Wolfram Schneider @@ -167,7 +169,6 @@ static long lastpid; static unsigned long cnt_offset; static unsigned long bufspace_offset; -static long cnt; /* these are for calculating cpu state percentages */ @@ -206,6 +207,22 @@ NULL }; +/* these are names given to allowed sorting orders -- first is default */ +char *ordernames[] = +{"cpu", "size", "res", "time", NULL}; + +/* forward definitions for comparison functions */ +int compare_cpu(); +int compare_size(); +int compare_res(); +int compare_time(); + +int (*proc_compares[])() = { + compare_cpu, + compare_size, + compare_res, + compare_time, + NULL }; /* these are for keeping track of the proc array */ @@ -311,6 +328,7 @@ statics->cpustate_names = cpustatenames; statics->memory_names = memorynames; statics->swap_names = swapnames; + statics->order_names = ordernames; /* all done! */ return(0); @@ -321,13 +339,12 @@ register char *uname_field; { - register char *ptr; static char Header[128]; snprintf(Header, sizeof(Header), smpmode ? smp_header : up_header, namelength, namelength, uname_field); cmdlength = 80 - strlen(Header) + 6; return Header; } @@ -691,20 +708,37 @@ } return(1); } - -/* comparison routine for qsort */ + +/* comparison routines for qsort */ /* - * proc_compare - comparison function for "qsort" - * Compares the resource consumption of two processes using five - * distinct keys. The keys (in descending order of importance) are: - * percent cpu, cpu ticks, state, resident set size, total virtual - * memory usage. The process states are ordered as follows (from least - * to most important): WAIT, zombie, sleep, stop, start, run. The - * array declaration below maps a process state index into a number - * that reflects this ordering. + * There are currently four possible comparison routines. main selects + * one of these by indexing in to the array proc_compares. + * + * Possible keys are defined as macros below. Currently these keys are + * defined: percent cpu, cpu ticks, process state, resident set size, + * total virtual memory usage. The process states are ordered as follows + * (from least to most important): WAIT, zombie, sleep, stop, start, run. + * The array declaration below maps a process state index into a number + * that reflects this ordering. */ +/* First, the possible comparison keys. These are defined in such a way + that they can be merely listed in the source code to define the actual + desired ordering. + */ + +#define ORDERKEY_PCTCPU if (dresult = pctdouble(PP(p2, p_pctcpu)) - pctdouble(PP(p1, p_pctcpu)),\ + (result = dresult > 0.0 ? 1 : dresult < 0.0 ? -1 : 0) == 0) +#define ORDERKEY_CPTICKS if ((result = PP(p2, p_runtime) - PP(p1, p_runtime)) == 0) +#define ORDERKEY_STATE if ((result = (long) (sorted_state[(unsigned char)PP(p2, p_stat)] - \ + sorted_state[(unsigned char)PP(p1, p_stat)])) == 0) +#define ORDERKEY_PRIO if ((result = PP(p2, p_priority) - PP(p1, p_priority)) == 0) +#define ORDERKEY_RSSIZE if ((result = VP(p2, vm_rssize) - VP(p1, vm_rssize)) == 0) +#define ORDERKEY_MEM if ((result = PROCSIZE(p2) - PROCSIZE(p1)) == 0) + +/* Now the array that maps process state to a weight */ + static unsigned char sorted_state[] = { 0, /* not used */ @@ -716,8 +750,10 @@ 4 /* stop */ }; +/* compare_cpu - the comparison function for sorting by cpu percentage */ + int -proc_compare(pp1, pp2) +compare_cpu(pp1, pp2) struct proc **pp1; struct proc **pp2; @@ -726,39 +762,106 @@ register struct kinfo_proc *p1; register struct kinfo_proc *p2; register int result; - register pctcpu lresult; + double dresult; /* remove one level of indirection */ p1 = *(struct kinfo_proc **) pp1; p2 = *(struct kinfo_proc **) pp2; - /* compare percent cpu (pctcpu) */ - if ((lresult = PP(p2, p_pctcpu) - PP(p1, p_pctcpu)) == 0) - { - /* use lifetime CPU usage to break the tie */ - if ((result = PP(p2, p_runtime) - PP(p1, p_runtime)) == 0) - { - /* use process state to break the tie */ - if ((result = sorted_state[(unsigned char) PP(p2, p_stat)] - - sorted_state[(unsigned char) PP(p1, p_stat)]) == 0) - { - /* use priority to break the tie */ - if ((result = PP(p2, p_priority) - PP(p1, p_priority)) == 0) - { - /* use resident set size (rssize) to break the tie */ - if ((result = VP(p2, vm_rssize) - VP(p1, vm_rssize)) == 0) - { - /* use total memory to break the tie */ - result = PROCSIZE(p2) - PROCSIZE(p1); - } - } - } - } - } - else - { - result = lresult < 0 ? -1 : 1; - } + ORDERKEY_PCTCPU + ORDERKEY_CPTICKS + ORDERKEY_STATE + ORDERKEY_PRIO + ORDERKEY_RSSIZE + ORDERKEY_MEM + ; + + return(result); +} + +/* compare_size - the comparison function for sorting by total memory usage */ + +int +compare_size(pp1, pp2) + +struct proc **pp1; +struct proc **pp2; + +{ + register struct kinfo_proc *p1; + register struct kinfo_proc *p2; + register int result; + double dresult; + + /* remove one level of indirection */ + p1 = *(struct kinfo_proc **) pp1; + p2 = *(struct kinfo_proc **) pp2; + + ORDERKEY_MEM + ORDERKEY_RSSIZE + ORDERKEY_PCTCPU + ORDERKEY_CPTICKS + ORDERKEY_STATE + ORDERKEY_PRIO + ; + + return(result); +} + +/* compare_res - the comparison function for sorting by resident set size */ + +int +compare_res(pp1, pp2) + +struct proc **pp1; +struct proc **pp2; + +{ + register struct kinfo_proc *p1; + register struct kinfo_proc *p2; + register int result; + double dresult; + + /* remove one level of indirection */ + p1 = *(struct kinfo_proc **) pp1; + p2 = *(struct kinfo_proc **) pp2; + + ORDERKEY_RSSIZE + ORDERKEY_MEM + ORDERKEY_PCTCPU + ORDERKEY_CPTICKS + ORDERKEY_STATE + ORDERKEY_PRIO + ; + + return(result); +} + +/* compare_time - the comparison function for sorting by total cpu time */ + +int +compare_time(pp1, pp2) + +struct proc **pp1; +struct proc **pp2; + +{ + register struct kinfo_proc *p1; + register struct kinfo_proc *p2; + register int result; + double dresult; + + /* remove one level of indirection */ + p1 = *(struct kinfo_proc **) pp1; + p2 = *(struct kinfo_proc **) pp2; + + ORDERKEY_CPTICKS + ORDERKEY_PCTCPU + ORDERKEY_STATE + ORDERKEY_PRIO + ORDERKEY_MEM + ORDERKEY_RSSIZE + ; return(result); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 07:39:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28969 for freebsd-current-outgoing; Sun, 31 May 1998 07:39:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA28964 for ; Sun, 31 May 1998 07:39:16 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 9770 invoked by uid 505); 31 May 1998 14:39:02 -0000 Date: 31 May 1998 14:39:02 -0000 Message-ID: <19980531143902.9769.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: fd crash (in isa_dmastart) In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, if you see that "Cannot access memory at 0xwhatever" I think that might be why you can't see softupdates calling it ;) Just a note here, of course. Other thing being that the only thing I was doing at all on the system was cp'ing some stuff onto the disk. Like I said, just a little clarification mail. Cheers, Brian Feldman > I'm not sure what causes this but it should be easy enough to reproduce.. > I'll add it to my list of things to clean up... > > Interestingly enoungh the stack trace shows no softupdates related > functions. > I will guess however that the softupdate code may not fully appreciate the > subtlties of bounce buffers > as they are a FreeBSD oddity. > (I can actually think of a few things to check out.) > this may be a problem with aha1542 scsi systems too. > > > > julian > > > On 31 May 1998, Brian Feldman wrote: > > > Well, out of curiousity, I wanted to try SoftUpdates on a floppy. Let's just say that SoftUpdates on a floppy is a Bad Thing, causing Too Much Disk Access and A Bad Panic. (out out evil capitals!) Here's the bt, for those interested, and I'll delete this huge vmcore tomorrow if noone tells me not to and we don't want to try to get any more info out of it: > > (kgdb) bt > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 > > #1 0xf0118fc7 in panic (fmt=0xf01f1f56 "isa_dmastart: bad bounce buffer") > > at ../../kern/kern_shutdown.c:421 > > #2 0xf01f1fcf in isa_dmastart (flags=587333684, addr=0xf2d4d014 "ð\004", > > nbytes=4096, chan=2) at ../../i386/isa/isa.c:767 > > #3 0xf01ec1fd in fdstate (fdcu=0, fdc=0xf02622d4) at ../../i386/isa/fd.c:1640 > > #4 0xf01ebcb3 in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 > > #5 0xf01ebc75 in fd_pseudointr (arg1=0x0) at ../../i386/isa/fd.c:1425 > > #6 0xf011d203 in softclock () at ../../kern/kern_timeout.c:124 > > #7 0xf01d6cc7 in doreti_swi () > > Cannot access memory at address 0x274e35f8. > > > > Now I'm relatively certain that this was specifically caused by way to much disk access on SoftUpdates' part; any idea how we should fix this? > > > > Cheers, > > Brian Feldman > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 07:39:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28994 for freebsd-current-outgoing; Sun, 31 May 1998 07:39:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA28983 for ; Sun, 31 May 1998 07:39:18 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 9781 invoked by uid 505); 31 May 1998 14:39:09 -0000 Date: 31 May 1998 14:39:09 -0000 Message-ID: <19980531143909.9780.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: fd crash (in isa_dmastart) In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure what causes this but it should be easy enough to reproduce.. > I'll add it to my list of things to clean up... > > Interestingly enoungh the stack trace shows no softupdates related > functions. > I will guess however that the softupdate code may not fully appreciate the > subtlties of bounce buffers > as they are a FreeBSD oddity. > (I can actually think of a few things to check out.) > this may be a problem with aha1542 scsi systems too. > > > > julian > > > On 31 May 1998, Brian Feldman wrote: > > > Well, out of curiousity, I wanted to try SoftUpdates on a floppy. Let's just say that SoftUpdates on a floppy is a Bad Thing, causing Too Much Disk Access and A Bad Panic. (out out evil capitals!) Here's the bt, for those interested, and I'll delete this huge vmcore tomorrow if noone tells me not to and we don't want to try to get any more info out of it: > > (kgdb) bt > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 > > #1 0xf0118fc7 in panic (fmt=0xf01f1f56 "isa_dmastart: bad bounce buffer") > > at ../../kern/kern_shutdown.c:421 > > #2 0xf01f1fcf in isa_dmastart (flags=587333684, addr=0xf2d4d014 "ð\004", > > nbytes=4096, chan=2) at ../../i386/isa/isa.c:767 > > #3 0xf01ec1fd in fdstate (fdcu=0, fdc=0xf02622d4) at ../../i386/isa/fd.c:1640 > > #4 0xf01ebcb3 in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 > > #5 0xf01ebc75 in fd_pseudointr (arg1=0x0) at ../../i386/isa/fd.c:1425 > > #6 0xf011d203 in softclock () at ../../kern/kern_timeout.c:124 > > #7 0xf01d6cc7 in doreti_swi () > > Cannot access memory at address 0x274e35f8. > > > > Now I'm relatively certain that this was specifically caused by way to much disk access on SoftUpdates' part; any idea how we should fix this? > > > > Cheers, > > Brian Feldman > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 07:42:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29473 for freebsd-current-outgoing; Sun, 31 May 1998 07:42:03 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA29458 for ; Sun, 31 May 1998 07:42:01 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 9875 invoked by uid 505); 31 May 1998 14:41:51 -0000 Date: 31 May 1998 14:41:51 -0000 Message-ID: <19980531144151.9874.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: IP Packet Aliasing Broke? In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I read this message, then took 30 seconds to test this out. Natd and ipfw work just peachy together, no problems. Brian Feldman > I made changes to ipfw and DIVERT that should have been transparent > but may not have been if natd didn't do things quite "by the book". > > I assume you are saying that natd is broken? > > julian > > > On Sat, 30 May 1998, Tom Jackson wrote: > > > On May 28 packet forwarding was working, on the 29 it was *not*. > > Any ideas or did I miss something? All I have done is make world > > and kernel rebuid. > > > > -- > > Tom > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 07:51:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00438 for freebsd-current-outgoing; Sun, 31 May 1998 07:51:37 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00415 for ; Sun, 31 May 1998 07:51:30 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id JAA01243; Sun, 31 May 1998 09:51:05 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199805311451.JAA01243@dyson.iquest.net> Subject: Re: jumbo nfs commit comming up soon... (ie: in a few hours) In-Reply-To: <199805311053.SAA02491@spinner.netplex.com.au> from Peter Wemm at "May 31, 98 06:53:55 pm" To: peter@netplex.com.au (Peter Wemm) Date: Sun, 31 May 1998 09:51:05 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've got a series of large NFS commits coming up shortly. 'cvs diff -u | > wc -l sys/nfs' is in the order of 6000 lines, so I'll try and break it up > into smaller components where practical. > > This means that while things are in transit, the kernel and/or utilities > may well not compile. Don't be too suprised if your world falls over if > you try and build from sources mid-commit. (I have not checked all the > userland stuff yet, amd in particular). > > One of the bigger components is a long -> int32_t change for Alpha and > other 64 bit support. > It is *wonderful* that you are making progress on NFS. That is one of our major problems, and making progress on that is a major contribution. A personal thank you!!! John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 07:56:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01368 for freebsd-current-outgoing; Sun, 31 May 1998 07:56:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA01363 for ; Sun, 31 May 1998 07:56:40 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id KAA18088; Sun, 31 May 1998 10:53:51 -0400 (EDT) (envelope-from wollman) Date: Sun, 31 May 1998 10:53:51 -0400 (EDT) From: Garrett Wollman Message-Id: <199805311453.KAA18088@khavrinen.lcs.mit.edu> To: Takanori Saneto Cc: current@FreeBSD.ORG Subject: Re: top -osize In-Reply-To: <87n2byso9r.fsf@sanewo.ba2.so-net.ne.jp> References: <19980528211849.A10559@rtfm.net> <19980528212002.A11468@emsphone.com> <87n2byso9r.fsf@sanewo.ba2.so-net.ne.jp> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > int > -proc_compare(pp1, pp2) > +compare_cpu(pp1, pp2) > struct proc **pp1; > struct proc **pp2; qsort(3) comparison functions take arguments of type `const void *', not `struct proc **'. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 08:29:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA04558 for freebsd-current-outgoing; Sun, 31 May 1998 08:29:07 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sanewo.ba2.so-net.ne.jp (root@p84b44a.sng2.ap.so-net.ne.jp [210.132.180.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA04548 for ; Sun, 31 May 1998 08:28:46 -0700 (PDT) (envelope-from sanewo@ba2.so-net.ne.jp) Received: from ba2.so-net.ne.jp (sanewo@sanewo.ba2.so-net.ne.jp [127.0.0.1]) by sanewo.ba2.so-net.ne.jp (8.8.8/8.8.8) with ESMTP id AAA00170; Mon, 1 Jun 1998 00:27:39 +0900 (JST) (envelope-from sanewo@ba2.so-net.ne.jp) Message-Id: <199805311527.AAA00170@sanewo.ba2.so-net.ne.jp> To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: top -osize In-reply-to: wollman@khavrinen.lcs.mit.edu's message of Sun, 31 May 1998 10:53:51 -0400. <199805311453.KAA18088@khavrinen.lcs.mit.edu> X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA) MIME-Version: 1.0 (generated by SEMI 1.4.5 - "Tomari") Content-Type: text/plain; charset=ISO-2022-JP Date: Mon, 01 Jun 1998 00:27:38 +0900 From: SANETO Takanori Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199805311453.KAA18088@khavrinen.lcs.mit.edu> Garrett Wollman said: >< said: > >> int >> -proc_compare(pp1, pp2) >> +compare_cpu(pp1, pp2) > >> struct proc **pp1; >> struct proc **pp2; > >qsort(3) comparison functions take arguments of type `const void *', >not `struct proc **'. Yes, you are right. My patch does not change the way comparison functions being (not) prototyped. In contrib/top/top.c: >#ifdef ORDER >extern int (*proc_compares[])(); >#else >extern int proc_compare(); >#endif Is it time to create a patch to make them prototyped and send it to the maintainer of ``top''? -- $B$5$M$r(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 08:46:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA06286 for freebsd-current-outgoing; Sun, 31 May 1998 08:46:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from limbo.rtfm.net (nathan@rtfm.net [204.141.125.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06281 for ; Sun, 31 May 1998 08:46:32 -0700 (PDT) (envelope-from nathan@limbo.rtfm.net) Received: (from nathan@localhost) by limbo.rtfm.net (8.8.8/8.8.8) id LAA00616; Sun, 31 May 1998 11:46:28 -0400 (EDT) (envelope-from nathan) Message-ID: <19980531114627.A580@rtfm.net> Date: Sun, 31 May 1998 11:46:27 -0400 From: Nathan Dorfman To: Takanori Saneto , current@FreeBSD.ORG Subject: Re: top -osize Mail-Followup-To: Takanori Saneto , current@FreeBSD.ORG References: <19980528211849.A10559@rtfm.net> <19980528212002.A11468@emsphone.com> <87n2byso9r.fsf@sanewo.ba2.so-net.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <87n2byso9r.fsf@sanewo.ba2.so-net.ne.jp>; from Takanori Saneto on Sun, May 31, 1998 at 07:55:28PM +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This won't patch into top (in -current). Hunk #8 fails at 762, and the code fails to compile: cc -O -pipe -DHAVE_GETOPT -I/usr/src/usr.bin/top -I/usr/src/usr.bin/top/../../contrib/top -c /usr/src/usr.bin/top/machine.c /usr/src/usr.bin/top/machine.c: In function `machine_init': /usr/src/usr.bin/top/machine.c:331: structure has no member named `order_names' *** Error code 1 Stop. -- ________________ ______________________________ / Nathan Dorfman \ / "Nietzsche is dead." - God \ / nathan@rtfm.net \/ http://www.FreeBSD.org/ \ / finger for PGP key \ FreeBSD 2.2.6 is now out! \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 08:57:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07516 for freebsd-current-outgoing; Sun, 31 May 1998 08:57:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from elephants.dyn.ml.org (root@mki1-pl-ri7.kos.net [206.186.40.96]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07507 for ; Sun, 31 May 1998 08:56:56 -0700 (PDT) (envelope-from jake@elephants.dyn.ml.org) Received: from elephants.dyn.ml.org (jake@elephants.dyn.ml.org [127.0.0.1]) by elephants.dyn.ml.org (8.8.8/8.8.8) with ESMTP id LAA00305 for ; Sun, 31 May 1998 11:59:35 -0400 (EDT) (envelope-from jake@elephants.dyn.ml.org) Message-Id: <199805311559.LAA00305@elephants.dyn.ml.org> X-Mailer: exmh version 2.0.2 2/24/98 To: current@FreeBSD.ORG Subject: Re: Undefined symbols referenced In-reply-to: Your message of "Sun, 31 May 1998 06:54:56 CDT." <35714510.7843D910@ver1.telmex.net.mx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 11:59:35 -0400 From: Jake Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just compiled and re-installed gimp-0.99.31, worked great. All I did to "clean up" my old install was delete the ~/.gimp directory, which has been problematic in prior attempts. make; make reinstall worked great. One minor hitch was that gtk-1.03 extracted into /usr/ports/x11/gtk/work/gtk-1.02 which I had to change to gtk-1.03 for it to work. A few days ago gimp-devel died on installation of xdelta-0.18, this time it was happy with xdelta-0.14 I guess, cause that's all I have in /var/db/pkg carry on... Jake -- http://www.checker.org/~jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 09:30:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10817 for freebsd-current-outgoing; Sun, 31 May 1998 09:30:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10812 for ; Sun, 31 May 1998 09:30:11 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id LAA02105; Sun, 31 May 1998 11:30:05 -0500 (CDT) Date: Sun, 31 May 1998 11:30:05 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199805311003.DAA20637@usr04.primenet.com> References: from "Richard Wackerbarth" at May 30, 98 04:15:40 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: Richard Wackerbarth Subject: Re: Fix for undefined "__error" and discussion of shared object Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:02 AM -0000 5/31/98, Terry Lambert wrote: >> As much as we might like to think otherwise, assumptions about the structure >> of the underlying OS and "hardcoded" into the source of the program. :-( > >The point is to make a port for FreeBSD 3.x work on FreeBSD 235.x, not >the reverse. In other words, "compile once, run anywhere". > >The binary compatability from FreeBSD 3.x to FreeBSD 235.x is a >problem for the XANDF processor during the install. And for it to be possible, there must be a "compatability library" of some kind. This, in turn means that you must emulate the archaic version of FreeBSD in its totality. What are you going to do when a concept entirely disappears? As an example, consider the impact of the eventual integration of devfs. By the time we get to FreeBSD 235.x, do you really expect to be able to support today's hack dejuor which relies on the present major/minor device numbers? I think not. As systems evolve, you are eventually forced to abandon the albatroses of legacy compatability. An even harder problem is related to timing assumptions that are hardcoded into programs. Many programs "work" only because they assume things about the hardware and/or compilers. Remember programs that "poked" an I/O register and controlled the timing with delay loops? They would never work today if a "decent" compiler were to get hold of them and optimize away the code that simply created delays. Where they were written, the languages never had the concept of optimization. As a result, the programmers never put the necessary hooks into the program to guide the compiler about which factors are important. All that I am saying is that I do not believe that it is possible to both maintain infinity compatability and allow for future innovation. At some point, the two concepts reach a point of unresolvable conflict. After that point, one of then will no longer apply. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 09:50:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12532 for freebsd-current-outgoing; Sun, 31 May 1998 09:50:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12523 for ; Sun, 31 May 1998 09:50:43 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id LAA02146; Sun, 31 May 1998 11:50:33 -0500 (CDT) Date: Sun, 31 May 1998 11:50:33 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <19980531052120.41610@follo.net> References: ; from Richard Wackerbarth on Sat, May 30, 1998 at 03:45:31PM -0500 <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Eivind Eklund From: Richard Wackerbarth Subject: Re: How about /usr/ports/kernel ? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:21 AM -0000 5/31/98, Eivind Eklund wrote: >On Sat, May 30, 1998 at 03:45:31PM -0500, Richard Wackerbarth wrote: >> At 4:29 PM -0000 5/30/98, Eivind Eklund wrote: >> > >My own view of this is that config(8) should scan for > > ../../*/conf/files.FreeBSD > > ../../*/conf/options.FreeBSD > > ../../*/conf/files.FreeBSD. > > ../../*/conf/options.FreeBSD. > >add concatenate this with the appropriate files. >[...on having kernels made as a part of a normal build...] > >We've discussed this before (off the list), and I tend to agree to >some of it. However, how is this related to the proposal above >(except for both being part of the kernel build structure)? I think that it is a "detail". Rather than increasing the complexity of "config", I would use the capability of "make" and the preprocessors to present to "config", a single list of elements that it must process. I am, somewhat, a Unix purist. I detest the trend toward mamoth monolithic programs which "do everything", each in its own slightly different way. I prefer the reuse of small highly targeted tools that do particular tasks in a clean, efficient manner. Sometimes, the tool starts small and grows by the addition of "warts" motivated by growth within the particular presentation of the underlying problem space. A different presentation may present the opportunity for a simpler solution. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 09:54:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12990 for freebsd-current-outgoing; Sun, 31 May 1998 09:54:48 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12971 for ; Sun, 31 May 1998 09:54:43 -0700 (PDT) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id SAA26133; Sun, 31 May 1998 18:57:43 +0200 (CEST) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Sun, 31 May 1998 18:57:42 +0200 (CEST) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Julian Elischer cc: Brian Feldman , freebsd-current@FreeBSD.ORG Subject: Re: fd crash (in isa_dmastart) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 May 1998, Julian Elischer wrote: > I'm not sure what causes this but it should be easy enough to reproduce.. > I'll add it to my list of things to clean up... > > Interestingly enoungh the stack trace shows no softupdates related > functions. > I will guess however that the softupdate code may not fully appreciate the > subtlties of bounce buffers > as they are a FreeBSD oddity. > (I can actually think of a few things to check out.) > this may be a problem with aha1542 scsi systems too. As I wrote you some time ago, it's enough to try to mount msdos floppy under DEVFS/SLICE kernel - it immediately panics with the same message. Andrzej Bialecki --------------------+--------------------------------------------------------- abial@nask.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. --------------------+--------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 09:56:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13271 for freebsd-current-outgoing; Sun, 31 May 1998 09:56:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13229 for ; Sun, 31 May 1998 09:56:52 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from skejdbrimir.ifi.uio.no (skejdbrimir.ifi.uio.no [129.240.65.2]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with SMTP id SAA25406; Sun, 31 May 1998 18:56:39 +0200 (MET DST) Received: from localhost (dag-erli@localhost) by skejdbrimir.ifi.uio.no ; Sun, 31 May 1998 16:56:39 GMT Mime-Version: 1.0 To: mcdougall@ameritech.net Cc: Kent A Vander Velden , current@FreeBSD.ORG Subject: Re: kernel config References: <199805310758.CAA14778@isua2.iastate.edu> <3571233A.DF5852A7@ameritech.net> Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-email-address-1: dag-erli@ifi.uio.no (for private or study-related mail) X-email-address-2: dagsm@hypnotech.no (for job-related mail) X-email-address-3: des@FreeBSD.org (for FreeBSD-related mail) X-email-address-4: finrod@ewox.org (for demoscene-related mail) X-disclaimer-1: I speak only for myself. The views expressed in this message X-disclaimer-2: are not those of the University of Oslo, the FreeBSD project, X-disclaimer-3: or any other organization or company to which I am or have at X-disclaimer-4: some time been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 31 May 1998 18:56:36 +0200 In-Reply-To: Adam McDougall's message of "Sun, 31 May 1998 05:30:34 -0400" Message-ID: Lines: 8 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Adam McDougall writes: > yup, add this to the kernel > options USERCONFIG_BOOT YAUKO! -- Noone else has a .sig like this one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 10:30:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA16972 for freebsd-current-outgoing; Sun, 31 May 1998 10:30:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA16948 for ; Sun, 31 May 1998 10:30:41 -0700 (PDT) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.0.Beta5/8.9.0.Beta5) id TAA02921 for current@freebsd.org; Sun, 31 May 1998 19:30:35 +0200 (SAT) From: John Hay Message-Id: <199805311730.TAA02921@zibbi.mikom.csir.co.za> Subject: ports and the aout lib directory To: current@FreeBSD.ORG Date: Sun, 31 May 1998 19:30:35 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, With the move of the lib files to /usr/lib/aout "make release" broke, because when it builds the perl5 port, the perl5 configure script try to find libc, but fail because it does not look in the aout subdirectory. I guess this is just the first one because there are probably other ports that try to do the same thing. So how should this be fixed? Should I just try to hack around it in the release/Makefile? Are the elf libs going to live in /usr/lib? And how soon? :-) Can we be without daily SNAPS for that long is what I mean. :-) John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 10:37:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18101 for freebsd-current-outgoing; Sun, 31 May 1998 10:37:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18080 for ; Sun, 31 May 1998 10:37:36 -0700 (PDT) (envelope-from jmacd@paris.CS.Berkeley.EDU) Received: (from jmacd@localhost) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) id KAA27038; Sun, 31 May 1998 10:36:55 -0700 (PDT) Message-ID: <19980531103654.23417@paris.CS.Berkeley.EDU> Date: Sun, 31 May 1998 10:36:54 -0700 From: Josh MacDonald To: Paul van der Zwan Cc: current@FreeBSD.ORG Subject: Re: Undefined symbols referenced References: <199805310204.VAA03255@isua1.iastate.edu> <199805311006.MAA00139@trantor.stuyts.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199805311006.MAA00139@trantor.stuyts.nl>; from Paul van der Zwan on Sun, May 31, 1998 at 12:06:20PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Quoting Paul van der Zwan (paulz@trantor.stuyts.nl): > I had the same problem a week or so ago. The xdelta port will not build on > current ( cvsupped and make world this weekend) even rebuilding the gdbm port > and reinstalling that does not work. > Gimp will now build because the maintainer removed the dependency on xdelta > but the xdelta port looks broken on current. I would say that current looks broken on xdelta. More specifically, your current looks broken. I don't appreciate hearing this type of report, which indicates the xdelta is to blame. I've gotten at least 10 of these reports. I don't like to hear that xdelta has been removed from GIMP either. People with these problems should not be running -current. -josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 10:48:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19675 for freebsd-current-outgoing; Sun, 31 May 1998 10:48:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shasta.wstein.com (joes@shasta.wstein.com [206.163.206.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19606; Sun, 31 May 1998 10:47:46 -0700 (PDT) (envelope-from joes@shasta.wstein.com) Received: (from joes@localhost) by shasta.wstein.com (8.9.0/8.9.0) id KAA19941; Sun, 31 May 1998 10:47:22 -0700 (PDT) From: Joseph Stein Message-Id: <199805311747.KAA19941@shasta.wstein.com> Subject: Re: Sendmail 8.9 In-Reply-To: <199805281423.WAA08282@spinner.netplex.com.au> from Peter Wemm at "May 28, 98 10:23:26 pm" To: peter@netplex.com.au (Peter Wemm) Date: Sun, 31 May 1998 10:47:21 -0700 (PDT) Cc: peter@netplex.com.au, dom@myrddin.demon.co.uk, current@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm allegedly wrote: > Argh, I take that back, I shouldn't have uttered such crap, especially when > I had a reply in my mailbox that I had not yet seen. (And even if it > wasn't, this still wasn't appropriate). My big mouth is really going to > get me in trouble sooner or later. So what was the final verdict? Any clarifications in the works, or is everyone that wants to use 8.9.0 on their own? (no problem for me, I'm already upgraded, but just a general question.) joe -- Joseph Stein Oregon FirePage http://www.ofp.org Beaverton, Oregon (*) [OFP4/PDX] (503) 301-1575 -or- joes@pager.wstein.com joes@wstein.com * Oregon, n.: Eighty billion gallons of water with no place to go on Saturday To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 10:53:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20582 for freebsd-current-outgoing; Sun, 31 May 1998 10:53:05 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zippy.dyn.ml.org (garbanzo@libya-235.ppp.hooked.net [206.169.227.235]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20574 for ; Sun, 31 May 1998 10:53:03 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.8/8.8.7) with ESMTP id KAA03780; Sun, 31 May 1998 10:53:25 -0700 (PDT) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Sun, 31 May 1998 10:53:24 -0700 (PDT) From: Alex X-Sender: garbanzo@zippy.dyn.ml.org To: Ollivier Robert cc: current@FreeBSD.ORG Subject: Re: ELF preparation step 2 done In-Reply-To: <19980527230443.A23502@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 27 May 1998, Ollivier Robert wrote: > According to Søren Schmidt: > > Not yet I belive, but I know John Polstra /has been/is/is going to/ > > work on such a beast... > > BTW, if anyone wants patches to compile XFree86 3.3.2 in ELF, just > ask. There are several assumptions in the code/Imakefiles to correct but it > works : Two questions: Where can I get the patches? And what's the accepted method for building an elf-world? My efforts still seem to result in a make buildworld falling over. - alex | "Contrary to popular belief, penguins are not the salvation of modern | | technology. Neither do they throw parties for the urban proletariat." | | Powered by FreeBSD http://www.freebsd.org/ | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 11:40:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27989 for freebsd-current-outgoing; Sun, 31 May 1998 11:40:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27981 for ; Sun, 31 May 1998 11:40:15 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id SAA07297; Sun, 31 May 1998 18:36:36 GMT Date: Mon, 1 Jun 1998 03:36:36 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: julian@whistle.com, phk@critter.freebsd.dk, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199805311005.DAA20689@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 May 1998, Terry Lambert wrote: > > > Just to get peace over the land again, I think you should implement > > > it so that one can mknod a device again, but discard the dev_t, > > > and use whatever DEVFS knows (better). > > This is a security hole. > > If a device is removed from a chroot environment, it should be impossible > to recreate it. > > The reasoning should be obvious. Why not just control permissions on mknod? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:02:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00606 for freebsd-current-outgoing; Sun, 31 May 1998 12:02:37 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gorillanet.gorilla.net (gorillanet.gorilla.net [208.128.8.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA00601 for ; Sun, 31 May 1998 12:02:35 -0700 (PDT) (envelope-from tom@gorilla.net) Received: from [208.143.84.50] by gorillanet.gorilla.net (NTMail 3.03.0014/18.aaac) with ESMTP id qa152064 for ; Sun, 31 May 1998 14:01:45 -0500 Received: (from tom@localhost) by gorilla.net (8.8.8/8.8.8) id OAA01551; Sun, 31 May 1998 14:02:32 -0500 (CDT) (envelope-from tom) Message-ID: <19980531140201.06705@TOJ.org> Date: Sun, 31 May 1998 14:02:01 -0500 From: Tom Jackson To: FreeBSD Current Subject: Re: IP Packet Aliasing Broke? Mail-Followup-To: FreeBSD Current References: <19980530210320.35350@TOJ.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Julian Elischer on Sun, May 31, 1998 at 12:12:41AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, May 31, 1998 at 12:12:41AM -0700, Julian Elischer wrote: > I made changes to ipfw and DIVERT that should have been transparent > but may not have been if natd didn't do things quite "by the book". > > I assume you are saying that natd is broken? > > julian > > > On Sat, 30 May 1998, Tom Jackson wrote: > > > On May 28 packet forwarding was working, on the 29 it was *not*. > > Any ideas or did I miss something? All I have done is make world > > and kernel rebuid. > > > > -- > > Tom > > No, sorry for not being clear. User ppp ip packet aliasing. Trying to figure out what happened but haven't yet. -- Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:14:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01639 for freebsd-current-outgoing; Sun, 31 May 1998 12:14:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01628 for ; Sun, 31 May 1998 12:14:16 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA07080; Sun, 31 May 1998 12:08:40 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd007078; Sun May 31 19:08:38 1998 Date: Sun, 31 May 1998 12:08:35 -0700 (PDT) From: Julian Elischer To: Brian Feldman cc: freebsd-current@FreeBSD.ORG Subject: Re: fd crash (in isa_dmastart) In-Reply-To: <19980531143902.9769.qmail@m2.findmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id MAA01629 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG was softupdates enabled of the floppy filesystem? (i.e. did you use "tunefs -n enable" on the floppy?) On 31 May 1998, Brian Feldman wrote: > Well, if you see that "Cannot access memory at 0xwhatever" I think that might be why you can't see softupdates calling it ;) Just a note here, of course. Other thing being that the only thing I was doing at all on the system was cp'ing some stuff onto the disk. Like I said, just a little clarification mail. > > Cheers, > Brian Feldman > > > I'm not sure what causes this but it should be easy enough to reproduce.. > > I'll add it to my list of things to clean up... > > > > Interestingly enoungh the stack trace shows no softupdates related > > functions. > > I will guess however that the softupdate code may not fully appreciate the > > subtlties of bounce buffers > > as they are a FreeBSD oddity. > > (I can actually think of a few things to check out.) > > this may be a problem with aha1542 scsi systems too. > > > > > > > > julian > > > > > > On 31 May 1998, Brian Feldman wrote: > > > > > Well, out of curiousity, I wanted to try SoftUpdates on a floppy. Let's just say that SoftUpdates on a floppy is a Bad Thing, causing Too Much Disk Access and A Bad Panic. (out out evil capitals!) Here's the bt, for those interested, and I'll delete this huge vmcore tomorrow if noone tells me not to and we don't want to try to get any more info out of it: > > > (kgdb) bt > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 > > > #1 0xf0118fc7 in panic (fmt=0xf01f1f56 "isa_dmastart: bad bounce buffer") > > > at ../../kern/kern_shutdown.c:421 > > > #2 0xf01f1fcf in isa_dmastart (flags=587333684, addr=0xf2d4d014 "ð\004", > > > nbytes=4096, chan=2) at ../../i386/isa/isa.c:767 > > > #3 0xf01ec1fd in fdstate (fdcu=0, fdc=0xf02622d4) at ../../i386/isa/fd.c:1640 > > > #4 0xf01ebcb3 in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 > > > #5 0xf01ebc75 in fd_pseudointr (arg1=0x0) at ../../i386/isa/fd.c:1425 > > > #6 0xf011d203 in softclock () at ../../kern/kern_timeout.c:124 > > > #7 0xf01d6cc7 in doreti_swi () > > > Cannot access memory at address 0x274e35f8. > > > > > > Now I'm relatively certain that this was specifically caused by way to much disk access on SoftUpdates' part; any idea how we should fix this? > > > > > > Cheers, > > > Brian Feldman > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:14:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01685 for freebsd-current-outgoing; Sun, 31 May 1998 12:14:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01680 for ; Sun, 31 May 1998 12:14:41 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA07092; Sun, 31 May 1998 12:09:40 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd007089; Sun May 31 19:09:38 1998 Date: Sun, 31 May 1998 12:09:35 -0700 (PDT) From: Julian Elischer To: Andrzej Bialecki cc: Brian Feldman , freebsd-current@FreeBSD.ORG Subject: Re: fd crash (in isa_dmastart) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ah this sounds more liekly.. I'll pursue this.. I wonder whether devfs was being used inthe other case? julian On Sun, 31 May 1998, Andrzej Bialecki wrote: > On Sun, 31 May 1998, Julian Elischer wrote: > > > I'm not sure what causes this but it should be easy enough to reproduce.. > > I'll add it to my list of things to clean up... > > > > Interestingly enoungh the stack trace shows no softupdates related > > functions. > > I will guess however that the softupdate code may not fully appreciate the > > subtlties of bounce buffers > > as they are a FreeBSD oddity. > > (I can actually think of a few things to check out.) > > this may be a problem with aha1542 scsi systems too. > > As I wrote you some time ago, it's enough to try to mount msdos floppy > under DEVFS/SLICE kernel - it immediately panics with the same message. > > Andrzej Bialecki > > --------------------+--------------------------------------------------------- > abial@nask.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } > Research & Academic | "Be open-minded, but don't let your brains to fall out." > Network in Poland | All of the above (and more) is just my personal opinion. > --------------------+--------------------------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:24:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03585 for freebsd-current-outgoing; Sun, 31 May 1998 12:24:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03561 for ; Sun, 31 May 1998 12:24:13 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA07272; Sun, 31 May 1998 12:17:22 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd007268; Sun May 31 19:17:21 1998 Date: Sun, 31 May 1998 12:17:18 -0700 (PDT) From: Julian Elischer To: Micha Class cc: current@FreeBSD.ORG Subject: Re: scsi-uk and DEVFS In-Reply-To: <3571407E.D3D078E1@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG thanks.. On Sun, 31 May 1998, Micha Class wrote: > Hello, > > I just found that the uk-driver which I am using for my scanner > (together with sane), does not include devicenodes when DEVFS is used. > > The following patch fixes that for me (mostly stolen from pt.c) If > someone with commit-privileges could check and possibly commit this, > this would be nice. > > Michael > > > -- > ------------------------------------------------------------------------- > michael class, viktor-renner str. 39, 72074 tuebingen, frg > E-Mail: michael_class@hp.com > Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) > ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:24:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03680 for freebsd-current-outgoing; Sun, 31 May 1998 12:24:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03668 for ; Sun, 31 May 1998 12:24:26 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA07259; Sun, 31 May 1998 12:16:32 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd007253; Sun May 31 19:16:23 1998 Date: Sun, 31 May 1998 12:16:20 -0700 (PDT) From: Julian Elischer To: John Hay cc: current@FreeBSD.ORG Subject: Re: ports and the aout lib directory In-Reply-To: <199805311730.TAA02921@zibbi.mikom.csir.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG yeah like the gcc28 port needs a patch to make the 2nd stage bootstrap look in /usr/lib/aout.. (it's a simple patch or replacing /lib, which we don't use anyhow) I may change see if I can fix the port myself tomorrow (should still work on 2.2 because /usr/lib/aout is no more bogus than /lib :-) On Sun, 31 May 1998, John Hay wrote: > Hi, > > With the move of the lib files to /usr/lib/aout "make release" broke, > because when it builds the perl5 port, the perl5 configure script > try to find libc, but fail because it does not look in the aout > subdirectory. I guess this is just the first one because there are > probably other ports that try to do the same thing. > > So how should this be fixed? Should I just try to hack around it in the > release/Makefile? Are the elf libs going to live in /usr/lib? And how > soon? :-) Can we be without daily SNAPS for that long is what I mean. :-) > > John > -- > John Hay -- John.Hay@mikom.csir.co.za > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:42:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07002 for freebsd-current-outgoing; Sun, 31 May 1998 12:42:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from feldman.dyn.ml.org (root@1Cust162.tnt5.tco2.da.uu.net [153.35.91.162]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06977 for ; Sun, 31 May 1998 12:42:17 -0700 (PDT) (envelope-from green@feldman.dyn.ml.org) Received: (from root@localhost) by feldman.dyn.ml.org (8.8.8/8.8.8) id PAA04250; Sun, 31 May 1998 15:42:09 -0400 (EDT) (envelope-from green) Message-ID: <19980531154208.A4224@dyn.ml.org> Date: Sun, 31 May 1998 15:42:08 -0400 From: The Super-User To: freebsd-current@FreeBSD.ORG Subject: really bad inodedep crash Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, there goes another crash. I got a VERY strange crash, something about inodedep, by pressing ^Z during a make in a port dir; I haven't been able to recreate this crash, and the core seemed to be corrupted (or maybe the system was actually that way) because a backtrace was showing two undefined functions continually looping. I'd know more, but this vmcore got corrupted I guess :-/. Ahh well, if I can ever find something else like this again, I'll post again. BTW, this is with SoftUpdates, but a few days ago my computer DID crash with no softupdates, and only async; go figure. Brian Feldman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:47:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07811 for freebsd-current-outgoing; Sun, 31 May 1998 12:47:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles208.castles.com [208.214.165.208]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07803 for ; Sun, 31 May 1998 12:47:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA12651; Sun, 31 May 1998 11:43:18 -0700 (PDT) Message-Id: <199805311843.LAA12651@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) cc: mcdougall@ameritech.net, Kent A Vander Velden , current@FreeBSD.ORG Subject: Re: kernel config In-reply-to: Your message of "31 May 1998 18:56:36 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 11:43:18 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Adam McDougall writes: > > yup, add this to the kernel > > options USERCONFIG_BOOT > > YAUKO! I have some work in progress to make this option go away (and have kernel.config always parsed). Are there any strong objections to this? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 12:48:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07905 for freebsd-current-outgoing; Sun, 31 May 1998 12:48:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sicily.odyssey.cs.cmu.edu (SICILY.ODYSSEY.CS.CMU.EDU [128.2.185.138]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA07894 for ; Sun, 31 May 1998 12:48:14 -0700 (PDT) (envelope-from rvb@sicily.odyssey.cs.cmu.edu) From: rvb@sicily.odyssey.cs.cmu.edu To: Mike Smith Cc: current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <199805300626.XAA01190@antipodes.cdrom.com> Date: 31 May 1998 15:48:00 -0400 In-Reply-To: Mike Smith's message of Fri, 29 May 1998 23:26:48 -0700 Message-ID: Lines: 18 X-Mailer: Gnus v5.4.46/Emacs 19.34 Source-Info: Sender is really rvb@sicily.odyssey.cs.cmu.edu Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith writes: > > > Yes, but you can't *look*at* the template mount to find out what these > > > numbers *are*. > > > > Why *not*? :-) > > Because it ain't mounted anyhere. Think: user says: > > # rm /dev/foo0 > > # mknod /dev/foo0 c ??? > Would it be too strange to just not let you delete this kind of file? A long long time ago . and .. where files and root could delete them and/or make cycles. Now the fs abstraction is slightly different and (I hope) this is illegal. Well, if there is irreplaceablt info in these devfs files, just make them immutable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 13:04:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10173 for freebsd-current-outgoing; Sun, 31 May 1998 13:04:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from isua3.iastate.edu (isua3.iastate.edu [129.186.1.139]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10149 for ; Sun, 31 May 1998 13:04:31 -0700 (PDT) (envelope-from graphix@iastate.edu) Received: from localhost (graphix@localhost) by isua3.iastate.edu (8.8.5/8.8.5) with SMTP id PAA16442; Sun, 31 May 1998 15:04:28 -0500 (CDT) Message-Id: <199805312004.PAA16442@isua3.iastate.edu> To: Edwin Culp CC: current@FreeBSD.ORG Subject: Re: Undefined symbols referenced In-reply-to: Your message of "Sun, 31 May 1998 06:54:56 CDT." <35714510.7843D910@ver1.telmex.net.mx> Date: Sun, 31 May 1998 15:04:28 CDT From: "Kent Vander Velden" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <35714510.7843D910@ver1.telmex.net.mx>, Edwin Culp writes: >> I had the same problem a week or so ago. The xdelta port will not build on >> current ( cvsupped and make world this weekend) even rebuilding the gdbm por >t >> and reinstalling that does not work. >> Gimp will now build because the maintainer removed the dependency on xdelta >> but the xdelta port looks broken on current. >> >> Paul >> >Just yesterday, I compiled gimp-0.99.31 from ports on two different >machines >running current from may 5 with ports updated, with no problems. I also >changed to gtk-1.03. First I cleaned up all previous installations of >both. After having built and installing world and recompiling all the libraries that gimp-devel depends on (including libgdbm) I still get the same messages. After deinstalling xdelta the XD plugin (apparently the only part of gimp that uses xdelta) was not built and gimp built fine. As Paul van der Zwan suggested it all seems to be xdelta's fault. Thanks! --- Kent Vander Velden kent@iastate.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 13:32:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14914 for freebsd-current-outgoing; Sun, 31 May 1998 13:32:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from myrddin.demon.co.uk (exim@myrddin.demon.co.uk [158.152.54.180]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA14879; Sun, 31 May 1998 13:32:29 -0700 (PDT) (envelope-from dom@myrddin.demon.co.uk) Received: from dom by myrddin.demon.co.uk with local (Exim 1.80 #1) id 0ygEll-0000xJ-00; Sun, 31 May 1998 21:31:53 +0100 To: Peter Wemm cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Sendmail 8.9 In-reply-to: Peter Wemm's message of "Thu, 28 May 1998 21:41:27 +0800". <199805281341.VAA08110@spinner.netplex.com.au> Date: Sun, 31 May 1998 21:31:52 +0100 From: Dom Mitchell Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 28 May 1998, Peter Wemm proclaimed: > Dom Mitchell wrote: > > Wouldn't it be easier to just stick with 8.8.8 until the licensing > > issues of this latest sendmail can be clarified? > > Yes, that's pretty much what is happening by default. I have asked the > sendmail people twice now about this and still have got no response. I > might try sending by fax next. I find it quite ironic that people setting > up to sell sendmail don't have a handle on email. *sigh* Sadly very often true. > > P.S. You left out MMDF. :-) > > MMDF can go away and die. I've wasted too much of my life fighting MMDF > (and often loosing).. I wholeheartedly agree after a year of working as mailman at Demon Internet. There are too many fools still out there on the Internet who think that it's actually a useful mailer. Mind you, it did have anti-relaying first. :-) -- cathetometric Cepolidae antigenicity burry beadlehood anthozooid amphiprotic amarevole aseptify aquacultural addleheadedness appropinquation antipleion amasser Athapascan admittance bedrench anallantoic Aurantium barbiton airampo athenee blondeness backbitingly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 13:37:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15869 for freebsd-current-outgoing; Sun, 31 May 1998 13:37:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15848; Sun, 31 May 1998 13:37:22 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id EAA04648; Mon, 1 Jun 1998 04:36:19 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199805312036.EAA04648@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Joseph Stein cc: dom@myrddin.demon.co.uk, current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Sendmail 8.9 In-reply-to: Your message of "Sun, 31 May 1998 10:47:21 MST." <199805311747.KAA19941@shasta.wstein.com> Date: Mon, 01 Jun 1998 04:36:18 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joseph Stein wrote: > Peter Wemm allegedly wrote: > > Argh, I take that back, I shouldn't have uttered such crap, especially when > > I had a reply in my mailbox that I had not yet seen. (And even if it > > wasn't, this still wasn't appropriate). My big mouth is really going to > > get me in trouble sooner or later. > > > So what was the final verdict? Any clarifications in the works, or is > everyone that wants to use 8.9.0 on their own? (no problem for me, I'm > already upgraded, but just a general question.) Yes, they have no interest with anything else other than sendmail itself. The intent is that one could sell a binary-only freebsd, as long as you either:- 1) removed sendmail 2) included sendmail source 3) provide sendmail source if asked 4) are not selling sendmail but are providing it with the system for free with no restrictions. ie: the end user could take the sendmail binaries and copy/distribute/whatever even though your commercial system license may prevent or restrict copying of everything else. In other words, it shouldn't be a problem in FreeBSD, unless somebody is trying to sell sendmail *itself* along with freebsd. An example of somebody who would need a seperate license would be somebody who is selling a mail handling system with extensive proprietary sendmail mods where the licensing requires the customer buy a copy per machine. Somebody in that situation would likely be interested in Sendmail Pro anyway. Clarifications to the license are theoretically under way but have to be approved by the lawyers first. > joe > -- > Joseph Stein Oregon FirePage http://www.ofp.org > Beaverton, Oregon (*) [OFP4/PDX] > (503) 301-1575 -or- joes@pager.wstein.com joes@wstein.com > * Oregon, n.: Eighty billion gallons of water with no place to go on Saturday > Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 13:44:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17533 for freebsd-current-outgoing; Sun, 31 May 1998 13:44:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17155; Sun, 31 May 1998 13:43:00 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id EAA04702; Mon, 1 Jun 1998 04:41:38 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199805312041.EAA04702@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Dom Mitchell cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Sendmail 8.9 In-reply-to: Your message of "Sun, 31 May 1998 21:31:52 +0100." Date: Mon, 01 Jun 1998 04:41:37 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dom Mitchell wrote: > On 28 May 1998, Peter Wemm proclaimed: > > Dom Mitchell wrote: > > > Wouldn't it be easier to just stick with 8.8.8 until the licensing > > > issues of this latest sendmail can be clarified? > > > > Yes, that's pretty much what is happening by default. I have asked the > > sendmail people twice now about this and still have got no response. I > > might try sending by fax next. I find it quite ironic that people setting > > up to sell sendmail don't have a handle on email. > > *sigh* Sadly very often true. I've taken that back. The explanation was far less sinister, they were just out of town for a week and were swamped. This is under way now. > > > P.S. You left out MMDF. :-) > > > > MMDF can go away and die. I've wasted too much of my life fighting MMDF > > (and often loosing).. > > I wholeheartedly agree after a year of working as mailman at Demon > Internet. There are too many fools still out there on the Internet who > think that it's actually a useful mailer. Mind you, it did have > anti-relaying first. :-) Yes, it does the anti-relaying too damn well - that was the problem I always had, I never really got a good handle on getting it to intentionally relay mail... :-] Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 13:45:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17960 for freebsd-current-outgoing; Sun, 31 May 1998 13:45:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles208.castles.com [208.214.165.208]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17514; Sun, 31 May 1998 13:44:13 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA12982; Sun, 31 May 1998 12:39:29 -0700 (PDT) Message-Id: <199805311939.MAA12982@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: tcobb cc: "'Mike Smith'" , "'shimon@simon-shapiro.org'" , "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: DPT Redux In-reply-to: Your message of "Sun, 31 May 1998 00:26:07 EDT." <509A2986E5C5D111B7DD0060082F32A402FAF6@freya.circle.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 12:39:29 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > -----Original Message----- > > From: Mike Smith [mailto:mike@smith.net.au] > > > I shutdown and rebooted machine (SYNC failed on shutdown) > > > Allowed FreeBSD to boot, it returned the following for sd1 > > > sd1: type 0 fixed SCSI 2 > > > sd1: Direct-Access 0MB (1 512 byte sectors) > > > > > > Then, system continued booting and finally panic'd with a > > "Page Fault in > > > Supervisor Mode" error prior to mounting drives. > > > > Did you happen to write down the details from this message? In > > conjunction with your kernel image, these are required in order to > > determine what happened. > > This is the one thing I neglected to do, unfortunately - I just got the > error name, not the rest of the info. The situation was a surprise and > had become an emergency at the point it was clear that FreeBSD wasn't > going to reboot. Grr. This makes identifying the culprit extremely difficult. 8( > > It's possible that something doesn't like being asked to boot from a > > zero-sized disk. It's also possible that something else later got > > upset - it's not clear where in the chain of events the panic > > occurred > > (see above). > > Actually, it wasn't booting from the "zero-sized" disk. From my earlier > email, I noted that I have two arrays configured, the first sd0, is the > boot disk and RAID-1 and contains all relevant system directories, the > second sd1, is simply an NFS export partition and is RAID-5. It was the > second disk (sd1) which showed the "0 MB/1 sector" problem. Gotcha - I had discarded the reference to the specific disk in question. > > Thanks for the extra info. Are you able to simulate the > > failure by eg. > > disconnecting one of the 'active' drives? If you can't do this on a > > regular basis, I believe we are able to arrange temporary access to a > > similar but idle system where this can be simulate. Simon > > may also be > > able to offer some suggestions inre. possible poor > > interaction between > > the dpt driver and some firmware revisions. > > I'm hoping to be able to create a duplicate array to this one for > testing, also. I'm getting resistance to budgeting additional funds for > DPT/FreeBSD at the moment :( The machine in question is currently (and > still) a live NFS server. I'm working on scheduling some downtime for > it in the next few days get a hotswap drive back in there. I expect > that I'll have to keep it down (1.5hrs) for a complete array rebuild on > the RAID-5 given the interactions I've seen recently. If you can boot while the array is rebuilding and obtain a traceback (and preferably a kernel core dump), this would be *invaluable* in determining the actual problem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 13:50:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA18864 for freebsd-current-outgoing; Sun, 31 May 1998 13:50:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18787 for ; Sun, 31 May 1998 13:49:57 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id NAA17705; Sun, 31 May 1998 13:49:56 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd017686; Sun May 31 13:49:54 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA12752; Sun, 31 May 1998 13:49:51 -0700 (MST) From: Terry Lambert Message-Id: <199805312049.NAA12752@usr06.primenet.com> Subject: Re: I see one major problem with DEVFS... To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Sun, 31 May 1998 20:49:50 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, current@FreeBSD.ORG In-Reply-To: <3354.896616697@critter.freebsd.dk> from "Poul-Henning Kamp" at May 31, 98 02:11:37 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >If a device is removed from a chroot environment, it should be impossible > >to recreate it. > > > >The reasoning should be obvious. > > But the argument is nontheless badly flawed. > > This should be done by disallowing mknods by chrooted processes if > such security is desired. If you disallow all mknods by all processes, then they will be disallowed by chrooted processes, which are a subset of the set of all processes. 8-). The mknod code should go away for anything but named pipes; and since FreeBSD has mkfifo for that case, it should go away, period. If you want a node that is already there, but want it by a different name, then you should use "ln" or "link(2)". That's the method, as I understand Julian's explanation of the security model. Maybe it's time to document the security model, critique it, then refine it, then implement to the documentation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 14:05:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA21976 for freebsd-current-outgoing; Sun, 31 May 1998 14:05:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21970 for ; Sun, 31 May 1998 14:05:13 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA23437; Sun, 31 May 1998 14:05:12 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd023410; Sun May 31 14:05:10 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA13664; Sun, 31 May 1998 14:05:05 -0700 (MST) From: Terry Lambert Message-Id: <199805312105.OAA13664@usr06.primenet.com> Subject: Re: I see one major problem with DEVFS... To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 31 May 1998 21:05:05 +0000 (GMT) Cc: tlambert@primenet.com, julian@whistle.com, phk@critter.freebsd.dk, current@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Jun 1, 98 03:36:36 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If a device is removed from a chroot environment, it should be impossible > > to recreate it. > > > > The reasoning should be obvious. > > Why not just control permissions on mknod? I think Julian should discuss his security model before we dive into this, but I can't see a circumstance where it would be legitimate to create a device with mknod, yet not possible to create it with the link(2) system call instead, using the template devfs. It seems to me that mknod is redundant (but mkfifo isn't). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 14:11:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22871 for freebsd-current-outgoing; Sun, 31 May 1998 14:11:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22866 for ; Sun, 31 May 1998 14:11:47 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.8.8/8.7.3) with ESMTP id RAA28499; Sun, 31 May 1998 17:11:04 -0400 (EDT) Message-Id: <199805312111.RAA28499@whizzo.transsys.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mike Smith cc: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ), mcdougall@ameritech.net, Kent A Vander Velden , current@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: kernel config References: <199805311843.LAA12651@antipodes.cdrom.com> In-reply-to: Your message of "Sun, 31 May 1998 11:43:18 PDT." <199805311843.LAA12651@antipodes.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 17:11:04 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Adam McDougall writes: > > > yup, add this to the kernel > > > options USERCONFIG_BOOT > > > > YAUKO! > > I have some work in progress to make this option go away (and have > kernel.config always parsed). Are there any strong objections to this? Sounds good to me. Is it still necessary to have the (undocumented) "USERCONFIG\n" string at the start of this file? As far as I know, this is only documented in the source code and seems to be a point of frequent confusion. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 14:39:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25950 for freebsd-current-outgoing; Sun, 31 May 1998 14:39:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25942 for ; Sun, 31 May 1998 14:39:28 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA09209; Sun, 31 May 1998 14:39:23 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd009152; Sun May 31 14:39:14 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA15254; Sun, 31 May 1998 14:39:07 -0700 (MST) From: Terry Lambert Message-Id: <199805312139.OAA15254@usr06.primenet.com> Subject: Re: I see one major problem with DEVFS... To: peter@netplex.com.au (Peter Wemm) Date: Sun, 31 May 1998 21:39:07 +0000 (GMT) Cc: jkh@time.cdrom.com, eivind@yes.no, current@FreeBSD.ORG In-Reply-To: <199805300511.NAA20017@spinner.netplex.com.au> from "Peter Wemm" at May 30, 98 01:11:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Remember this is merely step 1. The Plan is to eventually replace minor/ > major devices completely so that the filesystem interface will probably be > through a 32 bit vnode pointer or something along those lines. Exactly. > Doing a mknod will be practically impossible. It was my understanding that it would be completely impossible. > (This has some major benefits but will be a major change in the > driver/kernel/fs interface. Drivers won't have a major/minor number > anymore, they'll just have a unit number.. More specifically structurally... struct fileops goes away. > specfs will either be gone or won't resemble anything like it does now, > and will probably hang off devfs instead. It'll be gone. The point of having a specfs is to allow the creation of device nodes on (potentially) non-FFS file systems, such as NFS. Currently, it is impossible to use device nodes over NFS mounts to very nearly any non-FreeBSD machine because of the number of major and minor bits exceeding the capability of the boot host. The DEVFS solves this problem, and at the same time makes it much easier to bring up a FreeBSD port to another architecture, by allowing a working environment without any local-media FS's. > For the problem at hand though, I once suggested to Julian that we use > undelete(2) to make files come back. "rm -W bpf4" could almost work as is, > except that it wants to stat the file and look for whiteout flags first and > 'rm' doesn't create a whiteout in devfs. (This might be an interesting > approach to the problem if all unlinks caused a whiteout instead of the > node disappearing entirely.) This would be useful for devices which you allow to come back; one might question why you made them go away in the first place, however. The model is more fuzzy for things like PnP device arrival on a copy of a template FS. When I plug in my Flash-RAM card, does it become visibile in the chroot environment? I'd say "no". In my mind, the simpler the security model, and the fewer exceptions, the better. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 14:45:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26943 for freebsd-current-outgoing; Sun, 31 May 1998 14:45:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26921; Sun, 31 May 1998 14:45:12 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id RAA06956; Sun, 31 May 1998 17:45:06 -0400 (EDT) Date: Sun, 31 May 1998 17:45:05 -0400 (EDT) From: The Hermit Hacker To: freebsd-current@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG Subject: May29th kernel with May20th CAM drivers: panic? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi... I'm not going to bother submitting a problem report on this, mainly because I don't even have a core to analyze, but I figured I'd at least put a 'head up' on this, in case this anything to someone... Fatal trap 12: page fault while in kernel mode fault virtual address = 0xefcb5b1c fault code = supervisor read, page not present instruction pointer = 0x8:0xf01a88ad stack pointer = 0x10:0xf6951af4 frame pointer = 0x10:0xf6951b28 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 = 7011 (innfeed) interrupt mask = net bio kernel: type 12 trap, code=0 Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx db> panic panic: from debugger syncing disks... 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 giving up dumping to dev 20401, offset 262144 dump Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01118a6 stack pointer = 0x10:0xf6951710 frame pointer = 0x10:0xf69517cc 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 = 7011 (innfeed) interrupt mask = net tty bio cam kernel: type 12 trap, code=0 Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx db> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 14:52:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28266 for freebsd-current-outgoing; Sun, 31 May 1998 14:52:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28258 for ; Sun, 31 May 1998 14:52:48 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id VAA22872; Sun, 31 May 1998 21:52:47 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA01079; Sun, 31 May 1998 23:52:33 +0200 (MET DST) Message-ID: <19980531235232.04296@follo.net> Date: Sun, 31 May 1998 23:52:32 +0200 From: Eivind Eklund To: Richard Wackerbarth Cc: current@FreeBSD.ORG Subject: Re: How about /usr/ports/kernel ? References: ; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <19980531052120.41610@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Richard Wackerbarth on Sun, May 31, 1998 at 11:50:33AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, May 31, 1998 at 11:50:33AM -0500, Richard Wackerbarth wrote: > At 3:21 AM -0000 5/31/98, Eivind Eklund wrote: >> On Sat, May 30, 1998 at 03:45:31PM -0500, Richard Wackerbarth wrote: >>> At 4:29 PM -0000 5/30/98, Eivind Eklund wrote: >>> >>> My own view of this is that config(8) should scan for >>> ../../*/conf/files.FreeBSD >>> ../../*/conf/options.FreeBSD >>> ../../*/conf/files.FreeBSD. >>> ../../*/conf/options.FreeBSD. >>> add concatenate this with the appropriate files. > >> [...on having kernels made as a part of a normal build...] >> >> We've discussed this before (off the list), and I tend to agree to >> some of it. However, how is this related to the proposal above >> (except for both being part of the kernel build structure)? > > I think that it is a "detail". Rather than increasing the complexity > of "config", I would use the capability of "make" and the preprocessors > to present to "config", a single list of elements that it must process. Now I get you. Yes, I agree this would be preferable given automated kernel builds (and I agree that automated kernel builds would be preferable :-) However, to be able to do automated kernel builds we have to have a way of specifying which kernels to build which do not come as a shock to our userbase (this is a political necessity; I don't think either of us would get any way arguing otherwise). This probably mean that we'll have to support the use of config(8) in the way it is presently used for a transition period of at least a year. This again mean that if we want to do the above during the next year (minimum), we'll have to add it to config. I want the above to be added yesterday (well, really in time for 2.2.0-RELEASE, that is in February last year :-) Do you disagree with the way of adding this meta-information to contributed subsystems? I'm all ears for anything better that give the same capabilites for external people modifying the system - I just haven't found any better way. [... deleted: points on Unix and design which I agree with but don't always find myself bright enough to be able to follow ...] Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:06:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00516 for freebsd-current-outgoing; Sun, 31 May 1998 15:06:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA00490 for ; Sun, 31 May 1998 15:06:34 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 2127 invoked by uid 505); 31 May 1998 22:06:20 -0000 Date: 31 May 1998 22:06:20 -0000 Message-ID: <19980531220620.2126.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: fd crash (in isa_dmastart) In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Correct. -Brian > was softupdates enabled of the floppy filesystem? > (i.e. did you use "tunefs -n enable" on the floppy?) > > > > On 31 May 1998, Brian Feldman wrote: > > > Well, if you see that "Cannot access memory at 0xwhatever" I think that might be why you can't see softupdates calling it ;) Just a note here, of course. Other thing being that the only thing I was doing at all on the system was cp'ing some stuff onto the disk. Like I said, just a little clarification mail. > > > > Cheers, > > Brian Feldman > > > > > I'm not sure what causes this but it should be easy enough to reproduce.. > > > I'll add it to my list of things to clean up... > > > > > > Interestingly enoungh the stack trace shows no softupdates related > > > functions. > > > I will guess however that the softupdate code may not fully appreciate the > > > subtlties of bounce buffers > > > as they are a FreeBSD oddity. > > > (I can actually think of a few things to check out.) > > > this may be a problem with aha1542 scsi systems too. > > > > > > > > > > > > julian > > > > > > > > > On 31 May 1998, Brian Feldman wrote: > > > > > > > Well, out of curiousity, I wanted to try SoftUpdates on a floppy. Let's just say that SoftUpdates on a floppy is a Bad Thing, causing Too Much Disk Access and A Bad Panic. (out out evil capitals!) Here's the bt, for those interested, and I'll delete this huge vmcore tomorrow if noone tells me not to and we don't want to try to get any more info out of it: > > > > (kgdb) bt > > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 > > > > #1 0xf0118fc7 in panic (fmt=0xf01f1f56 "isa_dmastart: bad bounce buffer") > > > > at ../../kern/kern_shutdown.c:421 > > > > #2 0xf01f1fcf in isa_dmastart (flags=587333684, addr=0xf2d4d014 "ð\004", > > > > nbytes=4096, chan=2) at ../../i386/isa/isa.c:767 > > > > #3 0xf01ec1fd in fdstate (fdcu=0, fdc=0xf02622d4) at ../../i386/isa/fd.c:1640 > > > > #4 0xf01ebcb3 in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 > > > > #5 0xf01ebc75 in fd_pseudointr (arg1=0x0) at ../../i386/isa/fd.c:1425 > > > > #6 0xf011d203 in softclock () at ../../kern/kern_timeout.c:124 > > > > #7 0xf01d6cc7 in doreti_swi () > > > > Cannot access memory at address 0x274e35f8. > > > > > > > > Now I'm relatively certain that this was specifically caused by way to much disk access on SoftUpdates' part; any idea how we should fix this? > > > > > > > > Cheers, > > > > Brian Feldman > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:11:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01563 for freebsd-current-outgoing; Sun, 31 May 1998 15:11:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA01552 for ; Sun, 31 May 1998 15:11:37 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 2397 invoked by uid 505); 31 May 1998 22:11:22 -0000 Date: 31 May 1998 22:11:22 -0000 Message-ID: <19980531221122.2396.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: fd crash (in isa_dmastart) (more clarifications) In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG No SCSI anything, so no CAM of course; no SLICE no DEVFS at all SoftUpdate and tunefs -n enable /dev/rfd0a This is a pretty normal 3.0 system. Now onto all the other crashes I'm getting so frequently nowadays..... -Brian > was softupdates enabled of the floppy filesystem? > (i.e. did you use "tunefs -n enable" on the floppy?) > > > > On 31 May 1998, Brian Feldman wrote: > > > Well, if you see that "Cannot access memory at 0xwhatever" I think that might be why you can't see softupdates calling it ;) Just a note here, of course. Other thing being that the only thing I was doing at all on the system was cp'ing some stuff onto the disk. Like I said, just a little clarification mail. > > > > Cheers, > > Brian Feldman > > > > > I'm not sure what causes this but it should be easy enough to reproduce.. > > > I'll add it to my list of things to clean up... > > > > > > Interestingly enoungh the stack trace shows no softupdates related > > > functions. > > > I will guess however that the softupdate code may not fully appreciate the > > > subtlties of bounce buffers > > > as they are a FreeBSD oddity. > > > (I can actually think of a few things to check out.) > > > this may be a problem with aha1542 scsi systems too. > > > > > > > > > > > > julian > > > > > > > > > On 31 May 1998, Brian Feldman wrote: > > > > > > > Well, out of curiousity, I wanted to try SoftUpdates on a floppy. Let's just say that SoftUpdates on a floppy is a Bad Thing, causing Too Much Disk Access and A Bad Panic. (out out evil capitals!) Here's the bt, for those interested, and I'll delete this huge vmcore tomorrow if noone tells me not to and we don't want to try to get any more info out of it: > > > > (kgdb) bt > > > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 > > > > #1 0xf0118fc7 in panic (fmt=0xf01f1f56 "isa_dmastart: bad bounce buffer") > > > > at ../../kern/kern_shutdown.c:421 > > > > #2 0xf01f1fcf in isa_dmastart (flags=587333684, addr=0xf2d4d014 "ð\004", > > > > nbytes=4096, chan=2) at ../../i386/isa/isa.c:767 > > > > #3 0xf01ec1fd in fdstate (fdcu=0, fdc=0xf02622d4) at ../../i386/isa/fd.c:1640 > > > > #4 0xf01ebcb3 in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 > > > > #5 0xf01ebc75 in fd_pseudointr (arg1=0x0) at ../../i386/isa/fd.c:1425 > > > > #6 0xf011d203 in softclock () at ../../kern/kern_timeout.c:124 > > > > #7 0xf01d6cc7 in doreti_swi () > > > > Cannot access memory at address 0x274e35f8. > > > > > > > > Now I'm relatively certain that this was specifically caused by way to much disk access on SoftUpdates' part; any idea how we should fix this? > > > > > > > > Cheers, > > > > Brian Feldman > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:13:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01938 for freebsd-current-outgoing; Sun, 31 May 1998 15:13:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01933 for ; Sun, 31 May 1998 15:13:20 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA18456; Sun, 31 May 1998 15:13:16 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd018435; Sun May 31 15:13:13 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA16988; Sun, 31 May 1998 15:13:11 -0700 (MST) From: Terry Lambert Message-Id: <199805312213.PAA16988@usr06.primenet.com> Subject: Re: Fix for undefined "__error" and discussion of shared object To: rkw@dataplex.net (Richard Wackerbarth) Date: Sun, 31 May 1998 22:13:11 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: from "Richard Wackerbarth" at May 31, 98 11:30:05 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> As much as we might like to think otherwise, assumptions about the structure > >> of the underlying OS and "hardcoded" into the source of the program. :-( > > > >The point is to make a port for FreeBSD 3.x work on FreeBSD 235.x, not > >the reverse. In other words, "compile once, run anywhere". > > > >The binary compatability from FreeBSD 3.x to FreeBSD 235.x is a > >problem for the XANDF processor during the install. > > And for it to be possible, there must be a "compatability library" of some > kind. This is false. If you install from an XANDF "binary", you regenerate the assmebly code, and you relink. When you relink, you will relink against whatever the current libraries are. If you are worrying about binary compatability, well, we already shoulder this burden for previous releases of FreeBSD, and previous releases of Linux, for that matter. > FreeBSD in its totality. What are you going to do when a concept entirely > disappears? As an example, consider the impact of the eventual integration > of devfs. By the time we get to FreeBSD 235.x, do you really expect to be > able to support today's hack dejuor which relies on the present major/minor > device numbers? I think not. Quite right. Software which depends on these constructs will fail to operate. This is as expected as software depending on WIN32 constructs failing to operate on FreeBSD now. > As systems evolve, you are eventually forced to abandon the albatroses > of legacy compatability. But they make such lovely necklaces... ;-). > An even harder problem is related to timing assumptions that are > hardcoded into programs. Many programs "work" only because they > assume things about the hardware and/or compilers. Like support for generating 386 assembly inline in nominally machine independent code? I am aware of the issues. The timing issues are less important, cv: > Remember programs that "poked" an I/O register and controlled the > timing with delay loops? FreeBSD still has some of this; and yes, they fail on some systems where the I/O space is cached. Linux has "fixed" these by doing a write as well as a read, which results in a cache flush, and yes, FreeBSD still has some bugs in this area, especially inre. keyboards and LEDs. > They would never work today if a "decent" compiler were to get hold > of them and optimize away the code that simply created delays. Not permissible, if the memory and/or I/O space addresses are marked volatile, as they should be. > Where they were written, the languages never had the concept of > optimization. The languages *did* have this concept. The problem is the ANSI C committees decision to allow certain types of optimization unless it was specifically disallowed. Yes, this broke a lot of programs, until the 'volatile fairy' sprinkled 'volatile dust' throughout the code that depended on compilers that believed in "above all else, do no harm". I blame compiler writers, since compilers should know about the hardware they are pretending to target. But that is another discussion... ;-). > As a result, the programmers never put the necessary hooks into > the program to guide the compiler about which factors are important. The problem is that the language changed, and there was an (invalid) assumption of unimportance "unless otherwise stated". Negative logic tends to back you into this type of incompatability corner. Part of the other discussion (see above)... > All that I am saying is that I do not believe that it is possible to > both maintain infinity compatability and allow for future innovation. > At some point, the two concepts reach a point of unresolvable conflict. > After that point, one of then will no longer apply. Well, I am (I hope) well known as an advocate of "revolution instead of evolution"; technology moves too damn slow for me as it is, since I can see the next vista, tantalizingly just out of reach, and it annoys the hell out of me. 8-). It's not just computer science, either, it's everywhere. I agree that at some point you are going to lose backward compatability; I think, however, that XANDF will push this off, since most of the historical compatability issues can be resolved by regenerating the assembly code, and relinking, which is implied. I *really* look forward to the day when I can buy an XANDF Motif library, and use it on all my hardware, regardless of the CPU type. 8-0. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:18:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03026 for freebsd-current-outgoing; Sun, 31 May 1998 15:18:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA03019 for ; Sun, 31 May 1998 15:18:39 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 2670 invoked by uid 505); 31 May 1998 22:18:25 -0000 Date: 31 May 1998 22:18:25 -0000 Message-ID: <19980531221825.2669.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: IP Packet Aliasing Broke? In-Reply-To: <19980531140201.06705@TOJ.org> To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, now that we know this, why don't you send the message over to Brian Somers rather than guessing whether he will check out the current freebsd-current messages? brian@freebsd.org, of course Brian Feldman > On Sun, May 31, 1998 at 12:12:41AM -0700, Julian Elischer wrote: > > I made changes to ipfw and DIVERT that should have been transparent > > but may not have been if natd didn't do things quite "by the book". > > > > I assume you are saying that natd is broken? > > > > julian > > > > > > On Sat, 30 May 1998, Tom Jackson wrote: > > > > > On May 28 packet forwarding was working, on the 29 it was *not*. > > > Any ideas or did I miss something? All I have done is make world > > > and kernel rebuid. > > > > > > -- > > > Tom > > > > > No, sorry for not being clear. User ppp ip packet aliasing. Trying to > figure out what happened but haven't yet. > -- > Tom > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:20:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03406 for freebsd-current-outgoing; Sun, 31 May 1998 15:20:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03363; Sun, 31 May 1998 15:20:18 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA04786; Sun, 31 May 1998 16:20:07 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199805312220.QAA04786@panzer.plutotech.com> Subject: Re: May29th kernel with May20th CAM drivers: panic? In-Reply-To: from The Hermit Hacker at "May 31, 98 05:45:05 pm" To: scrappy@hub.org (The Hermit Hacker) Date: Sun, 31 May 1998 16:20:07 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Hermit Hacker wrote... > > Hi... > > I'm not going to bother submitting a problem report on this, > mainly because I don't even have a core to analyze, but I figured I'd at > least put a 'head up' on this, in case this anything to someone... > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xefcb5b1c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf01a88ad > stack pointer = 0x10:0xf6951af4 > frame pointer = 0x10:0xf6951b28 > 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 = 7011 (innfeed) > interrupt mask = net bio > kernel: type 12 trap, code=0 > Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx tulip_txput() is in the DEC 2114x driver. I kinda doubt this really has anything to do with CAM. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:29:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05547 for freebsd-current-outgoing; Sun, 31 May 1998 15:29:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05497; Sun, 31 May 1998 15:29:34 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id SAA12178; Sun, 31 May 1998 18:29:29 -0400 (EDT) Date: Sun, 31 May 1998 18:29:28 -0400 (EDT) From: The Hermit Hacker To: "Kenneth D. Merry" cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? In-Reply-To: <199805312220.QAA04786@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 May 1998, Kenneth D. Merry wrote: > The Hermit Hacker wrote... > > > > Hi... > > > > I'm not going to bother submitting a problem report on this, > > mainly because I don't even have a core to analyze, but I figured I'd at > > least put a 'head up' on this, in case this anything to someone... > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xefcb5b1c > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xf01a88ad > > stack pointer = 0x10:0xf6951af4 > > frame pointer = 0x10:0xf6951b28 > > 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 = 7011 (innfeed) > > interrupt mask = net bio > > kernel: type 12 trap, code=0 > > Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx > > > tulip_txput() is in the DEC 2114x driver. Hrmmm...are there any known problems with the 2114x driver? I do see the following periodically: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) de0: abnormal interrupt: transmit underflow (raising TX threshold to 8|512) On: de0: rev 0x22 int a irq 9 on pci0.10.0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:60:67:30:75:ef In 100Mb/s mode... > I kinda doubt this > really has anything to do with CAM. The reason I included the bit about the CAM driver was the second panic, which mentioned 'cam' in the interrupt_mask, whereas the first didn't...:( db> panic panic: from debugger syncing disks... 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 giving up dumping to dev 20401, offset 262144 dump Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01118a6 stack pointer = 0x10:0xf6951710 frame pointer = 0x10:0xf69517cc 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 = 7011 (innfeed) interrupt mask = net tty bio cam kernel: type 12 trap, code=0 Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx db> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:35:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06597 for freebsd-current-outgoing; Sun, 31 May 1998 15:35:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06578 for ; Sun, 31 May 1998 15:34:58 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id IAA15578; Mon, 1 Jun 1998 08:43:15 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199805312243.IAA15578@cimlogic.com.au> Subject: Re: ELF preparation step 2 done In-Reply-To: from Alex at "May 31, 98 10:53:24 am" To: garbanzo@hooked.net (Alex) Date: Mon, 1 Jun 1998 08:43:15 +1000 (EST) Cc: roberto@keltia.freenix.fr, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex wrote: > And what's the accepted method for building an elf-world? My efforts > still seem to result in a make buildworld falling over. The make world process is currently unsuitable for building elf from a standing start (i.e. with only aout). Messages to this list have noted that certain elf preparation steps have been completed, not that you can build elf yet. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 15:35:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06650 for freebsd-current-outgoing; Sun, 31 May 1998 15:35:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from azimov.videotron.ca (ppp027.132.mmtl.videotron.net [207.96.132.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06635 for ; Sun, 31 May 1998 15:35:30 -0700 (PDT) (envelope-from sepotvin@videotron.ca) Received: from videotron.ca (localhost [127.0.0.1]) by azimov.videotron.ca (8.8.8/8.8.8) with ESMTP id SAA00382 for ; Sun, 31 May 1998 18:37:18 -0400 (EDT) (envelope-from sepotvin@videotron.ca) Message-ID: <3571DB9E.2C392372@videotron.ca> Date: Sun, 31 May 1998 18:37:18 -0400 From: "Stephane E. Potvin" Organization: IBM Canada Ltd. X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: Softded panic Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Got the following panic trying to run a make release on my system FreeBSD alexis.videotron.ca 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Sat May 30 16:53:12 EDT 1998 rubik@alexis.videotron.ca:/mnt/.2/FreeBSD/src/sys/compile/ALEXIS i386 Pentium 166Mhz, 32M RAM Here is the panic information: 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.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... IdlePTD 225000 initial pcb at 1ffb04 panicstr: handle_written_inodeblock: live inodedep panic messages: --- panic: handle_written_inodeblock: live inodedep syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xf013183e stack pointer = 0x10:0xf01efdc4 frame pointer = 0x10:0xf01efdd0 = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault dumping to dev 20001, offset 196608 dump 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:281 281 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:281 #1 0xf01160c6 in panic (fmt=0xf01c221f "page fault") at ../../kern/kern_shutdown.c:421 #2 0xf01c2e6d in trap_fatal (frame=0xf01efd88) at ../../i386/i386/trap.c:879 #3 0xf01c2900 in trap_pfault (frame=0xf01efd88, usermode=0) at ../../i386/i386/trap.c:772 #4 0xf01c255f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1073168320, tf_ebp = -266404400, tf_isp = -266404432, tf_ebx = -248261952, tf_edx = -1073168320, tf_ecx = -266404376, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -267184066, tf_cs = 8, tf_eflags = 66118, tf_esp = -248261952, tf_ss = -248261872}) at ../../i386/i386/trap.c:396 #5 0xf013183e in flushdirtybuffers (slpflag=0, slptimeo=0) at ../../kern/vfs_bio.c:1254 #6 0xf0130853 in bdwrite (bp=0xf133d2c0) at ../../kern/vfs_bio.c:512 #7 0xf0196841 in ffs_update (vp=0xf3242020, access=0xf01efe70, modify=0xf01efe70, waitfor=0) at ../../ufs/ffs/ffs_inode.c:132 #8 0xf019ee52 in ffs_sync (mp=0xf06c9800, waitfor=2, cred=0xf06c1e00, p=0xf0219088) at ../../ufs/ffs/ffs_vfsops.c:999 #9 0xf01393e3 in sync (p=0xf0219088, uap=0x0) at ../../kern/vfs_syscalls.c:517 #10 0xf0115cab in boot (howto=256) at ../../kern/kern_shutdown.c:203 #11 0xf01160c6 in panic ( fmt=0xf019ba03 "handle_written_inodeblock: live inodedep") at ../../kern/kern_shutdown.c:421 #12 0xf019bccf in handle_written_inodeblock (inodedep=0xf087ea80, bp=0xf1317040) at ../../ufs/ffs/ffs_softdep.c:3240 #13 0xf019b4bb in softdep_disk_write_complete (bp=0xf1317040) at ../../ufs/ffs/ffs_softdep.c:2921 #14 0xf0132626 in biodone (bp=0xf1317040) at ../../kern/vfs_bio.c:1917 #15 0xf01e5411 in wdintr (unit=0) at ../../i386/isa/wd.c:1419 (kgdb) frame 12 #12 0xf019bccf in handle_written_inodeblock (inodedep=0xf087ea80, bp=0xf1317040) at ../../ufs/ffs/ffs_softdep.c:3240 3240 panic("handle_written_inodeblock: live inodedep" ); (kgdb) print *inodedep $1 = {id_list = {wk_list = {le_next = 0xf08c8e80, le_prev = 0xf1317164}, wk_type = 1, wk_state = 13}, id_hash = {le_next = 0x0, le_prev = 0xf06ddc6c}, id_fs = 0xf06ee800, id_ino = 318372, id_nlinkdelta = 0, id_savedino = 0x0, id_deps = {le_next = 0xf0d71b80, le_prev = 0xf0c08c58}, id_buf = 0x0, id_savedsize = 0xffffffffffffffff, id_pendinghd = {lh_first = 0xf0803260}, id_bufwait = {lh_first = 0x0}, id_inowait = {lh_first = 0x0}, id_inoupdt = {tqh_first = 0x0, tqh_last = 0xf087eac4}, id_newinoupdt = {tqh_first = 0x0, tqh_last = 0xf087eacc}} (kgdb) print (struct diradd) *inodedep->id_pendinghd->lh_first $2 = {da_list = {wk_list = {le_next = 0x0, le_prev = 0xf087eab8}, wk_type = 10, wk_state = 32781}, da_pdlist = {le_next = 0xf08c4d40, le_prev = 0xf082b8ac}, da_offset = 60, da_newinum = 318372, da_un = { dau_previous = 0xf0bf3a00, dau_pagedep = 0xf0bf3a00}} Seems that a directory buffer hit the disk before the associated inode. LIST_FIRST(&inodedep->id_pendinghd) != NULL when trying to free the inodedep after the buffer had been written to disk. If I'm completely wrong feel free to laugh but please point me where I'm mistaken. Is there a paper somewhere with more detailed informations on the inner working of softupdates? Regards Stephane E. Potvin POS and Industry Helpdesk IBM Cadana Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 16:14:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10994 for freebsd-current-outgoing; Sun, 31 May 1998 16:14:27 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10989 for ; Sun, 31 May 1998 16:14:19 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA11646; Sun, 31 May 1998 16:07:28 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd011641; Sun May 31 23:07:24 1998 Date: Sun, 31 May 1998 16:07:21 -0700 (PDT) From: Julian Elischer To: The Super-User cc: freebsd-current@FreeBSD.ORG Subject: Re: really bad inodedep crash In-Reply-To: <19980531154208.A4224@dyn.ml.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG thanks.. Is this SMP? On Sun, 31 May 1998, The Super-User wrote: > Well, there goes another crash. I got a VERY strange crash, something about inodedep, by pressing ^Z during a make in a port dir; I haven't been able to recreate this crash, and the core seemed to be corrupted (or maybe the system was actually that way) because a backtrace was showing two undefined functions continually looping. I'd know more, but this vmcore got corrupted I guess :-/. Ahh well, if I can ever find something else like this again, I'll post again. BTW, this is with SoftUpdates, but a few days ago my computer DID crash with no softupdates, and only async; go figure. > > Brian Feldman > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 16:44:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA15384 for freebsd-current-outgoing; Sun, 31 May 1998 16:44:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA15379 for ; Sun, 31 May 1998 16:44:24 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id QAA07930; Sun, 31 May 1998 16:43:37 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Mike Smith cc: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ), mcdougall@ameritech.net, Kent A Vander Velden , current@FreeBSD.ORG Subject: Re: kernel config In-reply-to: Your message of "Sun, 31 May 1998 11:43:18 PDT." <199805311843.LAA12651@antipodes.cdrom.com> Date: Sun, 31 May 1998 16:43:37 -0700 Message-ID: <7926.896658217@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Adam McDougall writes: > > > yup, add this to the kernel > > > options USERCONFIG_BOOT > > > > YAUKO! > > I have some work in progress to make this option go away (and have > kernel.config always parsed). Are there any strong objections to this? The reason it was added in the first place was the fact that these commands could also (in the past, at least, haven't checked lately) be pulled out of "info block" following the boot blocks. Since these could also contain garbage if uninitialized, I added the explicit check for the USERCONFIG string. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 16:59:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18103 for freebsd-current-outgoing; Sun, 31 May 1998 16:59:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA18093 for ; Sun, 31 May 1998 16:59:35 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 9457 invoked by uid 505); 31 May 1998 23:59:20 -0000 Date: 31 May 1998 23:59:20 -0000 Message-ID: <19980531235920.9456.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: really bad inodedep crash In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nope, single CPU, single user (not boot -s, just me only using it), etc. Brian > thanks.. > Is this SMP? > > > On Sun, 31 May 1998, The Super-User wrote: > > > Well, there goes another crash. I got a VERY strange crash, something about inodedep, by pressing ^Z during a make in a port dir; I haven't been able to recreate this crash, and the core seemed to be corrupted (or maybe the system was actually that way) because a backtrace was showing two undefined functions continually looping. I'd know more, but this vmcore got corrupted I guess :-/. Ahh well, if I can ever find something else like this again, I'll post again. BTW, this is with SoftUpdates, but a few days ago my computer DID crash with no softupdates, and only async; go figure. > > > > Brian Feldman > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 17:05:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19335 for freebsd-current-outgoing; Sun, 31 May 1998 17:05:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA19327 for ; Sun, 31 May 1998 17:05:17 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 9690 invoked by uid 505); 1 Jun 1998 00:05:02 -0000 Date: 1 Jun 1998 00:05:02 -0000 Message-ID: <19980601000502.9689.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: ELF preparation step 2 done In-Reply-To: <199805312243.IAA15578@cimlogic.com.au> To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, after making world and having all /usr/libexec/{elf,aout}, I guess one could make an ELF world in a couple steps, if they're interested: 1. export BINFORMAT=elf and make usr.bin/objformat, and make install it 2. go to lib/, 'echo "BINFORMAT=elf" > /etc/objectformat' and make all the libs, and install them (to /usr/lib? mine installed there, I moved them to /usr/lib/elf, should the elf libs really be there or just /usr/lib?) 3. make the world; it _should_ work now, but I didn't try it Brian Feldman > Alex wrote: > > And what's the accepted method for building an elf-world? My efforts > > still seem to result in a make buildworld falling over. > > The make world process is currently unsuitable for building elf from > a standing start (i.e. with only aout). Messages to this list have > noted that certain elf preparation steps have been completed, not that > you can build elf yet. > > -- > John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ > CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 17:05:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19457 for freebsd-current-outgoing; Sun, 31 May 1998 17:05:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19436 for ; Sun, 31 May 1998 17:05:44 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA00936; Sun, 31 May 1998 19:05:39 -0500 (EST) (envelope-from toor) Message-Id: <199806010005.TAA00936@dyson.iquest.net> Subject: Re: really bad inodedep crash In-Reply-To: from Julian Elischer at "May 31, 98 04:07:21 pm" To: julian@whistle.com (Julian Elischer) Date: Sun, 31 May 1998 19:05:39 -0500 (EST) Cc: root@dyn.ml.org, freebsd-current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer said: > > thanks.. > Is this SMP? > Regarding SMP, I have found a couple of bona-fide bugs in the last day or so. It is not a good idea to try to fix it right now, because I have lots of good stuff being readied. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 17:15:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21356 for freebsd-current-outgoing; Sun, 31 May 1998 17:15:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21351 for ; Sun, 31 May 1998 17:15:16 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id KAA21095; Mon, 1 Jun 1998 10:14:52 +1000 Date: Mon, 1 Jun 1998 10:14:52 +1000 From: Bruce Evans Message-Id: <199806010014.KAA21095@godzilla.zeta.org.au> To: abial@nask.pl, julian@whistle.com Subject: Re: fd crash (in isa_dmastart) Cc: brianfeldman@hotmail.com, freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Sun, 31 May 1998, Julian Elischer wrote: > >> I'm not sure what causes this but it should be easy enough to reproduce.. >> I'll add it to my list of things to clean up... >> >> Interestingly enoungh the stack trace shows no softupdates related >> functions. >> I will guess however that the softupdate code may not fully appreciate the >> subtlties of bounce buffers >> as they are a FreeBSD oddity. >> (I can actually think of a few things to check out.) >> this may be a problem with aha1542 scsi systems too. > >As I wrote you some time ago, it's enough to try to mount msdos floppy >under DEVFS/SLICE kernel - it immediately panics with the same message. It's probably just the stale v_object bug. Here is a a sure kill: [Put an msdosfs floppy in /dev/fd0.] mount /dev/fd0 /mnt mount -t msdos /dev/fd0 /mnt msdosfs with a block size of 512 produces requests on the block device that are misaligned relative to page boundaries (1 block at blkno #0, 3 blocks at #1, 3 blocks at #4 and 3 blocks at #7, maybe more). Normally these requests are handled sub-optimally using malloced buffers, but the stale v_object makes getblk() think that a B_VMIO buffer will work. This gives a bogus buffer for the (3 blocks #7 request): #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.16 (i386-unknown-freebsd), #Copyright 1996 Free Software Foundation, Inc... #IdlePTD 2c9000 #initial pcb at 239d1c #panicstr: isa_dmacheck: no physical page present #panic messages: #--- #panic: isa_dmacheck: no physical page present # #syncing disks... 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 15 giving up #1: dev:00010202, flags:20100010, blkno:7, lblkno:7 #2: dev:00000400, flags:21020034, blkno:89664, lblkno:0 #3: dev:00000400, flags:21020014, blkno:85422, lblkno:0 #4: dev:00000400, flags:21020034, blkno:70432, lblkno:0 #5: dev:00000400, flags:21020034, blkno:71054, lblkno:0 #6: dev:00000400, flags:21020014, blkno:71806, lblkno:0 #7: dev:00000400, flags:21020014, blkno:69070, lblkno:0 #8: dev:00000400, flags:21020014, blkno:71276, lblkno:0 #9: dev:00000400, flags:21020014, blkno:71070, lblkno:0 #10: dev:00000400, flags:21020014, blkno:70320, lblkno:0 #11: dev:00000400, flags:21020014, blkno:67312, lblkno:0 #12: dev:00000400, flags:21020034, blkno:65712, lblkno:65712 #13: dev:00000400, flags:21020034, blkno:65680, lblkno:65680 #14: dev:00000400, flags:21020034, blkno:65648, lblkno:65648 #15: dev:00000400, flags:21020034, blkno:65600, lblkno:65600 # #dumping to dev 30001, offset 67520 #dump 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 #--- ##0 boot (howto=256) at ./@/kern/kern_shutdown.c:281 #281 dumppcb.pcb_cr3 = rcr3(); #(kgdb) where ##0 boot (howto=256) at ./@/kern/kern_shutdown.c:281 ##1 0xf0121293 in panic ( # fmt=0xf0209138 "isa_dmacheck: no physical page present") # at ./@/kern/kern_shutdown.c:421 ##2 0xf02091bd in isa_dmarangecheck ( # va=0xf14e3000
, length=512, chan=2) # at ./@/i386/isa/isa.c:908 ##3 0xf0208eca in isa_dmastart (flags=537919504, # addr=0xf14e3000
, nbytes=512, chan=2) # at ./@/i386/isa/isa.c:772 ##4 0xf0203e46 in fdstate (fdcu=0, fdc=0xf0287028) at ./@/i386/isa/fd.c:1757 ##5 0xf02038fc in fdintr (vfdc=0xf0287028) at ./@/i386/isa/fd.c:1560 #(kgdb) up 4 ##4 0xf0203e46 in fdstate (fdcu=0, fdc=0xf0287028) at ./@/i386/isa/fd.c:1757 #1757 isa_dmastart(bp->b_flags, bp->b_data+fd->skip, #(kgdb) p/x *bp #$1 = {b_hash = {le_next = 0xf12cf6f8, le_prev = 0xf023bc30}, b_vnbufs = { # le_next = 0xf12d0160, le_prev = 0xf948ea30}, b_freelist = { # tqe_next = 0xf12d03b0, tqe_prev = 0xf022a244}, b_act = {tqe_next = 0x0, # tqe_prev = 0xf0287070}, b_proc = 0x0, b_flags = 0x20100010, # b_qindex = 0x0, b_usecount = 0x5, b_error = 0x0, b_bufsize = 0x600, # b_bcount = 0x600, b_resid = 0x0, b_dev = 0x10202, b_data = 0xf14e2e00, ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^ 0x600 bytes required only 0x200 bytes here # b_kvabase = 0xf14e2000, b_kvasize = 0x2000, b_lblkno = 0x7, b_blkno = 0x7, # b_offset = 0x0000000000000e00, b_iodone = 0x0, b_iodone_chain = 0x0, # b_vp = 0xf948ea00, b_dirtyoff = 0x0, b_dirtyend = 0x0, b_rcred = 0x0, # b_wcred = 0x0, b_validoff = 0x0, b_validend = 0x0, b_pblkno = 0x7, # b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, # b_spc = 0x0, b_cluster = {cluster_head = {tqh_first = 0x0, tqh_last = 0x0}, # cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, b_pages = {0xf0463508, ^^^^^^^^^^^^^^^^^^^^^ only one page mapped # 0x0 }, b_npages = 0x1, b_dep = {lh_first = 0x0}} #(kgdb) q Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 17:16:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA21502 for freebsd-current-outgoing; Sun, 31 May 1998 17:16:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dt050n33.san.rr.com (@dt053nd2.san.rr.com [204.210.34.210]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA21489 for ; Sun, 31 May 1998 17:16:25 -0700 (PDT) (envelope-from Studded@san.rr.com) Received: from san.rr.com (Studded@localhost [127.0.0.1]) by dt050n33.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA14765; Sun, 31 May 1998 17:16:18 -0700 (PDT) (envelope-from Studded@san.rr.com) Message-ID: <3571F2D2.684F8F26@san.rr.com> Date: Sun, 31 May 1998 17:16:18 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE-0507 i386) MIME-Version: 1.0 To: Luigi Rizzo CC: current@FreeBSD.ORG Subject: Re: How about /usr/ports/kernel ? References: <199805301346.PAA29505@labinfo.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > > Just looking backward, i realize that i am doing a lot of work > on the kernel, and so are others. So, how about adding a new port > category, /usr/ports/kernel, where one can find various kernel > enhancements etc which for any reason did not find their way in the > main source tree ? I like this idea a lot personally. However I proposed the idea of a port for something not too long ago (cam, softupdates... something like that) and was told flat out that it could not be done. I hope whoever told me that was wrong. :) Doug -- *** Chief Operations Officer, DALnet IRC network *** *** Proud designer and maintainer of one of the world's largest *** Internet Relay Chat servers with 5,328 simultaneous connections *** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 17:25:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA22953 for freebsd-current-outgoing; Sun, 31 May 1998 17:25:08 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from hermes.iaccess.com.au (hermes.iaccess.com.au [203.5.74.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA22948 for ; Sun, 31 May 1998 17:25:04 -0700 (PDT) (envelope-from andrew@iaccess.com.au) Received: from alpine.iaccess (alpine.iaccess.com.au [203.5.74.227]) by hermes.iaccess.com.au (8.8.5/8.8.5) with SMTP id KAA29669 for ; Mon, 1 Jun 1998 10:25:30 +1000 (EST) Message-ID: <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess> From: "Andrew Specht" To: Subject: mbuf cluster problem continues!! Date: Mon, 1 Jun 1998 10:28:03 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi again, I'm still having the same mbuf cluster problem. I'm running squid with a 14 Gig Cache and getting up to 200 connections a second. The problem is that mbuf clusters in-use just keeps on rising until it gets to the peak and then the whole thing crashes. I've got it set to 22000 at the moment, but last time they went up to nearly 10000 before it crashed. Is there a problem with leaking mbuf clusters still, or is that what they are supposed to do? If this has been addressed already and i missed it, i would be glad if someone could bring me up to date :) Thanks again Andrew Specht | System Administrator E-mail: andrew@iaccess.com.au | Internet Access Australia Internet: http://www.iaccess.com.au | Melbourne, Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 17:55:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26867 for freebsd-current-outgoing; Sun, 31 May 1998 17:55:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from aldan.ziplink.net (mi@kot.ne.mediaone.net [24.128.29.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26846 for ; Sun, 31 May 1998 17:54:56 -0700 (PDT) (envelope-from mi@rtfm.ziplink.net) Received: from rtfm.ziplink.net (rtfm [199.232.255.52]) by aldan.ziplink.net (8.8.8/8.8.7) with ESMTP id AAA25143 for ; Mon, 1 Jun 1998 00:54:48 GMT (envelope-from mi@rtfm.ziplink.net) Received: (from mi@localhost) by rtfm.ziplink.net (8.8.8/8.8.5) id UAA25668 for current@freebsd.org; Sun, 31 May 1998 20:54:51 -0400 (EDT) From: Mikhail Teterin Message-Id: <199806010054.UAA25668@rtfm.ziplink.net> Subject: Re: kernel config In-Reply-To: <199805311843.LAA12651@antipodes.cdrom.com> from "Mike Smith" at "May 31, 98 11:43:18 am" To: current@FreeBSD.ORG Date: Sun, 31 May 1998 20:54:51 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" > yup, add this to the kernel => > options USERCONFIG_BOOT =I have some work in progress to make this option go away (and have =kernel.config always parsed). Are there any strong objections to this? Yes. Kernel will become even bigger. Why not make it a default, but leave NO_USERCONFIG_BOOT for those who do not want it? Yours, -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 18:16:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01113 for freebsd-current-outgoing; Sun, 31 May 1998 18:16:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01099 for ; Sun, 31 May 1998 18:16:40 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id BAA28893; Mon, 1 Jun 1998 01:16:38 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA02186; Mon, 1 Jun 1998 03:16:24 +0200 (MET DST) Message-ID: <19980601031623.27330@follo.net> Date: Mon, 1 Jun 1998 03:16:23 +0200 From: Eivind Eklund To: Studded Cc: current@FreeBSD.ORG Subject: Re: How about /usr/ports/kernel ? References: <199805301346.PAA29505@labinfo.iet.unipi.it> <3571F2D2.684F8F26@san.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <3571F2D2.684F8F26@san.rr.com>; from Studded on Sun, May 31, 1998 at 05:16:18PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, May 31, 1998 at 05:16:18PM -0700, Studded wrote: > Luigi Rizzo wrote: > > > > Just looking backward, i realize that i am doing a lot of work > > on the kernel, and so are others. So, how about adding a new port > > category, /usr/ports/kernel, where one can find various kernel > > enhancements etc which for any reason did not find their way in the > > main source tree ? > > I like this idea a lot personally. However I proposed the idea of a > port for something not too long ago (cam, softupdates... something like > that) and was told flat out that it could not be done. I hope whoever > told me that was wrong. :) It depend on what the code does and how it does it. There are some things that are easily portable between versions, and some things that just about aren't possible at all. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 18:22:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01911 for freebsd-current-outgoing; Sun, 31 May 1998 18:22:14 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from aldan.ziplink.net (mi@kot.ne.mediaone.net [24.128.29.55]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01904 for ; Sun, 31 May 1998 18:22:08 -0700 (PDT) (envelope-from mi@rtfm.ziplink.net) Received: from rtfm.ziplink.net (rtfm [199.232.255.52]) by aldan.ziplink.net (8.8.8/8.8.7) with ESMTP id BAA25305 for ; Mon, 1 Jun 1998 01:21:59 GMT (envelope-from mi@rtfm.ziplink.net) Received: (from mi@localhost) by rtfm.ziplink.net (8.8.8/8.8.5) id VAA25839 for current@freebsd.org; Sun, 31 May 1998 21:22:03 -0400 (EDT) From: Mikhail Teterin Message-Id: <199806010122.VAA25839@rtfm.ziplink.net> Subject: TenDRA/XANDF to the rescue? (Re: Fix for undefined...) In-Reply-To: <199805312213.PAA16988@usr06.primenet.com> from "Terry Lambert" at "May 31, 98 10:13:11 pm" To: current@FreeBSD.ORG Date: Sun, 31 May 1998 21:22:02 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02500 for freebsd-current-outgoing; Sun, 31 May 1998 18:26:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02495 for ; Sun, 31 May 1998 18:26:20 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id SAA08827; Sun, 31 May 1998 18:25:56 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Brian Feldman" cc: freebsd-current@FreeBSD.ORG Subject: Re: ELF preparation step 2 done In-reply-to: Your message of "01 Jun 1998 00:05:02 -0000." <19980601000502.9689.qmail@m2.findmail.com> Date: Sun, 31 May 1998 18:25:56 -0700 Message-ID: <8823.896664356@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, after making world and having all /usr/libexec/{elf,aout}, I guess one You might get /usr/libexec/elf from a make world, but you won't get a /usr/lib/elf and that's pretty important. > 3. make the world; it _should_ work now, but I didn't try it Why not? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 19:27:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10040 for freebsd-current-outgoing; Sun, 31 May 1998 19:27:33 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA10020 for ; Sun, 31 May 1998 19:27:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id CAA00805; Mon, 1 Jun 1998 02:27:23 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA02362; Mon, 1 Jun 1998 04:27:08 +0200 (MET DST) Message-ID: <19980601042708.54610@follo.net> Date: Mon, 1 Jun 1998 04:27:08 +0200 From: Eivind Eklund To: Mikhail Teterin , current@FreeBSD.ORG Subject: Re: TenDRA/XANDF to the rescue? (Re: Fix for undefined...) References: <199805312213.PAA16988@usr06.primenet.com> <199806010122.VAA25839@rtfm.ziplink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806010122.VAA25839@rtfm.ziplink.net>; from Mikhail Teterin on Sun, May 31, 1998 at 09:22:02PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, May 31, 1998 at 09:22:02PM -0400, Mikhail Teterin wrote: > Terry Lambert once stated: > > =I agree that at some point you are going to lose backward compatability; > =I think, however, that XANDF will push this off, since most of the > =historical compatability issues can be resolved by regenerating the > =assembly code, and relinking, which is implied. > > Well, what's wrong with plain C-code, for example? Just because it > is source and is easier to reverse engineer? Theoreticly, C must > be as crossplatform as XANDF or whatnot. C is more limited in it's expressiveness. It is bad as an intermediate format for other languages because metadata is lost (which limit the optimization possibilities). > Ok, how about Java byte code? java byte code can't express e.g. C. This also answer the rest of your post (which I've deleted). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 19:57:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA13785 for freebsd-current-outgoing; Sun, 31 May 1998 19:57:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA13777 for ; Sun, 31 May 1998 19:57:14 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id VAA03893; Sun, 31 May 1998 21:57:05 -0500 (CDT) Date: Sun, 31 May 1998 21:57:05 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199805312213.PAA16988@usr06.primenet.com> References: from "Richard Wackerbarth" at May 31, 98 11:30:05 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: Richard Wackerbarth Subject: Re: Fix for undefined "__error" and discussion of shared object Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:13 PM -0000 5/31/98, Terry Lambert wrote: >> >The point is to make a port for FreeBSD 3.x work on FreeBSD 235.x, not >> >the reverse. In other words, "compile once, run anywhere". >> > >> >The binary compatability from FreeBSD 3.x to FreeBSD 235.x is a >> >problem for the XANDF processor during the install. >> >> And for it to be possible, there must be a "compatability library" of some >> kind. I was meaning a library in the sense of emulating otherwise discarded constructs. >>By the time we get to FreeBSD 235.x, do you really expect to be >> able to support today's hack dejuor which relies on the present major/minor >> device numbers? I think not. > >Quite right. Software which depends on these constructs will fail to >operate. You have conceded my point. >Well, I am (I hope) well known as an advocate of "revolution instead of >evolution"; technology moves too damn slow for me as it is If you are successful, FreeBSD will not reach 235.x. It will have gotten another name long before. >I agree that at some point you are going to lose backward compatability; >I think, however, that XANDF will push this off, since most of the >historical compatability issues can be resolved by regenerating the >assembly code, and relinking, which is implied. I don't disagree. However, "push ... off" is far different from your initial statement. >I *really* look forward to the day when I can buy an XANDF Motif >library, and use it on all my hardware, regardless of the CPU type. >8-0. Aren't we really just emulating an "XANDF" machine with an XANDF->whatever micro-code expanded inline? Where is my XANDF native machine? Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 19:57:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA13854 for freebsd-current-outgoing; Sun, 31 May 1998 19:57:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles157.castles.com [208.214.165.157]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA13849 for ; Sun, 31 May 1998 19:57:47 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA14336; Sun, 31 May 1998 17:49:54 -0700 (PDT) Message-Id: <199806010049.RAA14336@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mikhail Teterin cc: current@FreeBSD.ORG Subject: Re: kernel config In-reply-to: Your message of "Sun, 31 May 1998 20:54:51 EDT." <199806010054.UAA25668@rtfm.ziplink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 17:49:54 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith once stated: > > => > yup, add this to the kernel > => > options USERCONFIG_BOOT > > =I have some work in progress to make this option go away (and have > =kernel.config always parsed). Are there any strong objections to this? > > Yes. Kernel will become even bigger. Why not make it a default, but > leave NO_USERCONFIG_BOOT for those who do not want it? Yours, The size change is miniscule. If you don't want it, and size concerns you, turn off userconfig (one of the largest kernel modules). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 20:13:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA16120 for freebsd-current-outgoing; Sun, 31 May 1998 20:13:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from enigami.com (enigami.com [208.140.182.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA16113 for ; Sun, 31 May 1998 20:13:14 -0700 (PDT) (envelope-from root@enigami.com) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by enigami.com (8.8.7/8.8.7) with ESMTP id XAA16170; Sun, 31 May 1998 23:13:06 -0400 (EDT) Received: (from ckempf@localhost) by singularity.enigami.com (8.8.8/8.8.8) id XAA17593; Sun, 31 May 1998 23:10:14 -0400 (EDT) (envelope-from root@enigami.com) X-Authentication-Warning: singularity.enigami.com: ckempf set sender to root using -f To: "Brian Feldman" , freebsd-current@FreeBSD.ORG Subject: Re: ELF preparation step 2 done References: <19980601000502.9689.qmail@m2.findmail.com> From: The & of all Evil Date: 31 May 1998 23:10:14 -0400 In-Reply-To: "Brian Feldman"'s message of "1 Jun 1998 00:05:02 -0000" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian Feldman" writes: > Well, after making world and having all /usr/libexec/{elf,aout}, I guess one could make an ELF world in a couple steps, if they're interested: > 1. export BINFORMAT=elf and make usr.bin/objformat, and make install it > 2. go to lib/, 'echo "BINFORMAT=elf" > /etc/objectformat' and make all the libs, and install them (to /usr/lib? mine installed there, I moved them to /usr/lib/elf, should the elf libs really be there or just /usr/lib?) > 3. make the world; it _should_ work now, but I didn't try it singularity:/usr/src/lib 14# make all ===> libcom_err cc -O -pipe -c /usr/src/lib/libcom_err/com_err.c -o com_err.o Unrecognized line in /etc/objectformat: BINFORMAT=elf Unrecognized line in /etc/objectformat: BINFORMAT=elf com_err.o: file not recognized: File format not recognized *** Error code 1 Stop. *** Error code 1 Stop. Maybe there is another step somewhere? -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: Cory Kempf Macintosh / Unix Consulting & Software Development ckempf@enigami.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 20:41:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA19960 for freebsd-current-outgoing; Sun, 31 May 1998 20:41:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles157.castles.com [208.214.165.157]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19947 for ; Sun, 31 May 1998 20:41:48 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA14834; Sun, 31 May 1998 19:36:57 -0700 (PDT) Message-Id: <199806010236.TAA14834@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Andrew Specht" cc: freebsd-current@FreeBSD.ORG Subject: Re: mbuf cluster problem continues!! In-reply-to: Your message of "Mon, 01 Jun 1998 10:28:03 +1000." <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 19:36:57 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi again, > > I'm still having the same mbuf cluster problem. I'm running squid with a 14 > Gig Cache and getting up to 200 connections a second. The problem is that > mbuf clusters in-use just keeps on rising until it gets to the peak and then > the whole thing crashes. I've got it set to 22000 at the moment, but last > time they went up to nearly 10000 before it crashed. Is there a problem > with leaking mbuf clusters still, or is that what they are supposed to do? Are you actually running on -current? And this is a production system? Are you aware that this is a really bad idea? The issue with mbufs is that you can't dynamically allocate them when you need them, so you have to have enough to begin with. Unfortunately, when you reach the point where you need them and there aren't any left, you can't (often) fail gracefully - things expect that they are going to get them when they need them. This is a fairly major flaw in the system's design. 8( However, I am not aware of any known mbuf leaks in the system at the moment. Are you certain that they're being leaked? Has your load managed to bring the system down with the settings at 22000? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 20:52:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA21196 for freebsd-current-outgoing; Sun, 31 May 1998 20:52:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles157.castles.com [208.214.165.157]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA21190 for ; Sun, 31 May 1998 20:52:40 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id TAA14896; Sun, 31 May 1998 19:47:33 -0700 (PDT) Message-Id: <199806010247.TAA14896@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Mike Smith , dag-erli@ifi.uio.no, mcdougall@ameritech.net, Kent A Vander Velden , current@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain Subject: Re: kernel config In-reply-to: Your message of "Sun, 31 May 1998 16:43:37 PDT." <7926.896658217@time.cdrom.com> Date: Sun, 31 May 1998 19:47:32 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Adam McDougall writes: > > > > yup, add this to the kernel > > > > options USERCONFIG_BOOT > > > > > > YAUKO! > > > > I have some work in progress to make this option go away (and have > > kernel.config always parsed). Are there any strong objections to this? [inre: the USERCONFIG string at the top of kernel.config] > The reason it was added in the first place was the fact that these > commands could also (in the past, at least, haven't checked lately) be > pulled out of "info block" following the boot blocks. Since these could > also contain garbage if uninitialized, I added the explicit check for > the USERCONFIG string. Support for reading this data from flat areas of the disk is no longer part of the bootstrap. I don't think that there are very many cases where this is likely to be in use (I seem to recall it required a special bootblock compilation option). If there is a strong case for requiring this signature, though, I have no objections. Actually, kernel.config is a strong contender for the 'extras' stuff I developed for the splashkit, but the extra bloat in the bootblocks would not make me popular, I wot. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 21:12:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA23943 for freebsd-current-outgoing; Sun, 31 May 1998 21:12:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA23936 for ; Sun, 31 May 1998 21:12:46 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id OAA16535; Mon, 1 Jun 1998 14:21:00 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199806010421.OAA16535@cimlogic.com.au> Subject: Re: ELF preparation step 2 done In-Reply-To: from The & of all Evil at "May 31, 98 11:10:14 pm" To: root@enigami.com (The & of all Evil) Date: Mon, 1 Jun 1998 14:20:59 +1000 (EST) Cc: brianfeldman@hotmail.com, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The & of all Evil wrote: > "Brian Feldman" writes: > > > Well, after making world and having all /usr/libexec/{elf,aout}, I guess one could make an ELF world in a couple steps, if they're interested: > > 1. export BINFORMAT=elf and make usr.bin/objformat, and make install it > > 2. go to lib/, 'echo "BINFORMAT=elf" > /etc/objectformat' and make all the libs, and install them (to /usr/lib? mine installed there, I moved them to /usr/lib/elf, should the elf libs really be there or just /usr/lib?) > > 3. make the world; it _should_ work now, but I didn't try it ^^^^^^^^^^^^^^^^^^^ Obviously. > > singularity:/usr/src/lib 14# make all > ===> libcom_err > cc -O -pipe -c /usr/src/lib/libcom_err/com_err.c -o com_err.o > Unrecognized line in /etc/objectformat: BINFORMAT=elf > Unrecognized line in /etc/objectformat: BINFORMAT=elf > com_err.o: file not recognized: File format not recognized A few things (not necessarily all) you need to do: 1. Make world to get aout and elf tools (built as aout executables) in their new places and objformat installed in /usr/bin. 2. chflags -R noschg /usr/obj/usr/src/tmp 3. rm -rf /usr/obj/* 4. Create /etc/objectformat with the line OBJFORMAT=elf 5. Add BINFORMAT=elf to /etc/make.conf 6. cd /usr/src/csu/i386-elf; make obj/depend/all/install 7. cd /usr/src/gnu/usr.bin/cc/libgcc; make obj/depend/all/install 8. cd /usr/src/lib/libc; make obj/depend/all/install 9. cd /usr/src/libexec/rtld-elf; make obj/depend/all/install 10. cd /usr/src/lib; make obj/depend/all/install 11. cd /usr/src/gnu/lib; make obj/depend/all/install 12. cd /usr/src; make obj/depend/all/install I have tried this. Step 12 bombs in src/gnu/usr.bin/ld. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 21:40:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA27753 for freebsd-current-outgoing; Sun, 31 May 1998 21:40:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cerebus.nectar.com (cerebus.nectar.com [204.27.67.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA27692 for ; Sun, 31 May 1998 21:40:00 -0700 (PDT) (envelope-from nectar@cerebus.nectar.com) Received: from cerebus.nectar.com (localhost.communique.net [127.0.0.1]) by cerebus.nectar.com (8.8.8/8.8.8) with ESMTP id XAA27085 for ; Sun, 31 May 1998 23:39:58 -0500 (CDT) Message-Id: <199806010439.XAA27085@cerebus.nectar.com> X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x094724A9 From: Jacques Vidrine Subject: union nethostaddr no longer defined for src/sbin/mount_nfs.c To: freebsd-current@FreeBSD.ORG Date: Sun, 31 May 1998 23:39:58 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hi, mount_nfs cannot be built on -current dated 5/31. mount_nfs requires nfs/nqnfs.h, which in turn requires ``union nethostaddr'', defined in nfs/nfs.h. The problem is recent changes described by the following commit log entry moved the definition of ``union nethostaddr'' from outside #ifdef KERNEL to inside #ifdef KERNEL. Of course, KERNEL is not defined when building mount_nfs. RCS file: /home/ncvs/src/sys/nfs/nfs.h,v Working file: nfs.h head: 1.40 [snippage] - ---------------------------- revision 1.37 date: 1998/05/31 17:27:45; author: peter; state: Exp; lines: +9 -9 NFS Jumbo commit part 1. Cosmetic and structural changes only. The aim of this part of commits is to minimize unnecessary differences between the other NFS's of similar origin. Yes, there are gratuitous changes here that the style folks won't like, but it makes the catch-up less difficult. - ---------------------------- FreeBSD was bit by this because in the past we stopped defining KERNEL in mount_nfs.c RCS file: /home/ncvs/src/sbin/mount_nfs/mount_nfs.c,v Working file: mount_nfs.c head: 1.28 [snippage] - ---------------------------- revision 1.27 date: 1998/02/01 21:53:19; author: bde; state: Exp; lines: +1 -3 Don't define KERNEL before including . It is no longer necessary. This fixes warnings about missing forward declarations for structs in kernel-only prototypes. - ---------------------------- The quick fix to get the world rolling is to backout the change made in revision 1.37 of src/sys/nfs.h. I'm not sure what the long-term fix should be --- I'd guess the same as the short term. Jacques Vidrine -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNXIwnTeRhT8JRySpAQG42AP9H+rumZakVIUXGPBd1etu5elJhcIG7o+a 2DkupzBiRgkKbMSsKEw2NWmZqAqsL0yF6MInPkIb2sBWTLOjjXEzdgpwodSkL1r4 hSs5So2OEf6rMi8GEjbC3Zf5H5MU6efwNbrgZnNdQ5AEYSlA/TP0o2m7wp1RO1Nq juR/im6UUIs= =b7EJ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 21:51:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA28806 for freebsd-current-outgoing; Sun, 31 May 1998 21:51:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA28791 for ; Sun, 31 May 1998 21:51:00 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA07373; Mon, 1 Jun 1998 14:50:54 +1000 Date: Mon, 1 Jun 1998 14:50:54 +1000 From: Bruce Evans Message-Id: <199806010450.OAA07373@godzilla.zeta.org.au> To: jkh@time.cdrom.com, mike@smith.net.au Subject: Re: kernel config Cc: current@FreeBSD.ORG, dag-erli@ifi.uio.no, graphix@iastate.edu, mcdougall@ameritech.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Support for reading this data from flat areas of the disk is no longer >part of the bootstrap. I don't think that there are very many cases It never was supported for biosboot, cdboot, dosboot or netboot, but is automatically supported by rawboot. >where this is likely to be in use (I seem to recall it required a >special bootblock compilation option). If there is a strong case for >requiring this signature, though, I have no objections. A signature is required to avoid parsing garbage from bootblocks that don't support the config area. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 22:21:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA02767 for freebsd-current-outgoing; Sun, 31 May 1998 22:21:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA02761 for ; Sun, 31 May 1998 22:21:03 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id WAA09567; Sun, 31 May 1998 22:20:11 -0700 (PDT) Message-Id: <199806010520.WAA09567@implode.root.com> To: "Andrew Specht" cc: freebsd-current@FreeBSD.ORG Subject: Re: mbuf cluster problem continues!! In-reply-to: Your message of "Mon, 01 Jun 1998 10:28:03 +1000." <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess> From: David Greenman Reply-To: dg@root.com Date: Sun, 31 May 1998 22:20:10 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I'm still having the same mbuf cluster problem. I'm running squid with a 14 >Gig Cache and getting up to 200 connections a second. The problem is that >mbuf clusters in-use just keeps on rising until it gets to the peak and then >the whole thing crashes. I've got it set to 22000 at the moment, but last >time they went up to nearly 10000 before it crashed. Is there a problem >with leaking mbuf clusters still, or is that what they are supposed to do? > >If this has been addressed already and i missed it, i would be glad if >someone could bring me up to date :) I've seen several reports of mbuf leaks in the specific case of running squid proxy servers. As I don't have anything remotely resembling that in any configuration I have here, someone else will have to troubleshoot this one. It's possible that this might actually be a bug in squid rather than in FreeBSD. I have really no idea; I've not seen any mbuf leaks in any other networking use of FreeBSD so it is surprising that one would show up when doing this. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 22:24:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA03217 for freebsd-current-outgoing; Sun, 31 May 1998 22:24:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA03212 for ; Sun, 31 May 1998 22:24:05 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id PAA09745; Mon, 1 Jun 1998 15:24:03 +1000 Date: Mon, 1 Jun 1998 15:24:03 +1000 From: Bruce Evans Message-Id: <199806010524.PAA09745@godzilla.zeta.org.au> To: freebsd-current@FreeBSD.ORG, n@nectar.com Subject: Re: union nethostaddr no longer defined for src/sbin/mount_nfs.c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >requires nfs/nqnfs.h, which in turn requires ``union nethostaddr'', >defined in nfs/nfs.h. > >The problem is recent changes described by the following commit >log entry moved the definition of ``union nethostaddr'' from >outside #ifdef KERNEL to inside #ifdef KERNEL. Of course, KERNEL >is not defined when building mount_nfs. > >RCS file: /home/ncvs/src/sys/nfs/nfs.h,v >Working file: nfs.h >head: 1.40 >[snippage] >- ---------------------------- >revision 1.37 >date: 1998/05/31 17:27:45; author: peter; state: Exp; lines: +9 -9 >NFS Jumbo commit part 1. Cosmetic and structural changes only. The aim >of this part of commits is to minimize unnecessary differences between >the other NFS's of similar origin. Yes, there are gratuitous changes here >that the style folks won't like, but it makes the catch-up less difficult. >- ---------------------------- > >FreeBSD was bit by this because in the past we stopped defining KERNEL >in mount_nfs.c > >RCS file: /home/ncvs/src/sbin/mount_nfs/mount_nfs.c,v >Working file: mount_nfs.c >head: 1.28 >[snippage] >- ---------------------------- >revision 1.27 >date: 1998/02/01 21:53:19; author: bde; state: Exp; lines: +1 -3 >Don't define KERNEL before including . It is no longer >necessary. This fixes warnings about missing forward declarations >for structs in kernel-only prototypes. >- ---------------------------- > >The quick fix to get the world rolling is to backout the change >made in revision 1.37 of src/sys/nfs.h. > >I'm not sure what the long-term fix should be --- I'd guess the >same as the short term. Just back out the part that clobbered this: RCS file: /home/ncvs/src/sys/nfs/nfs.h,v Working file: nfs.h head: 1.40 ... ---------------------------- revision 1.33 date: 1998/02/01 21:23:29; author: bde; state: Exp; lines: +15 -15 Moved declaration of `union nethostadr' outside of the KERNEL section, to give pollution compatible with . At least mount_nfs.c previously had to #define KERNEL before including to get this pollution, but this gave other pollution. Moved comment about NFSINT_SIGMASK to immediately before the code that it applies to. ---------------------------- Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 22:38:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04589 for freebsd-current-outgoing; Sun, 31 May 1998 22:38:08 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04571; Sun, 31 May 1998 22:38:02 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id WAA09607; Sun, 31 May 1998 22:37:33 -0700 (PDT) Message-Id: <199806010537.WAA09607@implode.root.com> To: The Hermit Hacker cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? In-reply-to: Your message of "Sun, 31 May 1998 17:45:05 EDT." From: David Greenman Reply-To: dg@root.com Date: Sun, 31 May 1998 22:37:32 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not going to bother submitting a problem report on this, >mainly because I don't even have a core to analyze, but I figured I'd at >least put a 'head up' on this, in case this anything to someone... > > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xefcb5b1c >fault code = supervisor read, page not present >instruction pointer = 0x8:0xf01a88ad >stack pointer = 0x10:0xf6951af4 >frame pointer = 0x10:0xf6951b28 >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 = 7011 (innfeed) >interrupt mask = net bio >kernel: type 12 trap, code=0 >Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx It appears that the mbuf chain is getting corrupted somehow. The above trap info indicates that the m_data pointer is bogus, resulting in a panic when the system attempts to get the physical address from the page tables. I don't see anything obvious in the 'de' driver that could cause this, so I suspect the buffer corruption is external to the driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 22:49:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA05949 for freebsd-current-outgoing; Sun, 31 May 1998 22:49:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fanfic.org (fanfic.org [205.150.35.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA05943 for ; Sun, 31 May 1998 22:49:51 -0700 (PDT) (envelope-from dstenn@fanfic.org) Received: from fanfic.org (fanfic.org [205.150.35.145]) by fanfic.org (8.8.8/8.8.8) with SMTP id BAA03520 for ; Mon, 1 Jun 1998 01:49:46 -0400 (EDT) (envelope-from dstenn@fanfic.org) Posted-Date: Mon, 1 Jun 1998 01:49:46 -0400 (EDT) Date: Mon, 1 Jun 1998 01:49:46 -0400 (EDT) From: Dennis Tenn To: FreeBSD Current Subject: Discussion of ELF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello folks. I know there has been some discussion about ELF vs a.out lately. What are the advantages between these two? Where can I find more info on them? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Dennis Tenn * There will always come a time dstenn@fanfic.org * When your love will be tested ICQ# 1457509 * Stand tall and rise to the occasion * For only then will you grow strong. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 23:04:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA07463 for freebsd-current-outgoing; Sun, 31 May 1998 23:04:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cerebus.nectar.com (cerebus.nectar.com [204.27.67.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA07458 for ; Sun, 31 May 1998 23:04:14 -0700 (PDT) (envelope-from nectar@cerebus.nectar.com) Received: from cerebus.nectar.com (localhost.communique.net [127.0.0.1]) by cerebus.nectar.com (8.8.8/8.8.8) with ESMTP id BAA27766; Mon, 1 Jun 1998 01:03:59 -0500 (CDT) Message-Id: <199806010603.BAA27766@cerebus.nectar.com> X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x094724A9 From: Jacques Vidrine In-reply-to: <199806010524.PAA09745@godzilla.zeta.org.au> References: <199806010524.PAA09745@godzilla.zeta.org.au> Subject: Re: union nethostaddr no longer defined for src/sbin/mount_nfs.c To: Bruce Evans Cc: freebsd-current@FreeBSD.ORG Date: Mon, 01 Jun 1998 01:03:59 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- You'd have to also back out revision 1.27 of src/sbin/mount_nfs.c of the same date. If a structure needs to be visible to userland utilities, it shouldn't be in a KERNEL section, IMHO. For that matter, I sometimes think there ought to be more header.h/headervar.h pairs instead of #ifdef KERNEL everywhere. I guess the question in my mind is which is more important with regards to the NFS code: * Progress towards a less ``polluted'' environment, OR * Kernel and header source code compatibility with other BSD systems Jacques Vidrine On 1 June 1998 at 15:24, Bruce Evans wrote: > Just back out the part that clobbered this: > > RCS file: /home/ncvs/src/sys/nfs/nfs.h,v > Working file: nfs.h > head: 1.40 > ... > ---------------------------- > revision 1.33 > date: 1998/02/01 21:23:29; author: bde; state: Exp; lines: +15 -15 > Moved declaration of `union nethostadr' outside of the KERNEL section, > to give pollution compatible with . At least mount_nfs.c > previously had to #define KERNEL before including to get > this pollution, but this gave other pollution. > > Moved comment about NFSINT_SIGMASK to immediately before the code that > it applies to. > ---------------------------- > > Bruce -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNXJETjeRhT8JRySpAQFzvgP/UXtSluOw+crdO3FLiQtpwwXEmQ9mJ2si CIALrmTFCWSx/fxMl0+ZffD5NDltnbRW9kE/wOR/+INeFj0QmerwZO1KiYrfGxJC 7TgiPKQx0ldg4g4z4Cqb5YkWOZf98oi0TWmTzlv1uKH0Jp0Bak9OjgjJOXMDUWgm b6hPagix6i0= =xcLV -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 23:14:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA08355 for freebsd-current-outgoing; Sun, 31 May 1998 23:14:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA08349 for ; Sun, 31 May 1998 23:14:26 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id QAA13173; Mon, 1 Jun 1998 16:14:23 +1000 Date: Mon, 1 Jun 1998 16:14:23 +1000 From: Bruce Evans Message-Id: <199806010614.QAA13173@godzilla.zeta.org.au> To: bde@zeta.org.au, n@nectar.com Subject: Re: union nethostaddr no longer defined for src/sbin/mount_nfs.c Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >You'd have to also back out revision 1.27 of >src/sbin/mount_nfs.c of the same date. No, rev.1.33 of src/sys/nfs/nfs.h is a prerequisite for rev.1.27 of src/sbin/mount_nfs/mount_nfs.c, so clobbering of rev.1.33 in rev.1.40 broke mount_nfs.c. >If a structure needs to be visible to userland utilities, it >shouldn't be in a KERNEL section, IMHO. For that matter, I >sometimes think there ought to be more header.h/headervar.h >pairs instead of #ifdef KERNEL everywhere. That's why `union nethostadr' moved it outside the KERNEL section. It probably doesn't need to be visible, but it is used in other nfs headers that don't even have a KERNEL section. >I guess the question in my mind is which is more important >with regards to the NFS code: > >* Progress towards a less ``polluted'' environment, OR >* Kernel and header source code compatibility with other > BSD systems I don't like pollution, but implemented consistent pollution. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 23:21:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09018 for freebsd-current-outgoing; Sun, 31 May 1998 23:21:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cerebus.nectar.com (cerebus.nectar.com [204.27.67.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09012 for ; Sun, 31 May 1998 23:21:39 -0700 (PDT) (envelope-from nectar@cerebus.nectar.com) Received: from cerebus.nectar.com (localhost.communique.net [127.0.0.1]) by cerebus.nectar.com (8.8.8/8.8.8) with ESMTP id BAA27920; Mon, 1 Jun 1998 01:21:33 -0500 (CDT) Message-Id: <199806010621.BAA27920@cerebus.nectar.com> X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x094724A9 From: Jacques Vidrine In-reply-to: <199806010614.QAA13173@godzilla.zeta.org.au> References: <199806010614.QAA13173@godzilla.zeta.org.au> Subject: Re: union nethostaddr no longer defined for src/sbin/mount_nfs.c To: Bruce Evans Cc: freebsd-current@FreeBSD.ORG Date: Mon, 01 Jun 1998 01:21:33 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- On 1 June 1998 at 16:14, Bruce Evans wrote: > No, rev.1.33 of src/sys/nfs/nfs.h is a prerequisite for > rev.1.27 of src/sbin/mount_nfs/mount_nfs.c, so clobbering > of rev.1.33 in rev.1.40 broke mount_nfs.c. Yes, that is what I was trying to get across in my original message. I think you've stated it more clearly than I (except it was revision 1.37 of nfs.h that undid revision 1.33). [snip] > >I guess the question in my mind is which is more important > >with regards to the NFS code: > > > >* Progress towards a less ``polluted'' environment, OR > >* Kernel and header source code compatibility with other > > BSD systems > > I don't like pollution, but implemented consistent pollution. :-) > Bruce Thanks, Jacques Vidrine -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNXJIbDeRhT8JRySpAQEC6gQAgqNuOhHgM9VSPEX6rbFCxclVDFx27erC sFPphgTeCF28ox+fiZegsUMDHqiqSKHaCD6tyK0uwLOeN/cgwuVkenZrkeGykYpL GMH5WsUa/hj+/RkkH/ZR23n26fdRdY3Ods4/doJLCdRUmU9YghhLJkYfxM+rf9Bq B5r5rGt3QvA= =ksYo -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 23:25:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09398 for freebsd-current-outgoing; Sun, 31 May 1998 23:25:15 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09382; Sun, 31 May 1998 23:25:12 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id QAA13930; Mon, 1 Jun 1998 16:24:47 +1000 Date: Mon, 1 Jun 1998 16:24:47 +1000 From: Bruce Evans Message-Id: <199806010624.QAA13930@godzilla.zeta.org.au> To: dg@root.com, scrappy@hub.org Subject: Re: May29th kernel with May20th CAM drivers: panic? Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It appears that the mbuf chain is getting corrupted somehow. The above >trap info indicates that the m_data pointer is bogus, resulting in a panic >when the system attempts to get the physical address from the page tables. >I don't see anything obvious in the 'de' driver that could cause this, so >I suspect the buffer corruption is external to the driver. I recently fixed one source of mbuf chain corruption: diff -c2 uipc_socket.c~ uipc_socket.c *** uipc_socket.c~ Sun May 17 04:45:15 1998 --- uipc_socket.c Thu May 28 14:21:40 1998 *************** *** 689,694 **** orig_resid = 0; if (psa) ! *psa = dup_sockaddr(mtod(m, struct sockaddr *), ! mp0 == 0); if (flags & MSG_PEEK) { m = m->m_next; --- 689,693 ---- orig_resid = 0; if (psa) ! *psa = dup_sockaddr(mtod(m, struct sockaddr *), 0); if (flags & MSG_PEEK) { m = m->m_next; It is apparently not OK for the MALLOC() in dup_sockaddr() to wait if the call is from here. Even lowering the ipl is not OK. To see corruption, add a reverse splx()/splnet() here and do a `ping -f' to an ethernet host. This normally causes a panic in sbdrop() within a second or two. OTOH, the reverse splx()/splnet() doesn't seem to cause any problems under light network loads, and MALLOC() doesn't normally sleep, so this bug probably only shows up under very heavy loads. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 31 23:56:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12737 for freebsd-current-outgoing; Sun, 31 May 1998 23:56:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12715 for ; Sun, 31 May 1998 23:56:24 -0700 (PDT) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.0.Beta5/8.9.0.Beta5) id IAA16317; Mon, 1 Jun 1998 08:54:17 +0200 (SAT) From: John Hay Message-Id: <199806010654.IAA16317@zibbi.mikom.csir.co.za> Subject: Re: mbuf cluster problem continues!! In-Reply-To: <199806010520.WAA09567@implode.root.com> from David Greenman at "May 31, 98 10:20:10 pm" To: dg@root.com Date: Mon, 1 Jun 1998 08:54:17 +0200 (SAT) Cc: andrew@iaccess.com.au, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >I'm still having the same mbuf cluster problem. I'm running squid with a 14 > >Gig Cache and getting up to 200 connections a second. The problem is that > >mbuf clusters in-use just keeps on rising until it gets to the peak and then > >the whole thing crashes. I've got it set to 22000 at the moment, but last > >time they went up to nearly 10000 before it crashed. Is there a problem > >with leaking mbuf clusters still, or is that what they are supposed to do? > > > >If this has been addressed already and i missed it, i would be glad if > >someone could bring me up to date :) > > I've seen several reports of mbuf leaks in the specific case of running > squid proxy servers. As I don't have anything remotely resembling that in any > configuration I have here, someone else will have to troubleshoot this one. > It's possible that this might actually be a bug in squid rather than in > FreeBSD. I have really no idea; I've not seen any mbuf leaks in any other > networking use of FreeBSD so it is surprising that one would show up when > doing this. Isn't it just the various TCP wait states for old connections that still have to timeout that look like mbuf leaks? Even on my not-so-very-busy squid server there is always some of them hanging around. You can easily see that with "netstat -an". John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 00:19:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA15394 for freebsd-current-outgoing; Mon, 1 Jun 1998 00:19:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA15373 for ; Mon, 1 Jun 1998 00:19:35 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id PAA07555; Mon, 1 Jun 1998 15:17:43 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806010717.PAA07555@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: John Birrell cc: root@enigami.com (The & of all Evil), brianfeldman@hotmail.com, freebsd-current@FreeBSD.ORG Subject: Re: ELF preparation step 2 done In-reply-to: Your message of "Mon, 01 Jun 1998 14:20:59 +1000." <199806010421.OAA16535@cimlogic.com.au> Date: Mon, 01 Jun 1998 15:17:42 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > The & of all Evil wrote: > > "Brian Feldman" writes: > > > > > Well, after making world and having all /usr/libexec/{elf,aout}, I guess one could make an ELF world in a couple steps, if they're interested: > > > 1. export BINFORMAT=elf and make usr.bin/objformat, and make install it > > > 2. go to lib/, 'echo "BINFORMAT=elf" > /etc/objectformat' and make all the libs, and install them (to /usr/lib? mine installed there, I moved them to /usr/lib/elf, should the elf libs really be there or just /usr/lib?) > > > 3. make the world; it _should_ work now, but I didn't try it > ^^^^^^^^^^^^^^^^^^^ > Obviously. > > > > > singularity:/usr/src/lib 14# make all > > ===> libcom_err > > cc -O -pipe -c /usr/src/lib/libcom_err/com_err.c -o com_err.o > > Unrecognized line in /etc/objectformat: BINFORMAT=elf > > Unrecognized line in /etc/objectformat: BINFORMAT=elf > > com_err.o: file not recognized: File format not recognized > > A few things (not necessarily all) you need to do: > > 1. Make world to get aout and elf tools (built as aout executables) in > their new places and objformat installed in /usr/bin. > 2. chflags -R noschg /usr/obj/usr/src/tmp > 3. rm -rf /usr/obj/* > 4. Create /etc/objectformat with the line OBJFORMAT=elf > 5. Add BINFORMAT=elf to /etc/make.conf > 6. cd /usr/src/csu/i386-elf; make obj/depend/all/install > 7. cd /usr/src/gnu/usr.bin/cc/libgcc; make obj/depend/all/install > 8. cd /usr/src/lib/libc; make obj/depend/all/install > 9. cd /usr/src/libexec/rtld-elf; make obj/depend/all/install > 10. cd /usr/src/lib; make obj/depend/all/install > 11. cd /usr/src/gnu/lib; make obj/depend/all/install > 12. cd /usr/src; make obj/depend/all/install > > I have tried this. Step 12 bombs in src/gnu/usr.bin/ld. I have a fully functioning make world that I believe will survive a transition from a.out to elf.. I have a load of patches to Makefiles that and a couple of tools (eg: install) that are needed to do this. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 00:21:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA15557 for freebsd-current-outgoing; Mon, 1 Jun 1998 00:21:24 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from myrddin.demon.co.uk (exim@myrddin.demon.co.uk [158.152.54.180]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA15541 for ; Mon, 1 Jun 1998 00:21:20 -0700 (PDT) (envelope-from dom@myrddin.demon.co.uk) Received: from dom by myrddin.demon.co.uk with local (Exim 1.80 #1) id 0ygOdT-0000C9-00; Mon, 1 Jun 1998 08:03:59 +0100 To: Terry Lambert Cc: current@FreeBSD.ORG Subject: Service Location Protocol References: <199805292330.QAA23999@usr05.primenet.com> From: Dom Mitchell In-Reply-To: Terry Lambert's message of "Fri, 29 May 1998 23:30:55 +0000 (GMT)" X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: Mon, 01 Jun 1998 08:03:58 +0100 Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: > When I ported the sample implementation of the Service Location > Protocol code from Sun Microsystems, I had to de-Linux the type > type declarations, then memset( &x, 0, sizeof(struct sockaddr_in)); > all over the place. Do you have a copy of this in a publically available location - it's something I've been wanting to play with... -- "Every minute there's a UNIX system crashing somewhere." -- DJB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 00:44:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18395 for freebsd-current-outgoing; Mon, 1 Jun 1998 00:44:24 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from engulf.net (root@engulf.com [207.96.124.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA18376 for ; Mon, 1 Jun 1998 00:44:19 -0700 (PDT) (envelope-from brandon@engulf.net) Received: from localhost (brandon@localhost) by engulf.net (8.8.8/8.8.8) with SMTP id CAA00444 for ; Mon, 1 Jun 1998 02:51:00 -0400 (EDT) Date: Mon, 1 Jun 1998 02:50:33 -0400 (EDT) From: Brandon Lockhart To: current@FreeBSD.ORG Subject: Big problems. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FreeBSD 3.0-CURRENT (From 5/30/98). Make world performed on 5/30, kernel re-made 5/31. Rebooted 6/1. I had an apparent power outage and when I cam back to the console, I had many error's. If anyone can tell me what to do to prevent this problem in the future, I would appreciate it greatly. ldconfig will not load /usr/local/lib. I don't know how to recall the error, but it was in the ALIAS part of it. ppp will not dial up at all. I type "dial" and it just hangs there. I had to use /stand/ppp to get online to send this post. Also, is there a way to find "cleared" files? My shutdown -r now is still not syncing disks, etc. (Could someone please send me a working copy) (of shutdown) or atleast how to do it manually without messing things up. I haven't noticed any more problems yet, but primary zone files in my /etc/named/ directory got tabs randomly placed into the file. Thank's for any help. ,----------------------. | Brandon Lockhart | `----------,-----------'------------. | brandon@engulf.net | `------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 01:07:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA20979 for freebsd-current-outgoing; Mon, 1 Jun 1998 01:07:28 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gjp.erols.com (root@alex-va-n008c243.moon.jic.com [206.156.18.253]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA20974 for ; Mon, 1 Jun 1998 01:07:24 -0700 (PDT) (envelope-from gjp@gjp.erols.com) Received: from gjp.erols.com (gjp@localhost.erols.com [127.0.0.1]) by gjp.erols.com (8.8.8/8.8.7) with ESMTP id EAA01087; Mon, 1 Jun 1998 04:06:12 -0400 (EDT) (envelope-from gjp@gjp.erols.com) X-Mailer: exmh version 2.0.1 12/23/97 To: John Hay cc: dg@root.com, andrew@iaccess.com.au, freebsd-current@FreeBSD.ORG From: "Gary Palmer" Subject: Re: mbuf cluster problem continues!! In-reply-to: Your message of "Sat, 01 Jun 1998 08:54:17 +0200." <199806010654.IAA16317@zibbi.mikom.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 04:06:12 -0400 Message-ID: <1083.896688372@gjp.erols.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Hay wrote in message ID <199806010654.IAA16317@zibbi.mikom.csir.co.za>: > Isn't it just the various TCP wait states for old connections that still > have to timeout that look like mbuf leaks? Even on my not-so-very-busy > squid server there is always some of them hanging around. You can easily > see that with "netstat -an". Especially if you have a lot of users using Internet Explorer 3 under 95... it seems to not close TCP sockets properly for some reason (at least on my local setup) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 01:16:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22232 for freebsd-current-outgoing; Mon, 1 Jun 1998 01:16:30 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from azimov.videotron.ca (ppp175.117.mmtl.videotron.net [207.253.117.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA22197 for ; Mon, 1 Jun 1998 01:16:24 -0700 (PDT) (envelope-from sepotvin@videotron.ca) Received: from videotron.ca (localhost [127.0.0.1]) by azimov.videotron.ca (8.8.8/8.8.8) with ESMTP id EAA09392; Mon, 1 Jun 1998 04:18:01 -0400 (EDT) (envelope-from sepotvin@videotron.ca) Message-ID: <357263B8.FF1541B3@videotron.ca> Date: Mon, 01 Jun 1998 04:18:00 -0400 From: "Stephane E. Potvin" Organization: IBM Canada Ltd. X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Peter Wemm , current@FreeBSD.ORG Subject: Re: ELF preparation step 2 done References: <199806010717.PAA07555@spinner.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > I have a fully functioning make world that I believe will survive a > transition from a.out to elf.. I have a load of patches to Makefiles that > and a couple of tools (eg: install) that are needed to do this. Same thing over here. Would it be possible to see yours so I can compare with mines? Thanks Stephane E. Potvin POS and Industry Helpdesk IBM Canada Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 01:19:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA22855 for freebsd-current-outgoing; Mon, 1 Jun 1998 01:19:37 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA22850 for ; Mon, 1 Jun 1998 01:19:34 -0700 (PDT) (envelope-from sinbin.demos.su!bag@kremvax.demos.su) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.5.31] with ESMTP id MAA19607; Mon, 1 Jun 1998 12:17:20 +0400 Received: by sinbin.demos.su id MAA12889; (8.6.12/D) Mon, 1 Jun 1998 12:16:38 +0400 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199806010816.MAA12889@sinbin.demos.su> Subject: Re: I see one major problem with DEVFS... In-Reply-To: <19980531001525.36883@follo.net> from "Eivind Eklund" at "May 31, 98 00:15:25 am" X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: eivind@yes.no (Eivind Eklund) Date: Mon, 1 Jun 1998 12:16:37 +0400 (MSD) Cc: sepotvin@videotron.ca, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, May 30, 1998 at 05:02:14PM -0400, Stephane E. Potvin wrote: > > Maybe this will seems a stupid question but why in the first place would > > someone want to delete a device from a devfs /dev? Or put differently why is > > not devfs append-only so someone would be able to make new links but not able > > to delete existing devices? > > For use in a chroot()'ed environment. there are several problems with dev's in a chroot'ed enviroment, for example a real system (we use it): 1. about 500 chroot'ed "virtual mashines", the /dev containes only necessary devices (tty??) for each VM (created by mknod when VM created) 2. users fs (on main server) with VM (end /dev for each VM) mounted via nfs on several hosts where users realy work (chroot on nfs) 3. each VM can created or deleted while system working on main server and what about future of this scheme with new devfs ideas? mount devfs for each VM on main server and hosts where users work? and unmount devfs on each host before VM deleted? Alex. > > Eivind. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 01:43:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25461 for freebsd-current-outgoing; Mon, 1 Jun 1998 01:43:25 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles157.castles.com [208.214.165.157]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA25455 for ; Mon, 1 Jun 1998 01:43:23 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id AAA16063; Mon, 1 Jun 1998 00:37:50 -0700 (PDT) Message-Id: <199806010737.AAA16063@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Brandon Lockhart cc: current@FreeBSD.ORG Subject: Re: Big problems. In-reply-to: Your message of "Mon, 01 Jun 1998 02:50:33 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 00:37:49 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > FreeBSD 3.0-CURRENT (From 5/30/98). Make world performed on 5/30, kernel > re-made 5/31. Rebooted 6/1. I had an apparent power outage and when I > cam back to the console, I had many error's. If anyone can tell me what > to do to prevent this problem in the future, I would appreciate it > greatly. Buy a UPS. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 01:48:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA26229 for freebsd-current-outgoing; Mon, 1 Jun 1998 01:48:15 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles157.castles.com [208.214.165.157]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA26224 for ; Mon, 1 Jun 1998 01:48:13 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id AAA16099; Mon, 1 Jun 1998 00:43:36 -0700 (PDT) Message-Id: <199806010743.AAA16099@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: jkh@time.cdrom.com, mike@smith.net.au, current@FreeBSD.ORG, dag-erli@ifi.uio.no, graphix@iastate.edu, mcdougall@ameritech.net Subject: Re: kernel config In-reply-to: Your message of "Mon, 01 Jun 1998 14:50:54 +1000." <199806010450.OAA07373@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 00:43:36 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Support for reading this data from flat areas of the disk is no longer > >part of the bootstrap. I don't think that there are very many cases > > It never was supported for biosboot, cdboot, dosboot or netboot, but > is automatically supported by rawboot. Understood (now I think about it). > >where this is likely to be in use (I seem to recall it required a > >special bootblock compilation option). If there is a strong case for > >requiring this signature, though, I have no objections. > > A signature is required to avoid parsing garbage from bootblocks that > don't support the config area. Indeed, courtesy of the stupid place that it's put. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 02:13:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA00170 for freebsd-current-outgoing; Mon, 1 Jun 1998 02:13:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA00139 for ; Mon, 1 Jun 1998 02:13:42 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA09919; Mon, 1 Jun 1998 02:12:01 -0700 (PDT) Message-Id: <199806010912.CAA09919@implode.root.com> To: John Hay cc: andrew@iaccess.com.au, freebsd-current@FreeBSD.ORG Subject: Re: mbuf cluster problem continues!! In-reply-to: Your message of "Sat, 01 Jun 1998 08:54:17 +0200." <199806010654.IAA16317@zibbi.mikom.csir.co.za> From: David Greenman Reply-To: dg@root.com Date: Mon, 01 Jun 1998 02:12:01 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I've seen several reports of mbuf leaks in the specific case of running >> squid proxy servers. As I don't have anything remotely resembling that in any >> configuration I have here, someone else will have to troubleshoot this one. >> It's possible that this might actually be a bug in squid rather than in >> FreeBSD. I have really no idea; I've not seen any mbuf leaks in any other >> networking use of FreeBSD so it is surprising that one would show up when >> doing this. > >Isn't it just the various TCP wait states for old connections that still >have to timeout that look like mbuf leaks? Even on my not-so-very-busy >squid server there is always some of them hanging around. You can easily >see that with "netstat -an". That could be...certainly something to check out. I seem to recall that the previous report of this problem was with a machine that had a very light proxy load, so it seemed unlikely that old connections could be a serious problem. ...but perhaps either the load wasn't as light as thought or perhaps there were very few mbuf clusters configured (or both). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 02:17:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA00952 for freebsd-current-outgoing; Mon, 1 Jun 1998 02:17:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA00920 for ; Mon, 1 Jun 1998 02:17:35 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id CAA09950; Mon, 1 Jun 1998 02:17:00 -0700 (PDT) Message-Id: <199806010917.CAA09950@implode.root.com> To: Bruce Evans cc: scrappy@hub.org, freebsd-current@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? In-reply-to: Your message of "Mon, 01 Jun 1998 16:24:47 +1000." <199806010624.QAA13930@godzilla.zeta.org.au> From: David Greenman Reply-To: dg@root.com Date: Mon, 01 Jun 1998 02:16:59 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> It appears that the mbuf chain is getting corrupted somehow. The above >>trap info indicates that the m_data pointer is bogus, resulting in a panic >>when the system attempts to get the physical address from the page tables. >>I don't see anything obvious in the 'de' driver that could cause this, so >>I suspect the buffer corruption is external to the driver. > >I recently fixed one source of mbuf chain corruption: Do you plan to commit this before the end of the century? :-) -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 02:52:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05170 for freebsd-current-outgoing; Mon, 1 Jun 1998 02:52:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA05164 for ; Mon, 1 Jun 1998 02:52:55 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id TAA27109; Mon, 1 Jun 1998 19:52:49 +1000 Date: Mon, 1 Jun 1998 19:52:49 +1000 From: Bruce Evans Message-Id: <199806010952.TAA27109@godzilla.zeta.org.au> To: bde@zeta.org.au, dg@root.com Subject: Re: May29th kernel with May20th CAM drivers: panic? Cc: freebsd-current@FreeBSD.ORG, scrappy@hub.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>I recently fixed one source of mbuf chain corruption: > > Do you plan to commit this before the end of the century? :-) Probably not. It's not clear whether callers can handle unexpected failures of dup_sockaddr(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 03:13:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA08244 for freebsd-current-outgoing; Mon, 1 Jun 1998 03:13:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA08107 for ; Mon, 1 Jun 1998 03:11:39 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id DAA18799; Mon, 1 Jun 1998 03:09:52 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Mike Smith cc: Brandon Lockhart , current@FreeBSD.ORG Subject: Re: Big problems. In-reply-to: Your message of "Mon, 01 Jun 1998 00:37:49 PDT." <199806010737.AAA16063@antipodes.cdrom.com> Date: Mon, 01 Jun 1998 03:09:51 -0700 Message-ID: <18795.896695791@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Buy a UPS. Wouldn't help him in this case anyway. he's just rebooting for the first time in awhile and just noticed what anyone who's been reading the -current mailing list for awhile already knows: the libs have moved from /usr/lib to /usr/lib/aout. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 03:45:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11978 for freebsd-current-outgoing; Mon, 1 Jun 1998 03:45:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11969 for ; Mon, 1 Jun 1998 03:45:33 -0700 (PDT) (envelope-from paulz@trantor.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <6742-9193>; Mon, 1 Jun 1998 12:45:11 +0200 Received: from trantor.stuyts.nl (uucp@localhost) by terminus.stuyts.nl (8.8.8/8.8.8) with UUCP id AAA29964; Mon, 1 Jun 1998 00:36:52 +0200 (MET DST) (envelope-from paulz@trantor.stuyts.nl) Received: from trantor.stuyts.nl (localhost [127.0.0.1]) by trantor.stuyts.nl (8.8.8/8.8.5) with ESMTP id AAA29878; Mon, 1 Jun 1998 00:24:52 +0200 (MET DST) Message-Id: <199805312224.AAA29878@trantor.stuyts.nl> X-Mailer: exmh version 2.0.2 2/24/98 To: Josh MacDonald Cc: current@FreeBSD.ORG Subject: Re: Undefined symbols referenced In-reply-to: Your message of "Sun, 31 May 1998 10:36:54 PDT." <19980531103654.23417@paris.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 00:24:51 +0200 From: Paul van der Zwan Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Quoting Paul van der Zwan (paulz@trantor.stuyts.nl): > > I had the same problem a week or so ago. The xdelta port will not build on > > current ( cvsupped and make world this weekend) even rebuilding the gdbm port > > and reinstalling that does not work. > > Gimp will now build because the maintainer removed the dependency on xdelta > > but the xdelta port looks broken on current. > > I would say that current looks broken on xdelta. More specifically, your > current looks broken. I don't appreciate hearing this type of report, which > indicates the xdelta is to blame. I've gotten at least 10 of these reports. > I don't like to hear that xdelta has been removed from GIMP either. People > with these problems should not be running -current. > > -josh What kind of problems ?? I don't like blaming something/one for my problems, but in this case in am just reporting a problem and in my opinion if there is a port does not build on current, it's the port and not currrent that is broken esp. if other ports stil build fine. In this case it is the combination of current and the xdelta 0.18 port that does not work.. I run current willingly and I know the problems it can cause, but if I follow al the steps like compiling all ports another port depends on, on an otherwise normal and up-to-date current, than that port is broken ( for current). Can you compile xdelta-0.18 on an up-to-date vanilla current with the system cc ??? If so it means our systems are not entirely identical and the difference might cause the port not to compile on my box. If removing xdelta from the GIMP port causes GIMP to work fine , that's OK with me, to be honest I have never noticed xdelta until it caused GMIP not to build. Paul -- Paul van der Zwan paulz @ trantor.stuyts.nl "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 04:31:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19875 for freebsd-current-outgoing; Mon, 1 Jun 1998 04:31:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA19870 for ; Mon, 1 Jun 1998 04:31:41 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id GAA07167; Mon, 1 Jun 1998 06:31:33 -0500 (CDT) Date: Mon, 1 Jun 1998 06:31:33 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <19980531235232.04296@follo.net> References: ; from Richard Wackerbarth on Sun, May 31, 1998 at 11:50:33AM -0500 ; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <19980531052120.41610@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Eivind Eklund From: Richard Wackerbarth Subject: Re: How about /usr/ports/kernel ? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:52 PM -0000 5/31/98, Eivind Eklund wrote: >However, to be able to do automated kernel builds we have to have a >way of specifying which kernels to build which do not come as a shock >to our userbase (this is a political necessity; I don't think either >of us would get any way arguing otherwise). This probably mean that >we'll have to support the use of config(8) in the way it is presently >used for a transition period of at least a year. Not necessarily. Consider the following strategy: (1) Replace "config" with a shell script that (a) copies the configuration file to .../src/sys/compile hierarchy (b) issues a message reminding the user that the procedure for building a kernel has been slightly modified, and perhaps (c) does a "make" in the newly constructed target area. (2) (To avoid confusion) Rename the present "config" and modify it to be a tool for the new structure. It would fit in, in a manner similar to yacc, to be called where needed. The only transition capability that I see necessary is that we still handle the present configuration files. If a user wishes to utilize the expanded capabilities that you (we) would like to be present, he can also convert to the modified structure for his configuration description and bypass the old config. As far as "automatic kernel build" is concerned, I think that this can be handled by having an optional Makefile.inc in the src/sys structure that adds SUBDIR's for the desired kernels. We could always use "SUBDIR?= GENERIC" to provide the default. >Do you disagree with the way of adding this meta-information to >contributed subsystems? I'm all ears for anything better that give >the same capabilites for external people modifying the system - I just >haven't found any better way. As I have previously stated, I view the kernel in the same way that I view a user-level command. It may require a few unique variants. However, it is fundamentally, source (compiled) into object (linked) into executable (loaded) for execution I see the inclusion of kernel components fitting in in a manner analogous to the "contrib" structure. Preprocessors give the standard "include" capability. As far as the building of a kernel is concerned, the configuration step can be used to generate a "Makefile" in the object directory and then invoke it. (Somewhat like the typical "configure" scripts in typical distributions) [... deleted: points on Unix and design which I agree with but don't always find myself bright enough to be able to follow ...] Summary: Think "Lego", or, for those old enough to remember, the A.C. Gilbert "Erector" sets rather than "Microsoft". Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 05:02:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA23049 for freebsd-current-outgoing; Mon, 1 Jun 1998 05:02:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23035 for ; Mon, 1 Jun 1998 05:02:04 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA20840; Mon, 1 Jun 1998 14:02:01 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id OAA16937; Mon, 1 Jun 1998 14:01:35 +0200 (MET DST) Date: Mon, 1 Jun 1998 14:01:35 +0200 (MET DST) From: Joerg Schilling Message-Id: <199806011201.OAA16937@sherwood.gmd.de> To: dufault@hda.com, schilling@fokus.gmd.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From dufault@hda.hda.com Fri May 29 20:12:29 1998 >> >I'm sure it will be straight forward to hook up to your library. >> >> Seems to be interesting, please send me a pointer. >Only if you promise not to give me trouble about errx - as a FreeBSD >utility their coding standard says to use that, and when >in Rome do as the Romans do. To make it portable, I'll need to replace them with my routines comerr() comerrno() errmsg() and errmsgno() wich I am using since 1982 - long before BSD intruduced things like that. I have no problems with these functions as I believe that it neccessary to have readable error messages and perror() don't makes good error messages. The problem that I have with the *BSD functions is that they make the programs non-portable. *BSD programs are often much better than GNU utilities but no-one can use them outside BSD. I believe the suing with AT&T has been won and there is no need to make programs look like they are not from a UNIX system. Please: - Put all non standard library extensions into a separate libbsd and make this library portable. ( you may add this library to the default library list of the compiler on *BSD so there will be no need to change makefiles) - Make sure that programs don't rely on nonstandard modifications of historical UNIX include files if there is a reason to compile and run these programs on a non *BSD system ( e.g. it is a non BSD kernel specific program). - Write man pages that use the stanmdard UNIX -man macros and not non-standard modifications. >If it is no longer available for anonymous ftp I'll put it up >here. I'll get back to you. I only found /sbin/scsi on the ftp server ... please give me a hint. P.S. I believe that the real problem might be that your program comes with a BSD license while my software comes with GPL. In any case, it seems to be a good idea to have a combination of a command line interpreter which allows easy sending of arbitrary commands and a portable SCSI transport library. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 05:04:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA23413 for freebsd-current-outgoing; Mon, 1 Jun 1998 05:04:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from techpower.net (techpower.net [205.133.231.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23394 for ; Mon, 1 Jun 1998 05:04:44 -0700 (PDT) (envelope-from hometeam@techpower.net) Received: from localhost (hometeam@localhost) by techpower.net (8.8.8/8.8.8) with SMTP id IAA25613 for ; Mon, 1 Jun 1998 08:03:49 -0400 (EDT) (envelope-from hometeam@techpower.net) Date: Mon, 1 Jun 1998 08:03:49 -0400 (EDT) From: Jt To: current@FreeBSD.ORG Subject: compile error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Latest snap this morning broken? "/usr/src/share/mk/bsd.own.mk", line 125: Malformed conditional (${BINFORMAT} == aout) "/usr/src/share/mk/bsd.own.mk", line 125: Need an operator "/usr/src/share/mk/bsd.own.mk", line 127: if-less else "/usr/src/share/mk/bsd.own.mk", line 127: Need an operator "/usr/src/share/mk/bsd.own.mk", line 129: if-less endif "/usr/src/share/mk/bsd.own.mk", line 129: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 05:08:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA23989 for freebsd-current-outgoing; Mon, 1 Jun 1998 05:08:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23984 for ; Mon, 1 Jun 1998 05:08:47 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA20932; Mon, 1 Jun 1998 14:08:14 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id OAA16974; Mon, 1 Jun 1998 14:07:51 +0200 (MET DST) Date: Mon, 1 Jun 1998 14:07:51 +0200 (MET DST) From: Joerg Schilling Message-Id: <199806011207.OAA16974@sherwood.gmd.de> To: mike@smith.net.au, schilling@fokus.gmd.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet / SCSI ABI test Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From mike@dingo.cdrom.com Fri May 29 22:20:41 1998 >> For this reason, I prefer to have some ABI checker software. >Alan Turing. >> But for timeout tests not every CD-ROM drive is usable because the only= >> idea I currently have to force a SCSI timeout is to do one very big >> SCSi-VERIFY on a disk with > 400MB data on it. This is because not all >> timeout implementations catch timeouts fast (< 1 minute). >Build a small board containing a 5380 and a microcontroller. Write = >some minimal SCSI target software, and put a console on it. = >You could probably sell 5-10 of these to SCSI driver authors. I believe that this effort is not worth it. The only problem I see when using a CD-ROM drive is that it must support the verify SCSI command in order to be able to check timeouts. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 05:16:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA24847 for freebsd-current-outgoing; Mon, 1 Jun 1998 05:16:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA24842 for ; Mon, 1 Jun 1998 05:16:19 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA21057; Mon, 1 Jun 1998 14:16:10 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id OAA16994; Mon, 1 Jun 1998 14:15:43 +0200 (MET DST) Date: Mon, 1 Jun 1998 14:15:43 +0200 (MET DST) From: Joerg Schilling Message-Id: <199806011215.OAA16994@sherwood.gmd.de> To: mike@smith.net.au, schilling@fokus.gmd.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From mike@dingo.cdrom.com Fri May 29 22:41:20 1998 >It's due to not checking the return value from the sysconf(_SC_PAGESIZE) >in fifo.c. Once you get past that, there's a timing failure between the >writer and reader processes due to a similar omission a little further >down the file. >Having dealt with these, I seem to be dummy-burning quite happily. = >I'll cut a disc for real to be sure, and then send you my patches for = >discussion. This seems to be the real problem with freebsd-current. You cannot deal with this problem: Systems that define _SC_PAGESIZE or _SC_PAGE_SIZE (HP-UX) don't support getpagesize() so there is no way to fix this in runtime except if you introduce an additional HAVE_GETPAGESIZE in the autoconfiguration. But even then the code would be badly readable. I would prefer if the sysconf code would call getpagesize() in userland. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 05:18:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA25144 for freebsd-current-outgoing; Mon, 1 Jun 1998 05:18:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA25139 for ; Mon, 1 Jun 1998 05:18:44 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA21103; Mon, 1 Jun 1998 14:18:36 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id OAA17003; Mon, 1 Jun 1998 14:18:13 +0200 (MET DST) Date: Mon, 1 Jun 1998 14:18:13 +0200 (MET DST) From: Joerg Schilling Message-Id: <199806011218.OAA17003@sherwood.gmd.de> To: paulz@trantor.stuyts.nl, schilling@fokus.gmd.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From paulz@trantor.stuyts.nl Fri May 29 22:46:23 1998 >> >> > Bus error (core dumped) >It looks like this is not related to the posix scheduling not present. >> >> If you are not able to analyze the core with adb and send a usable >> bug description, I cannot help.. >Maybe the following gdb output helps. >$ sudo ./cdrecord dev=0,4,0 -data -dummy /scratch/img/psnl >Cdrecord release 1.6 Copyright (C) 1995-1998 Jörg Schilling >./cdrecord: Function not implemented. WARNING: Cannot set RR-scheduler >Bus error (core dumped) >[22:28:38 trantor:paulz:/usr/source/ports/sysutils/cdrecord/work/cdrecord-1.6/cdrecord/OBJ/i386-freebsd-cc] >$ sudo gdb ./cdrecord cdrecord.core >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.16 (i386-unknown-freebsd), >Copyright 1996 Free Software Foundation, Inc... >Core was generated by `cdrecord'. >Program terminated with signal 10, Bus error. >Reading symbols from /usr/libexec/ld.so...done. >Reading symbols from /usr/lib/aout/libc.so.3.1...done. >#0 fillbytes (tov=0xffffffff, cnt=541769726, val=0) at fillbytes.c:49 >49 *to++ = cval; >(gdb) where >#0 fillbytes (tov=0xffffffff, cnt=541769726, val=0) at fillbytes.c:49 >#1 0x610d in init_fifo (fs=4194304) at fifo.c:179 >#2 0x1d00 in main (ac=5, av=0xefbfd5c4) at cdrecord.c:227 Thanks, this makes it clear that the problem is related to the not working sysconf(_SC_PAGESIZE) Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 06:10:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA01886 for freebsd-current-outgoing; Mon, 1 Jun 1998 06:10:48 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from enigami.com (enigami.com [208.140.182.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA01878 for ; Mon, 1 Jun 1998 06:10:45 -0700 (PDT) (envelope-from root@enigami.com) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by enigami.com (8.8.7/8.8.7) with ESMTP id JAA17526; Mon, 1 Jun 1998 09:09:40 -0400 (EDT) Received: (from ckempf@localhost) by singularity.enigami.com (8.8.8/8.8.8) id JAA12215; Mon, 1 Jun 1998 09:06:51 -0400 (EDT) (envelope-from root@enigami.com) X-Authentication-Warning: singularity.enigami.com: ckempf set sender to root using -f To: Peter Wemm Subject: Re: ELF preparation step 2 done References: <199806011159.TAA08567@spinner.netplex.com.au> Cc: John Birrell , freebsd-current@FreeBSD.ORG From: The & of all Evil Date: 01 Jun 1998 09:06:51 -0400 In-Reply-To: Peter Wemm's message of "Mon, 01 Jun 1998 19:59:17 +0800" Message-ID: Lines: 43 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm writes: > Cory Kempf wrote: > > Due to the volume of spam I receive, I am no longer accepting > > e-mail that is not addressed to me personally. > > Well, you'd better unsubscribe from the freebsd mailing lists then.. You're > sending this out in response to everybody sending mail on the lists. Uh, I shouldn't be! Anything with a sender field containing freebsd should be caught as belonging to the list and filed accordingly. Poking through my backup folder, I found an article you sent this morning, where you replied to an article by John Birrell, where he outlines a 12 step program... Resubmitting it to procmail... hmmm, that worked correctly! OK, found it. Somehow, dispite not being logged in as root, emacs sent my reply as root. You cc'd me (root), causing a copy of the article to show up here directly first. The direct article didn't have the Sender: field, and wasn't addressed to me. Thus, it was treated as Spam (unfortunately, I do get a lot of spam) Anyway, I fixed my filters, so that mail addressed to root (which is forwarded to me) also makes it through the filters. Sorry about that! +C -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: Cory Kempf Macintosh / Unix Consulting & Software Development ckempf@enigami.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 06:16:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA03052 for freebsd-current-outgoing; Mon, 1 Jun 1998 06:16:28 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA03045 for ; Mon, 1 Jun 1998 06:16:25 -0700 (PDT) (envelope-from benst@terminus.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <6926-9193>; Mon, 1 Jun 1998 15:16:07 +0200 Received: from daneel.stuyts.nl (daneel.stuyts.nl [193.78.231.7]) by terminus.stuyts.nl (8.8.8/8.8.8) with ESMTP id PAA00771; Mon, 1 Jun 1998 15:05:49 +0200 (MET DST) (envelope-from benst) Received: (from benst@localhost) by daneel.stuyts.nl (8.8.5/8.8.5) id PAA10258; Mon, 1 Jun 1998 15:05:43 +0200 (MET DST) Message-Id: <199806011305.PAA10258@daneel.stuyts.nl> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2) Received: by NeXT.Mailer (1.118.2) From: Ben Stuyts Date: Mon, 1 Jun 98 15:05:39 +0200 To: current@FreeBSD.ORG, brian@awfulhak.org Subject: ppp cannot find libalias Reply-To: ben@stuyts.nl Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, This is on -current, cvsupped on May 30. I just removed every old library in /usr/lib, as they are now in /usr/lib/aout. The new ppp does not look in the correct place for libalias yet. It still looks in /usr/lib: [terminus.stuyts.nl usr.sbin/ppp]7: ppp nlnet Working in interactive mode Using interface: tun0 Warning: _PATH_ALIAS_PREFIX (/usr/lib/libalias.so.2.*): Invalid lib: cannot stat "/usr/lib/libalias.so.2." : No such file or directory Warning: Cannot load alias library Warning: alias enable: Failed 1 In /usr/src/usr.sbin/ppp/loadalias.c it says: loadalias.c:#define _PATH_ALIAS_PREFIX "/usr/lib/libalias.so.2." Best regards, Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 06:45:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA07154 for freebsd-current-outgoing; Mon, 1 Jun 1998 06:45:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA07139 for ; Mon, 1 Jun 1998 06:44:59 -0700 (PDT) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id XAA10895; Mon, 1 Jun 1998 23:44:55 +1000 (EST) Message-ID: <19980601234455.27126@rf900.physics.usyd.edu.au> Date: Mon, 1 Jun 1998 23:44:55 +1000 From: David Dawes To: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet References: <199806011201.OAA16937@sherwood.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199806011201.OAA16937@sherwood.gmd.de>; from Joerg Schilling on Mon, Jun 01, 1998 at 02:01:35PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 01, 1998 at 02:01:35PM +0200, Joerg Schilling wrote: >The problem that I have with the *BSD functions is that they make the programs >non-portable. *BSD programs are often much better than GNU utilities but no-one >can use them outside BSD. > - Put all non standard library extensions into a separate > libbsd and make this library portable. > ( you may add this library to the default library list of the > compiler on *BSD so there will be no need to change makefiles) While I wouldn't advocate FreeBSD dumbing down to satisfy some portability lowest common denominator, I have run into this situation before when wanting to use the FreeBSD version of some utilities on other platforms. It'd be great to have a FreeBSD compatibility library for other OSs. I'm curious as to whether anyone else has done this? At the times I could have used it there more pressing issues so I never did have a go at it myself. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 06:52:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA07911 for freebsd-current-outgoing; Mon, 1 Jun 1998 06:52:39 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA07901 for ; Mon, 1 Jun 1998 06:52:35 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 18660 invoked by uid 505); 1 Jun 1998 13:52:11 -0000 Date: 1 Jun 1998 13:52:11 -0000 Message-ID: <19980601135211.18659.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: ELF preparation step 2 done In-Reply-To: To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oops, quite sorry, objectformat should have "OBJFORMAT=elf", not "BINFORMAT=elf". Sorry again. Brian Feldman > "Brian Feldman" writes: > > > Well, after making world and having all /usr/libexec/{elf,aout}, I guess one could make an ELF world in a couple steps, if they're interested: > > 1. export BINFORMAT=elf and make usr.bin/objformat, and make install it > > 2. go to lib/, 'echo "BINFORMAT=elf" > /etc/objectformat' and make all the libs, and install them (to /usr/lib? mine installed there, I moved them to /usr/lib/elf, should the elf libs really be there or just /usr/lib?) > > 3. make the world; it _should_ work now, but I didn't try it > > singularity:/usr/src/lib 14# make all > ===> libcom_err > cc -O -pipe -c /usr/src/lib/libcom_err/com_err.c -o com_err.o > Unrecognized line in /etc/objectformat: BINFORMAT=elf > Unrecognized line in /etc/objectformat: BINFORMAT=elf > com_err.o: file not recognized: File format not recognized > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > > Maybe there is another step somewhere? > > > -- > Thinking of purchasing RAM from the Chip Merchant? > Please read this first: > > Cory Kempf Macintosh / Unix Consulting & Software Development > ckempf@enigami.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 06:56:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA08700 for freebsd-current-outgoing; Mon, 1 Jun 1998 06:56:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA08674 for ; Mon, 1 Jun 1998 06:56:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id NAA25723; Mon, 1 Jun 1998 13:56:48 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA03876; Mon, 1 Jun 1998 15:56:31 +0200 (MET DST) Message-ID: <19980601155630.19988@follo.net> Date: Mon, 1 Jun 1998 15:56:30 +0200 From: Eivind Eklund To: Richard Wackerbarth , Terry Lambert Cc: current@FreeBSD.ORG Subject: XANDF (was Re: Fix for undefined "__error" and discussion of shared object) References: <199805312213.PAA16988@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Richard Wackerbarth on Sun, May 31, 1998 at 09:57:05PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, May 31, 1998 at 09:57:05PM -0500, Richard Wackerbarth wrote: > >I *really* look forward to the day when I can buy an XANDF Motif > >library, and use it on all my hardware, regardless of the CPU type. > >8-0. > > Aren't we really just emulating an "XANDF" machine with an XANDF->whatever > micro-code expanded inline? Where is my XANDF native machine? Having an XANDF native machine would be very strange. XANDF was designed to be a intermediate format. It can contain variations/extension for different architectures, and I'm not certain it would be feasible to execute it. You at least want to do an optimization pass as you install it; XANDF code is usually distributed with some architecture-specific code - code that is _intended_ to be dead code on other architectures. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 07:03:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA10156 for freebsd-current-outgoing; Mon, 1 Jun 1998 07:03:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA10151 for ; Mon, 1 Jun 1998 07:03:50 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 19703 invoked by uid 505); 1 Jun 1998 14:03:25 -0000 Date: 1 Jun 1998 14:03:25 -0000 Message-ID: <19980601140325.19702.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: Undefined symbols referenced In-Reply-To: <199805312224.AAA29878@trantor.stuyts.nl> To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For all you GIMP users: export CVSROOT=':pserver:anonymous@cvs.gimp.org:/debian/home/gnomecvs' mkdir CVSROOT;cd CVSROOT cvs login && cvs -z9 co gtk+ gimp for dir in gtk+ gimp; do cd $dir; ./autogen.sh; gmake all install clean; cd ..; done Is that really too hard, rather than using the goddamned port?! Brian Feldman > > Quoting Paul van der Zwan (paulz@trantor.stuyts.nl): > > > I had the same problem a week or so ago. The xdelta port will not build on export > > > current ( cvsupped and make world this weekend) even rebuilding the gdbm port > > > and reinstalling that does not work. > > > Gimp will now build because the maintainer removed the dependency on xdelta > > > but the xdelta port looks broken on current. > > > > I would say that current looks broken on xdelta. More specifically, your > > current looks broken. I don't appreciate hearing this type of report, which > > indicates the xdelta is to blame. I've gotten at least 10 of these reports. > > I don't like to hear that xdelta has been removed from GIMP either. People > > with these problems should not be running -current. > > > > -josh > > What kind of problems ?? I don't like blaming something/one for my problems, > but in this case in am just reporting a problem and in my opinion if there is > a port does not build on current, it's the port and not currrent that is broken > esp. if other ports stil build fine. > In this case it is the combination of current and the xdelta 0.18 > port that does not work.. I run current willingly and I know the problems > it can cause, but if I follow al the steps like compiling all ports another > port depends on, on an otherwise normal and up-to-date current, than that > port is broken ( for current). > Can you compile xdelta-0.18 on an up-to-date vanilla current with the system > cc ??? If so it means our systems are not entirely identical and the > difference might cause the port not to compile on my box. > If removing xdelta from the GIMP port causes GIMP to work fine , that's OK > with me, to be honest I have never noticed xdelta until it caused GMIP not to > build. > > Paul > > -- > Paul van der Zwan paulz @ trantor.stuyts.nl > "I think I'll move to theory, everything works in theory..." > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 07:10:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA11828 for freebsd-current-outgoing; Mon, 1 Jun 1998 07:10:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from m2.findmail.com (m2.findmail.com [209.185.96.135]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA11820 for ; Mon, 1 Jun 1998 07:09:58 -0700 (PDT) (envelope-from brianfeldman@hotmail.com) Received: (qmail 20190 invoked by uid 505); 1 Jun 1998 14:09:35 -0000 Date: 1 Jun 1998 14:09:35 -0000 Message-ID: <19980601140935.20189.qmail@m2.findmail.com> From: "Brian Feldman" Subject: Re: ppp cannot find libalias In-Reply-To: <199806011305.PAA10258@daneel.stuyts.nl> To: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So fix it, I don't see what the problem is here? Brian Feldman > Hi, > > This is on -current, cvsupped on May 30. I just removed every old library in > /usr/lib, as they are now in /usr/lib/aout. The new ppp does not look in the > correct place for libalias yet. It still looks in /usr/lib: > > [terminus.stuyts.nl usr.sbin/ppp]7: ppp nlnet > Working in interactive mode > Using interface: tun0 > Warning: _PATH_ALIAS_PREFIX (/usr/lib/libalias.so.2.*): Invalid lib: cannot > stat "/usr/lib/libalias.so.2." : No such file or directory > Warning: Cannot load alias library > Warning: alias enable: Failed 1 > > In /usr/src/usr.sbin/ppp/loadalias.c it says: > > loadalias.c:#define _PATH_ALIAS_PREFIX "/usr/lib/libalias.so.2." > > Best regards, > Ben > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 07:21:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14001 for freebsd-current-outgoing; Mon, 1 Jun 1998 07:21:27 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from azimov.videotron.ca (ppp046.118.mmtl.videotron.net [207.253.118.46]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13993 for ; Mon, 1 Jun 1998 07:21:21 -0700 (PDT) (envelope-from sepotvin@videotron.ca) Received: from videotron.ca (localhost [127.0.0.1]) by azimov.videotron.ca (8.8.8/8.8.8) with ESMTP id KAA03407 for ; Mon, 1 Jun 1998 10:23:06 -0400 (EDT) (envelope-from sepotvin@videotron.ca) Message-ID: <3572B94A.7AAD0FB1@videotron.ca> Date: Mon, 01 Jun 1998 10:23:06 -0400 From: "Stephane E. Potvin" Organization: IBM Canada Ltd. X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: Error in sys.mk Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG bsd.own.mk is included before /etc/make.conf in the current sys.mk This causes ${LIBDIR} to be wrongly set to /usr/local/lib/aout when BINFORMAT=elf is set into /etc/make.conf The following patch did the trick for me though I don't know if it's the best/preferable way to do it or if it will break some other esoteric part of the make process. Can someone more knowledgeable in the mk files check this and tell me if I'm completely out of the track? *** sys.mk.orig Mon May 18 17:09:10 1998 --- sys.mk Mon Jun 1 10:07:54 1998 *************** *** 243,250 **** .endif - .include - .if exists(/etc/make.conf) .include .endif --- 243,250 ---- .endif .if exists(/etc/make.conf) .include .endif + + .include Regards Stephane E. Potvin POS and Industry Helpdesk IBM Canada Ltd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 07:24:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14466 for freebsd-current-outgoing; Mon, 1 Jun 1998 07:24:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA14460 for ; Mon, 1 Jun 1998 07:24:06 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id HAA20869; Mon, 1 Jun 1998 07:23:40 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: ben@stuyts.nl cc: current@FreeBSD.ORG, brian@awfulhak.org Subject: Re: ppp cannot find libalias In-reply-to: Your message of "Mon, 01 Jun 1998 15:05:39 +0200." <199806011305.PAA10258@daneel.stuyts.nl> Date: Mon, 01 Jun 1998 07:23:39 -0700 Message-ID: <20865.896711019@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > /usr/lib, as they are now in /usr/lib/aout. The new ppp does not look in the > correct place for libalias yet. It still looks in /usr/lib: Hmmm. What do you guys think of this? The ELF path may be wrong since I'm not sure if my understanding of how ELF names its shared libs is entirely sound, but that's easily fixed if so. Index: loadalias.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/ppp/loadalias.c,v retrieving revision 1.16 diff -u -r1.16 loadalias.c --- loadalias.c 1998/05/21 21:46:19 1.16 +++ loadalias.c 1998/06/01 14:21:54 @@ -40,7 +40,12 @@ #include "id.h" #include "loadalias.h" -#define _PATH_ALIAS_PREFIX "/usr/lib/libalias.so.2." +static char *_PathAliasPrefixes[] = { + "/usr/lib/aout/libalias.so.2.", + "/usr/lib/elf/libalias.so", + "/usr/lib/libalias.so.2.", + NULL +}; #define off(item) ((int)&(((struct aliasHandlers *)0)->item)) #define entry(a) { off(a), "_PacketAlias" #a } @@ -68,29 +73,17 @@ struct aliasHandlers PacketAlias; -int -alias_Load() +static int +_alias_Load(char *path) { - const char *path; - const char *env; int i; - - if (PacketAlias.dl) - return 0; - path = _PATH_ALIAS_PREFIX; - env = getenv("_PATH_ALIAS_PREFIX"); - if (env) { - if (ID0realuid() == 0) - path = env; - else - log_Printf(LogALERT, "Ignoring environment _PATH_ALIAS_PREFIX" - " value (%s)\n", env); - } + if (!*path) + return -1; PacketAlias.dl = dlopen(path, RTLD_NOW); if (PacketAlias.dl == (void *) 0) { - /* Look for _PATH_ALIAS_PREFIX with any number appended */ + /* Look for prefix with any number appended */ int plen; plen = strlen(path); @@ -135,11 +128,8 @@ } } } - if (PacketAlias.dl == (void *) 0) { - log_Printf(LogWARN, "_PATH_ALIAS_PREFIX (%s*): Invalid lib: %s\n", - path, dlerror()); + if (PacketAlias.dl == (void *) 0) return -1; - } } for (i = 0; map[i].name; i++) { *(void **)((char *)&PacketAlias + map[i].offset) = @@ -155,6 +145,35 @@ (*PacketAlias.Init)(); return 0; +} + +int +alias_Load() +{ + char *env, *paths[2]; + char **p = NULL; + int i = -1; + + if (PacketAlias.dl) + return 0; + + if ((env = getenv("_PATH_ALIAS_PREFIX")) != NULL) { + if (ID0realuid() == 0) { + paths[0] = env; + paths[1] = NULL; + p = paths; + } + else + log_Printf(LogALERT, "Ignoring environment _PATH_ALIAS_PREFIX" + " value (%s)\n", env); + } + if (!p) + p = _PathAliasPrefixes; + while (*p && (i = _alias_Load(*p))) + ++p; + if (i) + log_Printf(LogWARN, "No valid alias libraries found in search path.\n"); + return i; } void To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:26:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA24888 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:26:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cerebus.nectar.com (cerebus.nectar.com [204.27.67.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA24881 for ; Mon, 1 Jun 1998 08:26:23 -0700 (PDT) (envelope-from nectar@cerebus.nectar.com) Received: from cerebus.nectar.com (localhost.communique.net [127.0.0.1]) by cerebus.nectar.com (8.8.8/8.8.8) with ESMTP id KAA29696; Mon, 1 Jun 1998 10:26:13 -0500 (CDT) Message-Id: <199806011526.KAA29696@cerebus.nectar.com> X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x094724A9 From: Jacques Vidrine In-reply-to: References: Subject: Re: compile error To: Jt Cc: freebsd-current@FreeBSD.ORG Date: Mon, 01 Jun 1998 10:26:13 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- There were changes to bsd.own.mk and possibly others that need to get into your system's /usr/share/mk before you can make ``make''. cd /usr/src/share/mk && make install will get them there for you. Jacques Vidrine On 1 June 1998 at 8:03, Jt wrote: > > Latest snap this morning broken? > > "/usr/src/share/mk/bsd.own.mk", line 125: Malformed conditional (${BINFORMAT} == > aout) > "/usr/src/share/mk/bsd.own.mk", line 125: Need an operator > "/usr/src/share/mk/bsd.own.mk", line 127: if-less else > "/usr/src/share/mk/bsd.own.mk", line 127: Need an operator > "/usr/src/share/mk/bsd.own.mk", line 129: if-less endif > "/usr/src/share/mk/bsd.own.mk", line 129: Need an operator make: fatal > errors encountered -- cannot continue > *** Error code 1 > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNXLIFTeRhT8JRySpAQGKHwQAoiQoIrnFFJ9A0k7/sFkNE1dW1LjHyo/B wK3iMmrmEBhqgSFj92y8OIwazjZYUi1auzlS36b5f5sNACbWxzMoBCUIMySR7/KU KNquNGoD+h0GGXZbnZSCL+Pzh6TyRdrOlSqg86nVeMjTv06d2f2JCogZlEUZMTPI 8ViOEYcHQms= =5Mep -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:35:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA26597 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:35:15 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA26590 for ; Mon, 1 Jun 1998 08:35:12 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id IAA21249; Mon, 1 Jun 1998 08:34:49 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Brian Feldman" cc: freebsd-current@FreeBSD.ORG Subject: Re: ppp cannot find libalias In-reply-to: Your message of "01 Jun 1998 14:09:35 -0000." <19980601140935.20189.qmail@m2.findmail.com> Date: Mon, 01 Jun 1998 08:34:49 -0700 Message-ID: <21245.896715289@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So fix it, I don't see what the problem is here? Ahem... 1. You don't get to be an old curmudgeon in this channel until you've paid your dues, OK? No problem, just don't let it happen again. :-) 2. The report helped me to formulate a fix which I've already posted to this list, so it *was* useful to have someone point it out. :-P - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:38:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27537 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:38:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27511 for ; Mon, 1 Jun 1998 08:38:37 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id LAA20206; Mon, 1 Jun 1998 11:38:26 -0400 (EDT) Date: Mon, 1 Jun 1998 11:38:26 -0400 (EDT) From: Snob Art Genre Reply-To: ben@rosengart.com To: Terry Lambert cc: Richard Wackerbarth , current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object In-Reply-To: <199805312213.PAA16988@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 May 1998, Terry Lambert wrote: > FreeBSD still has some of this; and yes, they fail on some systems > where the I/O space is cached. Linux has "fixed" these by doing > a write as well as a read, which results in a cache flush, and > yes, FreeBSD still has some bugs in this area, especially inre. > keyboards and LEDs. This must be why I can never get xload -lights to work. Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:42:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA28429 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:42:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA28360 for ; Mon, 1 Jun 1998 08:42:09 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id IAA21347; Mon, 1 Jun 1998 08:41:46 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Brian Feldman" cc: freebsd-current@FreeBSD.ORG Subject: Re: Undefined symbols referenced In-reply-to: Your message of "01 Jun 1998 14:03:25 -0000." <19980601140325.19702.qmail@m2.findmail.com> Date: Mon, 01 Jun 1998 08:41:46 -0700 Message-ID: <21343.896715706@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > For all you GIMP users: > export CVSROOT=':pserver:anonymous@cvs.gimp.org:/debian/home/gnomecvs' > mkdir CVSROOT;cd CVSROOT > cvs login && cvs -z9 co gtk+ gimp > for dir in gtk+ gimp; do cd $dir; ./autogen.sh; gmake all install clean; cd . .; done > Is that really too hard, rather than using the goddamned port?! Not hard, just not a functional substitute: [do anoncvs stuff to get gtk+ and gimp, which works fine] jkh@time-> cd .. jkh@time-> for dir in gtk+ gimp; do cd $dir; ./autogen.sh; gmake all install clean; cd ..; > done You must have libtool installed to compile GTK+. Get ftp://alpha.gnu.org/gnu/libtool-1.0h.tar.gz (or a newer version if it is available) You must have automake installed to compile GTK+. Get ftp://ftp.cygnus.com/pub/home/tromey/automake-1.2d.tar.gz (or a newer version if it is available) gmake: *** No rule to make target `all'. Stop. You must have libtool installed to compile GIMP. Get ftp://ftp.gnu.org/pub/gnu/libtool-1.2.tar.gz (or a newer version if it is available) ... The DEPENDENCIES like this are specifically what the ports collection is good at dealing with so that things work consistently for most users and not just they folks who've already installed libtook and/or automake and simply forgotten that fact. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:47:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA29426 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:47:01 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles228.castles.com [208.214.165.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA29419 for ; Mon, 1 Jun 1998 08:46:56 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id HAA17730; Mon, 1 Jun 1998 07:41:34 -0700 (PDT) Message-Id: <199806011441.HAA17730@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Mike Smith , Brandon Lockhart , current@FreeBSD.ORG Subject: Re: Big problems. In-reply-to: Your message of "Mon, 01 Jun 1998 03:09:51 PDT." <18795.896695791@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 07:41:34 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Buy a UPS. > > Wouldn't help him in this case anyway. he's just rebooting for the > first time in awhile and just noticed what anyone who's been reading > the -current mailing list for awhile already knows: the libs have > moved from /usr/lib to /usr/lib/aout. :) Ok, so "Buy a UPS and read the -current lists". Wash behind your ears. Eat your greens. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:51:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA00430 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:51:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mexcom.net (ver1-10.uninet.net.mx [200.38.135.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA00410 for ; Mon, 1 Jun 1998 08:51:14 -0700 (PDT) (envelope-from eculp@ver1.telmex.net.mx) Received: from sunix (telmex@sunix.mexcom.net [206.103.64.3]) by ns.mexcom.net (8.8.8/8.8.7) with SMTP id KAA04951; Mon, 1 Jun 1998 10:47:21 -0500 (CDT) Message-ID: <3572C124.1B413322@ver1.telmex.net.mx> Date: Mon, 01 Jun 1998 09:56:36 -0500 From: Edwin Culp Organization: Mexico Communicates, S.C. X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.14 i586) MIME-Version: 1.0 To: Brian Feldman CC: freebsd-current@FreeBSD.ORG Subject: Re: Undefined symbols referenced References: <19980601140325.19702.qmail@m2.findmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Feldman wrote: > > For all you GIMP users: > export CVSROOT=':pserver:anonymous@cvs.gimp.org:/debian/home/gnomecvs' > mkdir CVSROOT;cd CVSROOT > cvs login && cvs -z9 co gtk+ gimp > for dir in gtk+ gimp; do cd $dir; ./autogen.sh; gmake all install clean; cd ..; done > Is that really too hard, rather than using the goddamned port?! > > Brian Feldman > Thanks, its much better. I'll give it a try now. ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 08:54:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01136 for freebsd-current-outgoing; Mon, 1 Jun 1998 08:54:48 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles228.castles.com [208.214.165.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01131 for ; Mon, 1 Jun 1998 08:54:45 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id HAA17783; Mon, 1 Jun 1998 07:50:13 -0700 (PDT) Message-Id: <199806011450.HAA17783@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: ben@stuyts.nl, current@FreeBSD.ORG, brian@awfulhak.org Subject: Re: ppp cannot find libalias In-reply-to: Your message of "Mon, 01 Jun 1998 07:23:39 PDT." <20865.896711019@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 07:50:12 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > /usr/lib, as they are now in /usr/lib/aout. The new ppp does not look in the > > correct place for libalias yet. It still looks in /usr/lib: > > Hmmm. What do you guys think of this? The ELF path may be wrong > since I'm not sure if my understanding of how ELF names its shared > libs is entirely sound, but that's easily fixed if so. This is the wrong place to do it. dlopen() should honour the standard library path for the format of the executable calling it. I proposed an appropriate change for the a.out runtime linker; I presume something very similar applies to the ELF linker (but I don't have sources here to verify). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 09:04:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA02457 for freebsd-current-outgoing; Mon, 1 Jun 1998 09:04:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA02446 for ; Mon, 1 Jun 1998 09:04:16 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id JAA22320; Mon, 1 Jun 1998 09:03:16 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Mike Smith cc: ben@stuyts.nl, current@FreeBSD.ORG, brian@awfulhak.org Subject: Re: ppp cannot find libalias In-reply-to: Your message of "Mon, 01 Jun 1998 07:50:12 PDT." <199806011450.HAA17783@antipodes.cdrom.com> Date: Mon, 01 Jun 1998 09:03:16 -0700 Message-ID: <22316.896716996@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is the wrong place to do it. dlopen() should honour the standard > library path for the format of the executable calling it. I proposed an So you're basically saying we should search through the hint cache or, if set, the LD_LIBRARY_PATH instead. Well fine. I had one idea for fixing it and I sent in my diffs. You then shot down my idea with a better one and ... - please complete the sentence. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 09:17:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04925 for freebsd-current-outgoing; Mon, 1 Jun 1998 09:17:54 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles228.castles.com [208.214.165.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04918 for ; Mon, 1 Jun 1998 09:17:50 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id IAA17888; Mon, 1 Jun 1998 08:13:18 -0700 (PDT) Message-Id: <199806011513.IAA17888@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joerg Schilling cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Mon, 01 Jun 1998 14:15:43 +0200." <199806011215.OAA16994@sherwood.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 01 Jun 1998 08:13:18 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id JAA04920 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >From mike@dingo.cdrom.com Fri May 29 22:41:20 1998 > > >It's due to not checking the return value from the sysconf(_SC_PAGESIZE) > >in fifo.c. Once you get past that, there's a timing failure between the > >writer and reader processes due to a similar omission a little further > >down the file. > > >Having dealt with these, I seem to be dummy-burning quite happily. = > >I'll cut a disc for real to be sure, and then send you my patches for = > >discussion. > > This seems to be the real problem with freebsd-current. There do not seem to be any other operational problems, no. The weekend intervened before I could complete checking against your error handling suggestions; I'll finish that this morning. > You cannot deal with this problem: > > Systems that define _SC_PAGESIZE or _SC_PAGE_SIZE (HP-UX) > don't support getpagesize() so there is no way to fix this > in runtime except if you introduce an additional > > HAVE_GETPAGESIZE > > in the autoconfiguration. > > But even then the code would be badly readable. This is a problem with the design of cdrecord, insofar as it's fairly clear it wasn't designed for portability. Probably the most expedient move would be not to pretend that cdrecord is compliant with the default POSIX API on FreeBSD for now, and wind back the presented API to one that it is. That's what _POSIX_VERSION is all about. Thanks for the HP-UX pointer; I'll take note that _SC_PAGESIZE is implicitly assumed to mean DONT_HAVE_GETPAGESIZE. > I would prefer if the sysconf code would call getpagesize() in userland. This would defeat the entire purpose of sysconf(), which is to pass opaque constants to the kernel. I don't see any merit in hacking a perfectly compliant interface to deal with (pardon my saying it) buggy applications. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 09:26:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06462 for freebsd-current-outgoing; Mon, 1 Jun 1998 09:26:53 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06442 for ; Mon, 1 Jun 1998 09:26:46 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id MAA22057; Mon, 1 Jun 1998 12:26:41 -0400 (EDT) (envelope-from wollman) Date: Mon, 1 Jun 1998 12:26:41 -0400 (EDT) From: Garrett Wollman Message-Id: <199806011626.MAA22057@khavrinen.lcs.mit.edu> To: dg@root.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: mbuf cluster problem continues!! In-Reply-To: <199806010520.WAA09567@implode.root.com> References: <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess> <199806010520.WAA09567@implode.root.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > I've seen several reports of mbuf leaks in the specific case of running > squid proxy servers. Not seen here. root@xyz(4)$ netstat -m 825/1408 mbufs in use: 531 mbufs allocated to data 17 mbufs allocated to packet headers 277 mbufs allocated to routing table entries 91/426 mbuf clusters in use 1028 Kbytes allocated to network (27% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Of course, it's not really working that hard. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 09:31:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07189 for freebsd-current-outgoing; Mon, 1 Jun 1998 09:31:03 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07175 for ; Mon, 1 Jun 1998 09:30:56 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id SAA27122; Mon, 1 Jun 1998 18:30:39 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id SAA17075; Mon, 1 Jun 1998 18:30:15 +0200 (MET DST) Date: Mon, 1 Jun 1998 18:30:15 +0200 (MET DST) From: Joerg Schilling Message-Id: <199806011630.SAA17075@sherwood.gmd.de> To: mike@smith.net.au, schilling@fokus.gmd.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From mike@antipodes.cdrom.com Mon Jun 1 18:17:40 1998 >> You cannot deal with this problem: >> = >> Systems that define _SC_PAGESIZE or _SC_PAGE_SIZE (HP-UX) >> don't support getpagesize() so there is no way to fix this >> in runtime except if you introduce an additional = >> = >> HAVE_GETPAGESIZE >> = >> in the autoconfiguration. >> = >> But even then the code would be badly readable. = >This is a problem with the design of cdrecord, insofar as it's fairly Sorry, this is a problem for evryone who wants to write portable code. But FreeBSD seems to ignore this issue. You may have a functional sysconf(_SC_PAGESIZE) _and_ getpagesize() if you like to be able to run portable applications but you cannot have a non functional sysconf(_SC_PAGESIZE). This looks to me like Microsofts tried to create a Posix environment that is Posix compliant on the paper but would prevent you from running real world Posix applications on it. >clear it wasn't designed for portability. Probably the most expedient >move would be not to pretend that cdrecord is compliant with the default >POSIX API on FreeBSD for now, and wind back the presented API to one >that it is. That's what _POSIX_VERSION is all about. Right, when I started to write cdrecord, I thought that it would only run on SunOS 4.x and SunOS 5.x but now it is one of the most portable application that I made. >Thanks for the HP-UX pointer; I'll take note that _SC_PAGESIZE is = >implicitly assumed to mean DONT_HAVE_GETPAGESIZE. >> I would prefer if the sysconf code would call getpagesize() in userland= >=2E >This would defeat the entire purpose of sysconf(), which is to pass = >opaque constants to the kernel. I don't see any merit in hacking a = You should read the Posix standard: The POSIX standard does not describe the behaviour of a kernel interface but the interface of callbable functions in the c-library. >perfectly compliant interface to deal with (pardon my saying it) buggy = >applications. I would call a sysconf implementation that is not functional for sysconf(_SC_PAGESIZE) although getpagesize() exists buggy. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 09:34:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07925 for freebsd-current-outgoing; Mon, 1 Jun 1998 09:34:33 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles228.castles.com [208.214.165.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07920 for ; Mon, 1 Jun 1998 09:34:30 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id IAA17978; Mon, 1 Jun 1998 08:30:00 -0700 (PDT) Message-Id: <199806011530.IAA17978@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joerg Schilling cc: dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Mon, 01 Jun 1998 14:01:35 +0200." <199806011201.OAA16937@sherwood.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 01 Jun 1998 08:30:00 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id JAA07921 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >Only if you promise not to give me trouble about errx - as a FreeBSD > >utility their coding standard says to use that, and when > >in Rome do as the Romans do. > > To make it portable, I'll need to replace them with my routines > comerr() comerrno() errmsg() and errmsgno() wich I am using since 1982 - > long before BSD intruduced things like that. > > I have no problems with these functions as I believe that it neccessary to > have readable error messages and perror() don't makes good error messages. Great. Replace a set of standard error reporting functions with older, nonstandard ones. 8) This really sinks most of the rest of your argument, unfortunately. > I believe the suing with AT&T has been won and there is no need to make > programs look like they are not from a UNIX system. Bear in mind that BSD is half of the Unix family tree. The BSD libc API is at least as valid as any other. The err() family of functions are mainstream from 4.4BSD, so they are shared with all the current BSD family. There are some legitimate candidates for this complaint, eg. the stringlist functions, yes. > Please: > > - Put all non standard library extensions into a separate > libbsd and make this library portable. > ( you may add this library to the default library list of the > compiler on *BSD so there will be no need to change makefiles) What you are suggesting you want here is a portable "libbsd". This will need more than just "non-standard" library extensions, as the alternative would be to put almost all of the BSD library in here. Rather, what needs to be done is for someone that wants to port BSD programs to other platforms to take the BSD libc and extract all those components which are a superset of the desired target platform(s) APIs and build a libbsd suited to each of the deficient targets. There is not likely to be much support for political emasculation of the BSD API. > - Make sure that programs don't rely on nonstandard modifications > of historical UNIX include files if there is a reason to compile > and run these programs on a non *BSD system ( e.g. it is a non > BSD kernel specific program). > > - Write man pages that use the stanmdard UNIX -man macros and not > non-standard modifications. Again, these would be fine if the BSD environment was somehow "non-standard". > P.S. > I believe that the real problem might be that your program comes with a BSD > license while my software comes with GPL. This is never a problem; BSD code can always be incorporated into a GPL product without having any significant impact on the GPL. The reverse is, regrettably, not the case. > In any case, it seems to be a good idea to have a combination of a > command line interpreter which allows easy sending of arbitrary commands > and a portable SCSI transport library. No kidding. This would be a very useful tool, especially if it were basically a library which could be linked with either a simple line-reading frontend or an application program... -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 09:55:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11199 for freebsd-current-outgoing; Mon, 1 Jun 1998 09:55:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11193 for ; Mon, 1 Jun 1998 09:55:46 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id LAA13043 for current@freebsd.org; Mon, 1 Jun 1998 11:55:45 -0500 (CDT) From: Kevin Day Message-Id: <199806011655.LAA13043@home.dragondata.com> Subject: NFS discovery To: current@FreeBSD.ORG Date: Mon, 1 Jun 1998 11:55:45 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's my setup: 2.2.6 NFS server with /home exported -current NFS client mounting server:/home under /home If the server gets rebooted or their link is temporarily severed, the client never recovers. Any attempt to read anything from /home causes the process to get wedged pretty nicely. (even kill -9 won't kill it) However entering this on the client machine mount -u -o async /home *while* the client's nfs is hosed will make it recover within 5 seconds. It even appears that all the writes that were queued are executed, and no data is lost. Is there any way of making whatever it was that did this happen automatically every once in a while? :) Does specificing async on an nfs mount even do anything? Also.... Unrelated, but still with NFS... Some of my customers are complaining that their log files are getting other users's deleted files mixed in with theirs. (all of this is over nfs). Any idea how? Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 10:21:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15853 for freebsd-current-outgoing; Mon, 1 Jun 1998 10:21:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pobox.com ([208.141.230.79]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15819; Mon, 1 Jun 1998 10:21:41 -0700 (PDT) (envelope-from alk@pobox.com) Received: (from alk@localhost) by pobox.com (8.8.8/8.7.3) id MAA14047; Mon, 1 Jun 1998 12:22:35 -0500 (CDT) Date: Mon, 1 Jun 1998 12:22:35 -0500 (CDT) Message-Id: <199806011722.MAA14047@pobox.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Reply-To: alk@pobox.com To: chat@FreeBSD.ORG CC: eivind@yes.no Subject: Re: TenDRA/XANDF to the rescue? (Re: Fix for undefined...) X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ redirected to chat ] Quoth Eivind Eklund : > java byte code can't express e.g. C. This also answer the rest of > your post (which I've deleted). Bzzt. C can compile to JVM perfectly correctly, thank you. The JVM is not well adapted to this purpose, and constructing a back-end which produced efficient code from JBC which expresses typical C pointer arithematic &c would be a very challenging task. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 10:30:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17843 for freebsd-current-outgoing; Mon, 1 Jun 1998 10:30:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17836 for ; Mon, 1 Jun 1998 10:30:38 -0700 (PDT) (envelope-from jmacd@paris.CS.Berkeley.EDU) Received: (from jmacd@localhost) by paris.CS.Berkeley.EDU (8.8.3/8.8.2) id KAA01123; Mon, 1 Jun 1998 10:29:51 -0700 (PDT) Message-ID: <19980601102950.15326@paris.CS.Berkeley.EDU> Date: Mon, 1 Jun 1998 10:29:50 -0700 From: Josh MacDonald To: Paul van der Zwan Cc: current@FreeBSD.ORG Subject: Re: Undefined symbols referenced References: <19980531103654.23417@paris.CS.Berkeley.EDU> <199805312224.AAA29878@trantor.stuyts.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <199805312224.AAA29878@trantor.stuyts.nl>; from Paul van der Zwan on Mon, Jun 01, 1998 at 12:24:51AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't know what your problem is. I don't have a current system to test this on. The errors indicate that xdelta can't find its read() and write() system calls, this should not happen! Jonathan Bresler has replied explaining what the possible sources of this are, and it is almost surely related to the recent changes to accomdate weak symbols and libc_r. I am unable to defend myself here without a system to test on, can someone current please help? -josh Quoting Paul van der Zwan (paulz@trantor.stuyts.nl): > > Quoting Paul van der Zwan (paulz@trantor.stuyts.nl): > > > I had the same problem a week or so ago. The xdelta port will not build on > > > current ( cvsupped and make world this weekend) even rebuilding the gdbm port > > > and reinstalling that does not work. > > > Gimp will now build because the maintainer removed the dependency on xdelta > > > but the xdelta port looks broken on current. > > > > I would say that current looks broken on xdelta. More specifically, your > > current looks broken. I don't appreciate hearing this type of report, which > > indicates the xdelta is to blame. I've gotten at least 10 of these reports. > > I don't like to hear that xdelta has been removed from GIMP either. People > > with these problems should not be running -current. > > > > -josh > > What kind of problems ?? I don't like blaming something/one for my problems, > but in this case in am just reporting a problem and in my opinion if there is > a port does not build on current, it's the port and not currrent that is broken > esp. if other ports stil build fine. > In this case it is the combination of current and the xdelta 0.18 > port that does not work.. I run current willingly and I know the problems > it can cause, but if I follow al the steps like compiling all ports another > port depends on, on an otherwise normal and up-to-date current, than that > port is broken ( for current). > Can you compile xdelta-0.18 on an up-to-date vanilla current with the system > cc ??? If so it means our systems are not entirely identical and the > difference might cause the port not to compile on my box. > If removing xdelta from the GIMP port causes GIMP to work fine , that's OK > with me, to be honest I have never noticed xdelta until it caused GMIP not to > build. > > Paul > > -- > Paul van der Zwan paulz @ trantor.stuyts.nl > "I think I'll move to theory, everything works in theory..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 10:44:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21117 for freebsd-current-outgoing; Mon, 1 Jun 1998 10:44:54 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21102 for ; Mon, 1 Jun 1998 10:44:45 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id TAA29000; Mon, 1 Jun 1998 19:44:24 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id TAA17106; Mon, 1 Jun 1998 19:44:00 +0200 (MET DST) Date: Mon, 1 Jun 1998 19:44:00 +0200 (MET DST) From: Joerg Schilling Message-Id: <199806011744.TAA17106@sherwood.gmd.de> To: mike@smith.net.au, schilling@fokus.gmd.de Cc: dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From mike@antipodes.cdrom.com Mon Jun 1 18:34:21 1998 >> >Only if you promise not to give me trouble about errx - as a FreeBSD >> >utility their coding standard says to use that, and when >> >in Rome do as the Romans do. >> = >> To make it portable, I'll need to replace them with my routines >> comerr() comerrno() errmsg() and errmsgno() wich I am using since 1982 = >- = >> long before BSD intruduced things like that. >> = >> I have no problems with these functions as I believe that it neccessary= > to = >> have readable error messages and perror() don't makes good error messag= >es. >Great. Replace a set of standard error reporting functions with older, = >nonstandard ones. 8) This really sinks most of the rest of your argument,= >unfortunately. You are right from the view of a *BSD user but from the view of a mainstream UNIX user the BSD functions are non standard too and in addition non portable. My functions are portable though. >> I believe the suing with AT&T has been won and there is no need to mak= >e >> programs look like they are not from a UNIX system. >Bear in mind that BSD is half of the Unix family tree. The BSD libc = >API is at least as valid as any other. The err() family of functions = >are mainstream from 4.4BSD, so they are shared with all the current BSD = >family. As long as err() is not portable, I prefer my functions which are even older then the *BSD ones. Around 1990 the number of pure BSD users did go dramatically down because many vendors switched over to SVr4. No commercial UNIX incorporated things from 4.4BSD (if I rememer correctly) in contrary to the former behaviour of these companies. I believe that > 80% of all UNIX users have no access to err(). So I cannot call 4.4BSD mainstream or half the UNIX tree. >> - Put all non standard library extensions into a separate >> libbsd and make this library portable. >> ( you may add this library to the default library list of the >> compiler on *BSD so there will be no need to change makefiles) >What you are suggesting you want here is a portable "libbsd". This = >will need more than just "non-standard" library extensions, as the = >alternative would be to put almost all of the BSD library in here. >Rather, what needs to be done is for someone that wants to port BSD = >programs to other platforms to take the BSD libc and extract all those = >components which are a superset of the desired target platform(s) APIs = >and build a libbsd suited to each of the deficient targets. >There is not likely to be much support for political emasculation of = >the BSD API. No doubt, there is a need for UNIX utilities with better error printing and standardized bahaviour and many ideas from 4.4 BSD are not bad, but they are not available outside *BSD. As one exaple, I now have my own termcap library that implements the exellent idea of the TERMPATH environment. The 4.4BSD version could not be used because it relies on the nonstandard BSD database system. OK, I already started my termcap library in 1986 so there was no need for the full effort of the complete implementation. BTW: I am using enhanced versions of tgoto() and tputs() because these functions are portable. I would not be able to log into diffrent UNIX systems if I would not use my own portable editor that uses native termcap. Terminfo is binary and non portable. If I log in and the local vi screws up my terminal I would be lost. Unfortunately nearly all UNIX systems screw up your terminal if you log in from a Sun. I hope you see, that I am sad to see that the BSD folks writes good software that cannot be shared without using the *BSD operating system. From my point of view this is not the right idea of free software. >> P.S. >> I believe that the real problem might be that your program comes with a= > BSD >> license while my software comes with GPL. >This is never a problem; BSD code can always be incorporated into a GPL = >product without having any significant impact on the GPL. The reverse = >is, regrettably, not the case. >> In any case, it seems to be a good idea to have a combination of a >> command line interpreter which allows easy sending of arbitrary command= >s >> and a portable SCSI transport library. >No kidding. This would be a very useful tool, especially if it were = >basically a library which could be linked with either a simple = >line-reading frontend or an application program... For disk formatting / analyze or repair, I would suggest my 'sformat' program. I wrote it starting from 1986 and SunOS 3.0. It was even the first SCSI disk formatting program that runs on SunOS (before Sun introduced their format program) before standalone programs have been used. I just finished 99% of the new version 3.4. It incorporates most of the portability know how from the actual cdrecord and it has much special knowledge how to handle disks. For other applications, I find a SCSI command line interpreter very useful for all operating systems. So please tell me whether you so called scsinew is the actual /sbin/scsi I found on the FreeBSD ftp server. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 10:51:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22476 for freebsd-current-outgoing; Mon, 1 Jun 1998 10:51:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from www.video-collage.com (www.video-collage.com [206.15.171.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA22454 for ; Mon, 1 Jun 1998 10:51:18 -0700 (PDT) (envelope-from mi@xxx.video-collage.com) Received: from xxx.video-collage.com (xxx.video-collage.com [199.232.254.68]) by www.video-collage.com (8.8.5/8.8.5) with ESMTP id NAA09083 for ; Mon, 1 Jun 1998 13:49:52 -0400 (EDT) Received: (from mi@localhost) by xxx.video-collage.com (8.8.8/8.8.7) id NAA29921 for current@freebsd.org; Mon, 1 Jun 1998 13:51:03 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <199806011751.NAA29921@xxx.video-collage.com> Subject: Re: NFS discovery In-Reply-To: <199806011655.LAA13043@home.dragondata.com> from Kevin Day at "Jun 1, 98 11:55:45 am" To: current@FreeBSD.ORG Date: Mon, 1 Jun 1998 13:51:03 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27181 for freebsd-current-outgoing; Mon, 1 Jun 1998 11:12:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27147 for ; Mon, 1 Jun 1998 11:12:00 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id OAA22409; Mon, 1 Jun 1998 14:11:48 -0400 (EDT) (envelope-from wollman) Date: Mon, 1 Jun 1998 14:11:48 -0400 (EDT) From: Garrett Wollman Message-Id: <199806011811.OAA22409@khavrinen.lcs.mit.edu> To: Mike Smith Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-Reply-To: <199806011513.IAA17888@antipodes.cdrom.com> References: <199806011215.OAA16994@sherwood.gmd.de> <199806011513.IAA17888@antipodes.cdrom.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > This would defeat the entire purpose of sysconf(), which is to pass > opaque constants to the kernel. Bullshit. Go look at the code before making pronouncements from on high. In particular, note the code which quite clearly states: case _SC_CHILD_MAX: return (getrlimit(RLIMIT_NPROC, &rl) ? -1 : rl.rlim_cur); case _SC_CLK_TCK: return (CLK_TCK); There is no earthly reason why a: case _SC_PAGESIZE: return (getpagesize()); ...cannot be added to this same switch statement. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 11:29:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29596 for freebsd-current-outgoing; Mon, 1 Jun 1998 11:29:31 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29588 for ; Mon, 1 Jun 1998 11:29:28 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id NAA20244; Mon, 1 Jun 1998 13:29:24 -0500 (CDT) From: Kevin Day Message-Id: <199806011829.NAA20244@home.dragondata.com> Subject: Re: NFS discovery In-Reply-To: <199806011751.NAA29921@xxx.video-collage.com> from Mikhail Teterin at "Jun 1, 98 01:51:03 pm" To: mi@video-collage.com (Mikhail Teterin) Date: Mon, 1 Jun 1998 13:29:24 -0500 (CDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Kevin Day once stated: > > =However entering this on the client machine > = > =mount -u -o async /home > = > =*while* the client's nfs is hosed will make it recover within 5 > =seconds. It even appears that all the writes that were queued are > =executed, and no data is lost. > > That's a great thing to know. Those hungups are damn annoying. > The reason is, probably, a side effect of how `-u'/`async' are > implemented. AFAIK, the fs is unmounted and then remounted with > async. Which is just what you wanted. That's my thought too, but: umount /home will freeze, so it's not exactly unmounting things. :) > > =Is there any way of making whatever it was that did this happen > =automatically every once in a while? :) > > NFS hung ups are a strange topic, in my experience. People agree > that they are "bad", but one is not supposed to complain about > them... Don't read my post as a complaint, rather as a 'hey, why does it do this?" :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 11:30:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29861 for freebsd-current-outgoing; Mon, 1 Jun 1998 11:30:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29849 for ; Mon, 1 Jun 1998 11:30:45 -0700 (PDT) (envelope-from benst@terminus.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <7078-9473>; Mon, 1 Jun 1998 20:30:26 +0200 Received: from daneel.stuyts.nl (daneel.stuyts.nl [193.78.231.7]) by terminus.stuyts.nl (8.8.8/8.8.8) with ESMTP id UAA08884; Mon, 1 Jun 1998 20:25:57 +0200 (MET DST) (envelope-from benst) Received: (from benst@localhost) by daneel.stuyts.nl (8.8.5/8.8.5) id UAA10399; Mon, 1 Jun 1998 20:25:51 +0200 (MET DST) Message-Id: <199806011825.UAA10399@daneel.stuyts.nl> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <19980601140935.20189.qmail@m2.findmail.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2) Received: by NeXT.Mailer (1.118.2) From: Ben Stuyts Date: Mon, 1 Jun 98 20:25:49 +0200 To: "Brian Feldman" Subject: Re: ppp cannot find libalias cc: freebsd-current@FreeBSD.ORG Reply-To: ben@stuyts.nl References: <19980601140935.20189.qmail@m2.findmail.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1 Jun 1998, "Brian Feldman" wrote: > So fix it, I don't see what the problem is here? I wrote: > > This is on -current, cvsupped on May 30. I just removed every old library > > in /usr/lib, as they are now in /usr/lib/aout. The new ppp does not look in > > the correct place for libalias yet. It still looks in /usr/lib: > > ... > > > > loadalias.c:#define _PATH_ALIAS_PREFIX "/usr/lib/libalias.so.2." The problem is: You want me to report these things or not? I already have put a /aout in there, but that won't do any good as soon as things move over to /usr/lib/elf. Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 11:40:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01873 for freebsd-current-outgoing; Mon, 1 Jun 1998 11:40:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01867 for ; Mon, 1 Jun 1998 11:40:56 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id CAA10468; Tue, 2 Jun 1998 02:40:32 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806011840.CAA10468@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Kevin Day Cc: current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 11:55:45 EST." <199806011655.LAA13043@home.dragondata.com> Date: Tue, 02 Jun 1998 02:40:31 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day wrote: > > Here's my setup: > > > 2.2.6 NFS server with /home exported > -current NFS client mounting server:/home under /home > > If the server gets rebooted or their link is temporarily severed, the client > never recovers. Any attempt to read anything from /home causes the process > to get wedged pretty nicely. (even kill -9 won't kill it) What's the wait channel that the client processes hang in BTW? 'ps -axlww' and look for the hung process. > However entering this on the client machine > > mount -u -o async /home > > *while* the client's nfs is hosed will make it recover within 5 seconds. It > even appears that all the writes that were queued are executed, and no data > is lost. > > Is there any way of making whatever it was that did this happen > automatically every once in a while? :) > > Does specificing async on an nfs mount even do anything? It only specifies the commit level of writes. An async nfs mount will tell the server not to bother to sync write data to disk before returning the rpc call. What age -current kernel sources are we talking about BTW? This kind of information is going to be pretty important from now on. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:04:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05001 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:04:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04978 for ; Mon, 1 Jun 1998 12:04:45 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA04839; Mon, 1 Jun 1998 19:04:37 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA04957; Mon, 1 Jun 1998 21:04:15 +0200 (MET DST) Message-ID: <19980601210415.48779@follo.net> Date: Mon, 1 Jun 1998 21:04:15 +0200 From: Eivind Eklund To: Richard Wackerbarth Cc: current@FreeBSD.ORG Subject: Re: How about /usr/ports/kernel ? References: ; ; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <19980531052120.41610@follo.net> <19980531235232.04296@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Richard Wackerbarth on Mon, Jun 01, 1998 at 06:31:33AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 01, 1998 at 06:31:33AM -0500, Richard Wackerbarth wrote: > At 9:52 PM -0000 5/31/98, Eivind Eklund wrote: > >However, to be able to do automated kernel builds we have to have a > >way of specifying which kernels to build which do not come as a shock > >to our userbase (this is a political necessity; I don't think either > >of us would get any way arguing otherwise). This probably mean that > >we'll have to support the use of config(8) in the way it is presently > >used for a transition period of at least a year. > > Not necessarily. Consider the following strategy: > (1) Replace "config" with a shell script that > (a) copies the configuration file to .../src/sys/compile hierarchy > (b) issues a message reminding the user that the procedure for > building a kernel has been slightly modified, and perhaps > (c) does a "make" in the newly constructed target area. > (2) (To avoid confusion) Rename the present "config" and modify > it to be a tool for the new structure. It would fit in, in a > manner similar to yacc, to be called where needed. This blows my present cross-builds (to 2.2) away, at least. Not good, as that probably means that it blows other people's builds, too. I proposed something similar to this as a solution for mknod - jkh shot me down (and with good reason, I might add). We need something that don't blow away our users - which I believe unfortunately mean we'll need to build compatibility into config for a while :-( > As far as "automatic kernel build" is concerned, I think that this can > be handled by having an optional Makefile.inc in the src/sys structure > that adds SUBDIR's for the desired kernels. > We could always use "SUBDIR?= GENERIC" to provide the default. This doesn't mesh with the use of 'SUBDIR' presently. Possibly we could add a 'beforesubdir' target that are responsible for making sure there are a subdir in either ${.OJDIR} or ${.CURDIR}, but I'm not certain how easy this will be. Something like the patches at the end _might_ work (but is completely untested). Now, to be able to do this with config files located other places that sys//conf, we need to be able to specify different paths for the kernel config, and for the destination directory. Patches to usr.sbin/config is at the end (compiles, but otherwise untested). This leaves us with a fairly simple sys/compile/Makefile, something like the following (again, completely untested): # Copyright (C) 1998, Eivind Eklund. All rights reserved. # You're hereby granted the right to do anything with this, as long as # you don't attempt to hold me responsible for it. .if exists(${.CURDIR}/../Makefile.inc) .include "${.CURDIR}/../Makefile.inc" .endif # Uncomment this to make the system default to building GENERIC #SUBDIR?=GENERIC beforesubdir: realbeforesubdir .include realbeforesubdir: @for entry in ${SUBDIR} ${_SUBDIR_EXTRA}; do \ (if ! (test -f ${SUBDIR_CHANGE}/${DIRPRFX}/subdirdrop && \ grep -w $${entry} \ ${SUBDIR_CHANGE}/${DIRPRFX}/subdirdrop \ > /dev/null); then \ (cd ${.CURDIR}/../$$(awk \ '/^machine/ {print ($2 ~ /^\".*\"$/) ? substr($2, 2, length($2)-2) : \ $2}' ${.CURDIR}/configs/$${entry})/conf && \ config -f ${.CURDIR}/configs/$${entry} \ -o ${.OBJDIR} $${entry}); \ fi); \ done; How does the above look? The extra interpretation of subdirdrop is dirty, as is the need for having targets after the include - the former I think can be fixed, the latter probably be very, very difficult (unless I'm misrememebering the order of evaluation in make - then it can just be moved :-) > >Do you disagree with the way of adding this meta-information to > >contributed subsystems? I'm all ears for anything better that give > >the same capabilites for external people modifying the system - I just > >haven't found any better way. > > As I have previously stated, I view the kernel in the same way that > I view a user-level command. It may require a few unique variants. > However, it is fundamentally, source (compiled) into object (linked) > into executable (loaded) for execution > > I see the inclusion of kernel components fitting in in a manner analogous > to the "contrib" structure. Can you give a _concrete_ proposal for how to solve this, presently for the kernel only? We need the capabilities outlined, and we've needed them for a while. I hope to avoid the use of a temporary measure here, so if you've got any ideas we can use to solve this to be compatible with a future generic way... > Summary: > Think "Lego", or, for those old enough to remember, the A.C. Gilbert > "Erector" sets rather than "Microsoft". However, _also_ think efficiency. These are often somewhat at odds. Eivind. Index: share/mk/bsd.subdir.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.subdir.mk,v retrieving revision 1.24 diff -u -r1.24 bsd.subdir.mk --- bsd.subdir.mk 1998/05/06 16:53:53 1.24 +++ bsd.subdir.mk 1998/06/01 18:42:31 @@ -39,18 +39,22 @@ .MAIN: all -.if defined(SUBDIR_CHANGE) && !empty(SUBDIR_CHANGE) && \ - exists(${SUBDIR_CHANGE}/${DIRPRFX}/subdirlist) +.if defined(SUBDIR_CHANGE) && !empty(SUBDIR_CHANGE) +.if exists(${SUBDIR_CHANGE}/${DIRPRFX}/subdirlist) SUBDIR!=cat ${SUBDIR_CHANGE}/${DIRPRFX}/subdirlist .endif -.if defined(SUBDIR_CHANGE) && !empty(SUBDIR_CHANGE) && \ - exists(${SUBDIR_CHANGE}/${DIRPRFX}/subdirlist) +.if exists(${SUBDIR_CHANGE}/${DIRPRFX}/subdirlist) _SUBDIR_EXTRA!=cat ${SUBDIR_CHANGE}/${DIRPRFX}/subdiradd +SUBDIR=${SUBDIR} ${_SUBDIR_EXTRA} .endif +# Should really fix up SUBDIR to respect "subdirdrop" here, instead of +# requiring it in the loops +.endif + _SUBDIRUSE: .USE - @for entry in ${SUBDIR} ${_SUBDIR_EXTRA}; do \ + @for entry in ${SUBDIR}; do \ (if ! (test -f ${SUBDIR_CHANGE}/${DIRPRFX}/subdirdrop && \ grep -w $${entry} \ ${SUBDIR_CHANGE}/${DIRPRFX}/subdirdrop \ @@ -60,10 +64,19 @@ "===> ${DIRPRFX}$${entry}.${MACHINE}"; \ edir=$${entry}.${MACHINE}; \ cd ${.CURDIR}/$${edir}; \ - else \ + elif test -d ${.OBJDIR}/$${entry}.${MACHINE}; then \ + ${ECHODIR} \ + "===> ${DIRPRFX}$${entry}.${MACHINE}"; \ + edir=$${entry}.${MACHINE}; \ + cd ${.OBJDIR}/$${edir}; \ + elif test -d ${.CURDIR}/$${entry}; then \ ${ECHODIR} "===> ${DIRPRFX}$$entry"; \ edir=$${entry}; \ cd ${.CURDIR}/$${edir}; \ + elif \ + ${ECHODIR} "===> ${DIRPRFX}$$entry"; \ + edir=$${entry}; \ + cd ${.OBJDIR}/$${edir}; \ fi; \ ${MAKE} ${.TARGET:realinstall=install} \ SUBDIR_CHANGE=${SUBDIR_CHANGE} \ @@ -72,7 +85,7 @@ ); \ done -${SUBDIR}:: +${SUBDIR}:: beforesubdir @if test -d ${.TARGET}.${MACHINE}; then \ cd ${.CURDIR}/${.TARGET}.${MACHINE}; \ else \ @@ -84,9 +97,13 @@ .for __target in all checkdpadd clean cleandepend cleandir depend lint \ maninstall obj objlink regress tags .if !target(${__target}) -${__target}: _SUBDIRUSE +${__target}: beforesubdir .WAIT _SUBDIRUSE .endif .endfor + +.if !target(beforesubdir) +beforesubdir: +.endif .if !target(install) .if !target(beforeinstall) Index: usr.sbin/config/config.8 =================================================================== RCS file: /home/ncvs/src/usr.sbin/config/config.8,v retrieving revision 1.10 diff -u -r1.10 config.8 --- config.8 1998/02/18 04:15:03 1.10 +++ config.8 1998/06/01 18:57:31 @@ -40,6 +40,8 @@ .Sh SYNOPSIS .Nm config .Op Fl gpr +.Op Fl f Ar configfile +.Op Fl o Ar directory .Ar SYSTEM_NAME .Sh DESCRIPTION This is the old version of the @@ -72,8 +74,12 @@ Available options and operands: .Pp .Bl -tag -width SYSTEM_NAME +.It Fl f Ar configfile +Use this file as the input filename, instead of ./SYSTEM_NAME .It Fl g Configure a system for debugging. +.It Fl o Ar directory +Use this file as the target directory, instead of ../../compile. .It Fl p Configure a system for profiling; for example, .Xr kgmon 8 Index: usr.sbin/config/main.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/config/main.c,v retrieving revision 1.24 diff -u -r1.24 main.c --- main.c 1998/05/02 01:57:38 1.24 +++ main.c 1998/06/01 18:55:06 @@ -66,6 +66,7 @@ #endif char *PREFIX; +static char *CDIR = "../../compile/"; static int no_config_clobber = TRUE; int old_config_present; @@ -85,12 +86,20 @@ struct stat buf; int ch; char *p; + char *configfn = NULL; /* filename */ + extern char *optarg; - while ((ch = getopt(argc, argv, "gprn")) != -1) + while ((ch = getopt(argc, argv, "f:go:prn")) != -1) switch (ch) { + case 'f': + configfn = optarg; + break; case 'g': debugging++; break; + case 'o': + CDIR = optarg; + break; case 'p': profiling++; break; @@ -112,8 +121,11 @@ if (argc != 1) usage(); - if (freopen(PREFIX = *argv, "r", stdin) == NULL) - err(2, "%s", PREFIX); + PREFIX = *argv; + if (configfn == NULL) + configfn = PREFIX; + if (freopen(configfn, "r", stdin) == NULL) + err(2, "%s", configfn); p = path((char *)NULL); if (stat(p, &buf)) { @@ -327,9 +339,8 @@ { register char *cp; -#define CDIR "../../compile/" - cp = malloc((unsigned int)(sizeof(CDIR) + strlen(PREFIX) + - (file ? strlen(file) : 0) + 2)); + cp = malloc((unsigned int)(strlen(CDIR) + strlen(PREFIX) + + (file ? strlen(file) : 0) + 3)); (void) strcpy(cp, CDIR); (void) strcat(cp, PREFIX); if (file) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:05:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05052 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:05:03 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05024 for ; Mon, 1 Jun 1998 12:04:58 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id MAA06763; Mon, 1 Jun 1998 12:04:49 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd006627; Mon Jun 1 12:04:37 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id MAA04619; Mon, 1 Jun 1998 12:04:33 -0700 (MST) From: Terry Lambert Message-Id: <199806011904.MAA04619@usr01.primenet.com> Subject: Re: Fix for undefined "__error" and discussion of shared object To: rkw@dataplex.net (Richard Wackerbarth) Date: Mon, 1 Jun 1998 19:04:33 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: from "Richard Wackerbarth" at May 31, 98 09:57:05 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I was meaning a library in the sense of emulating otherwise discarded > constructs. This is the point of having a well defined API. THe one case you can point to in FreeBSD is the dropping of the ISO and other family functions from libc. Having an emulation library would not help you here, since these are kernel hooks. For standard libraries, the libraries stay around. If they are in XANDF, it won't even matter what architecture we eventually run. > >>By the time we get to FreeBSD 235.x, do you really expect to be > >> able to support today's hack dejuor which relies on the present major/minor > >> device numbers? I think not. > > > >Quite right. Software which depends on these constructs will fail to > >operate. > > You have conceded my point. You conceded first by stating that what you were talking about was a hack. > >Well, I am (I hope) well known as an advocate of "revolution instead of > >evolution"; technology moves too damn slow for me as it is > > If you are successful, FreeBSD will not reach 235.x. It will have gotten > another name long before. I doubt that. BSD can absob technology and remain BSD. The 2.x systems didn't support NFS, for example; is BSD any less BSD now that it does support NFS, yet has dropped support for the old "berknet" serial networking? > >I agree that at some point you are going to lose backward compatability; > >I think, however, that XANDF will push this off, since most of the > >historical compatability issues can be resolved by regenerating the > >assembly code, and relinking, which is implied. > > I don't disagree. However, "push ... off" is far different from your > initial statement. My initial statement was intended to underscore the irrelevence of not moving an ABI forward when it becomes obvious that it should be done. ELF is one very good example. IMO, -current users should all be running ELF systems now; -current is not -release, and the sooner -current moves to ELF, the faster things can be tested. The fact that you have to drop slash-screen support, etc. to get a dual boot is irrelevent. We should take the hack, with the expectation of getting rid of the a.out boot code to resolve the size issue at some future date. Moving to the TenDRA compiler has a lot of advantages: 1) It forces FreeBSD to actually seperate machine dependent and machine independent code. This is a good thing. I think it would be an error to support inline assembly in the TenDRA compiler. 2) It's already machine independent. 3) It supports both Linux and UnixWare, among other UNIX-like OSs. If it becomes widely adopted, then it will be possible to buy a single shrink-wrapped version of a product to run on any UNIX platform. 4) It has a BSD/CMU style license. 5) It is a revolutionary rather than evolutionary product; that is, it was designed to be the way it is, rather than starting as something else and growing warts to become what it is today. Multiple language back-ending, seperation of code generation, etc., are all warts, as far as GCC derived sources are concerned. It also has a couple of disadvantages: 1) We, as programmers, have to actually think about architectural dependence of our code. 2) It has a bit of a problem with not supporting the #pragma pack(#) construct, which is needed to map hardware registers (it uses a packing of 4, but bitfields are correctly handled. The first disadvantage is an advantage, to my mind. 8-). The second is somewhat of an advantage, in that we should be dealing with bitfields anyway, instead of sized types (C doesen't support sized types, one of its major failinures, IMO). > >I *really* look forward to the day when I can buy an XANDF Motif > >library, and use it on all my hardware, regardless of the CPU type. > >8-0. > > Aren't we really just emulating an "XANDF" machine with an XANDF->whatever > micro-code expanded inline? Where is my XANDF native machine? No. There is a fundamental difference here. XANDF is not JAVA; it's not a bytecode format, it's a distribution formant. The code still needs architecture specific peephole optimzations, etc.. I doubt it would be possible to build an XANDFVM. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:06:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05311 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:06:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05201 for ; Mon, 1 Jun 1998 12:06:04 -0700 (PDT) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id VAA29822 for ; Mon, 1 Jun 1998 21:09:35 +0200 (CEST) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Mon, 1 Jun 1998 21:09:35 +0200 (CEST) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: freebsd-current@FreeBSD.ORG Subject: "swaps on generic" - what a name... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, What's your opinion on the above clause in kernel config file? I know it's the holy tradition which stands behind it, but I find it totally misleading in current state of affairs. Perhaps I'm missing some bigger picture, but for me it's equal to something like: enable choosing the root device. Could it be expressed better in terms of normal kernel option, say "options ASK_ROOT"? Andrzej Bialecki --------------------+--------------------------------------------------------- abial@nask.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. --------------------+--------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:09:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05931 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:09:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05876 for ; Mon, 1 Jun 1998 12:08:52 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id DAA10546; Tue, 2 Jun 1998 03:08:24 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806011908.DAA10546@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Kevin Day cc: mi@video-collage.com (Mikhail Teterin), current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 13:29:24 EST." <199806011829.NAA20244@home.dragondata.com> Date: Tue, 02 Jun 1998 03:08:23 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day wrote: > > Kevin Day once stated: > > > > =However entering this on the client machine > > = > > =mount -u -o async /home > > = > > =*while* the client's nfs is hosed will make it recover within 5 > > =seconds. It even appears that all the writes that were queued are > > =executed, and no data is lost. > > > > That's a great thing to know. Those hungups are damn annoying. > > The reason is, probably, a side effect of how `-u'/`async' are > > implemented. AFAIK, the fs is unmounted and then remounted with > > async. Which is just what you wanted. > > That's my thought too, but: > > umount /home > > will freeze, so it's not exactly unmounting things. :) That's because umount (in it's infinite wisdom) tries to stat() the argument to see what file type (/dev node) or directory it is (and resolve symlinks and other wierd things). This causes the NFS hang. I was debating whether to remove it so that it worked solely from the vfs mount list. Incidently, umount -f -t nfs server:/home usually works, as long as the VFS layer isn't deadlocked on the mountlist or a busy filesystem. This is because stat("server:/home") fails with an ENOENT rather than doing a nfs operation. Definately a ``feature'' if I ever saw one. > > =Is there any way of making whatever it was that did this happen > > =automatically every once in a while? :) > > > > NFS hung ups are a strange topic, in my experience. People agree > > that they are "bad", but one is not supposed to complain about > > them... > > Don't read my post as a complaint, rather as a 'hey, why does it do this?" > :) Is it consistant BTW? Or are you not willing to do blow away your server again? :-) > Kevin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:12:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06815 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:12:03 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06757 for ; Mon, 1 Jun 1998 12:11:49 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id DAA10580; Tue, 2 Jun 1998 03:11:24 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806011911.DAA10580@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: ben@stuyts.nl cc: "Brian Feldman" , freebsd-current@FreeBSD.ORG Subject: Re: ppp cannot find libalias In-reply-to: Your message of "Mon, 01 Jun 1998 20:25:49 +0200." <199806011825.UAA10399@daneel.stuyts.nl> Date: Tue, 02 Jun 1998 03:11:24 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ben Stuyts wrote: > On 1 Jun 1998, "Brian Feldman" wrote: > > > So fix it, I don't see what the problem is here? > > I wrote: > > > > This is on -current, cvsupped on May 30. I just removed every old library > > > in /usr/lib, as they are now in /usr/lib/aout. The new ppp does not look in > > > the correct place for libalias yet. It still looks in /usr/lib: > > > ... > > > > > > loadalias.c:#define _PATH_ALIAS_PREFIX "/usr/lib/libalias.so.2." > > The problem is: You want me to report these things or not? > > I already have put a /aout in there, but that won't do any good as soon as > things move over to /usr/lib/elf. > > Ben I don't see why we don't just link with -lalias and be done with it. It's quite simple to do a dlopen(NULL) to do symbolic lookups if code impact is a problem. Or just initialize the PacketAlias struct with &functionname from libalias. At least for the time being something like this is needed. Assumptions about pathnames to libraries and versioning is likely to be a very slippery business over the next few months until the dust settles. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:16:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08189 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:16:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08146 for ; Mon, 1 Jun 1998 12:16:23 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA10536; Mon, 1 Jun 1998 12:07:16 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd010511; Mon Jun 1 19:07:09 1998 Message-ID: <3572FBD0.33590565@whistle.com> Date: Mon, 01 Jun 1998 12:06:56 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: "Alex G. Bulushev" CC: Eivind Eklund , sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <199806010816.MAA12889@sinbin.demos.su> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG THis is the single best argument I've heard for allowing devfs type nodes on a normal fs. :-) certainly DEVFS makes the case of providing devices to chroot environments a lot more 'heavyweight' A number of things to note about this: 1/ There is a suggestion that there be a mount option that simply mounts an EMPTY devfs, which would then be populatable using some form of mknod (which uses the name to create the device and not the major/minor) 2/ one would need to do this on each reboot or login.. alternatively a single master might exist and be referenced by a nullfs mount, unless they all wanted different devices. (e.g just their own tty device) I agonised over this when trying to figure out a way of making dynamic devices. I eventually came to the conclusion that leaving devices around across reboots wa more of a security risk than recreating them to a known state on boot or when required. My guess is that each VM (virtual machine?) would either have it's devices added as it is entered by a user, (or at least checked) or at reboot time by some custom scripts (You must be doing this with custom scripts anyway.) The two missing pieces are: 1/ the ability to mount an empty devfs 2/ the ability to create a single node in it (the reason for this discussion) a workaround for the moment would be to mount a full one, and mv the devices you need to .hold, rm -rf everything else, and mv them back. julian Alex G. Bulushev wrote: > > > On Sat, May 30, 1998 at 05:02:14PM -0400, Stephane E. Potvin wrote: > > > Maybe this will seems a stupid question but why in the first place would > > > someone want to delete a device from a devfs /dev? Or put differently why is > > > not devfs append-only so someone would be able to make new links but not able > > > to delete existing devices? > > > > For use in a chroot()'ed environment. > > there are several problems with dev's in a chroot'ed enviroment, > for example a real system (we use it): > 1. about 500 chroot'ed "virtual mashines", the /dev containes only > necessary devices (tty??) for each VM (created by mknod when VM created) > 2. users fs (on main server) with VM (end /dev for each VM) mounted via nfs > on several hosts where users realy work (chroot on nfs) > 3. each VM can created or deleted while system working on main server > > and what about future of this scheme with new devfs ideas? > mount devfs for each VM on main server and hosts where users work? > and unmount devfs on each host before VM deleted? what do you mean 'server' and what do you mean by "hosts where users work"? julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:20:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09272 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:20:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09222 for ; Mon, 1 Jun 1998 12:20:23 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA05276; Mon, 1 Jun 1998 19:19:49 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA05003; Mon, 1 Jun 1998 21:19:32 +0200 (MET DST) Message-ID: <19980601211931.09973@follo.net> Date: Mon, 1 Jun 1998 21:19:31 +0200 From: Eivind Eklund To: Julian Elischer , "Alex G. Bulushev" Cc: sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <199806010816.MAA12889@sinbin.demos.su> <3572FBD0.33590565@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <3572FBD0.33590565@whistle.com>; from Julian Elischer on Mon, Jun 01, 1998 at 12:06:56PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 01, 1998 at 12:06:56PM -0700, Julian Elischer wrote: > THis is the single best argument I've heard for allowing > devfs type nodes on a normal fs. :-) > > certainly DEVFS makes the case of providing devices to chroot > environments a lot more 'heavyweight' > > A number of things to note about this: > 1/ There is a suggestion that there be a mount option that simply > mounts an EMPTY devfs, which would then be populatable using some > form of mknod (which uses the name to create the device and not the > major/minor) Can't this easily be done by mounting a DEVFS, wiping it, mounting one more, and ln'ing in the nodes? No changes required to do that... Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:28:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11027 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:28:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11011 for ; Mon, 1 Jun 1998 12:28:38 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA05571; Mon, 1 Jun 1998 19:28:36 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA05095; Mon, 1 Jun 1998 21:28:18 +0200 (MET DST) Message-ID: <19980601212818.39604@follo.net> Date: Mon, 1 Jun 1998 21:28:18 +0200 From: Eivind Eklund To: Mike Smith Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet References: <199806011201.OAA16937@sherwood.gmd.de> <199806011530.IAA17978@antipodes.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806011530.IAA17978@antipodes.cdrom.com>; from Mike Smith on Mon, Jun 01, 1998 at 08:30:00AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 01, 1998 at 08:30:00AM -0700, Mike Smith wrote: > > P.S. > > I believe that the real problem might be that your program comes with a BSD > > license while my software comes with GPL. > > This is never a problem; BSD code can always be incorporated into a GPL > product without having any significant impact on the GPL. The reverse > is, regrettably, not the case. Eh? _Nothing_ can be incorporated into a GPL product except GPLed code; of you've got public domain code, you may of course make it GPL first... 'No further restrictions' clauses of the GPL (clauses 6 and 7 of GPL v2). This specifically contradicts clause 4 of the standard BSD license. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:45:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14277 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:45:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14269 for ; Mon, 1 Jun 1998 12:45:06 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id OAA21139; Mon, 1 Jun 1998 14:44:50 -0500 (CDT) From: Kevin Day Message-Id: <199806011944.OAA21139@home.dragondata.com> Subject: Re: NFS discovery In-Reply-To: <199806011840.CAA10468@spinner.netplex.com.au> from Peter Wemm at "Jun 2, 98 02:40:31 am" To: peter@netplex.com.au (Peter Wemm) Date: Mon, 1 Jun 1998 14:44:50 -0500 (CDT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Kevin Day wrote: > > > > Here's my setup: > > > > > > 2.2.6 NFS server with /home exported > > -current NFS client mounting server:/home under /home > > > > If the server gets rebooted or their link is temporarily severed, the client > > never recovers. Any attempt to read anything from /home causes the process > > to get wedged pretty nicely. (even kill -9 won't kill it) > > What's the wait channel that the client processes hang in BTW? 'ps > -axlww' and look for the hung process. Next time it happens, I'll look. However, I'm doubly out of luck as my nfs server os also my NIS server. ps usually fails because it can't look up a user name... I'll see if it works. :) > > > However entering this on the client machine > > > > mount -u -o async /home > > > > *while* the client's nfs is hosed will make it recover within 5 seconds. It > > even appears that all the writes that were queued are executed, and no data > > is lost. > > > > Is there any way of making whatever it was that did this happen > > automatically every once in a while? :) > > > > Does specificing async on an nfs mount even do anything? > > It only specifies the commit level of writes. An async nfs mount will > tell the server not to bother to sync write data to disk before returning > the rpc call. Ok. I doubt actually setting it to async is doing it, rather just updating it is fixing the problem. (doing mount -u -o async /home *again* will fix it again and again. I'm wondering if just mount -u /home will do it or not.) > > What age -current kernel sources are we talking about BTW? This kind of > information is going to be pretty important from now on. > The client is from mar 25th. I can update if needed. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:47:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA14944 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:47:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14928 for ; Mon, 1 Jun 1998 12:47:32 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id OAA21359; Mon, 1 Jun 1998 14:47:01 -0500 (CDT) From: Kevin Day Message-Id: <199806011947.OAA21359@home.dragondata.com> Subject: Re: NFS discovery In-Reply-To: <199806011908.DAA10546@spinner.netplex.com.au> from Peter Wemm at "Jun 2, 98 03:08:23 am" To: peter@netplex.com.au (Peter Wemm) Date: Mon, 1 Jun 1998 14:47:00 -0500 (CDT) Cc: mi@video-collage.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > That's my thought too, but: > > > > umount /home > > > > will freeze, so it's not exactly unmounting things. :) > > That's because umount (in it's infinite wisdom) tries to stat() the > argument to see what file type (/dev node) or directory it is (and resolve > symlinks and other wierd things). This causes the NFS hang. > > I was debating whether to remove it so that it worked solely from the vfs > mount list. How about an option to control it? :) > > Incidently, > umount -f -t nfs server:/home > usually works, as long as the VFS layer isn't deadlocked on the mountlist > or a busy filesystem. This is because stat("server:/home") fails with an > ENOENT rather than doing a nfs operation. Definately a ``feature'' if I > ever saw one. I tried that too, and umount would freeze. (I could at least ^C out of it though) > > > > Don't read my post as a complaint, rather as a 'hey, why does it do this?" > > :) > > Is it consistant BTW? Or are you not willing to do blow away your server > again? :-) I discovered it a few days ago, during massive power problems. (the servre kept rebooting randomly) and it worked every time. I'm about to reboot the server again, and can test whatever is needed. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:55:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17020 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:55:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA17004 for ; Mon, 1 Jun 1998 12:55:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA00742; Mon, 1 Jun 1998 11:49:31 -0700 (PDT) Message-Id: <199806011849.LAA00742@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joerg Schilling cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Mon, 01 Jun 1998 18:30:15 +0200." <199806011630.SAA17075@sherwood.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 01 Jun 1998 11:49:30 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA17008 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >From mike@antipodes.cdrom.com Mon Jun 1 18:17:40 1998 > > >> You cannot deal with this problem: > >> = > > >> Systems that define _SC_PAGESIZE or _SC_PAGE_SIZE (HP-UX) > >> don't support getpagesize() so there is no way to fix this > >> in runtime except if you introduce an additional = > > >> = > > >> HAVE_GETPAGESIZE > >> = > > >> in the autoconfiguration. > >> = > > >> But even then the code would be badly readable. = > > >This is a problem with the design of cdrecord, insofar as it's fairly > > Sorry, this is a problem for evryone who wants to write portable code. > But FreeBSD seems to ignore this issue. It's not an operating system issue, it's an application issue. Obtaining the page size is something that needs to be abstracted out of the application's space into the operating system interface for the application, simply because it's something that's traditionally platform-specific. In your case, you would probably want a vector mechanism, eg. struct { int (* pagesize)(); ... } sysdep; so then in your application context you say: pagesize = sysdep.pagesize(); and in the BSD layer you would say: int bsd_pagesize(void) { int pagesize; if ((pagesize = sysconf(_SC_PAGESIZE)) == -1) pagesize = getpagesize(); return(pagesize); } ... void appsetup(void) { ... sysdep.pagesize = bsd_pagesize; ... } This is really basic portability design. > You may have a functional sysconf(_SC_PAGESIZE) _and_ getpagesize() if you > like to be able to run portable applications but you cannot have a non > functional sysconf(_SC_PAGESIZE). That's an opinion. It's not one that others share. I would be inclined to say that if you want to call sysconf() at all, you need to be prepared to handle it properly, and that includes setting/checking errno when you make the call. > This looks to me like Microsofts tried to create a Posix environment that > is Posix compliant on the paper but would prevent you from running real world > Posix applications on it. This is more of a commentary on the usefulness of the Posix standard than anything else. > I would call a sysconf implementation that is not functional for sysconf(_SC_PAGESIZE) > although getpagesize() exists buggy. That's one interpretation. I'd be curious to know whether the functionality of one given sysconf() argument implies the functionality of others though. Peter? Is this something that your reading of the Posix words would let us get away with? It'd certainly reduce the noise on this one a little. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 12:57:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17678 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:57:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA17653 for ; Mon, 1 Jun 1998 12:57:40 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id MAA24257; Mon, 1 Jun 1998 12:57:16 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Mikhail Teterin cc: current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 13:51:03 EDT." <199806011751.NAA29921@xxx.video-collage.com> Date: Mon, 01 Jun 1998 12:57:15 -0700 Message-ID: <24254.896731035@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > NFS hung ups are a strange topic, in my experience. People agree > that they are "bad", but one is not supposed to complain about > them... You misunderstand. It's simply that people have been complaining about NFS hangs for so long now, most readers would rather see agreement that they're "bad" followed by some actual action. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 13:10:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20866 for freebsd-current-outgoing; Mon, 1 Jun 1998 13:10:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA20831 for ; Mon, 1 Jun 1998 13:10:25 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00827; Mon, 1 Jun 1998 12:04:30 -0700 (PDT) Message-Id: <199806011904.MAA00827@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jordan K. Hubbard" cc: Mike Smith , ben@stuyts.nl, current@FreeBSD.ORG, brian@awfulhak.org Subject: Re: ppp cannot find libalias In-reply-to: Your message of "Mon, 01 Jun 1998 09:03:16 PDT." <22316.896716996@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 12:04:30 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This is the wrong place to do it. dlopen() should honour the standard > > library path for the format of the executable calling it. I proposed an > > So you're basically saying we should search through the hint cache or, > if set, the LD_LIBRARY_PATH instead. Well fine. I had one idea for > fixing it and I sent in my diffs. You then shot down my idea with > a better one and ... - please complete the sentence. :-) Not even the hint cache. Note that this is the a.out rtld; I don't know (yet) where to look for the ELF one. Index: rtld.c =================================================================== RCS file: /uluru1/ncvs/src/gnu/usr.bin/ld/rtld/rtld.c,v retrieving revision 1.52 diff -u -r1.52 rtld.c --- rtld.c 1998/02/06 16:46:46 1.52 +++ rtld.c 1998/06/01 20:11:27 @@ -1902,29 +1902,34 @@ struct so_map *old_tail = link_map_tail; struct so_map *smp; int bind_now = mode == RTLD_NOW; + char *name; - /* - * path == NULL is handled by map_object() - */ - anon_open(); + if (path == NULL) + return NULL; + + /* If path is not qualified, search for it on the standard searchpath */ + name = (strchr(path, '/') != NULL) ? strdup(path) : rtfindfile(path); + /* Map the object, and the objects on which it depends */ smp = map_object(path, (struct sod *) NULL, (struct so_map *) NULL); if(smp == NULL) /* Failed */ - return NULL; + goto depart; LM_PRIVATE(smp)->spd_flags |= RTLD_DL; /* Relocate and initialize all newly-mapped objects */ if(link_map_tail != old_tail) { /* We have mapped some new objects */ if(reloc_dag(smp, bind_now) == -1) /* Failed */ - return NULL; + smp = NULL, goto depart; init_dag(smp); } unmaphints(); anon_close(); + depart: + free(name); return smp; } -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 13:16:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22525 for freebsd-current-outgoing; Mon, 1 Jun 1998 13:16:30 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22442 for ; Mon, 1 Jun 1998 13:16:17 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA00869; Mon, 1 Jun 1998 12:09:40 -0700 (PDT) Message-Id: <199806011909.MAA00869@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: bag@sinbin.demos.su (Alex G. Bulushev) cc: eivind@yes.no (Eivind Eklund), sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Mon, 01 Jun 1998 12:16:37 +0400." <199806010816.MAA12889@sinbin.demos.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 12:09:39 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > there are several problems with dev's in a chroot'ed enviroment, > for example a real system (we use it): > 1. about 500 chroot'ed "virtual mashines", the /dev containes only > necessary devices (tty??) for each VM (created by mknod when VM created) > 2. users fs (on main server) with VM (end /dev for each VM) mounted via nfs > on several hosts where users realy work (chroot on nfs) > 3. each VM can created or deleted while system working on main server > > and what about future of this scheme with new devfs ideas? > mount devfs for each VM on main server and hosts where users work? > and unmount devfs on each host before VM deleted? That's the most logical way of doing it. It would be quite straightforward to mount a DEVFS and have it not populated by default (eg. mount -t devfs -o empty ...). Then your mknods run as "normal" creating the devices you want. DEVFS is per-system. You cannot export a DEVFS via NFS (it makes no sense to do so - devices there are only relevant to the host system). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 13:30:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA26219 for freebsd-current-outgoing; Mon, 1 Jun 1998 13:30:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA26143 for ; Mon, 1 Jun 1998 13:30:28 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.8.8/8.8.8) with ESMTP id VAA08511; Mon, 1 Jun 1998 21:30:17 +0100 (BST) (envelope-from kpielorz@tdx.co.uk) Message-ID: <35730F59.510D55FB@tdx.co.uk> Date: Mon, 01 Jun 1998 21:30:17 +0100 From: Karl Pielorz Organization: TDX X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Mikhail Teterin CC: current@FreeBSD.ORG, toasty@home.dragondata.com Subject: Re: NFS discovery References: <199806011751.NAA29921@xxx.video-collage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikhail Teterin wrote: > NFS hung ups are a strange topic, in my experience. People agree > that they are "bad", but one is not supposed to complain about > them... I remember having a long conversation with a friend a few years back (can I get any more vague?) - Where he was praising NFS's ability to crash - as it assures that say your running a program on a remote system, it will either run to completion - or hang if the server dies... This I presume works on the assumption that it helps somehow to have a client that's 'hung' in mid-air (i.e. at least you know if failed) rather than risking any corruption that might have been caused by the server disappearing for a while... I think you can change this behaviour - have a look at the man page for 'mount_nfs' - in particular things like the '-i' option & 'soft' mounting etc... Regards, Karl Pielorz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 13:51:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA01121 for freebsd-current-outgoing; Mon, 1 Jun 1998 13:51:53 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA01114 for ; Mon, 1 Jun 1998 13:51:48 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA01047; Mon, 1 Jun 1998 12:45:49 -0700 (PDT) Message-Id: <199806011945.MAA01047@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Garrett Wollman cc: Mike Smith , freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Mon, 01 Jun 1998 14:11:48 EDT." <199806011811.OAA22409@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 12:45:49 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There is no earthly reason why a: > > case _SC_PAGESIZE: > return (getpagesize()); > > ....cannot be added to this same switch statement. Ok, consider it done, although in a slightly more general fashion. And relax. This is meant to be fun, right? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 14:12:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA06338 for freebsd-current-outgoing; Mon, 1 Jun 1998 14:12:54 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA06225 for ; Mon, 1 Jun 1998 14:12:25 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id VAA08630; Mon, 1 Jun 1998 21:12:02 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA05513; Mon, 1 Jun 1998 23:11:44 +0200 (MET DST) Message-ID: <19980601231144.27297@follo.net> Date: Mon, 1 Jun 1998 23:11:44 +0200 From: Eivind Eklund To: Andrzej Bialecki , freebsd-current@FreeBSD.ORG Subject: Re: "swaps on generic" - what a name... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Andrzej Bialecki on Mon, Jun 01, 1998 at 09:09:35PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 01, 1998 at 09:09:35PM +0200, Andrzej Bialecki wrote: > Could it be expressed better in terms of normal kernel option, say > "options ASK_ROOT"? Yes, if that's all it does. Patches, please :-) Eivind, who's willing to shoot holy cows :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 14:17:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA07348 for freebsd-current-outgoing; Mon, 1 Jun 1998 14:17:07 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from www.video-collage.com (www.video-collage.com [206.15.171.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA07222 for ; Mon, 1 Jun 1998 14:16:33 -0700 (PDT) (envelope-from mi@xxx.video-collage.com) Received: from xxx.video-collage.com (xxx.video-collage.com [199.232.254.68]) by www.video-collage.com (8.8.5/8.8.5) with ESMTP id RAA29844 for ; Mon, 1 Jun 1998 17:15:12 -0400 (EDT) Received: (from mi@localhost) by xxx.video-collage.com (8.8.8/8.8.7) id RAA20073 for current@freebsd.org; Mon, 1 Jun 1998 17:16:20 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <199806012116.RAA20073@xxx.video-collage.com> Subject: Re: NFS discovery In-Reply-To: <199806011908.DAA10546@spinner.netplex.com.au> from Peter Wemm at "Jun 2, 98 03:08:23 am" To: current@FreeBSD.ORG Date: Mon, 1 Jun 1998 17:16:19 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10756 for freebsd-current-outgoing; Mon, 1 Jun 1998 14:29:41 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10458 for ; Mon, 1 Jun 1998 14:28:19 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id RAA05760; Mon, 1 Jun 1998 17:03:44 -0400 (EDT) From: Peter Dufault Message-Id: <199806012103.RAA05760@hda.hda.com> Subject: Re: cdrecord trouble on currnet In-Reply-To: <199806011811.OAA22409@khavrinen.lcs.mit.edu> from Garrett Wollman at "Jun 1, 98 02:11:48 pm" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Mon, 1 Jun 1998 17:03:43 -0400 (EDT) Cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There is no earthly reason why a: > > case _SC_PAGESIZE: > return (getpagesize()); > > ...cannot be added to this same switch statement. Sorry to come to this late - There are probably a others in there (memlock, memlock_range) that will lead to problems if I don't check and make them reflect BSD practice. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 14:34:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11754 for freebsd-current-outgoing; Mon, 1 Jun 1998 14:34:07 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11581 for ; Mon, 1 Jun 1998 14:33:10 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id HAA00254; Tue, 2 Jun 1998 07:33:03 +1000 Date: Tue, 2 Jun 1998 07:33:03 +1000 From: Bruce Evans Message-Id: <199806012133.HAA00254@godzilla.zeta.org.au> To: mike@smith.net.au, wollman@khavrinen.lcs.mit.edu Subject: Re: cdrecord trouble on currnet Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> This would defeat the entire purpose of sysconf(), which is to pass >> opaque constants to the kernel. > >Bullshit. Go look at the code before making pronouncements from on >high. > >In particular, note the code which quite clearly states: > > case _SC_CHILD_MAX: > return (getrlimit(RLIMIT_NPROC, &rl) ? -1 : rl.rlim_cur); > case _SC_CLK_TCK: > return (CLK_TCK); > >There is no earthly reason why a: > > case _SC_PAGESIZE: > return (getpagesize()); > >...cannot be added to this same switch statement. Except it gives yet more namespace pollution. Existing namespace pollution can be leveraged by calling sysctl() directly: case _SC_PAGESIZE: mib[0] = CTL_HW; mib[1] = HW_PAGESIZE; break; Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 14:36:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12470 for freebsd-current-outgoing; Mon, 1 Jun 1998 14:36:57 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from www.video-collage.com (www.video-collage.com [206.15.171.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12273 for ; Mon, 1 Jun 1998 14:36:03 -0700 (PDT) (envelope-from mi@xxx.video-collage.com) Received: from xxx.video-collage.com (xxx.video-collage.com [199.232.254.68]) by www.video-collage.com (8.8.5/8.8.5) with ESMTP id RAA02135 for ; Mon, 1 Jun 1998 17:34:37 -0400 (EDT) Received: (from mi@localhost) by xxx.video-collage.com (8.8.8/8.8.7) id RAA21867 for current@freebsd.org; Mon, 1 Jun 1998 17:35:49 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <199806012135.RAA21867@xxx.video-collage.com> Subject: Re: NFS discovery In-Reply-To: <35730F59.510D55FB@tdx.co.uk> from Karl Pielorz at "Jun 1, 98 09:30:17 pm" To: current@FreeBSD.ORG Date: Mon, 1 Jun 1998 17:35:49 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" NFS hung ups are a strange topic, in my experience. People agree that => they are "bad", but one is not supposed to complain about them... =I remember having a long conversation with a friend a few years back =(can I get any more vague?) - Where he was praising NFS's ability to =crash - as it assures that say your running a program on a remote =system, it will either run to completion - or hang if the server =dies... This I presume works on the assumption that it helps somehow =to have a client that's 'hung' in mid-air (i.e. at least you know if =failed) rather than risking any corruption that might have been caused =by the server disappearing for a while... This is true. However, there must be a thing right before having to reboot the whole system. I must be able to avoid the total reboot of the client (in which case my in-mid-air app will loose its data anyway) and getting rid of the hung mountpoint. =I think you can change this behaviour - have a look at the man page =for 'mount_nfs' - in particular things like the '-i' option & 'soft' =mounting etc... This is different and, AFAIK, it slows down your usual NFS work... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 15:07:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19897 for freebsd-current-outgoing; Mon, 1 Jun 1998 15:07:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (root@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19886 for ; Mon, 1 Jun 1998 15:07:07 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id OAA02636; Mon, 1 Jun 1998 14:46:04 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd002584; Mon Jun 1 14:45:54 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA25252; Mon, 1 Jun 1998 14:45:47 -0700 (MST) From: Terry Lambert Message-Id: <199806012145.OAA25252@usr05.primenet.com> Subject: Re: Service Location Protocol To: dom@myrddin.demon.co.uk (Dom Mitchell) Date: Mon, 1 Jun 1998 21:45:47 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: from "Dom Mitchell" at Jun 1, 98 08:03:58 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > When I ported the sample implementation of the Service Location > > Protocol code from Sun Microsystems, I had to de-Linux the type > > type declarations, then memset( &x, 0, sizeof(struct sockaddr_in)); > > all over the place. > > Do you have a copy of this in a publically available location - it's > something I've been wanting to play with... The licensing is kind of bogus: * This implementation of Service Location Protocol for Linux * (Sun Linux SLP) is a product of Sun Microsystems, Inc. and is provided * for unrestricted use provided that this legend is included on all tape * media and as a part of the software program in whole or part. Users * may copy or modify Sun Linux SLP without charge, but are not authorized * to license or distribute it to anyone else except as part of a product or * program developed by the user. There's really no good reason for this. You can contact the same place I did to get the sample implementation: Charles.Perkins@Eng.Sun.COM and then I can send you the patches to de-Linux it. One real problem with SLP is that the service definitions are less than useful (currently, only LPR is defined in a draft standard, and the attributes provided in the draft are a very bad match to any printer hardware I've ever used). My soloution to this was to define myself as a namespace authority ("appliance") in place of the default of "iana", and start defining more rational URL's for services like "I will relay mail for your service group", etc.. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 15:41:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA27571 for freebsd-current-outgoing; Mon, 1 Jun 1998 15:41:54 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA27556 for ; Mon, 1 Jun 1998 15:41:47 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA20140; Mon, 1 Jun 1998 15:41:45 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd020108; Mon Jun 1 15:41:39 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA27865; Mon, 1 Jun 1998 15:41:31 -0700 (MST) From: Terry Lambert Message-Id: <199806012241.PAA27865@usr05.primenet.com> Subject: Re: cdrecord trouble on currnet To: schilling@fokus.gmd.de (Joerg Schilling) Date: Mon, 1 Jun 1998 22:41:30 +0000 (GMT) Cc: mike@smith.net.au, schilling@fokus.gmd.de, dufault@hda.com, freebsd-current@FreeBSD.ORG In-Reply-To: <199806011744.TAA17106@sherwood.gmd.de> from "Joerg Schilling" at Jun 1, 98 07:44:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> >Only if you promise not to give me trouble about errx - as a FreeBSD > >> >utility their coding standard says to use that, and when > >> >in Rome do as the Romans do. > >> > >> To make it portable, I'll need to replace them with my routines > >> comerr() comerrno() errmsg() and errmsgno() wich I am using since 1982 > >> long before BSD intruduced things like that. > >> > >> I have no problems with these functions as I believe that it neccessary > >> to have readable error messages and perror() don't makes good error > >> messages. > >Great. Replace a set of standard error reporting functions with older, = > >nonstandard ones. 8) This really sinks most of the rest of your argument,= > >unfortunately. > > You are right from the view of a *BSD user but from the view of a > mainstream UNIX user the BSD functions are non standard too and in > addition non portable. I have to agree. I greatly dislike the err(3)/warn(3) functions. Among other things they lead to a boatload of lint/compiler directives of the form "/* NOTREACHED*/". Not to mention the amount of damage they tend to perpetrate on single-entry/single-exit architecture (which drastically reduces bug counts according to all four studies published on it), and the damage they do to internationalization via data-only changes. > My functions are portable though. I think that code that relies on anything more than perror(3)/strerror(3) is asking for trouble, personally. Direct access to sys_errlist and sys_nerr, as well as assumptions about errno, are just plain wrong. > Around 1990 the number of pure BSD users did go dramatically down because > many vendors switched over to SVr4. No commercial UNIX incorporated things > from 4.4BSD (if I rememer correctly) in contrary to the former behaviour of > these companies. BSDI. Also note that SVR4 was 55% or better BSD4.3 code (one of the reasons the suit went away). > I believe that > 80% of all UNIX users have no access to err(). > So I cannot call 4.4BSD mainstream or half the UNIX tree. One fix: #if defined(__BSD44__) #define ERR(x) err x #else #define ERR(x) myfunction x #endif ... ERR((1, "%s", file_name)); > >What you are suggesting you want here is a portable "libbsd". This = > >will need more than just "non-standard" library extensions, as the = > >alternative would be to put almost all of the BSD library in here. > >Rather, what needs to be done is for someone that wants to port BSD = > >programs to other platforms to take the BSD libc and extract all those = > >components which are a superset of the desired target platform(s) APIs = > >and build a libbsd suited to each of the deficient targets. This wouldn't fly, for the reasons listed. The correct way to get this behaviour is to turn on compiler whining about unprototyped functions, and then set the apropriate POSIX version before including headers. > No doubt, there is a need for UNIX utilities with better error printing > and standardized bahaviour and many ideas from 4.4 BSD are not bad, but > they are not available outside *BSD. The function err(3)/warn(3) are farcical. The real need is for a machine parsable name/value syslog(3) formatting and conventions. Much less than the J. Abela "Universal Format for Logger Messages" draft standard, which attempts to define a new protocol as well as a convention that is less than useful for agregating the status of services, seperate from the status of filters (services hang out; filters exit). With this information, it would be possible to write a syslogd that parses messages, and can, at any point in time, provide you with the status of services exported by your machine. The defenition of dependent relationships between services is left as an exercise for the people who don't want a SysV style rc.d mechanism (ie: how do I know DNS is up before I actually offer mail services, since mail services depend on a functioning DNS). Try this experiment: add a duplicate host name record for an upper and lower case version of a host name to your DNS. Send mail to "root@mydomain". Wait one hour. Delete the 39,000 bounce messages that were generated. > As one exaple, I now have my own termcap library that implements the > exellent idea of the TERMPATH environment. The 4.4BSD version could > not be used because it relies on the nonstandard BSD database system. > OK, I already started my termcap library in 1986 so there was no need for > the full effort of the complete implementation. BTW: I am using enhanced > versions of tgoto() and tputs() because these functions are portable. I think you are confusing termcap (BSD) with terminfo (Bill Joy at Sun). The termcap file is standard to all UNIX implementations, and has been for a long time, until UNIX vendors switch to terminfor to make it so users couldn't screw up terminal definitions (so they come screwed up from the factory, instead). There are valid reasons to have your own termcap library, but there aren't really valid reasons to have your own getcap()/tgetent() functions. You should use the platform native database mechanism (for example, you can get this information from VMS's database, even though most DEC products, like EDT and LSE, hard-code things and are too stupid to use the database themselves). > I hope you see, that I am sad to see that the BSD folks writes good > software that cannot be shared without using the *BSD operating system. > From my point of view this is not the right idea of free software. The big problem here is that you have a gratuitously different "make" program; probably GNU make, which needs ridiculously complex makefiles to describe common operations. I have never understood why putting commonly performed operations into each and every Makefile was a good design decision.... > >> P.S. > >> I believe that the real problem might be that your program comes > >> with a BSD license while my software comes with GPL. > > > >This is never a problem; BSD code can always be incorporated into a GPL = > >product without having any significant impact on the GPL. The reverse = > >is, regrettably, not the case. Actually, that's not true; the GPL has just as hard a time with the UCB additional "restriction" of claim-credit in the UCB/CMU copyright. This is gratuitous as hell on the part of the GPL, but there you have it... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:03:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01712 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:03:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01684 for ; Mon, 1 Jun 1998 16:02:52 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA01875; Mon, 1 Jun 1998 16:02:45 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd001808; Mon Jun 1 16:02:38 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA28930; Mon, 1 Jun 1998 16:02:36 -0700 (MST) From: Terry Lambert Message-Id: <199806012302.QAA28930@usr05.primenet.com> Subject: Re: NFS discovery To: toasty@home.dragondata.com (Kevin Day) Date: Mon, 1 Jun 1998 23:02:36 +0000 (GMT) Cc: mi@video-collage.com, current@FreeBSD.ORG In-Reply-To: <199806011829.NAA20244@home.dragondata.com> from "Kevin Day" at Jun 1, 98 01:29:24 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > NFS hung ups are a strange topic, in my experience. People agree > > that they are "bad", but one is not supposed to complain about > > them... > > Don't read my post as a complaint, rather as a 'hey, why does it do this?" > :) The freeze on server crash comes from an outstanding RPC call that was made, the call was ack'ed, but the response had not yet been sent. Because the call was ack'ed, the client doesn't retry the call. This is arguably a bug in the client code. The easiest workaround is to use UDP NFS instead of TCP. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:07:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02751 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:07:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02728 for ; Mon, 1 Jun 1998 16:07:32 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id HAA11791; Tue, 2 Jun 1998 07:06:32 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806012306.HAA11791@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Mikhail Teterin cc: current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 17:16:19 -0400." <199806012116.RAA20073@xxx.video-collage.com> Date: Tue, 02 Jun 1998 07:06:32 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mikhail Teterin wrote: > Peter Wemm once stated: > > =That's because umount (in it's infinite wisdom) tries to stat() the > =argument to see what file type (/dev node) or directory it is (and resolve > =symlinks and other wierd things). This causes the NFS hang. > > If the client is SGI, it is possible to drop the dead mount with > > umount server:/server/path > if > umount /client/path > hangs. > > I'm glad to see someone else agreeing here. It seems incredibly stupid > if a reboot is required to get rid of the hanging nfs mount point. This is basically what we do, except that umount won't automatically break filesystem semantics of a pending operation, you have to force it with -f as converting open files to dead vnodes is pretty rude to say the least. ie: umount -f server:/server/path (I use the "-t nfs" out of habit). I don't think that anybody is saying that what we've got now is ideal. It will all be fixed very soon, it's just that there are some more pressing problems to deal with yet, and things like random data corruption are generally more destructive than unmount hangs. Not by far, mind you - having to reboot a client and loose in-transit data isn't nice either. Problems like the client not recovering after the server has come back are high on the list. We've got a fair few other really ugly problems in the PR database still. Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:09:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA03277 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:09:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA03263 for ; Mon, 1 Jun 1998 16:09:47 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id SAA17484; Mon, 1 Jun 1998 18:09:26 -0500 (CDT) From: Kevin Day Message-Id: <199806012309.SAA17484@home.dragondata.com> Subject: Re: NFS discovery In-Reply-To: <35730F59.510D55FB@tdx.co.uk> from Karl Pielorz at "Jun 1, 98 09:30:17 pm" To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Mon, 1 Jun 1998 18:09:26 -0500 (CDT) Cc: mi@video-collage.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mikhail Teterin wrote: > > > NFS hung ups are a strange topic, in my experience. People agree > > that they are "bad", but one is not supposed to complain about > > them... > > I remember having a long conversation with a friend a few years back (can I > get any more vague?) - Where he was praising NFS's ability to crash - as it > assures that say your running a program on a remote system, it will either > run to completion - or hang if the server dies... > This I presume works on the assumption that it helps somehow to have a > client that's 'hung' in mid-air (i.e. at least you know if failed) rather > than risking any corruption that might have been caused by the server > disappearing for a while... > > I think you can change this behaviour - have a look at the man page for > 'mount_nfs' - in particular things like the '-i' option & 'soft' mounting > etc... > My two problems are slightly different though. 1) After enough processes get 'hung', the entire box dies. 2) After the server comes back, the client never recovers. (I'm using both -i and -s) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:13:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04082 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:13:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04065 for ; Mon, 1 Jun 1998 16:13:06 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA11650; Mon, 1 Jun 1998 16:13:04 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd011559; Mon Jun 1 16:12:59 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA29364; Mon, 1 Jun 1998 16:12:53 -0700 (MST) From: Terry Lambert Message-Id: <199806012312.QAA29364@usr05.primenet.com> Subject: Re: I see one major problem with DEVFS... To: mike@smith.net.au (Mike Smith) Date: Mon, 1 Jun 1998 23:12:53 +0000 (GMT) Cc: bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG In-Reply-To: <199806011909.MAA00869@dingo.cdrom.com> from "Mike Smith" at Jun 1, 98 12:09:39 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > and what about future of this scheme with new devfs ideas? > > mount devfs for each VM on main server and hosts where users work? > > and unmount devfs on each host before VM deleted? > > That's the most logical way of doing it. It would be quite > straightforward to mount a DEVFS and have it not populated by default > (eg. mount -t devfs -o empty ...). Then your mknods run as "normal" > creating the devices you want. Since it's the same space, you could hard link from your devfs into the empty one to create the nodes. This is even better, since it allows a chroot in a chroot to never inherit more than the parent. 8-). > DEVFS is per-system. You cannot export a DEVFS via NFS (it makes no > sense to do so - devices there are only relevant to the host system). This is a deficiency in NFS, not anything else, in that it can't proxy ioctl's via descriptor. A VFS proxy layer (as described in Heidemann's thesis, in fact) *could* proxy this data. For normal devices that are only operated on via open/close/read/write, it makes sens to export a devfs. This works for printers, disks, floppy drives, backup tapes (assuming the rewind/norewind device name convention is maintained) and, in some cases, pty's and ttys. The dmesg, etc., is another obvious candidate. This isn't as useful as the true proxy provided by OpenNET, but it's a good step in that direction. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:17:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04941 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:17:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04931 for ; Mon, 1 Jun 1998 16:17:28 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id SAA20375; Mon, 1 Jun 1998 18:17:16 -0500 (CDT) From: Kevin Day Message-Id: <199806012317.SAA20375@home.dragondata.com> Subject: Re: NFS discovery In-Reply-To: <199806012302.QAA28930@usr05.primenet.com> from Terry Lambert at "Jun 1, 98 11:02:36 pm" To: tlambert@primenet.com (Terry Lambert) Date: Mon, 1 Jun 1998 18:17:15 -0500 (CDT) Cc: mi@video-collage.com, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > NFS hung ups are a strange topic, in my experience. People agree > > > that they are "bad", but one is not supposed to complain about > > > them... > > > > Don't read my post as a complaint, rather as a 'hey, why does it do this?" > > :) > > > The freeze on server crash comes from an outstanding RPC call that > was made, the call was ack'ed, but the response had not yet been sent. > > Because the call was ack'ed, the client doesn't retry the call. > This is arguably a bug in the client code. > > The easiest workaround is to use UDP NFS instead of TCP. I am using UDP.... (TCP seemed much much worse) I'm resigned to the fact that NFS does freeze and never come back... What I was curious about was why the `mount -u -o async /blah` 'unfroze' it. I am going to reboot the server tonight, and I'm going to try to keep the client up. If there's anything anyone wants me to do (other than check to see what all the processes are waiting on) please let me know within a few hours. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:18:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05292 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:18:56 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA05271 for ; Mon, 1 Jun 1998 16:18:47 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA06543; Mon, 1 Jun 1998 16:18:38 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpd006490; Mon Jun 1 16:18:32 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA29727; Mon, 1 Jun 1998 16:18:27 -0700 (MST) From: Terry Lambert Message-Id: <199806012318.QAA29727@usr05.primenet.com> Subject: Re: NFS discovery To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Mon, 1 Jun 1998 23:18:27 +0000 (GMT) Cc: mi@video-collage.com, current@FreeBSD.ORG, toasty@home.dragondata.com In-Reply-To: <35730F59.510D55FB@tdx.co.uk> from "Karl Pielorz" at Jun 1, 98 09:30:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > NFS hung ups are a strange topic, in my experience. People agree > > that they are "bad", but one is not supposed to complain about > > them... > > I remember having a long conversation with a friend a few years back (can I > get any more vague?) - Where he was praising NFS's ability to crash - as it > assures that say your running a program on a remote system, it will either > run to completion - or hang if the server dies... > This I presume works on the assumption that it helps somehow to have a > client that's 'hung' in mid-air (i.e. at least you know if failed) rather > than risking any corruption that might have been caused by the server > disappearing for a while... The program is supposed to hang only until the server comes back up. The problem is the use of TCP, and that the RPC call is not retried after a request ack before a request completion. This is exactly analogous to the FIN_WAIT_2 problem: --> request <-- response 1 <-- response 2 (this one never comes) Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:19:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05505 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:19:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.westbend.net (ns1.westbend.net [207.217.224.194]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA05488 for ; Mon, 1 Jun 1998 16:19:54 -0700 (PDT) (envelope-from hetzels@westbend.net) Received: from admin (admin.westbend.net [207.217.224.195]) by mail.westbend.net (8.8.8/8.8.8) with SMTP id SAA10744; Mon, 1 Jun 1998 18:19:47 -0500 (CDT) (envelope-from hetzels@westbend.net) Message-ID: <046601bd8db3$c49fa0a0$c3e0d9cf@admin.westbend.net> From: "Scot W. Hetzel" To: "Mike Smith" Cc: Subject: Re: ppp cannot find libalias Date: Mon, 1 Jun 1998 18:19:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Mike Smith >Not even the hint cache. Note that this is the a.out rtld; I don't >know (yet) where to look for the ELF one. > Mike, I cleaned up your code, I HATE goto's. Scot anon_open(); + if (path == NULL) + return NULL; + + /* If path is not qualified, search for it on the standard searchpath */ + name = (strchr(path, '/') != NULL) ? strdup(path) : rtfindfile(path); + /* Map the object, and the objects on which it depends */ smp = map_object(path, (struct sod *) NULL, (struct so_map *) NULL); - if(smp == NULL) /* Failed */ - return NULL; + if(smp != NULL) /* Succeeded */ { LM_PRIVATE(smp)->spd_flags |= RTLD_DL; /* Relocate and initialize all newly-mapped objects */ - if(link_map_tail != old_tail) { /* We have mapped some new objects */ + if(link_map_tail != old_tail) && (reloc_dag(smp, bind_now) != -1) - if(reloc_dag(smp, bind_now) == -1) /* Failed */ - return NULL; init_dag(smp); else + smp = NULL; -} unmaphints(); anon_close(); } + free(name); return smp; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:28:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07789 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:28:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07722 for ; Mon, 1 Jun 1998 16:28:03 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA18476; Mon, 1 Jun 1998 16:27:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd018441; Mon Jun 1 16:27:51 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA00473; Mon, 1 Jun 1998 16:27:48 -0700 (MST) From: Terry Lambert Message-Id: <199806012327.QAA00473@usr05.primenet.com> Subject: Re: NFS discovery To: toasty@home.dragondata.com (Kevin Day) Date: Mon, 1 Jun 1998 23:27:48 +0000 (GMT) Cc: tlambert@primenet.com, mi@video-collage.com, current@FreeBSD.ORG In-Reply-To: <199806012317.SAA20375@home.dragondata.com> from "Kevin Day" at Jun 1, 98 06:17:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The freeze on server crash comes from an outstanding RPC call that > > was made, the call was ack'ed, but the response had not yet been sent. > > > > Because the call was ack'ed, the client doesn't retry the call. > > This is arguably a bug in the client code. > > > > The easiest workaround is to use UDP NFS instead of TCP. > > I am using UDP.... (TCP seemed much much worse) I'm resigned to the fact > that NFS does freeze and never come back... What I was curious about was why > the `mount -u -o async /blah` 'unfroze' it. The remount flushes all data and restarts all transactions. It is the transaction restart that is causing you to recover. The unmount stat transaction fails to trigger a restart because it doesn't get an ESTALE back for the mount point reference because the NFS VOP_LOCK can't be reentered. To see this better, look at how the client builds cookies and makes transaction requests, and what it sleeps on inre the remount case. This is a well known problem that crept in under cover of some of the macrotized "goto"'s in the 4.4 code. It is not trivial to resolve, mostly because the NFS code is such crap right now. One thing that would help greatly is to view the NFS server as a peer of other VFS consumers (like the syscall layer is a VFS consumer) on the server side, and the NFS client as a reeentrant finite state automaton (an idea that the NFS VOP_LOCK thwarts because of lack of reentrancy being inherent in its design). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:29:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08229 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:29:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08202 for ; Mon, 1 Jun 1998 16:29:21 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA14626; Mon, 1 Jun 1998 16:29:14 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd014595; Mon Jun 1 16:29:12 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA00551; Mon, 1 Jun 1998 16:29:03 -0700 (MST) From: Terry Lambert Message-Id: <199806012329.QAA00551@usr05.primenet.com> Subject: Re: NFS discovery To: peter@netplex.com.au (Peter Wemm) Date: Mon, 1 Jun 1998 23:29:03 +0000 (GMT) Cc: toasty@home.dragondata.com, mi@video-collage.com, current@FreeBSD.ORG In-Reply-To: <199806011908.DAA10546@spinner.netplex.com.au> from "Peter Wemm" at Jun 2, 98 03:08:23 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > That's because umount (in it's infinite wisdom) tries to stat() the > argument to see what file type (/dev node) or directory it is (and resolve > symlinks and other wierd things). This causes the NFS hang. And it shouldn't. The transactions are inapropriately serialized without a retry. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 16:31:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08797 for freebsd-current-outgoing; Mon, 1 Jun 1998 16:31:51 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08723 for ; Mon, 1 Jun 1998 16:31:20 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id SAA08502; Mon, 1 Jun 1998 18:30:39 -0500 (CDT) Date: Mon, 1 Jun 1998 18:30:39 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199806011904.MAA04619@usr01.primenet.com> References: from "Richard Wackerbarth" at May 31, 98 09:57:05 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: Richard Wackerbarth Subject: Re: Fix for undefined "__error" and discussion of shared object Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 7:04 PM -0000 6/1/98, Terry Lambert wrote: >You conceded first by stating that what you were talking about was a hack. Unfortunately, the code that we consider "a hack" is someone else's prize code. :-) He won't be happy that you have dropped support for it. >> >Well, I am (I hope) well known as an advocate of "revolution instead of >> >evolution"; technology moves too damn slow for me as it is >> >> If you are successful, FreeBSD will not reach 235.x. It will have gotten >> another name long before. > >I doubt that. BSD can absorb technology and remain BSD. The 2.x systems >didn't support NFS, for example; is BSD any less BSD now that it does >support NFS, yet has dropped support for the old "berknet" serial >networking? I think that the "marketing types" will tell you that there is a middle ground in numbering. Only the foolhardy adopt the 1.0 version of anything. (It still needs "shaking out".) Similarly, when the number gets too big, most people think "legacy warts". (They want something fresher.) The solution is easy, just change the name and start numbering again. :-) This is especially true if you have a "relvolution" rather than incremental change. >ELF is one very good example. IMO, -current users should all >be running ELF systems now; -current is not -release, and the sooner >-current moves to ELF, the faster things can be tested. The fact >that you have to drop slash-screen support, etc. to get a dual boot >is irrelevent. We should take the hack, with the expectation of >getting rid of the a.out boot code to resolve the size issue at >some future date. Here, I agree. IMHO, we have gone too long, and have too many projects "almost" there. We need to do whatever is necessary to get some of them firmly "in" and move on. >> Aren't we really just emulating an "XANDF" machine with an XANDF->whatever >> micro-code expanded inline? Where is my XANDF native machine? > >No. There is a fundamental difference here. XANDF is not JAVA; it's >not a bytecode format, it's a distribution formant. But it still has a set of acceptable constructs. I argue that these are the "instruction set" of this virtual machine. > The code still needs architecture specific peephole optimzations, etc.. Does it "need" them (as in REQUIRE)? The optimizations could equally be viewed as a part of an efficient emulation. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 17:12:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18214 for freebsd-current-outgoing; Mon, 1 Jun 1998 17:12:39 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18125 for ; Mon, 1 Jun 1998 17:12:10 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id QAA01852; Mon, 1 Jun 1998 16:06:00 -0700 (PDT) Message-Id: <199806012306.QAA01852@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: schilling@fokus.gmd.de (Joerg Schilling), dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet In-reply-to: Your message of "Mon, 01 Jun 1998 22:41:30 -0000." <199806012241.PAA27865@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 16:06:00 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >> I have no problems with these functions as I believe that it neccessary > > >> to have readable error messages and perror() don't makes good error > > >> messages. > > >Great. Replace a set of standard error reporting functions with older, = > > >nonstandard ones. 8) This really sinks most of the rest of your argument,= > > >unfortunately. > > > > You are right from the view of a *BSD user but from the view of a > > mainstream UNIX user the BSD functions are non standard too and in > > addition non portable. And yours are standard? Or any more portable than the BSD library functions? I take your point that if you're adopting something into your own family you want it to conform, I'm just suggesting that your perspective is a bit warped. > I have to agree. I greatly dislike the err(3)/warn(3) functions. Among > other things they lead to a boatload of lint/compiler directives of the > form "/* NOTREACHED*/". This is only an issue if your error checking tools can't be informed that a function doesn't return. If your tools contain implicit information about the behaviour of exit(), abort(), longjmp() etc. then they are not portable either. > > Around 1990 the number of pure BSD users did go dramatically down because > > many vendors switched over to SVr4. No commercial UNIX incorporated things > > from 4.4BSD (if I rememer correctly) in contrary to the former behaviour of > > these companies. > > BSDI. There are other vendors using 4.4-derived code as well, not to mention the number of embedded platforms using 4.4-derived code. > > I believe that > 80% of all UNIX users have no access to err(). > > So I cannot call 4.4BSD mainstream or half the UNIX tree. I can make up numbers just as easily. But even using your numbers, 20% is too large to be ignored. > One fix: The correct "fix" is, of course, to use a set of functions suited to your application environment and then shim them out on a per-platform basis. That's just portability-101 again. > The correct way to get this behaviour is to turn on compiler whining > about unprototyped functions, and then set the apropriate POSIX version > before including headers. That's better, yes. It makes it more difficult to build sophisticated application-level services out of composite target environment services handled on a per-target basis. > > No doubt, there is a need for UNIX utilities with better error printing > > and standardized bahaviour and many ideas from 4.4 BSD are not bad, but > > they are not available outside *BSD. > > The function err(3)/warn(3) are farcical. Actually, err/warn are far from farcial. They provide a useful set of functionality commonly required for trivial commandline applications. They are available anywhere outside of the BSD environment you care to build or duplicate them. > > I hope you see, that I am sad to see that the BSD folks writes good > > software that cannot be shared without using the *BSD operating system. > > From my point of view this is not the right idea of free software. Which parts of the application or the library services it uses are not free? How are we supposed to raise the quality of the environment if not by doing new things? Do you expect us to accept stagnation as the price for lowest-common-denominator compatibility? > > >> P.S. > > >> I believe that the real problem might be that your program comes > > >> with a BSD license while my software comes with GPL. > > > > > >This is never a problem; BSD code can always be incorporated into a GPL = > > >product without having any significant impact on the GPL. The reverse = > > >is, regrettably, not the case. > > Actually, that's not true; the GPL has just as hard a time with the > UCB additional "restriction" of claim-credit in the UCB/CMU copyright. > This is gratuitous as hell on the part of the GPL, but there you have > it... You are referring to clause 6 in GPL2? This is violated so regularly that I would expect it to be almost unenforceable. A literal interpretation makes it impossible (in fact a violation of the GPL) to ask people to send you bug reports. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 18:34:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01640 for freebsd-current-outgoing; Mon, 1 Jun 1998 18:34:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lamb.sas.com (root@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01588 for ; Mon, 1 Jun 1998 18:33:54 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.8.7/8.8.7) with SMTP id VAA13031 for ; Mon, 1 Jun 1998 21:33:50 -0400 (EDT) Received: by mozart (5.65c/SAS/Domains/5-6-90) id AA02102; Mon, 1 Jun 1998 21:33:43 -0400 From: "John W. DeBoskey" Message-Id: <199806020133.AA02102@mozart> Subject: VSZ of rcp.statd ?? To: freebsd-current@FreeBSD.ORG Date: Mon, 1 Jun 1998 21:33:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, The rpc.statd process seems to be (ahem), very large on my machines. The two sample below are from a just rebooted machine, and one that's been up for 13 days. The same is true for machines with uptimes of 50 days. I'm thinking this is normal, since I'm accessing 30,000 files from my fileserver during a build process. However, I'd like to know what other people think, and if it's 'normal'. Comments? Critiques? Thanks, John $ uname -a FreeBSD bb01f39.unx.sas.com 3.0-980506-SNAP FreeBSD 3.0-980506-SNAP #1: Thu May 14 10:37:05 EDT 1998 brdean@bb01f39.unx.sas.com:/usr/src/sys/compile/BBKERN-ADM i386 $ uptime 9:27PM up 13 days, 9:04, 7 users, load averages: 1.00, 1.00, 1.00 $ ps -axl UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 118 1 60 2 0 262936 420 select Is ?? 0:00.00 rpc.statd And: $ uname -a FreeBSD bb01f10.unx.sas.com 3.0-980223-SNAP FreeBSD 3.0-980223-SNAP #2: Sun Mar 1 18:22:21 GMT 1998 root@bb01f10.unx.sas.com:/usr/src/sys/compile/BBKERN i386 $ ps -axl UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 141 1 65 2 0 262920 148 select Is ?? 0:00.00 rpc.statd $ uptime 9:29PM up 10:34, 1 user, load averages: 0.02, 0.01, 0.00 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 18:50:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA04629 for freebsd-current-outgoing; Mon, 1 Jun 1998 18:50:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA04598 for ; Mon, 1 Jun 1998 18:49:38 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA02307; Mon, 1 Jun 1998 17:42:07 -0700 (PDT) Message-Id: <199806020042.RAA02307@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Mon, 01 Jun 1998 23:12:53 -0000." <199806012312.QAA29364@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 17:42:07 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > and what about future of this scheme with new devfs ideas? > > > mount devfs for each VM on main server and hosts where users work? > > > and unmount devfs on each host before VM deleted? > > > > That's the most logical way of doing it. It would be quite > > straightforward to mount a DEVFS and have it not populated by default > > (eg. mount -t devfs -o empty ...). Then your mknods run as "normal" > > creating the devices you want. > > Since it's the same space, you could hard link from your devfs into > the empty one to create the nodes. > > This is even better, since it allows a chroot in a chroot to never > inherit more than the parent. 8-). However it is problematic to link outside of a chroot, and it may not always be desirable to be so fancy (eg. when using chroot for engineering rather than security reasons). > > DEVFS is per-system. You cannot export a DEVFS via NFS (it makes no > > sense to do so - devices there are only relevant to the host system). > > This is a deficiency in NFS, not anything else, in that it can't > proxy ioctl's via descriptor. A VFS proxy layer (as described in > Heidemann's thesis, in fact) *could* proxy this data. No, it's a direct feature of DEVFS, or more particularly to achieve the results desired by the original poster you cannot use an NFS-mounted devfs. > For normal devices that are only operated on via open/close/read/write, > it makes sens to export a devfs. No, it does not. There is no identifying information exported with a DEVFS node that allows the local system to correctly connect a node from a remote DEVFS (which may not map to a local driver) to a local device. > This isn't as useful as the true proxy provided by OpenNET, but it's > a good step in that direction. You want to proxy device accesses to devices on the exporting system. That's a completely different kettle of fish entirely. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 19:16:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10951 for freebsd-current-outgoing; Mon, 1 Jun 1998 19:16:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA10884 for ; Mon, 1 Jun 1998 19:15:49 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id VAA01572; Mon, 1 Jun 1998 21:15:38 -0500 (EST) (envelope-from toor) Message-Id: <199806020215.VAA01572@dyson.iquest.net> Subject: Re: VSZ of rcp.statd ?? In-Reply-To: <199806020133.AA02102@mozart> from "John W. DeBoskey" at "Jun 1, 98 09:33:43 pm" To: jwd@unx.sas.com (John W. DeBoskey) Date: Mon, 1 Jun 1998 21:15:38 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John W. DeBoskey said: > Hi, > > The rpc.statd process seems to be (ahem), very large on my machines. The > two sample below are from a just rebooted machine, and one that's been up > for 13 days. The same is true for machines with uptimes of 50 days. > > I'm thinking this is normal, since I'm accessing 30,000 files from my > fileserver during a build process. However, I'd like to know what other > people think, and if it's 'normal'. > > Comments? Critiques? > It is big because of a mmap of /var/db/statd.status, and 0x10000000 is allocated to the mapping. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 19:29:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA13087 for freebsd-current-outgoing; Mon, 1 Jun 1998 19:29:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12869 for ; Mon, 1 Jun 1998 19:27:58 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id TAA25559; Mon, 1 Jun 1998 19:27:22 -0700 (PDT) (envelope-from jdp) Message-Id: <199806020227.TAA25559@austin.polstra.com> To: toj@gorillanet.gorilla.net Subject: Re: IP Packet Aliasing Broke? In-Reply-To: <19980531140201.06705@TOJ.org> References: <19980530210320.35350@TOJ.org> <19980531140201.06705@TOJ.org> Organization: Polstra & Co., Seattle, WA Cc: current@FreeBSD.ORG Date: Mon, 01 Jun 1998 19:27:22 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On May 28 packet forwarding was working, on the 29 it was *not*. > > > Any ideas or did I miss something? All I have done is make world > > > and kernel rebuid. > > No, sorry for not being clear. User ppp ip packet aliasing. Trying to > figure out what happened but haven't yet. You might have gotten bitten by the move of the libraries from /usr/lib to /usr/lib/aout. Where is libalias.so.*? If it is in /usr/lib/aout, try creating a symlink to it in /usr/lib. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 20:45:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26658 for freebsd-current-outgoing; Mon, 1 Jun 1998 20:45:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA26624 for ; Mon, 1 Jun 1998 20:45:24 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 808 invoked by uid 1000); 2 Jun 1998 00:46:42 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <35712F0A.58921DFD@tdx.co.uk> Date: Mon, 01 Jun 1998 20:46:42 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Karl Pielorz Subject: Re: problems with SCSI drives over sd9? Cc: current@FreeBSD.ORG, obrien@NUXI.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 31-May-98 Karl Pielorz wrote: > David O'Brien wrote: >> >> But my drives are NOT continuiously numbered. Currently I've got >> sd0,sd1,sd2,sd3 on one controler, and >> sd10,sd11,sd12,sd13,sd14,sd15,sd18 on another one. (the last digit >> matches the SCSI id). I can confirm correct operation to sd127 or so. All devices are wired, though. Many holes in between, but up to 10 or so individual disks. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 20:51:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27689 for freebsd-current-outgoing; Mon, 1 Jun 1998 20:51:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA27543 for ; Mon, 1 Jun 1998 20:50:39 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 850 invoked by uid 1000); 2 Jun 1998 00:51:52 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199805292208.PAA01191@dingo.cdrom.com> Date: Mon, 01 Jun 1998 20:51:51 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT driver fails and panics with Degraded Array Cc: Karl Pielorz , tcobb , "freebsd-current@freebsd.org" , Michael Hancock Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 29-May-98 Mike Smith wrote: >> >> I am routinely running a Dual DPT with 38 drives on 6 busses. On >> 3.0-CURRENT SMP. The system did lose disk drives, either intentionally, >> or >> by accident. I cannot confirm any of Mr. Cobb's finding. I have not >> been >> funished with any data, including the panic point, which I suspect is >> not >> in the DPT code. I am still waiting for such data. > > I'd just like to point out that the "biodone: buffer not busy" panic > doesn't come from the DPT driver, but may be caused by it calling > biodone() on a buffer that the system does not believe is busy. > > These situations are worth analysing, and I hope to see you and Troy > resolving this one, even if it means that you point the finger > elsewhere. I got these particularly with tape devices. Especially if there are two tape drives on the system and yoy try to (for example) cpio to both independently. I put a ton of debugging code in the DPT driver to try and catch the DPT sending biodone twice on the same request and am pretty comfortable the driver is not it. Especially when the st.c peripheral driver will do it almost consistently, and the disks will almost never do that. Since the DPT driver does not know a disk from a cucamber, I doubt it is at fault. But any persistent test cases are very welcome. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 21:05:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA00332 for freebsd-current-outgoing; Mon, 1 Jun 1998 21:05:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA00313 for ; Mon, 1 Jun 1998 21:05:07 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 953 invoked by uid 1000); 2 Jun 1998 01:06:24 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FAE8@freya.circle.net> Date: Mon, 01 Jun 1998 21:06:24 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: tcobb Subject: RE: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I simply am tired of this thread. There will be no more response from me on this isuue. The author displays complete lack of understanding of how the FreeBSD kernel, the SCSI abstraction layer, the DPT driver, and the DPT firmware operate and interact. While this lack of knowledge is understandable, the attempt to diagnose the problem in this context is irritating. Simon On 30-May-98 tcobb wrote: > I won't respond to each of Simon's many emails over the past 24 hours, > simply because most of them were out-of-context reactions to a thread > that grew from my original DPT post yesterday. > > Instead, I think that the most productive thing is to provide a bit more > of the information requested. > > The system is using a single PM3334UW/2 with drives configured in the > following logical arrays: > > 2 1GB drives as RAID-1 (sd0) > 7 4GB drives as RAID-5 (sd1) > 1 4GB hot swap > > Event #1: > 1 of the RAID-5 drives fails, DPT hardware begins to auto-rebuild with > the hot swap drive > DPT driver freezes access to sd1, system remains running but access to > sd1 hangs > > I shutdown and rebooted machine (SYNC failed on shutdown) > Allowed FreeBSD to boot, it returned the following for sd1 > sd1: type 0 fixed SCSI 2 > sd1: Direct-Access 0MB (1 512 byte sectors) > > Then, system continued booting and finally panic'd with a "Page Fault in > Supervisor Mode" error prior to mounting drives. > > I then booted the system with a DOS floppy, used DPTmgr to examine > array. The array was complete, but in degraded mode. It had begun > rebuilding itself, which specs say can happen in the background while > other accesses are going on. I tested redundancy info on the array AND > tested random reads on the array -- all succeeded. > > So, I exited DPTmgr, and tried booting back to FreeBSD, same problem as > above occurred (0MB 1 sector, panic). Then, I rebooted into DOS and let > the DPT card run its rebuild from there. It completed about 1.5 hours > later, and showed the array optimal. > > I then rebooted into FreeBSD which showed the correct info again. > > Event #2: > This was the next day. Hard drive fails in array (this was the ex-hot > swap from above). This leaves the array with no hotswap to insert, but > no data lost. The array is now again in degraded mode. The card > screams bloody murder. HOWEVER, the DPT driver does NOT hang on access > to the sd1 partition. I successfully shutdown the machine (SYNC > succeeded this time). I insert a new harddrive into the array so that > the DPT hardware will begin rebuilding with this new drive. On reboot, > FreeBSD showed the same results as above (0MB, 1 sector, panic). > Rebooting back to DOS and running DPTmgr showed that the array was in > degraded mode, but that no data was lost and that redundancy information > was all there. It automatically began rebuilding with the new drive. I > tested rebooting into FreeBSD, same results (0/1/panic). Rebooted back > to DOS, allowed the hardware to finish its rebuild (1.5 hours), rebooted > to FreeBSD and it showed the correct results. > > > So, here's the summary for those of you who've stayed with me. > > With RAID-5 and a HOT SWAP drive, a single drive failure caused the DPT > driver in FreeBSD to hang on access to the partition. This appears to > be because DPT was doing a background rebuild automatically. > > With RAID-5 and NO hot swap drive, a single drive failure does NOT cause > the DPT driver in FreeBSD to hang on access to the partition. This > appears to be because DPT was NOT doing a background rebuild -- there > being no drives to rebuild into. > > With RAID-5 and a new drive to rebuild on, the DPT hardware begins > automatic rebuilds of the array. However, in these conditions the DPT > driver (or other FreeBSD component) does not correctly sense the size > information and panics the kernel during bootup. This symptom goes away > after the rebuild is complete. This symptom does not appear when in DOS > under the same circumstances. DOS DPTmgr checks show the array of the > correct size. BIOS bootup screen for DPT shows the array of the correct > size. > > The super-summary is that it appears the the DPT driver or other FreeBSD > code component is not correctly coordinating with the DPT hardware (or > sensing status properly) when the DPT hardware is doing a background > rebuild of the array. > > This array has been running non-stop since November 1997. Cabling is > good. Active terminators and custom cables created by Granite are used. > Seagate and Micropolis drives are used. The RAID-5 array is in an > external rackmount case. > > -Troy Cobb > Circle Net, Inc. > http://www.circle.net > > > Here's the dmesg ouput, trimmed to show relevant data. > > FreeBSD 3.0-CURRENT #0: Sun May 24 04:30:04 EDT 1998 > root@kali.circle.net:/usr/src/sys/compile/BENZAITEN-4 > CPU: Pentium (232.67-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x543 Stepping=3 > Features=0x8001bf > real memory = 134217728 (131072K bytes) > avail memory = 128147456 (125144K bytes) > DEVFS: ready for devices > DPT: RAID Manager driver, Version 1.0.5 > Probing for devices on PCI bus 0: > DPT: PCI SCSI HBA Driver, version 1.4.2 > chip0: rev 0x02 on pci0.0.0 > chip1: rev 0x01 on pci0.7.0 > dpt0: rev 0x02 int a irq 9 on > pci0.20.0 > dpt0: DPT type 3, model PM3334UW firmware 07M0, Protocol 0 > on port 6310 with Write-Back cache. LED = 0000 0000 > dpt0: Enabled Options: > Recover Lost Interrupts > Collect Metrics > Optimize CPU Cache > dpt0: waiting for scsi devices to settle > scbus0 at dpt0 bus 0 > dpt0: Initializing Lost IRQ Timer > sd0 at scbus0 target 0 lun 0 > sd0: type 0 fixed SCSI 2 > sd0: Direct-Access 1029MB (2109328 512 byte sectors) > dpt0: waiting for scsi devices to settle > scbus1 at dpt0 bus 1 > sd1 at scbus1 target 2 lun 0 > sd1: type 0 fixed SCSI 2 > sd1: Direct-Access 20503MB (41990720 512 byte sectors) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 21:20:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03223 for freebsd-current-outgoing; Mon, 1 Jun 1998 21:20:23 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA03044 for ; Mon, 1 Jun 1998 21:19:58 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 1047 invoked by uid 1000); 2 Jun 1998 01:21:14 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199805310309.UAA09016@antipodes.cdrom.com> Date: Mon, 01 Jun 1998 21:21:13 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 31-May-98 Mike Smith wrote: ... > Thanks for the extra info. Are you able to simulate the failure by eg. > disconnecting one of the 'active' drives? If you can't do this on a > regular basis, I believe we are able to arrange temporary access to a > similar but idle system where this can be simulate. Simon may also be > able to offer some suggestions inre. possible poor interaction between > the dpt driver and some firmware revisions. I have tested and simpulated this problem. Again, the DPT driver in FreeBSD does not know a disk from an onion. It simply passes SCSI SCBs formatted by the abstraction layer to the controller, and passes results back. >From the controller model I can guess the firmware revisions range in question. I have run tests on most of them, and, under normal conditions, what is described, simply does not happen. I did find a window with these conditions: * During boot (and only during boot), while the scsi abstraction layer still runs in polled mode (interrupts off). * The DPT controller has enough bandwidth to accept commands one at a time. * The DPT controller then delays responding to commands 1,000 longer than the SCSI abstraction layer (sd.c, in this case) specified. In 3.0 I reduced this to only 50 times longer. * When command completion is probed, the DPT will NOT report error, but successful condition, or no condition at all. Under these conditions, the DPT driver could return a ``successful'' completion code. In this case, the abstraction layer will post the device with whatever capacity value was there before calling the DPT driver. It is possible, under these conditions that nonsense will be assumed. The panic may be triggered by the SCSI abstraction layer trying to interpret some of its trash as valid data. Since the DPT driver does not supply, in its callback, any pointers, the memory reference failure is most likely not directly induced by the DPT driver. A patch to close this window was submitted for review and will be checked in as soon as the FreeBSD committer accepts the code as valid and acceptable. Summary: Theyre is a bit of ``pointing elsewhere'' here as, after thorough review, I do not see the memory failure in the driver. Neither do I see any other defect. As a historical curiosity, I have seen this failure mode in certain interm DPT firmware version. The failure was in the firmware, and was induced by a large array re-build. It was not restricted to while-building, but caused the array to trash permanently. I doubt that version of the firmware was supplied to the complainer in this case. Since I have not recived any direct info, as I asked for, this is but a wild guess. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 21:22:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03772 for freebsd-current-outgoing; Mon, 1 Jun 1998 21:22:39 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA03686 for ; Mon, 1 Jun 1998 21:22:15 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 1063 invoked by uid 1000); 2 Jun 1998 01:23:33 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199805310309.UAA09016@antipodes.cdrom.com> Date: Mon, 01 Jun 1998 21:23:33 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 31-May-98 Mike Smith wrote: >> I shutdown and rebooted machine (SYNC failed on shutdown) >> Allowed FreeBSD to boot, it returned the following for sd1 >> sd1: type 0 fixed SCSI 2 >> sd1: Direct-Access 0MB (1 512 byte sectors) This version of the firmware (7M0) is newer than any I have ever seen. If it is a decendant of 7L7, then the failure mode well known. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 21:29:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05246 for freebsd-current-outgoing; Mon, 1 Jun 1998 21:29:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA05221 for ; Mon, 1 Jun 1998 21:28:56 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 1109 invoked by uid 1000); 2 Jun 1998 01:30:14 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FAE9@freya.circle.net> Date: Mon, 01 Jun 1998 21:30:14 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: tcobb Subject: RE: DPT driver fails and panics with Degraded Array Cc: Karl Pielorz , "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 30-May-98 tcobb wrote: >> -----Original Message----- >> From: Simon Shapiro [mailto:shimon@simon-shapiro.org] > [SNIP] >> At this point, the load on >> the system will >> reach 140-400 (we run the tests against RAID-0 and RAID-1, the >> performance differs) > >>From my quick review of the replies of FreeBSD DPT RAID users, all of > them appear to be using their arrays in RAID-0 or RAID-1 configurations. > > According to Simon's test procedure for his releases (portion copied > above), he too only uses the DPT RAID-0 and RAID-1 features. > > In my setup, I'm using both RAID-5 and RAID-1. I have yet to have a > drive failure on the RAID-1 array (*knock on wood*), the problems I saw > were with the RAID-5 array and rebuilds. Assume is an acronym for making an A-s out of You and Me. I routinely use and test RAID-0, 1, 5, in configurations of 6, 7, 14, and 21 drives. > *PERHAPS* the key point is that the driver developer hasn't tested the > FreeBSD DPT driver with a RAID-5 array. Perhaps not. Perhaps your attitude can sustain improvement. You are making presumptions left and right. Go read the code and then say where the failure is. I have yet to see ANY direct communications from you, with ANY data. The only thing that appears to be useful is the quote in the INQUIRY message you posted here. This indicates a very new release of the DPT FIRMWARE. So new, in fact, that my own internal contact at DPT has not sent it to me yet. The release prior to that was broken. Have you had bothered to ASK me about it, I may have told you that days ago. Even supply you with a known, reliable firmware version. > What is clear from my prior post (the really long one) is that in my > configuration the DPT driver or some other FreeBSD software component > does not correctly deal with the DPT hardware doing a background > rebuild. This is not clear at all. Not to me. What is clear to me is that I completely lost any patience for you. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jun 1 22:34:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA16551 for freebsd-current-outgoing; Mon, 1 Jun 1998 22:34:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fang.cs.sunyit.edu (perlsta@fang.cs.sunyit.edu [192.52.220.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA16541 for ; Mon, 1 Jun 1998 22:34:18 -0700 (PDT) (envelope-from perlsta@fang.cs.sunyit.edu) Received: from localhost (perlsta@localhost) by fang.cs.sunyit.edu (8.8.5/8.7.3) with SMTP id AAA03776 for ; Tue, 2 Jun 1998 00:36:08 GMT Date: Tue, 2 Jun 1998 00:36:08 +0000 (GMT) From: Alfred Perlstein To: current@FreeBSD.ORG Subject: Re: forwarded message from Kevin Street In-Reply-To: <13683.30076.606912.433434@kstreet.interlog.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG this fixed the problem in x11amp, there are still problems when using the volume slider while playing a song. basically it kills x11amp 7 star office 4 is not dying from the segment leak now, but only a few seconds after startup it crashes dumping some sorta list of X enviornemt variables. so this patch really works, however other things... well :) this will be commited no? thanks to everyone -Alfred it's especially great not to have to run text mode amp anymore. On Mon, 1 Jun 1998, Kevin Street wrote: > Alfred, way back in March you posted to freebsd-hackers with a problem > with left over shared memory from Star Office and x11amp. If you've > been following some of the recent threads on Star Office you may have > seen this already, but if not I thought I'd alert you that there's a > possible fix for this. Take a look at the attached message and see if > the patch might work for you. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 00:14:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA03833 for freebsd-current-outgoing; Tue, 2 Jun 1998 00:14:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA03714 for ; Tue, 2 Jun 1998 00:14:01 -0700 (PDT) (envelope-from pierre.dampure@k2c.co.uk) Received: (qmail 578 invoked from network); 2 Jun 1998 07:13:55 -0000 Received: from userb119.uk.uudial.com (HELO jfsebastian) (193.149.71.102) by smtp.dial.pipex.com with SMTP; 2 Jun 1998 07:13:55 -0000 Message-ID: <007301bd8df5$5c14e8a0$0242000a@jfsebastian.k2c.co.uk> From: "Pierre Y. Dampure" To: Subject: /usr/src/usr.bin/reinstall ? Date: Tue, 2 Jun 1998 08:09:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A make world of -current fails, as the "tools build" section of /usr/src/Makefile now references /usr/src/usr.bin/reinstall, which does not seem to live anywhere. Typo? Best Regards, Pierre Y. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 00:36:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA06401 for freebsd-current-outgoing; Tue, 2 Jun 1998 00:36:28 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA06393 for ; Tue, 2 Jun 1998 00:36:26 -0700 (PDT) (envelope-from pierre.dampure@k2c.co.uk) Received: (qmail 3319 invoked from network); 2 Jun 1998 07:36:25 -0000 Received: from userb119.uk.uudial.com (HELO jfsebastian) (193.149.71.102) by smtp.dial.pipex.com with SMTP; 2 Jun 1998 07:36:25 -0000 Message-ID: <000901bd8df8$80a33f70$0242000a@jfsebastian.k2c.co.uk> From: "Pierre Y. Dampure" To: Cc: Subject: You changes to /usr/src/Makefile Date: Tue, 2 Jun 1998 08:31:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter, With regards to your build-tools changes in /usr/src/Makefile, did you mean /sbin/ldconfig, rather than /usr.bin/reinstall ? Best Regards, Pierre Y. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 00:59:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08839 for freebsd-current-outgoing; Tue, 2 Jun 1998 00:59:30 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from d183-205.uoregon.edu (d183-205.uoregon.edu [128.223.183.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08830; Tue, 2 Jun 1998 00:59:28 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d183-205.uoregon.edu (8.8.8/8.8.7) id AAA24629; Tue, 2 Jun 1998 00:59:11 -0700 (PDT) Message-ID: <19980602005908.13903@hydrogen.nike.efn.org> Date: Tue, 2 Jun 1998 00:59:08 -0700 From: John-Mark Gurney To: The Hermit Hacker Cc: "Kenneth D. Merry" , freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? References: <199805312220.QAA04786@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from The Hermit Hacker on Sun, May 31, 1998 at 06:29:28PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.6-STABLE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Hermit Hacker scribbled this message on May 31: > On Sun, 31 May 1998, Kenneth D. Merry wrote: > > > The Hermit Hacker wrote... > > > > > > Hi... > > > > > > I'm not going to bother submitting a problem report on this, > > > mainly because I don't even have a core to analyze, but I figured I'd at > > > least put a 'head up' on this, in case this anything to someone... > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0xefcb5b1c > > > fault code = supervisor read, page not present > > > instruction pointer = 0x8:0xf01a88ad > > > stack pointer = 0x10:0xf6951af4 > > > frame pointer = 0x10:0xf6951b28 > > > 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 = 7011 (innfeed) > > > interrupt mask = net bio > > > kernel: type 12 trap, code=0 > > > Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx > > > > > > tulip_txput() is in the DEC 2114x driver. > > Hrmmm...are there any known problems with the 2114x driver? I do > see the following periodically: > > de0: abnormal interrupt: transmit underflow (raising TX threshold to > 96|256) > de0: abnormal interrupt: transmit underflow (raising TX threshold to > 8|512) > > On: > > de0: rev 0x22 int a irq 9 on pci0.10.0 > de0: 21140A [10-100Mb/s] pass 2.2 > de0: address 00:60:67:30:75:ef > > In 100Mb/s mode... actually, I'm running -stable and I keep getting: de0: abnormal interrupt: transmit underflow de0: receive: 08:00:09:39:2b:b8: bad crc but I see the bad crc's from multiple machines, it just depends upon the amount of traffic from that machine, I even get them from the cisco router.... I didn't get these messages when I had a ne2k clone in the machine... de0 rev 17 int a irq 11 on pci0:10:0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:80:19:35:21:93 it works great besides the 1second lockups when a transmit underflow happen... the machine is nothing special... k6-200, 48megs ram, buslogic scsi.. -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 04:21:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA06018 for freebsd-current-outgoing; Tue, 2 Jun 1998 04:21:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA05988 for ; Tue, 2 Jun 1998 04:21:27 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id GAA07799; Tue, 2 Jun 1998 06:56:56 -0400 (EDT) From: Peter Dufault Message-Id: <199806021056.GAA07799@hda.hda.com> Subject: Re: cdrecord trouble on currnet In-Reply-To: <199806011849.LAA00742@dingo.cdrom.com> from Mike Smith at "Jun 1, 98 11:49:30 am" To: mike@smith.net.au (Mike Smith) Date: Tue, 2 Jun 1998 06:56:56 -0400 (EDT) Cc: schilling@fokus.gmd.de, mike@smith.net.au, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Peter? Is this something that your reading of the Posix words would > let us get away with? It'd certainly reduce the noise on this one a > little. This is absolutely, positively a bug. In particular, the minimum return value for PAGESIZE is 1. I introduced this bug by mechanically adding the sysconfs added in .1b and overlooking that PAGESIZE reflects an existing variable. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 06:26:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23424 for freebsd-current-outgoing; Tue, 2 Jun 1998 06:26:53 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA23419 for ; Tue, 2 Jun 1998 06:26:50 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg by adelphi.physics.adelaide.edu.au (5.65/AndrewR-930902) id AA08057; Tue, 2 Jun 1998 22:56:41 +0930 Received: by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA30374; Tue, 2 Jun 1998 23:54:43 +0930 Date: Tue, 2 Jun 1998 23:54:39 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: freebsd-current@FreeBSD.ORG Subject: removing /usr/src/sys/compile/XXX Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've noticed my compile/MORDEN kernel build directory isnt getting blown away as it's claimed to - this has been happening for a while (my kernel is currently: FreeBSD 3.0-CURRENT #30: Tue May 28 01:50:31 CST 1998 as part of the regular cvsup-config-make depend all install clean sequence. It used to only increment the build number if I rebuilt without doing a config in the meantime. I suspect this wasnt a deliberate change: I eventually tracked down a problem I was having building new kernels (it was complaining about a ton of undefined vop_* symbols in vnode_if.h) to the fact that these hadnt been regenerated properly. More about my current problems in a followup message (it's perhaps of more general interest). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 06:43:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25739 for freebsd-current-outgoing; Tue, 2 Jun 1998 06:43:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA25726 for ; Tue, 2 Jun 1998 06:42:57 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg by adelphi.physics.adelaide.edu.au (5.65/AndrewR-930902) id AA04648; Tue, 2 Jun 1998 23:12:56 +0930 Received: by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA23768; Wed, 3 Jun 1998 00:10:58 +0930 Date: Wed, 3 Jun 1998 00:10:57 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: freebsd-current@FreeBSD.ORG Subject: Old kernels not compatible with elf-changes? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This first part is just by way of introduction - the title becomes relevant later: This morning I got bitten with a strange bug wherein a kernel current as of the 28th of may decided to chew up one of my nosync-mounted filesystems: the problem first manifested itself as a hang (possibly panic to debugger, but I was in X and couldnt tell) while rm'ing a large directory on the /usr partition (no softupdates on that partition, mount flags nosync). Upon rebooting fsck gave a TON of errors about unreferenced and unallocated stuff - upon later inspection, none of which seemed to come from the directory I was actually removing. I tried to finish removing the directory, but it failed to remove several directories, claiming they were not empty, but obviously were. fsck immediately thereafter caught these and cleaned them up (unallocated inodes or something). I lost a fair chunk of my system, so I removed softupdates from /usr2 from single-user mode, mounted everything sync and everything but /usr readonly, and did a make install from /usr2/src. This failed halfway through with a panic somewhere in the ffs code - details of which I wrote down but left at work today :( Since there was something obviously wrong with the kernel I was using (though I hadnt had a problem for the prior 4 days) I tried to reboot into the previous kernel of May 26. So far the disk seems to have maintained integrity, but this kernel appears to be incompatible with one of the ld changes since then: [morden|root] 23:07 /usr/src/sys/compile/MORDEN ls -l /usr/bin/ld -r-xr-xr-x 9 bin bin 12288 May 27 22:20 /usr/bin/ld* [morden|root] 23:08 /usr/src/sys/compile/MORDEN ld /usr/bin/ld: Bad address. [morden|root] 23:08 /usr/src/sys/compile/MORDEN file /usr/bin/ld /usr/bin/ld: FreeBSD/i386 compact demand paged dynamically linked executable So I'm obviously in a bit of a quandry: unable to link a new kernel, unable to link an older copy of the ld source which would presumably work, and unable to boot into a current kernel for fear of losing my hard drives. Also unable to download a current GENERIC kernel because the snapshots arent being released :-) Can anyone shed some light as to whether the above problem (specifically, pre-elf stage 2 kernels not being able to work with post-elf stage 2 world) is general or something which is peculiar to me? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 07:02:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29243 for freebsd-current-outgoing; Tue, 2 Jun 1998 07:02:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29038 for ; Tue, 2 Jun 1998 07:01:57 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id OAA14771; Tue, 2 Jun 1998 14:01:35 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA24150; Tue, 2 Jun 1998 16:01:14 +0200 (MET DST) Message-ID: <19980602160113.46922@follo.net> Date: Tue, 2 Jun 1998 16:01:13 +0200 From: Eivind Eklund To: Alfred Perlstein , current@FreeBSD.ORG Subject: Re: forwarded message from Kevin Street References: <13683.30076.606912.433434@kstreet.interlog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Alfred Perlstein on Tue, Jun 02, 1998 at 12:36:08AM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 02, 1998 at 12:36:08AM +0000, Alfred Perlstein wrote: > this fixed the problem in x11amp, there are still problems when using the > volume slider while playing a song. basically it kills x11amp 7 Which error message does it give, brightnm? We can't fix errors where we don't have exact descriptions (and I don't have a working soundcard yet, so it is kinda hard to test). Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 07:16:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02400 for freebsd-current-outgoing; Tue, 2 Jun 1998 07:16:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA02391 for ; Tue, 2 Jun 1998 07:16:33 -0700 (PDT) (envelope-from sinbin.demos.su!bag@kremvax.demos.su) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.5.31] with ESMTP id SAA15839; Tue, 2 Jun 1998 18:10:24 +0400 Received: by sinbin.demos.su id SAA06048; (8.6.12/D) Tue, 2 Jun 1998 18:10:01 +0400 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199806021410.SAA06048@sinbin.demos.su> Subject: Re: I see one major problem with DEVFS... In-Reply-To: <3572FBD0.33590565@whistle.com> from "Julian Elischer" at "Jun 1, 98 12:06:56 pm" X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: julian@whistle.com (Julian Elischer) Date: Tue, 2 Jun 1998 18:10:01 +0400 (MSD) Cc: eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > THis is the single best argument I've heard for allowing > devfs type nodes on a normal fs. :-) > > certainly DEVFS makes the case of providing devices to chroot > environments a lot more 'heavyweight' more more 'heavyweight' > > A number of things to note about this: > 1/ There is a suggestion that there be a mount option that simply > mounts an EMPTY devfs, which would then be populatable using some > form of mknod (which uses the name to create the device and not the > major/minor) > > 2/ one would need to do this on each reboot or login.. > alternatively a single master might exist and be referenced by > a nullfs mount, unless they all wanted different devices. > (e.g just their own tty device) > > I agonised over this when trying to figure out a way of making > dynamic devices. I eventually came to the conclusion that > leaving devices around across reboots wa more of a security > risk than recreating them to a known state on boot or when required. may by special "devfs" layer in generic fs structure solve some kind of problem? files of type 'device' treated by special way via file name or special id while fs mount or device create via mknod for this purpose it is necessary special dirent+inode chain in fs for initializing devfs layer while mount ... or the best way use special file with device path/name's for each fs (like quota.user quota.group) for example: mount /dev/sd0e /mnt ^- without devfs layer initialization mount -o devname=/var/devname/dev.name /dev/sd0e /mnt ^- with devfs layer initialization /var/devname/dev.name contain: relative path device name /dir1/dev/ ttyp0 /dir1/dev/ ttyp1 /dir2/dev/ ttyp0 /dir2/dev/ ttyp1 this way we can use special part of standart mount procedure instead of custom scripts (for mknod/rm) and the ability to mount of devfs and now we may mount via nfs: mount -t nfs -o devname=/var/devname/dev.name nfs.server.net:/mnt /mnt ^^^^^^^^^^^^^^^^^^^^^ local file > > My guess is that each VM (virtual machine?) would either have it's > devices added as it is entered by a user, (or at least checked) > or at reboot time by some custom scripts > (You must be doing this with custom scripts anyway.) > > The two missing pieces are: > 1/ the ability to mount an empty devfs > 2/ the ability to create a single node in it (the reason for > this discussion) > > a workaround for the moment would be to mount a full one, and mv > the devices you need to .hold, rm -rf everything else, > and mv them back. not exelent ... :) > > julian > > > Alex G. Bulushev wrote: > > > > > On Sat, May 30, 1998 at 05:02:14PM -0400, Stephane E. Potvin wrote: > > > > Maybe this will seems a stupid question but why in the first place would > > > > someone want to delete a device from a devfs /dev? Or put differently why is > > > > not devfs append-only so someone would be able to make new links but not able > > > > to delete existing devices? > > > > > > For use in a chroot()'ed environment. > > > > there are several problems with dev's in a chroot'ed enviroment, > > for example a real system (we use it): > > 1. about 500 chroot'ed "virtual mashines", the /dev containes only > > necessary devices (tty??) for each VM (created by mknod when VM created) > > 2. users fs (on main server) with VM (end /dev for each VM) mounted via nfs > > on several hosts where users realy work (chroot on nfs) > > 3. each VM can created or deleted while system working on main server > > > > and what about future of this scheme with new devfs ideas? > > mount devfs for each VM on main server and hosts where users work? > > and unmount devfs on each host before VM deleted? > what do you mean 'server' and what do you mean by > "hosts where users work"? server == nfs server for all other hosts hosts where users work == nfs clients where users login and run nfs_server | private ethernet for nfs mount ---+---------+---------+--------+---------+-- | | | | | host1 host2 host3 host4 host5 <- hosts for user | | | | | login/run ---+---------+---------+--------+---------+--+ external ethernet | router | ---+---------+---------+--------+---------+--+ | | | | | TS1 TS2 TS3 TS4 TS5 <- terminal servers ^modem ^modem ^modem ^modem ^modems > > julian > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 07:31:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA05002 for freebsd-current-outgoing; Tue, 2 Jun 1998 07:31:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA04972 for ; Tue, 2 Jun 1998 07:31:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id OAA16281; Tue, 2 Jun 1998 14:31:14 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA24317; Tue, 2 Jun 1998 16:30:53 +0200 (MET DST) Message-ID: <19980602163053.16755@follo.net> Date: Tue, 2 Jun 1998 16:30:53 +0200 From: Eivind Eklund To: Kris Kennaway , freebsd-current@FreeBSD.ORG Subject: Re: removing /usr/src/sys/compile/XXX References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Kris Kennaway on Tue, Jun 02, 1998 at 11:54:39PM +0930 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 02, 1998 at 11:54:39PM +0930, Kris Kennaway wrote: > I've noticed my compile/MORDEN kernel build directory isnt getting > blown away as it's claimed to Where is that claimed? I thought I'd removed all references to that... > - this has been happening for a while (my > kernel is currently: > > FreeBSD 3.0-CURRENT #30: Tue May 28 01:50:31 CST 1998 > > as part of the regular cvsup-config-make depend all install clean > sequence. It used to only increment the build number if I rebuilt without > doing a config in the meantime. I suspect this wasnt a deliberate change: This was a deliberate change. It was a lot of work to make it possible, too :-) Anyway; you can't do "make depend all install clean" - you have to do "make depend && make " - otherwise make doesn't pick up the dependency information from 'make depend'. > I eventually tracked down a problem I was having building new kernels (it > was complaining about a ton of undefined vop_* symbols in vnode_if.h) to > the fact that these hadnt been regenerated properly. Please give more details about this failure - this shouldn't happen. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 07:57:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA08762 for freebsd-current-outgoing; Tue, 2 Jun 1998 07:57:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA08755 for ; Tue, 2 Jun 1998 07:57:05 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg by adelphi.physics.adelaide.edu.au (5.65/AndrewR-930902) id AA07412; Wed, 3 Jun 1998 00:27:04 +0930 Received: by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA17576; Wed, 3 Jun 1998 01:25:06 +0930 Date: Wed, 3 Jun 1998 01:25:05 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Eivind Eklund Cc: freebsd-current@FreeBSD.ORG Subject: Re: removing /usr/src/sys/compile/XXX In-Reply-To: <19980602163053.16755@follo.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 2 Jun 1998, Eivind Eklund wrote: > On Tue, Jun 02, 1998 at 11:54:39PM +0930, Kris Kennaway wrote: > > I've noticed my compile/MORDEN kernel build directory isnt getting > > blown away as it's claimed to > > Where is that claimed? I thought I'd removed all references to > that... Err - only in the recesses of my memory, it seems :/ You're correct it no longer does this. > > sequence. It used to only increment the build number if I rebuilt without > > doing a config in the meantime. I suspect this wasnt a deliberate change: > > This was a deliberate change. It was a lot of work to make it > possible, too :-) > > Anyway; you can't do "make depend all install clean" - you have to do > "make depend && make " - otherwise make doesn't pick up the > dependency information from 'make depend'. Okay, you caught me again - I was being sloppy. That is in fact the procedure I go through - I figured the one I gave was equivalent :-) > > I eventually tracked down a problem I was having building new kernels (it > > was complaining about a ton of undefined vop_* symbols in vnode_if.h) to > > the fact that these hadnt been regenerated properly. > > Please give more details about this failure - this shouldn't happen. Unfortunately I've blown away the offending files in my haste to get a system which can actually build things properly again (see my other post) - but the situation was that even doing a make clean didnt fix them. Specifically: 1) cvsup to current src-sys 2) cd /usr/src/sys/i386/conf && config MORDEN 3) cd ../../compile/MORDEN; make depend && make all -j4 --> dies 4) make clean; repeat from step 2, no change Something occurred since May 28 which broke this for me. I've cvsupped regularly since then and my vnode_if.{sh,src} havent changed recently: [morden|kkenn] 0:26 /usr/src/sys/kern ls -l vn* -rw-r--r-- 1 root wheel 14854 Jun 2 22:22 vnode_if.c -rw-r--r-- 1 root wheel 23837 Jun 2 22:22 vnode_if.h -rw-r--r-- 1 root wheel 11850 Dec 20 13:04 vnode_if.sh -rw-r--r-- 1 root wheel 8304 May 7 21:18 vnode_if.src I can provide a list of the /usr/src/sys/* files which have changed in the past 4 days according to find -mtime -4 if that would be any help. I do seem to remember one of the two vnode_if.[ch] files being about 40k long, with the ones generated by vnode_if.sh being about 20k. Now that I've rm -rf'ed the compile directory they're being correctly recreated, it seems. I'm /fairly/ certain, however, that I'd done this rm -rf at some point before in the 4 days since may 28 when I was last able to build a current kernel. The vnode_if.[ch] files were being recreated - I remember doing a ls -l and noticing they had dates of June 1. It just seems that at least one of them was being created incorrectly. I dont have any local mods to my source tree (well, I had been playing around with an atapi patch, but cvsup keeps on blowing it away like cvsup does and I hadnt bothered to look at making it 'permanent'. Sorry I couldnt be of more help - I need to learn to start keeping logs of stuff when it breaks, since occasionally it turns out to be significant and not just a temporary bogon :) > Eivind. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 08:25:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12861 for freebsd-current-outgoing; Tue, 2 Jun 1998 08:25:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from skraldespand.demos.su (skraldespand.demos.su [194.87.5.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA12850 for ; Tue, 2 Jun 1998 08:24:59 -0700 (PDT) (envelope-from mishania@skraldespand.demos.su) Received: by skraldespand.demos.su id TAA21401; (8.8.8/D) Tue, 2 Jun 1998 19:24:25 +0400 (MSD) Message-ID: <19980602192424.02082@demos.su> Date: Tue, 2 Jun 1998 19:24:24 +0400 From: "Mikhail A. Sokolov" To: Garrett Wollman Cc: dg@root.com, freebsd-current@FreeBSD.ORG Subject: Re: mbuf cluster problem continues!! References: <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess> <199806010520.WAA09567@implode.root.com> <199806011626.MAA22057@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit In-Reply-To: <199806011626.MAA22057@khavrinen.lcs.mit.edu>; from Garrett Wollman on Mon, Jun 01, 1998 at 12:26:41PM -0400 Organization: Demos Company, Ltd., Moscow, Russian Federation. X-Point-of-View: Gravity is myth, - the earth sucks. X-Useless-Header: Look ma! It's a # sign! Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, On Mon, Jun 01, 1998 at 12:26:41PM -0400, Garrett Wollman wrote: # < said: # > I've seen several reports of mbuf leaks in the specific case of running # > squid proxy servers. # Not seen here. # root@xyz(4)$ netstat -m # 825/1408 mbufs in use: Oh well, it's not squid what is definite culprit here, not closing tcp connections: let's take a machine, which is attacked by clients, is being agressively used nfs server and doesn't even have any services besides nfs, which could leave tcp connections not closed: {zz}~/# netstat -m 10577/10688 mbufs in use: 10057 mbufs allocated to data 520 mbufs allocated to packet headers 451/728 mbuf clusters in use 2792 Kbytes allocated to network (79% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines {zz}~/# uptime 6:44ÐÐ up 1 day, 8:57, 21 users, load averages: 1.85, 1.80, 1.62 NMBCLUSTERS are 24k, and still the machine will leak mbuf's once a week. {zz}~/# nfsstat -w 1 Getattr Lookup Readlink Read Write Rename Access Readdir Client: 0 0 0 0 0 0 0 0 Server: 4919834 3679844 37708 1306501 1102222 17918 121153149 48113 ... This machine usually runs some 20-200 simultaneous sendmails, 20-100 interactive (read: ~shell) users, up to 5 nfs clients, ~50 simulateneous httpd's. Taking a look at it's neighbour, a virtual web/ftp server: {xx}~/# netstat -m 1813/4256 mbufs in use: 1203 mbufs allocated to data 609 mbufs allocated to packet headers 1 mbufs allocated to socket names and addresses 1150/2802 mbuf clusters in use 6136 Kbytes allocated to network (41% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines {xx}~/# uptime 7:07ÐÐ up 40 days, 3:11, 11 users, load averages: 1.07, 0.89, 0.96 {xx}~/# nfsstat -w 1 Getattr Lookup Readlink Read Write Rename Access Readdir Client: 70935468 45165217 772137 7905938 20548126 358237 -2070886142 218656 ^^^^^^^^^^^ Ouch. Interesting, eh? This one is the above mentioned zz nfs client, and the other difference is that it doesn't handle pop clients and has less sendmail's. Plus, which is important, it _is_ a caching server (read: squid), serves not that much, though, some 40k requests/day. Although, it does exceed mbuf's once in a while, not once per week, though, as you might see from uptime. {zz}~/# netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 180.178.31.240.21491 128.50.150.242.64 -225392640 tcp 0 0 148.229.162.242.17651 128.121.206.242.206 -225392640 tcp 0 0 20.85.153.242.18419 128.179.223.242.19 -225392640 ^^^^^^^^^^ Charming.. Btw, what's that? # Of course, it's not really working that hard. # -- #Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same Of course, both are current, as of 1998/04/20. And yes, that's a machines in productions use; yes, we know we shouldn't... but -stable lacks SMP and tons of other usefull features. My 2 kopeks. -- -mishania To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 08:33:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA14485 for freebsd-current-outgoing; Tue, 2 Jun 1998 08:33:48 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA14479 for ; Tue, 2 Jun 1998 08:33:44 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg by adelphi.physics.adelaide.edu.au (5.65/AndrewR-930902) id AA04217; Wed, 3 Jun 1998 01:03:42 +0930 Received: by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA11417; Wed, 3 Jun 1998 02:01:44 +0930 Date: Wed, 3 Jun 1998 02:01:44 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Eivind Eklund Cc: freebsd-current@FreeBSD.ORG Subject: Re: removing /usr/src/sys/compile/XXX In-Reply-To: <19980602163053.16755@follo.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 2 Jun 1998, Eivind Eklund wrote: > > I eventually tracked down a problem I was having building new kernels (it > > was complaining about a ton of undefined vop_* symbols in vnode_if.h) to > > the fact that these hadnt been regenerated properly. > > Please give more details about this failure - this shouldn't happen. Actually - thinking about it more (and testing the hypothesis by attempting a kernel build), I believe what may have happened is that vnode_if.h somehow gained an extra copy of itself - the file doubled to 47k in length and this problem persisted through multiple make clean;make depends. I've tested the effect this has and it's definitely what I was seeing: kernel compile proceeds most of the way through then dies with a lot of crap like you'd expect: ... vnode_if.h:1090: warning: previous declaration of `vop_strategy_desc' vnode_if.h:2212: warning: redundant redeclaration of `VOP_STRATEGY' in same scop e vnode_if.h:1094: warning: previous declaration of `VOP_STRATEGY' vnode_if.h:2214: redefinition of `VOP_STRATEGY' vnode_if.h:1094: `VOP_STRATEGY' previously defined here vnode_if.h:2223: redefinition of `struct vop_bwrite_args' ... Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 09:31:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25403 for freebsd-current-outgoing; Tue, 2 Jun 1998 09:31:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA25380 for ; Tue, 2 Jun 1998 09:31:02 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id LAA07012 for ; Tue, 2 Jun 1998 11:31:02 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id LAA21798; Tue, 2 Jun 1998 11:31:01 -0500 (CDT) Message-ID: <19980602113100.12385@mcs.net> Date: Tue, 2 Jun 1998 11:31:00 -0500 From: Karl Denninger To: current@FreeBSD.ORG Subject: Probelm with libskey and lpr continues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The following problem has been in make world's now for months, and still continues. bash# cc -pipe -DPERMIT_CONSOLE -D_SKEY_INTERNAL -I/usr/src/lib/libskey -W -Wall -Werror -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/lib/libskey/skeyaccess.c -o skeyaccess.o cc1: warnings being treated as errors /usr/obj/usr/src/tmp/usr/include/stdio.h:365: warning: `__sputc' defined but not used /usr/obj/usr/src/tmp/usr/include/ctype.h:146: warning: `__maskrune' defined but not used /usr/obj/usr/src/tmp/usr/include/ctype.h:160: warning: `__toupper' defined but not used /usr/obj/usr/src/tmp/usr/include/ctype.h:167: warning: `__tolower' defined but not used The "problem" is not real, since these warnings are spurious (its caused by the definitions themselves; nobody ever references them in the file in question). The -Wall causes this. The lpr package suffers from the same problem. Removing the -Wall "cures" this. I understand this is a workaround, but this is preventing a "make world" on a clean disk structure from working. Will someone please commit either a real fix, or a removal of the -Wall in the Makefiles affected? - -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 09:31:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25467 for freebsd-current-outgoing; Tue, 2 Jun 1998 09:31:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA25436; Tue, 2 Jun 1998 09:31:23 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199806021631.JAA25436@hub.freebsd.org> Subject: Re: mbuf cluster problem continues!! In-Reply-To: <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess> from Andrew Specht at "Jun 1, 98 10:28:03 am" To: andrew@iaccess.com.au (Andrew Specht) Date: Tue, 2 Jun 1998 09:31:21 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Specht wrote: > Hi again, > > I'm still having the same mbuf cluster problem. I'm running squid with a 14 > Gig Cache and getting up to 200 connections a second. The problem is that > mbuf clusters in-use just keeps on rising until it gets to the peak and then > the whole thing crashes. I've got it set to 22000 at the moment, but last > time they went up to nearly 10000 before it crashed. Is there a problem > with leaking mbuf clusters still, or is that what they are supposed to do? > > If this has been addressed already and i missed it, i would be glad if > someone could bring me up to date :) > > Thanks again Andrew, which ethernet card(s) are you using? the ep driver is known to have some problems. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 10:20:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA03048 for freebsd-current-outgoing; Tue, 2 Jun 1998 10:20:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from puck.nether.net (jared@puck.nether.net [204.42.254.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA03041 for ; Tue, 2 Jun 1998 10:20:08 -0700 (PDT) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.0/8.7.3) id NAA21412; Tue, 2 Jun 1998 13:20:02 -0400 Message-ID: <19980602132002.B21220@puck.nether.net> Date: Tue, 2 Jun 1998 13:20:02 -0400 From: Jared Mauch To: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= Cc: freebsd-current@FreeBSD.ORG Subject: Re: kernel panics.. References: <19980527002414.A3954@puck.nether.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.91.1i In-Reply-To: =?iso-8859-1?Q?=3Cxzp3edvkd3b=2Efsf=40gjallarhorn=2Eifi=2Euio=2Eno=3E=3B?= =?iso-8859-1?Q?_from_Dag-Erling_Coidan_Sm=F8rgrav__on_Wed=2C_May_27=2C_1?= =?iso-8859-1?Q?998_at_04:22:48PM_+0200?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any ideas yet of what's causing this yet? Very obnoxious as FreeBSD is the only OS doing this... Thanks. - Jared On Wed, May 27, 1998 at 04:22:48PM +0200, Dag-Erling Coidan Smørgrav wrote: > Jared Mauch writes: > > Anyone want the source for my program that nukes the system? :) > > Yes, please, thankyouverymuch :) > > -- > Noone else has a .sig like this one. -- Work: jared@qual.net - We Make The Internet Work for Your Business 9-5pm(ET) 800 637 4424x2634 - 24x7 NOC - 800 424 3223 pgp key available via finger from jared@puck.nether.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 11:13:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12149 for freebsd-current-outgoing; Tue, 2 Jun 1998 11:13:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles327.castles.com [208.214.167.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12095; Tue, 2 Jun 1998 11:12:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00985; Tue, 2 Jun 1998 10:07:18 -0700 (PDT) Message-Id: <199806021707.KAA00985@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Subject: Re: DPT Redux In-reply-to: Your message of "Mon, 01 Jun 1998 21:21:13 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jun 1998 10:07:18 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I did find a window with these conditions: > > * During boot (and only during boot), while the scsi abstraction layer > still runs in polled mode (interrupts off). > > * The DPT controller has enough bandwidth to accept commands one at a time. > > * The DPT controller then delays responding to commands 1,000 longer than > the SCSI abstraction layer (sd.c, in this case) specified. In 3.0 I > reduced this to only 50 times longer. > > * When command completion is probed, the DPT will NOT report error, but > successful condition, or no condition at all. > > Under these conditions, the DPT driver could return a ``successful'' > completion code. In this case, the abstraction layer will post the device > with whatever capacity value was there before calling the DPT driver. > It is possible, under these conditions that nonsense will be assumed. > The panic may be triggered by the SCSI abstraction layer trying to > interpret some of its trash as valid data. ... > Summary: Theyre is a bit of ``pointing elsewhere'' here as, after thorough > review, I do not see the memory failure in the driver. Neither do I see > any other defect. Then could you characterise "returning a successful completion code for an incomplete/failed transfer"? The SCSI stack has to assume at this point that the transaction is complete, even though you're admitting that it's not. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 11:15:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12714 for freebsd-current-outgoing; Tue, 2 Jun 1998 11:15:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles327.castles.com [208.214.167.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12703 for ; Tue, 2 Jun 1998 11:15:29 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA01018; Tue, 2 Jun 1998 10:11:01 -0700 (PDT) Message-Id: <199806021711.KAA01018@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Scot W. Hetzel" cc: "Mike Smith" , current@FreeBSD.ORG Subject: Re: ppp cannot find libalias In-reply-to: Your message of "Mon, 01 Jun 1998 18:19:46 CDT." <046601bd8db3$c49fa0a0$c3e0d9cf@admin.westbend.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jun 1998 10:11:01 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: Mike Smith > > >Not even the hint cache. Note that this is the a.out rtld; I don't > >know (yet) where to look for the ELF one. > > > Mike, I cleaned up your code, I HATE goto's. Terry likes them. I find them easier to deal with than insane nesting. Unfortunately I can't use your diff as-is as it appears to have suffered catastrophic whitespace damage, but I take your point. Are there any disagreements with the basic idea, ie. use rtfindfile() to locate files requested by dlopen() if they do not contain path components? > Scot > > anon_open(); > > + if (path == NULL) > + return NULL; > + > + /* If path is not qualified, search for it on the standard searchpath */ > + name = (strchr(path, '/') != NULL) ? strdup(path) : rtfindfile(path); > + > /* Map the object, and the objects on which it depends */ > smp = map_object(path, (struct sod *) NULL, (struct so_map *) NULL); > - if(smp == NULL) /* Failed */ > - return NULL; > + if(smp != NULL) /* Succeeded */ > { > LM_PRIVATE(smp)->spd_flags |= RTLD_DL; > > /* Relocate and initialize all newly-mapped objects */ > - if(link_map_tail != old_tail) { /* We have mapped some new objects */ > + if(link_map_tail != old_tail) && (reloc_dag(smp, bind_now) != -1) > - if(reloc_dag(smp, bind_now) == -1) /* Failed */ > - return NULL; > init_dag(smp); > else > + smp = NULL; > -} > > unmaphints(); > anon_close(); > } > + free(name); > return smp; > } > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 12:56:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA28440 for freebsd-current-outgoing; Tue, 2 Jun 1998 12:56:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA28434 for ; Tue, 2 Jun 1998 12:56:14 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id MAA28485; Tue, 2 Jun 1998 12:56:09 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd028403; Tue Jun 2 12:56:04 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA03610; Tue, 2 Jun 1998 12:55:50 -0700 (MST) From: Terry Lambert Message-Id: <199806021955.MAA03610@usr06.primenet.com> Subject: Re: I see one major problem with DEVFS... To: mike@smith.net.au (Mike Smith) Date: Tue, 2 Jun 1998 19:55:49 +0000 (GMT) Cc: tlambert@primenet.com, mike@smith.net.au, bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG In-Reply-To: <199806020042.RAA02307@dingo.cdrom.com> from "Mike Smith" at Jun 1, 98 05:42:07 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Since it's the same space, you could hard link from your devfs into > > the empty one to create the nodes. > > > > This is even better, since it allows a chroot in a chroot to never > > inherit more than the parent. 8-). > > However it is problematic to link outside of a chroot, and it may not > always be desirable to be so fancy (eg. when using chroot for > engineering rather than security reasons). Not the same thing. I'm talking about: -----------+---+-------------------+-----------+------- chroot 2 | | | | -------+---+---+-----------+-------+-----------+------- chroot 1 | | | | | | ---+---+---+---+---+---+---+---+---+---+---+---+---+--- system | | | | | | | | | | | | | ---+---+---+---+---+---+---+---+---+---+---+---+---+--- template chroot 1 and chroot 2 were populated from system using the link(2) call, which worked "across" devfs instances. > > > DEVFS is per-system. You cannot export a DEVFS via NFS (it makes no > > > sense to do so - devices there are only relevant to the host system). > > No, it's a direct feature of DEVFS, or more particularly to achieve the > results desired by the original poster you cannot use an NFS-mounted > devfs. ??? You'd have to restate your understanding of the results; from mine, I was under the impression they were talking about remote mounts of NFS roots. There is also the problem of non-devfs capable kernels remote NFS root mounting from FreeBSD -- this one requires the ability referesent device node for remote use, even if they locally have no meaning. > > For normal devices that are only operated on via open/close/read/write, > > it makes sens to export a devfs. > > No, it does not. There is no identifying information exported with a > DEVFS node that allows the local system to correctly connect a node > from a remote DEVFS (which may not map to a local driver) to a local > device. The vnode *is* the device. No connection is necessary. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 13:12:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA01796 for freebsd-current-outgoing; Tue, 2 Jun 1998 13:12:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA01542 for ; Tue, 2 Jun 1998 13:11:43 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 22441 invoked by uid 1000); 2 Jun 1998 21:13:05 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199806021707.KAA00985@antipodes.cdrom.com> Date: Tue, 02 Jun 1998 17:13:05 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT Redux Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am deleting the cross-post to current.... On 02-Jun-98 Mike Smith wrote: ... > Then could you characterise "returning a successful completion code for > an incomplete/failed transfer"? The SCSI stack has to assume at this > point that the transaction is complete, even though you're admitting > that it's not. There was one specific failure mode, yes. To get there, especially on a RAID array, you had to have so many ducks lined up: * DPT free enough to accept commands * DPT so busy it will not reply to INQUIRY on a RAID array (there is no SCSI bus involved here) * DPT not setting the hardware registers as busy, while oh, so busy. This condition had to persist for several minutes. The patch checked in against current fixes that. the same patch will/should be checked in against 2.2 any moment now. BTW, for this to exist, the DPT firmware has to be rather sick. I can rplicate this scsnario with some broken, unpublished versions of the firmware. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 13:53:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA07619 for freebsd-current-outgoing; Tue, 2 Jun 1998 13:53:56 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from kstreet.interlog.com (kws@kstreet.interlog.com [198.53.146.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07604 for ; Tue, 2 Jun 1998 13:53:51 -0700 (PDT) (envelope-from kws@kstreet.interlog.com) Received: (from kws@localhost) by kstreet.interlog.com (8.8.8/8.8.8) id QAA03026; Tue, 2 Jun 1998 16:53:46 -0400 (EDT) (envelope-from kws) To: current@FreeBSD.ORG Subject: panic mounting dos floppy From: Kevin Street Date: 02 Jun 1998 16:53:46 -0400 Message-ID: <87af7vmso5.fsf@kstreet.interlog.com> Lines: 40 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got a mostly repeatable (4 for 5) panic today while mounting a dos floppy following an unsuccessful mount. I'd accidentally done: # mount /dev/fd0 /dev/fd0 on /mnt/unix/a: Incorrect super block. # mount /mnt/dos/a I have the following in my /etc/fstab: (same device, different fs types and mount points) /dev/fd0 /mnt/unix/a ufs rw,noauto 0 0 /dev/fd0 /mnt/dos/a msdos rw,noauto,noexec 0 0 I can mount and unmount /mnt/dos/a with no problems as long as I don't do the failing ufs type mount first. This is on FreeBSD-current from about May 26. I have `options BOUNCE_BUFFERS' in the kernel. The panic is (this is the shortest one): (kgdb) where #0 boot (howto=256) at ../../kern/kern_shutdown.c:281 #1 0xf0114a26 in panic ( fmt=0xf01ac094 "isa_dmacheck: no physical page present") at ../../kern/kern_shutdown.c:421 #2 0xf01ac119 in isa_dmarangecheck ( va=0xf446b000
, length=512, chan=2) at ../../i386/isa/isa.c:900 #3 0xf01abe26 in isa_dmastart (flags=537919504, addr=0xf446b000
, nbytes=512, chan=2) at ../../i386/isa/isa.c:764 #4 0xf01aa015 in fdstate (fdcu=0, fdc=0xf0215a40) at ../../i386/isa/fd.c:1640 #5 0xf01a9acb in fdintr (fdcu=0) at ../../i386/isa/fd.c:1445 (kgdb) -- Kevin Street street@iName.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 15:13:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22029 for freebsd-current-outgoing; Tue, 2 Jun 1998 15:13:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from freya.circle.net (freya.circle.net [209.95.95.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22008; Tue, 2 Jun 1998 15:13:14 -0700 (PDT) (envelope-from tcobb@staff.circle.net) Received: by freya.circle.net with Internet Mail Service (5.5.1960.3) id ; Tue, 2 Jun 1998 18:12:38 -0400 Message-ID: <509A2986E5C5D111B7DD0060082F32A402FB1D@freya.circle.net> From: tcobb To: "'shimon@simon-shapiro.org'" , Mike Smith Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" Subject: RE: DPT Redux Date: Tue, 2 Jun 1998 18:12:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: Simon Shapiro [mailto:shimon@simon-shapiro.org] > I am deleting the cross-post to current.... > > On 02-Jun-98 Mike Smith wrote: > ... > > > Then could you characterise "returning a successful > completion code for > > an incomplete/failed transfer"? The SCSI stack has to > assume at this > > point that the transaction is complete, even though you're > admitting > > that it's not. > > There was one specific failure mode, yes. To get there, > especially on a > RAID array, you had to have so many ducks lined up: > > * DPT free enough to accept commands > * DPT so busy it will not reply to INQUIRY on a RAID array > (there is no > SCSI bus involved here) > * DPT not setting the hardware registers as busy, while oh, so busy. > > This condition had to persist for several minutes. The patch > checked in > against current fixes that. the same patch will/should be checked in > against 2.2 any moment now. > > BTW, for this to exist, the DPT firmware has to be rather sick. I can > rplicate this scsnario with some broken, unpublished versions of the > firmware. In your test case, please try to replicate this problem with the firmware version available for download from DPT's site right now. That was the version I used on my card (or, at least, the one available mid last week). -Troy Cobb Circle Net, Inc. http://www.circle.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 15:22:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23416 for freebsd-current-outgoing; Tue, 2 Jun 1998 15:22:56 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pcpsj.pfcs.com (harlan.fred.net [205.252.219.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23410 for ; Tue, 2 Jun 1998 15:22:53 -0700 (PDT) (envelope-from Harlan.Stenn@pfcs.com) Received: from mumps.pfcs.com [192.52.69.11] (HELO mumps.pfcs.com) by pcpsj.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Tue, 2 Jun 1998 18:22:49 -0400 (EDT) Received: from brown.pfcs.com [192.52.69.44] (HELO brown.pfcs.com) by mumps.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Tue, 2 Jun 1998 15:22:44 -0700 (PDT) Received: from localhost [127.0.0.1] (HELO brown.pfcs.com) by brown.pfcs.com (8.8.8/8.8.8) via ESMTP id for ; Tue, 2 Jun 1998 18:22:47 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: current@FreeBSD.ORG Subject: TenDRA compiler? X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n:c(Cc* $cbtusxDP6T)Hr'k&zrwq0.3&~bAI~YJco[r.mE+K|(q]F=ZNXug:s6tyOk{VTqARy0#axm6BWti9C d Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jun 1998 18:22:46 -0400 Message-ID: <26692.896826166@brown.pfcs.com> From: Harlan Stenn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just installed the TenDRA compiler on one of my boxes (I used the port). Unfortunately, tcc doesn't seem to see any of the system #include files. My initial read of the docs hasn't shed any light on the problem. What did I miss? H To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 15:43:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA25341 for freebsd-current-outgoing; Tue, 2 Jun 1998 15:43:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA25323 for ; Tue, 2 Jun 1998 15:43:36 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id IAA21711; Wed, 3 Jun 1998 08:53:01 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199806022253.IAA21711@cimlogic.com.au> Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199806021955.MAA03610@usr06.primenet.com> from Terry Lambert at "Jun 2, 98 07:55:49 pm" To: tlambert@primenet.com (Terry Lambert) Date: Wed, 3 Jun 1998 08:53:01 +1000 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > -----------+---+-------------------+-----------+------- chroot 2 > | | | | > -------+---+---+-----------+-------+-----------+------- chroot 1 > | | | | | | > ---+---+---+---+---+---+---+---+---+---+---+---+---+--- system > | | | | | | X | | | | | | | > ---+---+---+---+---+---+---+---+---+---+---+---+---+--- template -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 17:43:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15627 for freebsd-current-outgoing; Tue, 2 Jun 1998 17:43:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15613 for ; Tue, 2 Jun 1998 17:43:07 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id RAA03024; Tue, 2 Jun 1998 17:43:00 -0700 (PDT) (envelope-from jdp) Message-Id: <199806030043.RAA03024@austin.polstra.com> To: kkennawa@physics.adelaide.edu.au Subject: Re: Old kernels not compatible with elf-changes? In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: current@FreeBSD.ORG Date: Tue, 02 Jun 1998 17:43:00 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Kris Kennaway wrote: > Since there was something obviously wrong with the kernel I was using > (though I hadnt had a problem for the prior 4 days) I tried to reboot > into the previous kernel of May 26. So far the disk seems to have > maintained integrity, but this kernel appears to be incompatible with > one of the ld changes since then: > > [morden|root] 23:07 /usr/src/sys/compile/MORDEN ls -l /usr/bin/ld > -r-xr-xr-x 9 bin bin 12288 May 27 22:20 /usr/bin/ld* > [morden|root] 23:08 /usr/src/sys/compile/MORDEN ld > /usr/bin/ld: Bad address. > [morden|root] 23:08 /usr/src/sys/compile/MORDEN file /usr/bin/ld > /usr/bin/ld: FreeBSD/i386 compact demand paged dynamically linked executable ... > Can anyone shed some light as to whether the above problem (specifically, > pre-elf stage 2 kernels not being able to work with post-elf stage 2 > world) is general or something which is peculiar to me? I can't think of any reason why "ld" would care which kernel it was running under. I notice that your "ls" still works, and I doubt that "ld" does very much that "ls" doesn't do too, from the kernel's point of view. So I think your "ld" binary is corrupted. Just for interest's sake, it might be fun to run it under ktrace. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 18:03:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19007 for freebsd-current-outgoing; Tue, 2 Jun 1998 18:03:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.westbend.net (ns1.westbend.net [207.217.224.194]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA18988 for ; Tue, 2 Jun 1998 18:03:51 -0700 (PDT) (envelope-from hetzels@westbend.net) Received: from admin (admin.westbend.net [207.217.224.195]) by mail.westbend.net (8.8.8/8.8.8) with SMTP id UAA13793; Tue, 2 Jun 1998 20:03:21 -0500 (CDT) (envelope-from hetzels@westbend.net) Message-ID: <00e001bd8e8b$66ef5080$c3e0d9cf@admin.westbend.net> From: "Scot W. Hetzel" To: "Mike Smith" Cc: Subject: Re: ppp cannot find libalias Date: Tue, 2 Jun 1998 20:03:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: Mike Smith >Unfortunately I can't use your diff as-is as it appears to have suffered >catastrophic whitespace damage, but I take your point. > I was being lazy, I edited your code directly in the mail program. >Are there any disagreements with the basic idea, ie. use rtfindfile() >to locate files requested by dlopen() if they do not contain path >components? > No objection if it works. But, when I compile I get a warning for rtfindfile, as shown below: >> + /* If path is not qualified, search for it on the standard searchpath */ >> + name = (strchr(path, '/') != NULL) ? strdup(path) : rtfindfile(path); >> + cc -O2 -pipe -I/usr/src/libexec/rtld-aout -I/usr/src/libexec/rtld-aout/i386 -fpic -fno-function-cse -DRTLD -Wall -c /usr/src/libexec/rtld-aout/rtld.c /usr/src/libexec/rtld-aout/rtld.c: In function `__dlopen': /usr/src/libexec/rtld-aout/rtld.c:1913: warning: passing arg 1 of `rtfindfile' discards `const' from pointer target type cc -O2 -pipe -I/usr/src/libexec/rtld-aout -I/usr/src/libexec/rtld-aout/i386 -fpic -fno-function-cse -DRTLD -Wall -nostdlib -Wl,-Bshareable,-Bsymbolic ,-assert,nosymbolic -o ld.so mdprologue.o rtld.o shlib.o md.o upport.o -lc_pic -lgcc_pic Scot NOTE: rtld.c (v1.53) has moved to libexec/rtld-aout. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 18:07:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19772 for freebsd-current-outgoing; Tue, 2 Jun 1998 18:07:29 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.camalott.com (root@[208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19680 for ; Tue, 2 Jun 1998 18:06:58 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-120.camalott.com [208.229.74.120] (may be forged)) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id UAA28607; Tue, 2 Jun 1998 20:05:14 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id WAA02058; Fri, 29 May 1998 22:12:28 -0500 (CDT) (envelope-from joelh) Date: Fri, 29 May 1998 22:12:28 -0500 (CDT) Message-Id: <199805300312.WAA02058@detlev.UUCP> To: tlambert@primenet.com CC: eivind@yes.no, rnordier@nordier.com, current@FreeBSD.ORG In-reply-to: <199805292120.OAA14978@usr04.primenet.com> (message from Terry Lambert on Fri, 29 May 1998 21:20:43 +0000 (GMT)) Subject: Re: Fix for undefined "__error" and discussion of shared object versioning From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199805292120.OAA14978@usr04.primenet.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>> * Possibilities for exploiting the cross-CPU nature of XANDF >> How are XANDF's cross-cpu capabilities more powerful than gcc's? > You can distribute "binaries" and localize them to an architecture at > install time. > This means you can distribute commercial code that will run on x86, > Alpha, MIPS, PPC, 68k, VAX, SPARC, etc., etc.. Does it have problems with endianness, et al? That is, if a program, at compile time, needs to know its endianness (or another architecture-dependant detail), does it still work? > For FreeBSD, this means one "ports" CDROM will work for all future > architectures. I'll consider that an advantage when I see more architectures. > It also means that one "ports" CDROM will work for FreeBSD 3.x and > FreeBSD 235.x. A case of Bushmill's goes to the first person who shows me a port that bitrot doesn't kill before FreeBSD 235. (Memo to myself: add this to my will...) >>> * Better error checking/control >> How do you mean? > Full mapping of the error checking and warning space. GCC only maps > the parts that they thought were important, and then it's done pretty > haphazardly. Mapping, you mean, to diagnostics? -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 18:09:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA20291 for freebsd-current-outgoing; Tue, 2 Jun 1998 18:09:20 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from engulf.net (brandon@engulf.com [207.96.124.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA20260 for ; Tue, 2 Jun 1998 18:09:06 -0700 (PDT) (envelope-from brandon@engulf.net) Received: from localhost (brandon@localhost) by engulf.net (8.8.8/8.8.8) with SMTP id VAA03692 for ; Tue, 2 Jun 1998 21:05:35 -0400 (EDT) Date: Tue, 2 Jun 1998 21:05:25 -0400 (EDT) From: Brandon Lockhart To: current@FreeBSD.ORG Subject: Let me guess... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, let me guess, I also missed the posts about the ppp -alias. For some reason, I can connect to anything outside the LAN from an internal machine. Is this the IP ALIASING headers I have been seeing lately? ,----------------------. | Brandon Lockhart | `----------,-----------'------------. | brandon@engulf.net | `------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 18:17:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22312 for freebsd-current-outgoing; Tue, 2 Jun 1998 18:17:33 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (root@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22290 for ; Tue, 2 Jun 1998 18:17:27 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA09013; Tue, 2 Jun 1998 16:10:02 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd008861; Tue Jun 2 16:09:35 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA23355; Tue, 2 Jun 1998 16:09:27 -0700 (MST) From: Terry Lambert Message-Id: <199806022309.QAA23355@usr01.primenet.com> Subject: Re: ppp cannot find libalias To: mike@smith.net.au (Mike Smith) Date: Tue, 2 Jun 1998 23:09:27 +0000 (GMT) Cc: hetzels@westbend.net, mike@smith.net.au, current@FreeBSD.ORG In-Reply-To: <199806021711.KAA01018@antipodes.cdrom.com> from "Mike Smith" at Jun 2, 98 10:11:01 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > >Not even the hint cache. Note that this is the a.out rtld; I don't > > >know (yet) where to look for the ELF one. > > > > Mike, I cleaned up your code, I HATE goto's. > > Terry likes them. I find them easier to deal with than insane nesting. I don't like them or not like them; I think it's silly to use bizarre constructs to avoid indentation, ie: for(;;) { if( aaa) break; if( bbb) break; if( ccc) break; if( ddd) break; if( eee) break; break; } You might as well use "?:" constructs. 8-|. What I like is single-entry/single-exit, and if it occasionally takes a goto to make this work, I prefer a goto (which has a specific, named target that I can search for) to a break (which may dump me out after any particular closing brace, and I have to go searching to find out which one). People who hate goto's for the sake of hating goto's don't understand that no matter how hard they try, the compiler is going to generate branch and jump instructions, and there's nothing they can do about it in a high level language, except cause the optimizer to invoke loop register preload and unrolling optimizations erroneously. A goto is a perfectly valid way to handle an exceptional condition; if you see you are skipping a lot of code with one, you have probably failed to correctly perform the necessary functional decomposition on your code; shame on you. There are numerous examples of this in the FreeBSD kernel, unfortunately. If you see yourself using a lot of goto's, well, it's either beta code that you've written that way for program flow readability (don't expect or suggest that it should be checked in), or you're optimizing for something other than the most common case and you are probably writing code that's a lot slower than it ought to be. For non-beta code, where it's now known to work, converting goto's to negative logic is a win (it saves branch instructions). > Are there any disagreements with the basic idea, ie. use rtfindfile() > to locate files requested by dlopen() if they do not contain path > components? I think it's fine. That's why I didn't bitch the first time it went by... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 20:08:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08480 for freebsd-current-outgoing; Tue, 2 Jun 1998 20:08:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08262 for ; Tue, 2 Jun 1998 20:07:33 -0700 (PDT) (envelope-from semen@iclub.nsu.ru) Received: from localhost (semen@localhost) by iclub.nsu.ru (8.8.8/8.8.5) with SMTP id KAA21017 for ; Wed, 3 Jun 1998 10:11:26 +0700 (NSS) Date: Wed, 3 Jun 1998 10:11:26 +0700 (NSS) From: Ustimenko Semen To: FreeBSD-current@FreeBSD.ORG Subject: volonteers need to test tx driver :-) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-535351022-896843486=:20905" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-535351022-896843486=:20905 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello! Here is new version of driver, not commited yet. It have a lot of debug output, and will dump card state on any error if debug flag on interface is on. Best regards. P.S: It is NEW driver, not only debug output enabled. --0-535351022-896843486=:20905 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="smc83c170.h" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: /sys/pci/smc83c170.h LyotDQogKiBDb3B5cmlnaHQgKGMpIDE5OTcgU2VtZW4gVXN0aW1lbmtvDQog KiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KICoNCiAqIFJlZGlzdHJpYnV0aW9u IGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Ig d2l0aG91dA0KICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3Zp ZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zDQogKiBhcmUgbWV0 Og0KICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3Qg cmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQNCiAqICAgIG5vdGljZSwgdGhp cyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lci4NCiAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBt dXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0DQogKiAgICBub3Rp Y2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5n IGRpc2NsYWltZXIgaW4gdGhlDQogKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0 aW9uLg0KICoNCiAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhF IEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQNCiAqIEFO WSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFRIRQ0KICogSU1QTElFRCBXQVJSQU5USUVT IE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UNCiAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQg U0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFDQog KiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJ QUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTA0KICogREFNQUdFUyAo SU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9G IFNVQlNUSVRVVEUgR09PRFMNCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVT RSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9O KQ0KICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElB QklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QNCiAqIExJQUJJ TElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJX SVNFKSBBUklTSU5HIElOIEFOWSBXQVkNCiAqIE9VVCBPRiBUSEUgVVNFIE9G IFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lC SUxJVFkgT0YNCiAqIFNVQ0ggREFNQUdFLg0KICoNCiAqICAgICAgJElkOiBz bWM4M2MxNzAuaCx2IDEuMTEgMTk5OC8wNS8yNCAxOTowNzowNSBnYWx2IEV4 cCAkDQogKg0KICovDQoNCi8qDQogKiBDb25maWd1cmF0aW9uDQogKi8NCiNk ZWZpbmUgRVBJQ19NQVhfREVWSUNFUwk0DQoNCiNkZWZpbmUgVFhfUklOR19T SVpFCQk4DQojZGVmaW5lIFJYX1JJTkdfU0laRQkJOA0KI2RlZmluZSBFUElD X0ZVTExfRFVQTEVYCTENCiNkZWZpbmUgRVBJQ19IQUxGX0RVUExFWAkwDQoj ZGVmaW5lIEVUSEVSX01BWF9GUkFNRV9MRU4JKEVUSEVSX01BWF9MRU4gKyBF VEhFUl9DUkNfTEVOKQ0KDQovKiBQQ0kgaWRlbnRpZmljYXRpb24gKi8NCiNk ZWZpbmUgU01DX1ZFTkRPUklECQkweDEwQjgNCiNkZWZpbmUgQ0hJUElEXzgz QzE3MAkJMHgwMDA1DQojZGVmaW5lCVBDSV9WRU5ET1JJRCh4KQkJKCh4KSAm IDB4RkZGRikNCiNkZWZpbmUJUENJX0NISVBJRCh4KQkJKCgoeCkgPj4gMTYp ICYgMHhGRkZGKQ0KDQovKiBQQ0kgY29uZmlndXJhdGlvbiAqLw0KI2RlZmlu ZQlQQ0lfQ0ZJRAkweDAwCS8qIENvbmZpZ3VyYXRpb24gSUQgKi8NCiNkZWZp bmUJUENJX0NGQ1MJMHgwNAkvKiBDb25maWd1cnRpb24gQ29tbWFuZC9TdGF0 dXMgKi8NCiNkZWZpbmUJUENJX0NGUlYJMHgwOAkvKiBDb25maWd1cmF0aW9u IFJldmlzaW9uICovDQojZGVmaW5lCVBDSV9DRkxUCTB4MGMJLyogQ29uZmln dXJhdGlvbiBMYXRlbmN5IFRpbWVyICovDQojZGVmaW5lCVBDSV9DQklPCTB4 MTAJLyogQ29uZmlndXJhdGlvbiBCYXNlIElPIEFkZHJlc3MgKi8NCiNkZWZp bmUJUENJX0NCTUEJMHgxNAkvKiBDb25maWd1cmF0aW9uIEJhc2UgTWVtb3J5 IEFkZHJlc3MgKi8NCiNkZWZpbmUJUENJX0NGSVQJMHgzYwkvKiBDb25maWd1 cmF0aW9uIEludGVycnVwdCAqLw0KI2RlZmluZQlQQ0lfQ0ZEQQkweDQwCS8q IENvbmZpZ3VyYXRpb24gRHJpdmVyIEFyZWEgKi8NCg0KI2RlZmluZQlQQ0lf Q09ORl9XUklURShyLCB2KQlwY2lfY29uZl93cml0ZShjb25maWdfaWQsIChy KSwgKHYpKQ0KI2RlZmluZQlQQ0lfQ09ORl9SRUFEKHIpCXBjaV9jb25mX3Jl YWQoY29uZmlnX2lkLCAocikpDQoNCi8qIEVQSUMncyByZWdpc3RlcnMgKi8N CiNkZWZpbmUJQ09NTUFORAkJMHgwMDAwDQojZGVmaW5lCUlOVFNUQVQJCTB4 MDAwNAkJLyogSW50ZXJydXB0IHN0YXR1cy4gU2VlIGJlbG93ICovDQojZGVm aW5lCUlOVE1BU0sJCTB4MDAwOAkJLyogSW50ZXJydXB0IG1hc2suIFNlZSBi ZWxvdyAqLw0KI2RlZmluZQlHRU5DVEwJCTB4MDAwQw0KI2RlZmluZQlOVkNU TAkJMHgwMDEwDQojZGVmaW5lCUVFQ1RMCQkweDAwMTQJCS8qIEVFUFJPTSBj b250cm9sICoqLw0KI2RlZmluZQlURVNUMQkJMHgwMDFDCQkvKiBYWFhYWCAq Lw0KI2RlZmluZQlDUkNDTlQJCTB4MDAyMAkJLyogQ1JDIGVycm9yIGNvdW50 ZXIgKi8NCiNkZWZpbmUJQUxJQ05UCQkweDAwMjQJCS8qIEZyYW1lVG9vTGFu ZyBlcnJvciBjb3VudGVyICovDQojZGVmaW5lCU1QQ05UCQkweDAwMjgJCS8q IE1pc3NlZEZyYW1lcyBlcnJvciBjb3VudGVycyAqLw0KI2RlZmluZQlNSUlD VEwJCTB4MDAzMA0KI2RlZmluZQlNSUlEQVRBCQkweDAwMzQNCiNkZWZpbmUJ TUlJQ0ZHCQkweDAwMzgNCiNkZWZpbmUgSVBHCQkweDAwM0MNCiNkZWZpbmUJ TEFOMAkJMHgwMDQwCQkvKiBNQUMgYWRkcmVzcyAqLw0KI2RlZmluZQlMQU4x CQkweDAwNDQJCS8qIE1BQyBhZGRyZXNzICovDQojZGVmaW5lCUxBTjIJCTB4 MDA0OAkJLyogTUFDIGFkZHJlc3MgKi8NCiNkZWZpbmUJSURfQ0hLCQkweDAw NEMNCiNkZWZpbmUJTUMwCQkweDAwNTAJCS8qIE11bHRpY2FzdCBmaWx0ZXIg dGFibGUgKi8NCiNkZWZpbmUJTUMxCQkweDAwNTQJCS8qIE11bHRpY2FzdCBm aWx0ZXIgdGFibGUgKi8NCiNkZWZpbmUJTUMyCQkweDAwNTgJCS8qIE11bHRp Y2FzdCBmaWx0ZXIgdGFibGUgKi8NCiNkZWZpbmUJTUMzCQkweDAwNUMJCS8q IE11bHRpY2FzdCBmaWx0ZXIgdGFibGUgKi8NCiNkZWZpbmUJUlhDT04JCTB4 MDA2MAkJLyogUnggY29udHJvbCByZWdpc3RlciAqLw0KI2RlZmluZQlUWENP TgkJMHgwMDcwCQkvKiBUeCBjb250cm9sIHJlZ2lzdGVyICovDQojZGVmaW5l CVRYU1RBVAkJMHgwMDc0DQojZGVmaW5lCVBSQ0RBUgkJMHgwMDg0CQkvKiBS eFJpbmcgYnVzIGFkZHJlc3MgKi8NCiNkZWZpbmUJUFJTVEFUCQkweDAwQTQN CiNkZWZpbmUJUFJDUFRIUgkJMHgwMEIwDQojZGVmaW5lCVBUQ0RBUgkJMHgw MEM0CQkvKiBUeFJpbmcgYnVzIGFkZHJlc3MgKi8NCiNkZWZpbmUJRVRYVEhS CQkweDAwREMNCg0KI2RlZmluZQlDT01NQU5EX1NUT1BfUlgJCTB4MDENCiNk ZWZpbmUJQ09NTUFORF9TVEFSVF9SWAkweDAyDQojZGVmaW5lCUNPTU1BTkRf VFhRVUVVRUQJMHgwNA0KI2RlZmluZQlDT01NQU5EX1JYUVVFVUVECTB4MDgN CiNkZWZpbmUJQ09NTUFORF9ORVhURlJBTUUJMHgxMA0KI2RlZmluZQlDT01N QU5EX1NUT1BfVERNQQkweDIwDQojZGVmaW5lCUNPTU1BTkRfU1RPUF9SRE1B CTB4NDANCiNkZWZpbmUJQ09NTUFORF9UWFVHTwkJMHg4MA0KDQovKiBUeCB0 aHJlc2hvbGQgKi8NCiNkZWZpbmUgVFhfRklGT19USFJFU0gJMHg4MAkJLyog MHg0MCBvciAweDEwICovDQoNCi8qIEludGVycnVwdCByZWdpc3RlciBiaXRz ICovDQojZGVmaW5lIElOVFNUQVRfUkNDCTB4MDAwMDAwMDENCiNkZWZpbmUg SU5UU1RBVF9IQ0MJMHgwMDAwMDAwMg0KI2RlZmluZSBJTlRTVEFUX1JRRQkw eDAwMDAwMDA0DQojZGVmaW5lIElOVFNUQVRfT1ZXCTB4MDAwMDAwMDgJDQoj ZGVmaW5lIElOVFNUQVRfUlhFCTB4MDAwMDAwMTAJDQojZGVmaW5lIElOVFNU QVRfVFhDCTB4MDAwMDAwMjANCiNkZWZpbmUgSU5UU1RBVF9UQ0MJMHgwMDAw MDA0MAkNCiNkZWZpbmUgSU5UU1RBVF9UUUUJMHgwMDAwMDA4MAkNCiNkZWZp bmUgSU5UU1RBVF9UWFUJMHgwMDAwMDEwMA0KI2RlZmluZSBJTlRTVEFUX0NO VAkweDAwMDAwMjAwDQojZGVmaW5lIElOVFNUQVRfUFJFSQkweDAwMDAwNDAw DQojZGVmaW5lIElOVFNUQVRfUkNUCTB4MDAwMDA4MDAJDQojZGVmaW5lIElO VFNUQVRfRkFUQUwJMHgwMDAwMTAwMAkvKiBPbmUgb2YgRFBFLEFQRSxQTUEs UFRBIGhhcHBlbmQgKi8JDQojZGVmaW5lIElOVFNUQVRfVU5VU0VEMQkweDAw MDAyMDAwDQojZGVmaW5lIElOVFNUQVRfVU5VU0VEMgkweDAwMDA0MDAwCQ0K I2RlZmluZSBJTlRTVEFUX0dQMgkweDAwMDA4MDAwCS8qIFBIWSBFdmVudCAq LwkNCiNkZWZpbmUgSU5UU1RBVF9JTlRfQUNUViAweDAwMDEwMDAwDQojZGVm aW5lIElOVFNUQVRfUlhJRExFCTB4MDAwMjAwMDANCiNkZWZpbmUgSU5UU1RB VF9UWElETEUJMHgwMDA0MDAwMA0KI2RlZmluZSBJTlRTVEFUX1JDSVAJMHgw MDA4MDAwMAkNCiNkZWZpbmUgSU5UU1RBVF9UQ0lQCTB4MDAxMDAwMDAJDQoj ZGVmaW5lIElOVFNUQVRfUkJFCTB4MDAyMDAwMDANCiNkZWZpbmUgSU5UU1RB VF9SQ1RTCTB4MDA0MDAwMDAJDQojZGVmaW5lCUlOVFNUQVRfUlNWCTB4MDA4 MDAwMDANCiNkZWZpbmUJSU5UU1RBVF9EUEUJMHgwMTAwMDAwMAkvKiBQQ0kg RmF0YWwgZXJyb3IgKi8NCiNkZWZpbmUJSU5UU1RBVF9BUEUJMHgwMjAwMDAw MAkvKiBQQ0kgRmF0YWwgZXJyb3IgKi8NCiNkZWZpbmUJSU5UU1RBVF9QTUEJ MHgwNDAwMDAwMAkvKiBQQ0kgRmF0YWwgZXJyb3IgKi8NCiNkZWZpbmUJSU5U U1RBVF9QVEEJMHgwODAwMDAwMAkvKiBQQ0kgRmF0YWwgZXJyb3IgKi8NCg0K I2RlZmluZQlHRU5DVExfU09GVF9SRVNFVAkJMHgwMDAwMDAwMQ0KI2RlZmlu ZQlHRU5DVExfRU5BQkxFX0lOVEVSUlVQVAkJMHgwMDAwMDAwMg0KI2RlZmlu ZQlHRU5DVExfU09GVFdBUkVfSU5URVJSVVBUCTB4MDAwMDAwMDQNCiNkZWZp bmUJR0VOQ1RMX1BPV0VSX0RPV04JCTB4MDAwMDAwMDgNCiNkZWZpbmUJR0VO Q1RMX09ORUNPUFkJCQkweDAwMDAwMDEwDQojZGVmaW5lCUdFTkNUTF9CSUdf RU5ESUFOCQkweDAwMDAwMDIwDQojZGVmaW5lCUdFTkNUTF9SRUNFSVZFX0RN QV9QUklPUklUWQkweDAwMDAwMDQwDQojZGVmaW5lCUdFTkNUTF9UUkFOU01J VF9ETUFfUFJJT1JJVFkJMHgwMDAwMDA4MA0KI2RlZmluZQlHRU5DVExfUkVD RUlWRV9GSUZPX1RIUkVTSE9MRDEyOAkweDAwMDAwMzAwDQojZGVmaW5lCUdF TkNUTF9SRUNFSVZFX0ZJRk9fVEhSRVNIT0xEOTYJMHgwMDAwMDIwMA0KI2Rl ZmluZQlHRU5DVExfUkVDRUlWRV9GSUZPX1RIUkVTSE9MRDY0CTB4MDAwMDAx MDANCiNkZWZpbmUJR0VOQ1RMX1JFQ0VJVkVfRklGT19USFJFU0hPTEQzMgkw eDAwMDAwMDAwDQojZGVmaW5lCUdFTkNUTF9NRU1PUllfUkVBRF9MSU5FCQkw eDAwMDAwNDAwDQojZGVmaW5lCUdFTkNUTF9NRU1PUllfUkVBRF9NVUxUSVBM RQkweDAwMDAwODAwDQojZGVmaW5lCUdFTkNUTF9TT0ZUV0FSRTEJCTB4MDAw MDEwMDANCiNkZWZpbmUJR0VOQ1RMX1NPRlRXQVJFMgkJMHgwMDAwMjAwMA0K I2RlZmluZQlHRU5DVExfUkVTRVRfUEhZCQkweDAwMDA0MDAwDQoNCiNkZWZp bmUJTlZDVExfRU5BQkxFX01FTU9SWV9NQVAJCTB4MDAwMDAwMDENCiNkZWZp bmUJTlZDVExfQ0xPQ0tfUlVOX1NVUFBPUlRFRAkweDAwMDAwMDAyDQojZGVm aW5lCU5WQ1RMX0dQMV9PVVRQVVRfRU5BQkxFCQkweDAwMDAwMDA0DQojZGVm aW5lCU5WQ1RMX0dQMl9PVVRQVVRfRU5BQkxFCQkweDAwMDAwMDA4DQojZGVm aW5lCU5WQ1RMX0dQMQkJCTB4MDAwMDAwMTANCiNkZWZpbmUJTlZDVExfR1Ay CQkJMHgwMDAwMDAyMA0KI2RlZmluZQlOVkNUTF9DQVJEQlVTX01PREUJCTB4 MDAwMDAwNDANCiNkZWZpbmUJTlZDVExfSVBHX0RFTEFZX01BU0soeCkJCSgo eCYweEYpPDw3KQ0KDQojZGVmaW5lCVJYQ09OX1NBVkVfRVJST1JFRF9QQUNL RVRTCTB4MDAwMDAwMDENCiNkZWZpbmUJUlhDT05fUkVDRUlWRV9SVU5UX0ZS QU1FUwkweDAwMDAwMDAyDQojZGVmaW5lCVJYQ09OX1JFQ0VJVkVfQlJPQURD QVNUX0ZSQU1FUwkweDAwMDAwMDA0DQojZGVmaW5lCVJYQ09OX1JFQ0VJVkVf TVVMVElDQVNUX0ZSQU1FUwkweDAwMDAwMDA4DQojZGVmaW5lCVJYQ09OX1JF Q0VJVkVfSU5WRVJTRV9JTkRJVklEVUFMX0FERFJFU1NfRlJBTUVTCTB4MDAw MDAwMTANCiNkZWZpbmUJUlhDT05fUFJPTUlTQ1VPVVNfTU9ERQkJMHgwMDAw MDAyMA0KI2RlZmluZQlSWENPTl9NT05JVE9SX01PREUJCTB4MDAwMDAwNDAN CiNkZWZpbmUJUlhDT05fRUFSTFlfUkVDRUlWRV9FTkFCTEUJMHgwMDAwMDA4 MA0KI2RlZmluZQlSWENPTl9FWFRFUk5BTF9CVUZGRVJfRElTQUJMRQkweDAw MDAwMDAwDQojZGVmaW5lCVJYQ09OX0VYVEVSTkFMX0JVRkZFUl8xNksJMHgw MDAwMDEwMA0KI2RlZmluZQlSWENPTl9FWFRFUk5BTF9CVUZGRVJfMzJLCTB4 MDAwMDAyMDANCiNkZWZpbmUJUlhDT05fRVhURVJOQUxfQlVGRkVSXzEyOEsJ MHgwMDAwMDMwMA0KDQojZGVmaW5lIFRYQ09OX0VBUkxZX1RSQU5TTUlUX0VO QUJMRQkweDAwMDAwMDAxDQojZGVmaW5lIFRYQ09OX0xPT1BCQUNLX0RJU0FC TEUJCTB4MDAwMDAwMDANCiNkZWZpbmUgVFhDT05fTE9PUEJBQ0tfTU9ERV9J TlQJCTB4MDAwMDAwMDINCiNkZWZpbmUgVFhDT05fTE9PUEJBQ0tfTU9ERV9Q SFkJCTB4MDAwMDAwMDQNCiNkZWZpbmUgVFhDT05fTE9PUEJBQ0tfTU9ERQkJ MHgwMDAwMDAwNg0KI2RlZmluZSBUWENPTl9GVUxMX0RVUExFWAkJMHgwMDAw MDAwNg0KI2RlZmluZSBUWENPTl9TTE9UX1RJTUUJCQkweDAwMDAwMDc4DQoN CiNpZiBkZWZpbmVkKEVBUkxZX1RYKQ0KICNkZWZpbmUgVFhDT05fREVGQVVM VAkJKFRYQ09OX1NMT1RfVElNRSB8IFRYQ09OX0VBUkxZX1RSQU5TTUlUX0VO QUJMRSkNCiAjZGVmaW5lIFRSQU5TTUlUX1RIUkVTSE9MRAkweDQwDQojZWxz ZQ0KICNkZWZpbmUgVFhDT05fREVGQVVMVAkJKFRYQ09OX1NMT1RfVElNRSkN CiNlbmRpZg0KI2lmIGRlZmluZWQoRUFSTFlfUlgpDQogI2RlZmluZSBSWENP Tl9ERUZBVUxUCQkoUlhDT05fRUFSTFlfUkVDRUlWRV9FTkFCTEUgfCBSWENP Tl9TQVZFX0VSUk9SRURfUEFDS0VUUykNCiNlbHNlDQogI2RlZmluZSBSWENP Tl9ERUZBVUxUCQkoMCkNCiNlbmRpZg0KLyoNCiAqIE5hdGlvbmFsIFNlbWlj b25kdWN0b3IncyBEUDgzODQwQSBSZWdpc3RlcnMgYW5kIGJpdHMNCiAqLw0K I2RlZmluZQlEUDgzODQwX09VSQkweDA4MDAxNw0KI2RlZmluZSBEUDgzODQw X0JNQ1IJMHgwMAkvKiBDb250cm9sIHJlZ2lzdGVyICovDQojZGVmaW5lIERQ ODM4NDBfQk1TUgkweDAxCS8qIFN0YXR1cyByZ2lzdGVyICovDQojZGVmaW5l CURQODM4NDBfQU5BUgkweDA0CS8qIEF1dG9uZWdvdGlhdGlvbiBhZHZlcnRp c2luZyByZWdpc3RlciAqLw0KI2RlZmluZQlEUDgzODQwX0xQQVIJMHgwNQkv KiBMaW5rIFBhcnRuZXIgQWJpbGl0eSByZWdpc3RlciAqLw0KI2RlZmluZSBE UDgzODQwX0FORVIJMHgwNgkvKiBBdXRvLU5lZ290aWF0aW9uIEV4cGFuc2lv biBSZWdpc3RlciAqLw0KI2RlZmluZSBEUDgzODQwX1BBUgkweDE5CS8qIFBI WSBBZGRyZXNzIFJlZ2lzdGVyICovDQojZGVmaW5lCURQODM4NDBfUEhZSURS MQkweDAyDQojZGVmaW5lCURQODM4NDBfUEhZSURSMgkweDAzDQoNCiNkZWZp bmUgQk1DUl9SRVNFVAkJMHg4MDAwDQojZGVmaW5lIEJNQ1JfMTAwTUJQUwkJ MHgyMDAwCS8qIDEwLzEwMCBNYnBzICovDQojZGVmaW5lIEJNQ1JfQVVUT05F R09USUFUSU9OCTB4MTAwMAkvKiBPTi9PRkYgKi8NCiNkZWZpbmUgQk1DUl9S RVNUQVJUX0FVVE9ORUcJMHgwMjAwDQojZGVmaW5lCUJNQ1JfRlVMTF9EVVBM RVgJMHgwMTAwDQoNCiNkZWZpbmUJQk1TUl8xMDBCQVNFX1Q0CQkweDgwMDAN CiNkZWZpbmUJQk1TUl8xMDBCQVNFX1RYX0ZECTB4NDAwMA0KI2RlZmluZQlC TVNSXzEwMEJBU0VfVFgJCTB4MjAwMA0KI2RlZmluZQlCTVNSXzEwQkFTRV9U X0ZECTB4MTAwMA0KI2RlZmluZQlCTVNSXzEwQkFTRV9UCQkweDA4MDANCiNk ZWZpbmUJQk1TUl9BVVRPTkVHX0NPTVBMRVRFCTB4MDAyMA0KI2RlZmluZSBC TVNSX0FVVE9ORUdfQUJMRQkweDAwMDgNCiNkZWZpbmUJQk1TUl9MSU5LX1NU QVRVUwkweDAwMDQNCg0KI2RlZmluZSBQQVJfRlVMTF9EVVBMRVgJCTB4MDQw MA0KDQojZGVmaW5lIEFORVJfTVVMVElQTEVfTElOS19GQVVMVAkweDEwDQoN Ci8qIEFOQVIgYW5kIExQQVIgaGF2ZSB0aGUgc2FtZSBiaXRzLCBkZWZpbmUg dGhlbSBvbmx5IG9uY2UgKi8NCiNkZWZpbmUJQU5BUl8xMAkJCTB4MDAyMA0K I2RlZmluZQlBTkFSXzEwX0ZECQkweDAwNDANCiNkZWZpbmUJQU5BUl8xMDBf VFgJCTB4MDA4MA0KI2RlZmluZQlBTkFSXzEwMF9UWF9GRAkJMHgwMTAwDQoj ZGVmaW5lCUFOQVJfMTAwX1Q0CQkweDAyMDANCg0KLyoNCiAqIFF1YWxpdHkg U2VtaWNvbmR1Y3RvcidzIFFTNjYxMiByZWdpc3RlcnMgYW5kIGJpdHMNCiAq Lw0KI2RlZmluZQlRUzY2MTJfT1VJCQkweDAwNjA1MQ0KI2RlZmluZQlRUzY2 MTJfTUNUTAkJMTcNCiNkZWZpbmUJUVM2NjEyX0lOVFNUQVQJCTI5DQojZGVm aW5lCVFTNjYxMl9JTlRNQVNLCQkzMA0KDQojZGVmaW5lCU1DVExfVDRfUFJF U0VOVAkJMHgxMDAwCS8qIEV4dGVybmFsIFQ0IEVuYWJsZWQsIGlnbm9yZWQg Ki8NCgkJCQkJLyogaWYgQXV0b05lZyBpcyBlbmFibGVkICovDQojZGVmaW5l CU1DVExfQlRFWFQJCTB4MDgwMAkvKiBSZWR1Y2VzIDEwYmFzZXQgc3F1ZWxj aCBsZXZlbCAqLw0KCQkJCQkvKiBmb3IgZXh0ZW5kZWQgY2FibGUgbGVuZ3Ro ICovDQoNCiNkZWZpbmUJSU5UU1RBVF9BTl9DT01QTEVURQkweDQwCS8qIEF1 dG9uZWdvdGlhdGlvbiBjb21wbGV0ZSAqLw0KI2RlZmluZQlJTlRTVEFUX1JG X0RFVEVDVEVECTB4MjAJLyogUmVtb3RlIEZhdWx0IGRldGVjdGVkICovDQoj ZGVmaW5lCUlOVFNUQVRfTElOS19TVEFUVVMJMHgxMAkvKiBMaW5rIHN0YXR1 cyBjaGFuZ2VkICovDQojZGVmaW5lCUlOVFNUQVRfQU5fTFBfQUNLCTB4MDgJ LyogQXV0b25lZy4gTFAgQWNrbm9sZWRnZSAqLw0KI2RlZmluZQlJTlRTVEFU X1BEX0ZBVUxUCTB4MDQJLyogUGFyYWxsZWwgRGV0ZWN0aW9uIEZhdWx0ICov DQojZGVmaW5lCUlOVFNUQVRfQU5fUEFHRQkJMHgwNAkvKiBBdXRvbmVnLiBQ YWdlIFJlY2VpdmVkICovDQojZGVmaW5lCUlOVFNUQVRfUkVfQ05UX0ZVTEwJ MHgwMQkvKiBSZWNlaXZlIEVycm9yIENvdW50ZXIgRnVsbCAqLw0KDQojZGVm aW5lCUlOVE1BU0tfVEhVTkRFUkxBTgkweDgwMDAJLyogRW5hYmxlIGludGVy cnVwdHMgKi8NCg0KLyoNCiAqIFN0cnVjdHVyZXMgZGVmaW5pdGlvbiBhbmQg RnVuY3Rpb25zIHByb3RvdHlwZXMNCiAqLw0KDQovKiBFUElDJ3MgaGFyZHdh cmUgZGVzY3JpcHRvcnMsIG11c3QgYmUgYWxpZ25lZCBvbiBkd29yZCBpbiBt ZW1vcnkgKi8NCi8qIE5COiB0byBtYWtlIGRyaXZlciBoYXBweSwgdGhpcyB0 d28gc3RydWN0dXJlcyBNVVNUIGhhdmUgdGhpZXIgc2l6ZXMgKi8NCi8qIGJl IGRpdmlzb3Igb2YgUEFHRV9TSVpFICovDQpzdHJ1Y3QgZXBpY190eF9kZXNj IHsNCgl2b2xhdGlsZSB1X2ludDE2X3QJc3RhdHVzOw0KCXZvbGF0aWxlIHVf aW50MTZfdAl0eGxlbmd0aDsNCgl2b2xhdGlsZSB1X2ludDMyX3QJYnVmYWRk cjsNCgl2b2xhdGlsZSB1X2ludDE2X3QJYnVmbGVuZ3RoOw0KCXZvbGF0aWxl IHVfaW50MTZfdAljb250cm9sOw0KCXZvbGF0aWxlIHVfaW50MzJfdAluZXh0 Ow0KfTsNCnN0cnVjdCBlcGljX3J4X2Rlc2Mgew0KCXZvbGF0aWxlIHVfaW50 MTZfdAlzdGF0dXM7DQoJdm9sYXRpbGUgdV9pbnQxNl90CXJ4bGVuZ3RoOw0K CXZvbGF0aWxlIHVfaW50MzJfdAlidWZhZGRyOw0KCXZvbGF0aWxlIHVfaW50 MzJfdAlidWZsZW5ndGg7DQoJdm9sYXRpbGUgdV9pbnQzMl90CW5leHQ7DQp9 Ow0KDQovKiBUaGlzIHN0cnVjdHVyZSBkZWZpbmVzIEVQSUMncyBmcmFnbWVu dCBsaXN0LCBtYXhpbXVtIG51bWJlciBvZiBmcmFncyAqLw0KLyogaXMgNjMu IExldCB1c2UgbWF4aW11bSwgYmVjb3VzZSBzaXplIG9mIHN0cnVjdCBNVVNU IGJlIGRpdmlzb3Igb2YgKi8NCi8qIFBBR0VfU0laRSwgYW5kIHNvbWV0aW1l cyBjb21lIG1idWZzIHdpdGggbW9yZSB0aGVuIDMwIGZyYWdzICovDQpzdHJ1 Y3QgZXBpY19mcmFnX2xpc3Qgew0KCXZvbGF0aWxlIHVfaW50MzJfdAkJbnVt ZnJhZ3M7DQoJc3RydWN0IHsNCgkJdm9sYXRpbGUgdV9pbnQzMl90CWZyYWdh ZGRyOw0KCQl2b2xhdGlsZSB1X2ludDMyX3QJZnJhZ2xlbjsNCgl9IGZyYWdb NjNdOyANCgl2b2xhdGlsZSB1X2ludDMyX3QJCXBhZDsJCS8qIGFsaWduIG9u IDI1NiBieXRlcyAqLw0KfTsNCg0KLyogVGhpcyBpcyBkcml2ZXIncyBzdHJ1 Y3R1cmUgdG8gZGVmaW5lIEVQSUMgZGVzY3JpcHRvcnMgKi8NCnN0cnVjdCBl cGljX3J4X2J1ZmZlciB7DQoJc3RydWN0IG1idWYgKgkJbWJ1ZjsJCS8qIG1i dWYgcmVjZWl2aW5nIHBhY2tldCAqLw0KfTsNCg0Kc3RydWN0IGVwaWNfdHhf YnVmZmVyIHsNCglzdHJ1Y3QgbWJ1ZiAqCQltYnVmOwkJLyogbWJ1ZiBjb250 YWluZWQgcGFja2V0ICovDQp9Ow0KDQovKg0KICogTkI6IEFMSUdOIE9GIEFC T1ZFIFNUUlVDVFVSRVMNCiAqIGVwaWNfcnhfZGVzYywgZXBpY190eF9kZXNj LCBlcGljX2ZyYWdfbGlzdCAtIG11c3QgYmUgYWxpZ25lZCBvbiBkd29yZA0K ICovDQoNCi8qIERyaXZlciBzdGF0dXMgc3RydWN0dXJlICovDQp0eXBlZGVm IHN0cnVjdCB7DQoJdV9pbnQzMl90CQl1bml0Ow0KCXN0cnVjdCBlcGljX3J4 X2J1ZmZlcglyeF9idWZmZXJbUlhfUklOR19TSVpFXTsNCglzdHJ1Y3QgZXBp Y190eF9idWZmZXIJdHhfYnVmZmVyW1RYX1JJTkdfU0laRV07DQoNCgkvKiBF YWNoIGVsZW1lbnQgb2YgYXJyYXkgTVVTVCBiZSBhbGlnbmVkIG9uIGR3b3Jk ICAqLw0KCS8qIGFuZCBib3VuZGVkIG9uIFBBR0VfU0laRSAJCQkgICAqLw0K CXN0cnVjdCBlcGljX3J4X2Rlc2MJKnJ4X2Rlc2M7DQoJc3RydWN0IGVwaWNf dHhfZGVzYwkqdHhfZGVzYzsNCglzdHJ1Y3QgZXBpY19mcmFnX2xpc3QJKnR4 X2ZsaXN0Ow0KI2lmIGRlZmluZWQoX05FVF9JRl9NRURJQV9IXykNCglzdHJ1 Y3QgaWZtZWRpYSAJCWlmbWVkaWE7DQojZW5kaWYNCglzdHJ1Y3QgYXJwY29t CQllcGljX2FjOw0KCXVfaW50MzJfdAkJcGh5aWQ7DQoJdV9pbnQzMl90CQlj dXJfdHg7DQoJdV9pbnQzMl90CQljdXJfcng7DQoJdV9pbnQzMl90CQlkaXJ0 eV90eDsNCgl1X2ludDMyX3QJCXBlbmRpbmdfdHhzOw0KI2lmIGRlZmluZWQo RVBJQ19VU0VJT1NQQUNFKQ0KCXVfaW50MzJfdAkJaW9iYXNlOw0KI2Vsc2UN CgljYWRkcl90CQkJY3NyOw0KI2VuZGlmDQoJc3RydWN0IGlmbWliX2lzb184 ODAyXzMJZG90M3N0YXRzOw0KfSBlcGljX3NvZnRjX3Q7DQoNCiNkZWZpbmUg ZXBpY19pZiBlcGljX2FjLmFjX2lmDQojZGVmaW5lIGVwaWNfbWFjYWRkciBl cGljX2FjLmFjX2VuYWRkcg0KI2lmIGRlZmluZWQoRVBJQ19VU0VJT1NQQUNF KQ0KICNkZWZpbmUgQ1NSX1dSSVRFXzQoc2MscmVnLHZhbCkgb3V0bCggKHNj KS0+aW9iYXNlICsgKHVfaW50MzJfdCkocmVnKSwgKHZhbCkgKQ0KICNkZWZp bmUgQ1NSX1dSSVRFXzIoc2MscmVnLHZhbCkgb3V0dyggKHNjKS0+aW9iYXNl ICsgKHVfaW50MzJfdCkocmVnKSwgKHZhbCkgKQ0KICNkZWZpbmUgQ1NSX1dS SVRFXzEoc2MscmVnLHZhbCkgb3V0YiggKHNjKS0+aW9iYXNlICsgKHVfaW50 MzJfdCkocmVnKSwgKHZhbCkgKQ0KICNkZWZpbmUgQ1NSX1JFQURfNChzYyxy ZWcpIGlubCggKHNjKS0+aW9iYXNlICsgKHVfaW50MzJfdCkocmVnKSApDQog I2RlZmluZSBDU1JfUkVBRF8yKHNjLHJlZykgaW53KCAoc2MpLT5pb2Jhc2Ug KyAodV9pbnQzMl90KShyZWcpICkNCiAjZGVmaW5lIENTUl9SRUFEXzEoc2Ms cmVnKSBpbmIoIChzYyktPmlvYmFzZSArICh1X2ludDMyX3QpKHJlZykgKQ0K I2Vsc2UNCiAjZGVmaW5lIENTUl9XUklURV8xKHNjLHJlZyx2YWwpICgoKih1 X2ludDhfdCopKChzYyktPmNzciArICh1X2ludDMyX3QpKHJlZykpKSA9ICh1 X2ludDhfdCkodmFsKSkNCiAjZGVmaW5lIENTUl9XUklURV8yKHNjLHJlZyx2 YWwpICgoKih1X2ludDE2X3QqKSgoc2MpLT5jc3IgKyAodV9pbnQzMl90KShy ZWcpKSkgPSAodV9pbnQxNl90KSh2YWwpKQ0KICNkZWZpbmUgQ1NSX1dSSVRF XzQoc2MscmVnLHZhbCkgKCgqKHVfaW50MzJfdCopKChzYyktPmNzciArICh1 X2ludDMyX3QpKHJlZykpKSA9ICh1X2ludDMyX3QpKHZhbCkpDQogI2RlZmlu ZSBDU1JfUkVBRF8xKHNjLHJlZykgKCoodV9pbnQ4X3QqKSgoc2MpLT5jc3Ig KyAodV9pbnQzMl90KShyZWcpKSkNCiAjZGVmaW5lIENTUl9SRUFEXzIoc2Ms cmVnKSAoKih1X2ludDE2X3QqKSgoc2MpLT5jc3IgKyAodV9pbnQzMl90KShy ZWcpKSkNCiAjZGVmaW5lIENTUl9SRUFEXzQoc2MscmVnKSAoKih1X2ludDMy X3QqKSgoc2MpLT5jc3IgKyAodV9pbnQzMl90KShyZWcpKSkNCiNlbmRpZg0K DQpzdGF0aWMgY2hhciogZXBpY19wY2lfcHJvYmUgX19QKChwY2ljaV90LCBw Y2lkaV90KSk7DQoNCi8qIEZvbG93aW5nIGZ1bmN0aW9ucyBjYWxscyBzcGxp bXAoKSAqLw0Kc3RhdGljIGludCBlcGljX2lmaW9jdGwgX19QKChyZWdpc3Rl ciBzdHJ1Y3QgaWZuZXQgKiwgaW50LCBjYWRkcl90KSk7DQpzdGF0aWMgdm9p ZCBlcGljX2lmc3RhcnQgX19QKChzdHJ1Y3QgaWZuZXQgKikpOw0Kc3RhdGlj IHZvaWQgZXBpY19pZndhdGNoZG9nIF9fUCgoc3RydWN0IGlmbmV0ICopKTsN CnN0YXRpYyB2b2lkIGVwaWNfcGNpX2F0dGFjaCBfX1AoKHBjaWNpX3QsIGlu dCkpOw0Kc3RhdGljIGludCBlcGljX2luaXQgX19QKChlcGljX3NvZnRjX3Qg KikpOw0Kc3RhdGljIHZvaWQgZXBpY19zdG9wIF9fUCgoZXBpY19zb2Z0Y190 ICopKTsNCg0Kc3RhdGljIGludCBlcGljX2lmbWVkaWFfY2hhbmdlIF9fUCgo c3RydWN0IGlmbmV0ICopKTsNCnN0YXRpYyB2b2lkIGVwaWNfaWZtZWRpYV9z dGF0dXMgX19QKChzdHJ1Y3QgaWZuZXQgKiwgc3RydWN0IGlmbWVkaWFyZXEg KikpOw0KDQovKiBGb2xsb3dpbmcgZnVuY3Rpb25zIGRvZXNuJ3QgY2FsbCBz cGxpbXAoKSAqLw0Kc3RhdGljIHZvaWQgZXBpY19pbnRyX25vcm1hbCBfX1Ao KHZvaWQgKikpOw0Kc3RhdGljIF9faW5saW5lIHZvaWQgZXBpY19yeF9kb25l IF9fUCgoZXBpY19zb2Z0Y190ICopKTsNCnN0YXRpYyBfX2lubGluZSB2b2lk IGVwaWNfdHhfZG9uZSBfX1AoKGVwaWNfc29mdGNfdCAqKSk7DQpzdGF0aWMg dm9pZCBlcGljX3NodXRkb3duIF9fUCgoaW50LCB2b2lkICopKTsNCg0Kc3Rh dGljIGludCBlcGljX2luaXRfcmluZ3MgX19QKChlcGljX3NvZnRjX3QgKikp Ow0Kc3RhdGljIHZvaWQgZXBpY19mcmVlX3JpbmdzIF9fUCgoZXBpY19zb2Z0 Y190ICopKTsNCnN0YXRpYyB2b2lkIGVwaWNfc3RvcF9hY3Rpdml0eSBfX1Ao KGVwaWNfc29mdGNfdCAqKSk7DQpzdGF0aWMgdm9pZCBlcGljX3N0YXJ0X2Fj dGl2aXR5IF9fUCgoZXBpY19zb2Z0Y190ICopKTsNCnN0YXRpYyB2b2lkIGVw aWNfc2V0X3J4X21vZGUgX19QKChlcGljX3NvZnRjX3QgKikpOw0Kc3RhdGlj IHZvaWQgZXBpY19zZXRfbWNfdGFibGUgX19QKChlcGljX3NvZnRjX3QgKikp Ow0Kc3RhdGljIHZvaWQgZXBpY19zZXRfbWVkaWFfc3BlZWQgX19QKChlcGlj X3NvZnRjX3QgKikpOw0Kc3RhdGljIHZvaWQgZXBpY19pbml0X3BoeSBfX1Ao KGVwaWNfc29mdGNfdCAqKSk7DQpzdGF0aWMgdm9pZCBlcGljX2R1bXBfc3Rh dGUgX19QKChlcGljX3NvZnRjX3QgKikpOw0Kc3RhdGljIGludCBlcGljX2F1 dG9uZWcgX19QKChlcGljX3NvZnRjX3QgKikpOw0KDQpzdGF0aWMgaW50IGVw aWNfcmVhZF9lZXByb20gX19QKChlcGljX3NvZnRjX3QgKix1X2ludDE2X3Qp KTsNCnN0YXRpYyB2b2lkIGVwaWNfb3V0cHV0X2VlcHJvbXcgX19QKChlcGlj X3NvZnRjX3QgKiwgdV9pbnQxNl90KSk7DQpzdGF0aWMgdV9pbnQxNl90IGVw aWNfaW5wdXRfZWVwcm9tdyBfX1AoKGVwaWNfc29mdGNfdCAqKSk7DQpzdGF0 aWMgdV9pbnQ4X3QgZXBpY19lZXByb21fY2xvY2sgX19QKChlcGljX3NvZnRj X3QgKix1X2ludDhfdCkpOw0Kc3RhdGljIHZvaWQgZXBpY193cml0ZV9lZXBy b21yZWcgX19QKChlcGljX3NvZnRjX3QgKix1X2ludDhfdCkpOw0Kc3RhdGlj IHVfaW50OF90IGVwaWNfcmVhZF9lZXByb21yZWcgX19QKChlcGljX3NvZnRj X3QgKikpOw0KDQpzdGF0aWMgaW50IGVwaWNfcmVhZF9waHlfcmVnaXN0ZXIg X19QKChlcGljX3NvZnRjX3QgKiwgdV9pbnQxNl90KSk7DQpzdGF0aWMgdm9p ZCBlcGljX3dyaXRlX3BoeV9yZWdpc3RlciBfX1AoKGVwaWNfc29mdGNfdCAq LCB1X2ludDE2X3QsdV9pbnQxNl90KSk7DQo= --0-535351022-896843486=:20905 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_tx.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: /sys/pci/if_tx.c LyotDQogKiBDb3B5cmlnaHQgKGMpIDE5OTcgU2VtZW4gVXN0aW1lbmtvIChz ZW1lbkBpY2x1Yi5uc3UucnUpDQogKiBBbGwgcmlnaHRzIHJlc2VydmVkLg0K ICoNCiAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBi aW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dA0KICogbW9kaWZpY2F0aW9u LCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBj b25kaXRpb25zDQogKiBhcmUgbWV0Og0KICogMS4gUmVkaXN0cmlidXRpb25z IG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmln aHQNCiAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4NCiAqIDIuIFJlZGlzdHJpYnV0 aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUg Y29weXJpZ2h0DQogKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRp b25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlDQogKiAg ICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlk ZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLg0KICoNCiAqIFRISVMgU09GVFdB UkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JT IGBgQVMgSVMnJyBBTkQNCiAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FS UkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQ0K ICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQg RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UNCiAqIEFSRSBESVND TEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05U UklCVVRPUlMgQkUgTElBQkxFDQogKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJF Q1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VR VUVOVElBTA0KICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlU RUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMNCiAqIE9S IFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1Ig QlVTSU5FU1MgSU5URVJSVVBUSU9OKQ0KICogSE9XRVZFUiBDQVVTRUQgQU5E IE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QNCiAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5H IE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkN CiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYg QURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YNCiAqIFNVQ0ggREFNQUdF Lg0KICoNCiAqCSRJZDogaWZfdHguYyx2IDEuMjkgMTk5OC8wNS8yNiAwMjox NjoxMSBnYWx2IEV4cCAkDQogKg0KICovDQoNCi8qDQogKiBFdGhlclBvd2Vy IElJIDEwLzEwMCAgRmFzdCBFdGhlcm5ldCAodHgwKQ0KICogKGFrYSBTTUM5 NDMyVFggYmFzZWQgb24gU01DODNjMTcwIEVQSUMgY2hpcCkNCiAqDQogKiBU T0RPOg0KICoJRGVhbCB3aXRoIFRYIHRocmVzaG9sZCAocHJvYmFibHkgd2Ug c2hvdWxkIGNhbGN1bGF0ZSBpdCBkZXBlbmRpbmcNCiAqCSAgICBvbiBwcm9j ZXNzb3Igc3BlZWQsIGFzIGRpZCB0aGUgTVMtRE9TIGRyaXZlcikuDQogKglE ZWFsIHdpdGggYnVzIG1hc3RlcmluZywgaS5lLiBpIHJlYWx5IGRvbid0IGtu b3cgd2hhdCB0byBkbyB3aXRoDQogKgkgICAgaXQgYW5kIGhvdyBpdCBjYW4g aW1wcm92ZSBwZXJmb3JtYW5jZS4NCiAqCUltcGxlbWVudCBGVUxMIElGRl9N VUxUSUNBU1Qgc3VwcG9ydC4NCiAqCUNhbGN1bGF0ZSBvcHRpbWFsIFJYIGFu ZCBUWCByaW5ncyBzaXplLg0KICoJVGVzdCwgdGVzdCBhbmQgdGVzdCBhZ2Fp bjotKQ0KICoJDQogKi8NCg0KLyogV2Ugc2hvdWxkIGRlZmluZSBjb21waWxl IHRpbWUgb3B0aW9ucyBiZWZvcmUgc21jODNjMTcwLmggaW5jbHVkZWQgKi8N Ci8qI2RlZmluZQlFUElDX05PSUZNRURJQQkxKi8NCi8qI2RlZmluZQlFUElD X1VTRUlPU1BBQ0UJMSovDQovKiNkZWZpbmUJRUFSTFlfUlgJMSovDQovKiNk ZWZpbmUJRUFSTFlfVFgJMSovDQojZGVmaW5lCUVQSUNfREVCVUcJMQ0KDQoj aWYgZGVmaW5lZChFUElDX0RFQlVHKQ0KI2RlZmluZSBkcHJpbnRmKGEpIHBy aW50ZiBhDQojZWxzZQ0KI2RlZmluZSBkcHJpbnRmKGEpDQojZW5kaWYNCg0K LyogTWFjcm8gdG8gZ2V0IGVpdGhlciBtYnVmIGNsdXN0ZXIgb3Igbm90aGlu ZyAqLw0KI2RlZmluZSBFUElDX01HRVRDTFVTVEVSKG0pIFwNCgl7IE1HRVRI RFIoKG0pLE1fRE9OVFdBSVQsTVRfREFUQSk7IFwNCgkgIGlmIChtKSB7IFwN CgkJTUNMR0VUKChtKSxNX0RPTlRXQUlUKTsgXA0KCQlpZiggTlVMTCA9PSAo KG0pLT5tX2ZsYWdzICYgTV9FWFQpICl7IFwNCgkJCW1fZnJlZW0obSk7IFwN CgkJCShtKSA9IE5VTEw7IFwNCgkJfSBcDQoJICB9IFwNCgl9DQoNCiNpbmNs dWRlICJwY2kuaCINCiNpZiBOUENJID4gMA0KDQojaW5jbHVkZSA8c3lzL3Bh cmFtLmg+DQojaW5jbHVkZSA8c3lzL3N5c3RtLmg+DQojaW5jbHVkZSA8c3lz L21idWYuaD4NCiNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+DQojaW5jbHVkZSA8 c3lzL21hbGxvYy5oPg0KI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4NCiNpbmNs dWRlIDxzeXMvc29ja2lvLmg+DQojaW5jbHVkZSA8bmV0L2lmLmg+DQojaWYg ZGVmaW5lZChTSU9DU0lGTUVESUEpICYmICFkZWZpbmVkKEVQSUNfTk9JRk1F RElBKQ0KI2luY2x1ZGUgPG5ldC9pZl9tZWRpYS5oPg0KI2VuZGlmDQojaW5j bHVkZSA8bmV0L2lmX21pYi5oPg0KI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4N CiNpbmNsdWRlIDxuZXRpbmV0L2lmX2V0aGVyLmg+DQojaW5jbHVkZSA8dm0v dm0uaD4NCiNpbmNsdWRlIDx2bS9wbWFwLmg+DQojaW5jbHVkZSA8bWFjaGlu ZS9jbG9jay5oPg0KDQojaW5jbHVkZSA8cGNpL3BjaXZhci5oPg0KI2luY2x1 ZGUgPHBjaS9zbWM4M2MxNzAuaD4NCg0KI2luY2x1ZGUgImJwZmlsdGVyLmgi DQojaWYgTkJQRklMVEVSID4gMA0KI2luY2x1ZGUgPG5ldC9icGYuaD4NCiNl bmRpZg0KDQovKg0KICogR2xvYmFsIHZhcmlhYmxlcw0KICovDQpzdGF0aWMg dV9sb25nIGVwaWNfcGNpX2NvdW50Ow0Kc3RhdGljIHN0cnVjdCBwY2lfZGV2 aWNlIHR4ZGV2aWNlID0geyANCgkidHgiLA0KCWVwaWNfcGNpX3Byb2JlLA0K CWVwaWNfcGNpX2F0dGFjaCwNCgkmZXBpY19wY2lfY291bnQsDQoJTlVMTCB9 Ow0KDQovKg0KICogQXBwZW5kIHRoaXMgZHJpdmVyIHRvIHBjaSBkcml2ZXJz IGxpc3QNCiAqLw0KREFUQV9TRVQgKCBwY2lkZXZpY2Vfc2V0LCB0eGRldmlj ZSApOw0KDQovKg0KICogaWZpb2N0bCBmdW5jdGlvbg0KICoNCiAqIHNwbGlt cCgpIGludm9rZWQgaGVyZQ0KICovDQpzdGF0aWMgaW50DQplcGljX2lmaW9j dGwgX19QKCgNCiAgICByZWdpc3RlciBzdHJ1Y3QgaWZuZXQgKiBpZnAsDQog ICAgaW50IGNvbW1hbmQsIGNhZGRyX3QgZGF0YSkpDQp7DQoJZXBpY19zb2Z0 Y190ICpzYyA9IGlmcC0+aWZfc29mdGM7DQoJc3RydWN0IGlmcmVxICppZnIg PSAoc3RydWN0IGlmcmVxICopIGRhdGE7DQoJaW50IHgsIGVycm9yID0gMDsN Cg0KCXggPSBzcGxpbXAoKTsNCg0KCXN3aXRjaCAoY29tbWFuZCkgew0KDQoJ Y2FzZSBTSU9DU0lGQUREUjoNCgljYXNlIFNJT0NHSUZBRERSOg0KCQlldGhl cl9pb2N0bChpZnAsIGNvbW1hbmQsIGRhdGEpOw0KCQlicmVhazsNCg0KCWNh c2UgU0lPQ1NJRkZMQUdTOg0KCQkvKg0KCQkgKiBJZiB0aGUgaW50ZXJmYWNl IGlzIG1hcmtlZCB1cCBhbmQgc3RvcHBlZCwgdGhlbiBzdGFydCBpdC4NCgkJ ICogSWYgaXQgaXMgbWFya2VkIGRvd24gYW5kIHJ1bm5pbmcsIHRoZW4gc3Rv cCBpdC4NCgkJICovDQoJCWlmIChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSB7 DQoJCQlpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfUlVOTklORykgPT0gMCkg ew0KCQkJCWVwaWNfaW5pdChzYyk7DQoJCQkJYnJlYWs7DQoJCQl9DQoJCX0g ZWxzZSB7DQoJCQlpZiAoaWZwLT5pZl9mbGFncyAmIElGRl9SVU5OSU5HKSB7 DQoJCQkJZXBpY19zdG9wKHNjKTsNCgkJCQlicmVhazsNCgkJCX0NCgkJfQ0K DQoJCS8qIEhhbmRsZSBJRkZfUFJPTUlTQyBmbGFnICovDQoJCWVwaWNfc2V0 X3J4X21vZGUoc2MpOw0KDQojaWYgIWRlZmluZWQoX05FVF9JRl9NRURJQV9I XykNCgkJLyogSGFuZGxlIElGRl9MSU5LeCBmbGFncyAqLw0KCQllcGljX3Nl dF9tZWRpYV9zcGVlZChzYyk7DQojZW5kaWYNCg0KCQlicmVhazsNCg0KCWNh c2UgU0lPQ0FERE1VTFRJOg0KCWNhc2UgU0lPQ0RFTE1VTFRJOg0KDQoJCS8q IFVwZGF0ZSBvdXQgbXVsdGljYXN0IGxpc3QgKi8NCiNpZiBkZWZpbmVkKF9f RnJlZUJTRF9fKSAmJiBfX0ZyZWVCU0RfXyA+PSAzDQoJCWVwaWNfc2V0X21j X3RhYmxlKHNjKTsNCgkJZXJyb3IgPSAwOw0KI2Vsc2UNCgkJZXJyb3IgPSAo Y29tbWFuZCA9PSBTSU9DQURETVVMVEkpID8NCgkJICAgIGV0aGVyX2FkZG11 bHRpKGlmciwgJnNjLT5lcGljX2FjKSA6DQoJCSAgICBldGhlcl9kZWxtdWx0 aShpZnIsICZzYy0+ZXBpY19hYyk7DQoNCgkJaWYgKGVycm9yID09IEVORVRS RVNFVCkgew0KCQkJZXBpY19zZXRfbWNfdGFibGUoc2MpOw0KCQkJZXJyb3Ig PSAwOw0KCQl9DQojZW5kaWYNCgkJYnJlYWs7DQoNCgljYXNlIFNJT0NTSUZN VFU6DQoJCS8qDQoJCSAqIFNldCB0aGUgaW50ZXJmYWNlIE1UVS4NCgkJICov DQoJCWlmIChpZnItPmlmcl9tdHUgPiBFVEhFUk1UVSkgew0KCQkJZXJyb3Ig PSBFSU5WQUw7DQoJCX0gZWxzZSB7DQoJCQlpZnAtPmlmX210dSA9IGlmci0+ aWZyX210dTsNCgkJfQ0KCQlicmVhazsNCg0KI2lmIGRlZmluZWQoX05FVF9J Rl9NRURJQV9IXykNCgljYXNlIFNJT0NTSUZNRURJQToNCgljYXNlIFNJT0NH SUZNRURJQToNCgkJZXJyb3IgPSBpZm1lZGlhX2lvY3RsKGlmcCwgaWZyLCAm c2MtPmlmbWVkaWEsIGNvbW1hbmQpOw0KCQlicmVhazsNCiNlbmRpZg0KDQoJ ZGVmYXVsdDoNCgkJZXJyb3IgPSBFSU5WQUw7DQoJfQ0KCXNwbHgoeCk7DQoN CglyZXR1cm4gZXJyb3I7DQp9DQoNCi8qDQogKiBpZnN0YXJ0IGZ1bmN0aW9u DQogKg0KICogc3BsaW1wKCkgYXNzdW1lZCB0byBiZSBkb25lDQogKi8NCnN0 YXRpYyB2b2lkDQplcGljX2lmc3RhcnQoc3RydWN0IGlmbmV0ICogY29uc3Qg aWZwKXsNCgllcGljX3NvZnRjX3QgKnNjID0gaWZwLT5pZl9zb2Z0YzsNCglz dHJ1Y3QgZXBpY190eF9idWZmZXIgKmJ1ZjsNCglzdHJ1Y3QgZXBpY190eF9k ZXNjICpkZXNjOw0KCXN0cnVjdCBlcGljX2ZyYWdfbGlzdCAqZmxpc3Q7DQoJ c3RydWN0IG1idWYgKm0sKm0wOw0KDQoJd2hpbGUoIHNjLT5wZW5kaW5nX3R4 cyA8IFRYX1JJTkdfU0laRSAgKXsNCgkJYnVmID0gc2MtPnR4X2J1ZmZlciAr IHNjLT5jdXJfdHg7DQoJCWRlc2MgPSBzYy0+dHhfZGVzYyArIHNjLT5jdXJf dHg7DQoJCWZsaXN0ID0gc2MtPnR4X2ZsaXN0ICsgc2MtPmN1cl90eDsNCg0K CQkvKiBHZXQgbmV4dCBwYWNrZXQgdG8gc2VuZCAqLw0KCQlJRl9ERVFVRVVF KCAmKHNjLT5lcGljX2lmLmlmX3NuZCksIG0wICk7DQoNCgkJLyogSWYgbm90 aGluZyB0byBzZW5kLCByZXR1cm4gKi8NCgkJaWYoIE5VTEwgPT0gbTAgKSBy ZXR1cm47DQoNCgkJLyogSWYgZGVzY3JpcHRvciBpcyBidXN5LCBzZXQgSUZG X09BQ1RJVkUgYW5kIGV4aXQgKi8NCgkJaWYoIGRlc2MtPnN0YXR1cyAmIDB4 ODAwMCApIHsNCgkJCWRwcmludGYoKCJ0eCVkOiBkZXNjIGlzIGJ1c3kgaW4g aWZzdGFydCwgdXAgYW5kIGRvd24gaW50ZXJmYWNlIHBsZWFzZVxuIixzYy0+ dW5pdCkpOw0KCQkJYnJlYWs7DQoJCX0NCg0KCQlpZiggYnVmLT5tYnVmICkg ew0KCQkJZHByaW50ZigoInR4JWQ6IG1idWYgbm90IGZyZWVkIGluIGlmc3Rh cnQsIHVwIGFuZCBkb3duIGludGVyZmFjZSBwbGFzZVxuIixzYy0+dW5pdCkp Ow0KCQkJYnJlYWs7DQoJCX0NCg0KCQkvKiBGaWxsIGZyYWdtZW50cyBsaXN0 ICovDQoJCWZsaXN0LT5udW1mcmFncyA9IDA7DQoJCWZvcihtPW0wOyhOVUxM IT1tKSYmKGZsaXN0LT5udW1mcmFnczw2Myk7bT1tLT5tX25leHQpIHsNCgkJ CWZsaXN0LT5mcmFnW2ZsaXN0LT5udW1mcmFnc10uZnJhZ2xlbiA9IG0tPm1f bGVuOyANCgkJCWZsaXN0LT5mcmFnW2ZsaXN0LT5udW1mcmFnc10uZnJhZ2Fk ZHIgPSB2dG9waHlzKCBtdG9kKG0sIGNhZGRyX3QpICk7DQoJCQlmbGlzdC0+ bnVtZnJhZ3MrKzsNCgkJfQ0KDQoJCS8qIElmIHBhY2tldCB3YXMgbW9yZSB0 aGFuIDYzIHBhcnRzLCAqLw0KCQkvKiByZWNvcHkgcGFja2V0IHRvIG5ldyBh bGxvY2F0ZWQgbWJ1ZiBjbHVzdGVyICovDQoJCWlmKCBOVUxMICE9IG0gKXsN CgkJCUVQSUNfTUdFVENMVVNURVIobSk7DQoJCQlpZiggTlVMTCA9PSBtICl7 DQoJCQkJcHJpbnRmKCJ0eCVkOiBjYW5ub3QgYWxsb2NhdGUgbWJ1ZiBjbHVz dGVyXG4iLHNjLT51bml0KTsNCgkJCQltX2ZyZWVtKG0wKTsNCgkJCQlzYy0+ ZXBpY19pZi5pZl9vZXJyb3JzKys7DQoJCQkJY29udGludWU7DQoJCQl9DQoN CgkJCW1fY29weWRhdGEoIG0wLCAwLCBtMC0+bV9wa3RoZHIubGVuLCBtdG9k KG0sY2FkZHJfdCkgKTsNCgkJCWZsaXN0LT5mcmFnWzBdLmZyYWdsZW4gPSBt LT5tX3BrdGhkci5sZW4gPSBtLT5tX2xlbiA9IG0wLT5tX3BrdGhkci5sZW47 DQoJCQltLT5tX3BrdGhkci5yY3ZpZiA9ICZzYy0+ZXBpY19pZjsNCg0KCQkJ Zmxpc3QtPm51bWZyYWdzID0gMTsNCgkJCWZsaXN0LT5mcmFnWzBdLmZyYWdh ZGRyID0gdnRvcGh5cyggbXRvZChtLCBjYWRkcl90KSApOw0KCQkJbV9mcmVl bShtMCk7DQoJCQltMCA9IG07DQoJCX0NCg0KCQkvKiBTYXZlIG1idWYgKi8N CgkJYnVmLT5tYnVmID0gbTA7DQoNCgkJLyogRG9lcyBub3QgZ2VuZXJhdGUg VFhDICovDQoJCWRlc2MtPmNvbnRyb2wgPSAweDAxOw0KDQoJCS8qIFBhY2tl dCBzaG91bGQgYmUgYXQgbGVhc3QgRVRIRVJfTUlOX0xFTiAqLw0KCQlkZXNj LT50eGxlbmd0aCA9IG1heChtMC0+bV9wa3RoZHIubGVuLEVUSEVSX01JTl9M RU4tRVRIRVJfQ1JDX0xFTik7DQoNCgkJLyogUGFzcyBvd25lcnNoaXAgdG8g dGhlIGNoaXAgKi8NCgkJZGVzYy0+c3RhdHVzID0gMHg4MDAwOw0KDQoJCS8q IFRyaWdnZXIgYW4gaW1tZWRpYXRlIHRyYW5zbWl0IGRlbWFuZC4gKi8NCgkJ Q1NSX1dSSVRFXzQoIHNjLCBDT01NQU5ELCBDT01NQU5EX1RYUVVFVUVEICk7 DQoNCgkJLyogU2V0IHdhdGNoZG9nIHRpbWVyICovDQoJCWlmcC0+aWZfdGlt ZXIgPSA0Ow0KDQojaWYgTkJQRklMVEVSID4gMA0KCQlpZiggaWZwLT5pZl9i cGYgKSBicGZfbXRhcCggaWZwLCBtMCApOw0KI2VuZGlmDQoNCgkJLyogUGFj a2V0IHF1ZXVlZCBzdWNjZXNzZnVsICovDQoJCXNjLT5wZW5kaW5nX3R4cysr Ow0KDQoJCS8qIFN3aXRjaCB0byBuZXh0IGRlc2NyaXB0b3IgKi8NCgkJc2Mt PmN1cl90eCA9ICggc2MtPmN1cl90eCArIDEgKSAlIFRYX1JJTkdfU0laRTsN Cgl9DQoNCglzYy0+ZXBpY19pZi5pZl9mbGFncyB8PSBJRkZfT0FDVElWRTsN Cg0KCXJldHVybjsNCgkNCn0NCg0KLyoNCiAqDQogKiBzcGxpbXAoKSBpbnZv a2VkIGJlZm9yZSBlcGljX2ludHJfbm9ybWFsKCkNCiAqLw0Kc3RhdGljIF9f aW5saW5lIHZvaWQNCmVwaWNfcnhfZG9uZSBfX1AoKA0KCWVwaWNfc29mdGNf dCAqc2MgKSkNCnsNCiAgICAgICAgaW50IGkgPSAwOw0KCXVfaW50MTZfdCBs ZW47DQoJc3RydWN0IGVwaWNfcnhfYnVmZmVyICpidWY7DQoJc3RydWN0IGVw aWNfcnhfZGVzYyAqZGVzYzsNCglzdHJ1Y3QgbWJ1ZiAqbTsNCglzdHJ1Y3Qg ZXRoZXJfaGVhZGVyICplaDsNCg0KCXdoaWxlKCAhKHNjLT5yeF9kZXNjW3Nj LT5jdXJfcnhdLnN0YXR1cyAmIDB4ODAwMCkgJiYgXA0KCQlpKysgPCBSWF9S SU5HX1NJWkUgKSB7DQoNCgkJYnVmID0gc2MtPnJ4X2J1ZmZlciArIHNjLT5j dXJfcng7DQoJCWRlc2MgPSBzYy0+cnhfZGVzYyArIHNjLT5jdXJfcng7DQoN CgkJLyogU3dpdGNoIHRvIG5leHQgZGVzY3JpcHRvciAqLw0KCQlzYy0+Y3Vy X3J4ID0gKHNjLT5jdXJfcngrMSkgJSBSWF9SSU5HX1NJWkU7DQoNCgkJLyog Q2hlY2sgZm9yIGVycm9ycywgdGhpcyBzaG91bGQgaGFwcGVuZCAqLw0KCQkv KiBvbmx5IGlmIFNBVkVfRVJST1JFRF9QQUNLRVRTIGlzIHNldCwgKi8NCgkJ Lyogbm9ybWFseSByeCBlcnJvcnMgZ2VuZXJhdGUgUlhFIGludGVycnVwdCAq Lw0KCQlpZiggIShkZXNjLT5zdGF0dXMgJiAxKSApIHsNCgkJCWRwcmludGYo KCJ0eCVkOiBSeCBlcnJvciBzdGF0dXM6IDB4JXhcbiIsc2MtPnVuaXQsZGVz Yy0+c3RhdHVzKSk7DQoJCQlzYy0+ZXBpY19pZi5pZl9pZXJyb3JzKys7DQoJ CQlkZXNjLT5zdGF0dXMgPSAweDgwMDA7DQoJCQljb250aW51ZTsNCgkJfQ0K DQoJCS8qIFNhdmUgcGFja2V0IGxlbmd0aCBhbmQgbWJ1ZiBjb250YWluZWQg cGFja2V0ICovIA0KCQlsZW4gPSBkZXNjLT5yeGxlbmd0aCAtIEVUSEVSX0NS Q19MRU47DQoJCW0gPSBidWYtPm1idWY7DQoNCgkJLyogVHJ5IHRvIGdldCBt YnVmIGNsdXN0ZXIgKi8NCgkJRVBJQ19NR0VUQ0xVU1RFUiggYnVmLT5tYnVm ICk7DQoJCWlmKCBOVUxMID09IGJ1Zi0+bWJ1ZiApIHsgDQoJCQlwcmludGYo InR4JWQ6IGNhbm5vdCBhbGxvY2F0ZSBtYnVmIGNsdXN0ZXJcbiIsc2MtPnVu aXQpOw0KCQkJYnVmLT5tYnVmID0gbTsNCgkJCWRlc2MtPnN0YXR1cyA9IDB4 ODAwMDsNCgkJCXNjLT5lcGljX2lmLmlmX2llcnJvcnMrKzsNCgkJCWNvbnRp bnVlOw0KCQl9DQoNCgkJLyogUG9pbnQgdG8gbmV3IG1idWYsIGFuZCBnaXZl IGRlc2NyaXB0b3IgdG8gY2hpcCAqLw0KCQlkZXNjLT5idWZhZGRyID0gdnRv cGh5cyggbXRvZCggYnVmLT5tYnVmLCBjYWRkcl90ICkgKTsNCgkJZGVzYy0+ c3RhdHVzID0gMHg4MDAwOw0KCQkNCgkJLyogRmlyc3QgbWJ1ZiBpbiBwYWNr ZXQgaG9sZHMgdGhlIGV0aGVybmV0IGFuZCBwYWNrZXQgaGVhZGVycyAqLw0K CQllaCA9IG10b2QoIG0sIHN0cnVjdCBldGhlcl9oZWFkZXIgKiApOw0KCQlt LT5tX3BrdGhkci5yY3ZpZiA9ICYoc2MtPmVwaWNfaWYpOw0KCQltLT5tX3Br dGhkci5sZW4gPSBtLT5tX2xlbiA9IGxlbjsNCg0KI2lmIE5CUEZJTFRFUiA+ IDANCgkJLyogR2l2ZSBtYnVmIHRvIEJQRklMVEVSICovDQoJCWlmKCBzYy0+ ZXBpY19pZi5pZl9icGYgKSBicGZfbXRhcCggJnNjLT5lcGljX2lmLCBtICk7 DQoNCgkJLyogQWNjZXB0IG9ubHkgb3VyIHBhY2tldHMsIGJyb2FkY2FzdHMg YW5kIG11bHRpY2FzdHMgKi8NCgkJaWYoIChlaC0+ZXRoZXJfZGhvc3RbMF0g JiAxKSA9PSAwICYmDQoJCSAgICBiY21wKGVoLT5ldGhlcl9kaG9zdCxzYy0+ ZXBpY19hYy5hY19lbmFkZHIsRVRIRVJfQUREUl9MRU4pKXsNCgkJCW1fZnJl ZW0obSk7DQoJCQljb250aW51ZTsNCgkJfQ0KI2VuZGlmDQoNCgkJLyogU2Vj b25kIG1idWYgaG9sZHMgcGFja2V0IGlmc2VsZiAqLw0KCQltLT5tX3BrdGhk ci5sZW4gPSBtLT5tX2xlbiA9IGxlbiAtIHNpemVvZihzdHJ1Y3QgZXRoZXJf aGVhZGVyKTsNCgkJbS0+bV9kYXRhICs9IHNpemVvZiggc3RydWN0IGV0aGVy X2hlYWRlciApOw0KDQoJCS8qIEdpdmUgbWJ1ZiB0byBPUyAqLw0KCQlldGhl cl9pbnB1dCgmc2MtPmVwaWNfaWYsIGVoLCBtKTsNCg0KCQkvKiBTdWNjZXNz ZnVseSByZWNlaXZlZCBmcmFtZSAqLw0KCQlzYy0+ZXBpY19pZi5pZl9pcGFj a2V0cysrOw0KICAgICAgICB9DQoNCglyZXR1cm47DQp9DQoNCi8qDQogKiBT eW5vcHNpczogRG8gbGFzdCBwaGFzZSBvZiB0cmFuc21pc3Npb24uIEkuZS4g aWYgZGVzYyBpcyANCiAqIHRyYW5zbWl0dGVkLCBkZWNyZWFzZSBwZW5kaW5n X3R4cyBjb3VudGVyLCBmcmVlIG1idWYgY29udGFpbmVkDQogKiBwYWNrZXQs IHN3aXRjaCB0byBuZXh0IGRlc2NyaXB0b3IgYW5kIHJlcGVhdCB1bnRpbCBu byBwYWNrZXRzDQogKiBhcmUgcGVuZGluZyBvciBkZXNjcmlwdHJvIGlzIG5v dCB0cmFuc21pdHRlZCB5ZXQuDQogKi8NCnN0YXRpYyBfX2lubGluZSB2b2lk DQplcGljX3R4X2RvbmUgX19QKCggDQogICAgcmVnaXN0ZXIgZXBpY19zb2Z0 Y190ICpzYyApKQ0Kew0KCXN0cnVjdCBlcGljX3R4X2J1ZmZlciAqYnVmOw0K CXN0cnVjdCBlcGljX3R4X2Rlc2MgKmRlc2M7DQoJdV9pbnQxNl90IHN0YXR1 czsNCg0KCXdoaWxlKCBzYy0+cGVuZGluZ190eHMgPiAwICl7DQoJCWJ1ZiA9 IHNjLT50eF9idWZmZXIgKyBzYy0+ZGlydHlfdHg7DQoJCWRlc2MgPSBzYy0+ dHhfZGVzYyArIHNjLT5kaXJ0eV90eDsNCgkJc3RhdHVzID0gZGVzYy0+c3Rh dHVzOw0KDQoJCS8qIElmIHBhY2tldCBpcyBub3QgdHJhbnNtaXR0ZWQsIHRo b3UgZm9sbG93ZWQgKi8NCgkJLyogcGFja2V0cyBhcmUgbm90IHRyYW5zbWl0 dGVkIHRvbyAqLw0KCQlpZiggc3RhdHVzICYgMHg4MDAwICkgYnJlYWs7DQoN CgkJLyogUGFja2V0IGlzIHRyYW5zbWl0dGVkLiBTd2l0Y2ggdG8gbmV4dCBh bmQgKi8NCgkJLyogZnJlZSBtYnVmICovDQoJCXNjLT5wZW5kaW5nX3R4cy0t Ow0KCQlzYy0+ZGlydHlfdHggPSAoc2MtPmRpcnR5X3R4ICsgMSkgJSBUWF9S SU5HX1NJWkU7DQoJCW1fZnJlZW0oIGJ1Zi0+bWJ1ZiApOw0KCQlidWYtPm1i dWYgPSBOVUxMOw0KDQoJCS8qIENoZWNrIGZvciBlcnJvcnMgYW5kIGNvbGxp c2lvbnMgKi8NCgkJaWYoIHN0YXR1cyAmIDB4MDAwMSApIHNjLT5lcGljX2lm LmlmX29wYWNrZXRzKys7DQoJCWVsc2Ugc2MtPmVwaWNfaWYuaWZfb2Vycm9y cysrOw0KCQlzYy0+ZXBpY19pZi5pZl9jb2xsaXNpb25zICs9IChzdGF0dXMg Pj4gOCkgJiAweDFGOw0KI2lmIGRlZmluZWQoRVBJQ19ERUJVRykNCgkJaWYo IChzdGF0dXMgJiAweDEwMDEpID09IDB4MTAwMSApIA0KCQkJcHJpbnRmKCJ0 eCVkOiBmcmFtZSBub3QgdHJhbnNtaXR0ZWQgZHVlIGNvbGxpc2lvbnNcbiIs c2MtPnVuaXQpOw0KI2VuZGlmDQoJfQ0KDQoJaWYoIHNjLT5wZW5kaW5nX3R4 cyA8IFRYX1JJTkdfU0laRSApIHNjLT5lcGljX2lmLmlmX2ZsYWdzICY9IH5J RkZfT0FDVElWRTsNCn0NCg0KLyoNCiAqIEludGVycnVwdCBmdW5jdGlvbg0K ICoNCiAqIHNwbGltcCgpIGFzc3VtZWQgdG8gYmUgZG9uZSANCiAqLw0Kc3Rh dGljIHZvaWQNCmVwaWNfaW50cl9ub3JtYWwoDQogICAgdm9pZCAqYXJnKQ0K ew0KCWVwaWNfc29mdGNfdCAqIHNjID0gKGVwaWNfc29mdGNfdCAqKSBhcmc7 DQogICAgICAgIGludCBzdGF0dXMsaT00Ow0KDQpkbyB7DQoJc3RhdHVzID0g Q1NSX1JFQURfNCggc2MsIElOVFNUQVQgKTsNCglDU1JfV1JJVEVfNCggc2Ms IElOVFNUQVQsIHN0YXR1cyApOw0KDQoJaWYoIHN0YXR1cyAmIChJTlRTVEFU X1JRRXxJTlRTVEFUX1JDQ3xJTlRTVEFUX09WVykgKSB7DQoJCWVwaWNfcnhf ZG9uZSggc2MgKTsNCgkJaWYoIHN0YXR1cyAmIChJTlRTVEFUX1JRRXxJTlRT VEFUX09WVykgKXsNCiNpZiBkZWZpbmVkKEVQSUNfREVCVUcpDQoJCQlpZigg c3RhdHVzICYgSU5UU1RBVF9PVlcgKSBwcmludGYoInR4JWQ6IG9uY2hpcCBS eCBidWZmZXIgb3ZlcmZsb3dlZFxuIixzYy0+dW5pdCk7DQoJCQlpZiggc3Rh dHVzICYgSU5UU1RBVF9SUUUgKSBwcmludGYoInR4JWQ6IFJ4IEZJRk8gb3Zl cmZsb3dlZFxuIixzYy0+dW5pdCk7DQoJCQlpZiggc2MtPmVwaWNfaWYuaWZf ZmxhZ3MgJiBJRkZfREVCVUcgKSBlcGljX2R1bXBfc3RhdGUoc2MpOw0KI2Vu ZGlmDQoJCQlpZiggIShDU1JfUkVBRF80KCBzYywgQ09NTUFORCApICYgQ09N TUFORF9SWFFVRVVFRCkgKQ0KCQkJCUNTUl9XUklURV80KCBzYywgQ09NTUFO RCwgQ09NTUFORF9SWFFVRVVFRCApOw0KCQkJc2MtPmVwaWNfaWYuaWZfaWVy cm9ycysrOw0KCQl9DQoJfQ0KDQoJaWYoIHN0YXR1cyAmIChJTlRTVEFUX1RY Q3xJTlRTVEFUX1RDQ3xJTlRTVEFUX1RRRSkgKSB7DQoJCWVwaWNfdHhfZG9u ZSggc2MgKTsNCiNpZiBkZWZpbmVkKEVQSUNfREVCVUcpDQoJCWlmKCAoc3Rh dHVzICYgKElOVFNUQVRfVFFFIHwgSU5UU1RBVF9UQ0MpKSAmJiAoc2MtPnBl bmRpbmdfdHhzID4gMSkgKQ0KCQkJcHJpbnRmKCJ0eCVkOiAlZCBwYWNrZXRz IHBlbmRpbmcgYWZ0ZXIgVFFFL1RDQ1xuIixzYy0+dW5pdCxzYy0+cGVuZGlu Z190eHMpOw0KI2VuZGlmDQoJCWlmKCAhKHNjLT5lcGljX2lmLmlmX2ZsYWdz ICYgSUZGX09BQ1RJVkUpICkNCgkJCWVwaWNfaWZzdGFydCggJnNjLT5lcGlj X2lmICk7DQoJfQ0KDQoJaWYoIChzdGF0dXMgJiBJTlRTVEFUX0dQMikgJiYg KFFTNjYxMl9PVUkgPT0gc2MtPnBoeWlkKSApIHsNCgkJdV9pbnQzMl90IHN0 YXR1czsNCg0KCQlzdGF0dXMgPSBlcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBz YywgUVM2NjEyX0lOVFNUQVQgKTsNCg0KCQlpZiggKHN0YXR1cyAmIElOVFNU QVRfQU5fQ09NUExFVEUpICYmIChlcGljX2F1dG9uZWcoc2MpID09IEVQSUNf RlVMTF9EVVBMRVgpICkgew0KCQkJc3RhdHVzID0gQk1DUl9GVUxMX0RVUExF WCB8IGVwaWNfcmVhZF9waHlfcmVnaXN0ZXIoIHNjLCBEUDgzODQwX0JNQ1Ig KTsNCgkJCUNTUl9XUklURV80KCBzYywgVFhDT04sIFRYQ09OX0ZVTExfRFVQ TEVYIHwgVFhDT05fREVGQVVMVCApOw0KCQl9IGVsc2Ugew0KCQkJLyogRGVm YXVsdCB0byBoYWxmLWR1cGxleCAqLw0KCQkJc3RhdHVzID0gfkJNQ1JfRlVM TF9EVVBMRVggJiBlcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBzYywgRFA4Mzg0 MF9CTUNSICk7DQoJCQlDU1JfV1JJVEVfNCggc2MsIFRYQ09OLCBUWENPTl9E RUZBVUxUICk7DQoJCX0NCg0KCQkvKiBUaGVyZSBpcyBhcHBhcmVudGx5IFFT NjYxMiBjaGlwIGJ1ZzogKi8NCgkJLyogQk1DUl9GVUxMX0RVUExFWCBmbGFn IGlzIG5vdCB1cGRhdGVkIGJ5ICovDQoJCS8qIGF1dG9uZWdvdGlhdGlvbiBw cm9jZXNzLCBzbyB1cGRhdGUgaXQgYnkgaGFuZHMgKi8NCgkJLyogc28gd2Ug Y2FuIHJlbHkgb24gaXQgaW4gZXBpY19pZm1lZGlhX3N0YXR1cygpICovDQoJ CWVwaWNfd3JpdGVfcGh5X3JlZ2lzdGVyKHNjLCBEUDgzODQwX0JNQ1IsIHN0 YXR1cyk7DQoNCgkJLyogV2Ugc2hvdWxkIGNsZWFyIEdQMiBpbnQgYWdhaW4g YWZ0ZXIgd2UgY2xlYXIgaXQgb24gUEhZICovDQoJCUNTUl9XUklURV80KCBz YywgSU5UU1RBVCwgSU5UU1RBVF9HUDIgKTsgDQoJfQ0KDQoJLyogQ2hlY2sg Zm9yIGVycm9ycyAqLw0KCWlmKCBzdGF0dXMgJiAoSU5UU1RBVF9GQVRBTHxJ TlRTVEFUX1BNQXxJTlRTVEFUX1BUQXxJTlRTVEFUX0FQRXxJTlRTVEFUX0RQ RXxJTlRTVEFUX1RYVXxJTlRTVEFUX1JYRSkgKXsNCgkJaWYoIHN0YXR1cyAm IChJTlRTVEFUX0ZBVEFMfElOVFNUQVRfUE1BfElOVFNUQVRfUFRBfElOVFNU QVRfQVBFfElOVFNUQVRfRFBFKSApew0KCQkJcHJpbnRmKCJ0eCVkOiBQQ0kg ZmF0YWwgZXJyb3Igb2NjdXJlZCAoJXMlcyVzJXMpXG4iLA0KCQkJCXNjLT51 bml0LA0KCQkJCShzdGF0dXMmSU5UU1RBVF9QTUEpPyJQTUEiOiIiLA0KCQkJ CShzdGF0dXMmSU5UU1RBVF9QVEEpPyIgUFRBIjoiIiwNCgkJCQkoc3RhdHVz JklOVFNUQVRfQVBFKT8iIEFQRSI6IiIsDQoJCQkJKHN0YXR1cyZJTlRTVEFU X0RQRSk/IiBEUEUiOiIiDQoJCQkpOw0KDQojaWYgZGVmaW5lZChFUElDX0RF QlVHKQ0KCQkJZXBpY19kdW1wX3N0YXRlKHNjKTsNCiNlbmRpZg0KCQkJZXBp Y19zdG9wKHNjKTsNCgkJCWVwaWNfaW5pdChzYyk7DQoJCQ0KCQkJcmV0dXJu Ow0KCQl9DQoNCgkJaWYgKHN0YXR1cyAmIElOVFNUQVRfUlhFKSB7DQoJCQlk cHJpbnRmKCgidHglZDogQ1JDL0FsaWdubWVudCBlcnJvclxuIixzYy0+dW5p dCkpOw0KCQkJc2MtPmVwaWNfaWYuaWZfaWVycm9ycysrOw0KCQl9DQoNCgkJ LyogVHggRklGTyB1bmRlcmZsb3cuIFNob3VsZCBub3QgaGFwcGVuZCBpZiAq Lw0KCQkvKiB3ZSBkb24ndCB1c2UgZWFybHkgdHgsIGhhbmRsZSBpdCBhbnl3 YXkgKi8NCgkJaWYgKHN0YXR1cyAmIElOVFNUQVRfVFhVKSB7DQoJCQlkcHJp bnRmKCgidHglZDogVHggdW5kZXJydW4gZXJyb3IsIHJlc3RhcnRpbmcgdHJh bmNpZXZlclxuIixzYy0+dW5pdCkpOw0KCQkJc2MtPmVwaWNfaWYuaWZfb2Vy cm9ycysrOw0KDQoJCQkvKiBSZXN0YXJ0IHRoZSB0cmFuc21pdCBwcm9jZXNz LiAqLw0KCQkJQ1NSX1dSSVRFXzQoc2MsIENPTU1BTkQsIENPTU1BTkRfVFhV R08gfCBDT01NQU5EX1RYUVVFVUVEKTsNCgkJfQ0KCX0NCg0KfSB3aGlsZSgg aS0tICYmIChDU1JfUkVBRF80KHNjLCBJTlRTVEFUKSAmIElOVFNUQVRfSU5U X0FDVFYpICk7DQoNCgkvKiBJZiBubyBwYWNrZXRzIGFyZSBwZW5kaW5nLCB0 aHVzIG5vIHRpbWVvdXRzICovDQoJaWYoIHNjLT5wZW5kaW5nX3R4cyA9PSAw ICkNCgkJc2MtPmVwaWNfaWYuaWZfdGltZXIgPSAwOw0KDQoJcmV0dXJuOw0K fQ0KDQovKg0KICogU3lub3BzaXM6IFRoaXMgb25lIGlzIGNhbGxlZCBpZiBw YWNrZXRzIHdhc24ndCB0cmFuc21pdHRlZA0KICogZHVyaW5nIHRpbWVvdXQu IFRyeSB0byBkZWFsbG9jYXRlIHRyYW5zbWl0dGVkIHBhY2tldHMsIGFuZCAN CiAqIGlmIHN1Y2Nlc3MgY29udGludWUgdG8gd29yay4NCiAqDQogKiBzcGxp bXAoKSBpbnZva2VkIGhlcmUNCiAqLw0Kc3RhdGljIHZvaWQNCmVwaWNfaWZ3 YXRjaGRvZyBfX1AoKA0KICAgIHN0cnVjdCBpZm5ldCAqaWZwKSkNCnsNCgll cGljX3NvZnRjX3QgKnNjID0gaWZwLT5pZl9zb2Z0YzsNCglpbnQgeDsNCg0K CXggPSBzcGxpbXAoKTsNCg0KCXByaW50ZigidHglZDogZGV2aWNlIHRpbWVv dXQgJWQgcGFja2V0cywgIiwgc2MtPnVuaXQsc2MtPnBlbmRpbmdfdHhzKTsN Cg0KCS8qIFRyeSB0byBmaW5pc2ggcXVldWVkIHBhY2tldHMgKi8NCgllcGlj X3R4X2RvbmUoIHNjICk7DQoNCgkvKiBJZiBub3Qgc3VjY2Vzc2Z1bCAqLw0K CWlmKCBzYy0+cGVuZGluZ190eHMgPiAwICl7DQojaWYgZGVmaW5lZChFUElD X0RFQlVHKQ0KCQlpZiggc2MtPmVwaWNfaWYuaWZfZmxhZ3MgJiBJRkZfREVC VUcgKSBlcGljX2R1bXBfc3RhdGUoc2MpOw0KI2VuZGlmDQoJCWlmcC0+aWZf b2Vycm9ycys9c2MtPnBlbmRpbmdfdHhzOw0KDQoJCS8qIFJlaW5pdGlhbGl6 ZSBib2FyZCAqLw0KCQlwcmludGYoInJlaW5pdGlhbGl6YXRpb25cbiIpOw0K CQllcGljX3N0b3Aoc2MpOw0KCQllcGljX2luaXQoc2MpOw0KDQoJfSBlbHNl IHByaW50Zigic2VlbXMgd2UgY2FuIGNvbnRpbnVlIG5vcm1hbHlcbiIpOw0K DQoJLyogU3RhcnQgb3V0cHV0ICovDQoJZXBpY19pZnN0YXJ0KCZzYy0+ZXBp Y19pZik7DQoNCglzcGx4KHgpOw0KfQ0KDQovKg0KICogU3lub3BzaXM6IENo ZWNrIGlmIFBDSSBpZCBjb3JyZXNwb25kcyB3aXRoIGJvYXJkIGlkLg0KICov DQpzdGF0aWMgY2hhcioNCmVwaWNfcGNpX3Byb2JlKA0KICAgIHBjaWNpX3Qg Y29uZmlnX2lkLA0KICAgIHBjaWRpX3QgZGV2aWNlX2lkKQ0Kew0KCWlmKCBQ Q0lfVkVORE9SSUQoZGV2aWNlX2lkKSAhPSBTTUNfVkVORE9SSUQgKQ0KCQly ZXR1cm4gTlVMTDsNCg0KCWlmKCBQQ0lfQ0hJUElEKGRldmljZV9pZCkgPT0g Q0hJUElEXzgzQzE3MCApDQoJCXJldHVybiAiU01DIDgzYzE3MCI7DQoNCgly ZXR1cm4gTlVMTDsNCn0NCg0KLyoNCiAqIFN5bm9wc2lzOiBBbGxvY2F0ZSBt ZW1vcnkgZm9yIHNvZnRjLCBkZXNjcmlwdG9ycyBhbmQgZnJhZyBsaXN0cy4N CiAqIENvbm5lY3QgdG8gaW50ZXJydXB0LCBhbmQgZ2V0IG1lbW9yeS9pbyBh ZGRyZXNzIG9mIGNhcmQgcmVnaXN0ZXJzLg0KICogUHJlaW5pdGlhbGl6ZSBz b2Z0YyBzdHJ1Y3R1cmUsIGF0dGFjaCB0byBpZiBtYW5hZ2VyLCBpZm1lZGlh IG1hbmFnZXINCiAqIGFuZCBicGYuIFJlYWQgbWVkaWEgY29uZmlndXJhdGlv biBhbmQgZXRjLg0KICoNCiAqIHNwbGltcCgpIGludm9rZWQgaGVyZQ0KICov DQpzdGF0aWMgdm9pZA0KZXBpY19wY2lfYXR0YWNoKA0KICAgIHBjaWNpX3Qg Y29uZmlnX2lkLA0KICAgIGludCB1bml0KQ0Kew0KCXN0cnVjdCBpZm5ldCAq IGlmcDsNCgllcGljX3NvZnRjX3QgKnNjOw0KI2lmIGRlZmluZWQoRVBJQ19V U0VJT1NQQUNFKQ0KCXVfaW50MzJfdCBpb2Jhc2U7DQojZWxzZQ0KCWNhZGRy X3QJcG1lbWJhc2U7DQojZW5kaWYNCglpbnQgaSxrLHMsdG1wOw0KCXVfaW50 MzJfdCBwb29sOw0KDQoJLyogQWxsb2NhdGUgbWVtb3J5IGZvciBzb2Z0Yywg aGFyZHdhcmUgZGVzY3JpcHRvcnMgYW5kIGZyYWcgbGlzdHMgKi8NCglzYyA9 IChlcGljX3NvZnRjX3QgKikgbWFsbG9jKA0KCQlzaXplb2YoZXBpY19zb2Z0 Y190KSArDQoJCXNpemVvZihzdHJ1Y3QgZXBpY19mcmFnX2xpc3QpKlRYX1JJ TkdfU0laRSArDQoJCXNpemVvZihzdHJ1Y3QgZXBpY19yeF9kZXNjKSpSWF9S SU5HX1NJWkUgKyANCgkJc2l6ZW9mKHN0cnVjdCBlcGljX3R4X2Rlc2MpKlRY X1JJTkdfU0laRSArIFBBR0VfU0laRSwNCgkJTV9ERVZCVUYsIE1fTk9XQUlU KTsNCg0KCWlmIChzYyA9PSBOVUxMKQlyZXR1cm47DQoNCgkvKiBBbGlnbiBw b29sIG9uIFBBR0VfU0laRSAqLw0KCXBvb2wgPSAoKHVfaW50MzJfdClzYykg KyBzaXplb2YoZXBpY19zb2Z0Y190KTsNCglwb29sID0gKHBvb2wgKyBQQUdF X1NJWkUgLSAxKSAmIH4oUEFHRV9TSVpFIC0gMSk7DQoNCgkvKiBQcmVpbml0 aWFsaXplIHNvZnRjIHN0cnVjdHVyZSAqLw0KICAgIAliemVybyhzYywgc2l6 ZW9mKGVwaWNfc29mdGNfdCkpOwkJDQoJc2MtPnVuaXQgPSB1bml0Ow0KDQoJ LyogRmlsbCBpZm5ldCBzdHJ1Y3R1cmUgKi8NCglpZnAgPSAmc2MtPmVwaWNf aWY7DQoJaWZwLT5pZl91bml0ID0gdW5pdDsNCglpZnAtPmlmX25hbWUgPSAi dHgiOw0KCWlmcC0+aWZfc29mdGMgPSBzYzsNCglpZnAtPmlmX2ZsYWdzID0g SUZGX0JST0FEQ0FTVHxJRkZfU0lNUExFWHxJRkZfTVVMVElDQVNUOw0KCWlm cC0+aWZfaW9jdGwgPSBlcGljX2lmaW9jdGw7DQoJaWZwLT5pZl9zdGFydCA9 IGVwaWNfaWZzdGFydDsNCglpZnAtPmlmX3dhdGNoZG9nID0gZXBpY19pZndh dGNoZG9nOw0KCWlmcC0+aWZfaW5pdCA9IChpZl9pbml0X2ZfdCopZXBpY19p bml0Ow0KCWlmcC0+aWZfdGltZXIgPSAwOw0KCWlmcC0+aWZfb3V0cHV0ID0g ZXRoZXJfb3V0cHV0Ow0KDQoJLyogR2V0IGlvYmFzZSBvciBtZW1iYXNlICov DQojaWYgZGVmaW5lZChFUElDX1VTRUlPU1BBQ0UpDQoJaWYgKCFwY2lfbWFw X3BvcnQoY29uZmlnX2lkLCBQQ0lfQ0JJTywodV9zaG9ydCAqKSAmKHNjLT5p b2Jhc2UpKSkgew0KCQlwcmludGYoInR4JWQ6IGNhbm5vdCBtYXAgcG9ydFxu Iix1bml0KTsNCgkJZnJlZShzYywgTV9ERVZCVUYpOw0KCQlyZXR1cm47DQoJ fQ0KI2Vsc2UNCglpZiAoIXBjaV9tYXBfbWVtKGNvbmZpZ19pZCwgUENJX0NC TUEsKHZtX29mZnNldF90ICopICYoc2MtPmNzciksKHZtX29mZnNldF90ICop ICZwbWVtYmFzZSkpIHsNCgkJcHJpbnRmKCJ0eCVkOiBjYW5ub3QgbWFwIG1l bW9yeVxuIix1bml0KTsgDQoJCWZyZWUoc2MsIE1fREVWQlVGKTsNCgkJcmV0 dXJuOw0KCX0NCiNlbmRpZg0KDQoJc2MtPnR4X2ZsaXN0ID0gKHZvaWQgKilw b29sOw0KCXBvb2wgKz0gc2l6ZW9mKHN0cnVjdCBlcGljX2ZyYWdfbGlzdCkq VFhfUklOR19TSVpFOw0KCXNjLT5yeF9kZXNjID0gKHZvaWQgKilwb29sOw0K CXBvb2wgKz0gc2l6ZW9mKHN0cnVjdCBlcGljX3J4X2Rlc2MpKlJYX1JJTkdf U0laRTsNCglzYy0+dHhfZGVzYyA9ICh2b2lkICopcG9vbDsNCg0KCS8qIEJy aW5nIHRoZSBjaGlwIG91dCBvZiBsb3ctcG93ZXIgbW9kZS4gKi8NCglDU1Jf V1JJVEVfNCggc2MsIEdFTkNUTCwgMHgwMDAwICk7DQoNCgkvKiBNYWdpYz8h ICBJZiB3ZSBkb24ndCBzZXQgdGhpcyBiaXQgdGhlIE1JSSBpbnRlcmZhY2Ug d29uJ3Qgd29yay4gKi8NCglDU1JfV1JJVEVfNCggc2MsIFRFU1QxLCAweDAw MDggKTsNCg0KCS8qIFJlYWQgbWFjIGFkZHJlc3MgZnJvbSBFRVBST00gKi8N Cglmb3IgKGkgPSAwOyBpIDwgRVRIRVJfQUREUl9MRU4gLyBzaXplb2YodV9p bnQxNl90KTsgaSsrKQ0KCQkoKHVfaW50MTZfdCAqKXNjLT5lcGljX21hY2Fk ZHIpW2ldID0gZXBpY19yZWFkX2VlcHJvbShzYyxpKTsNCg0KCS8qIERpc3Bs YXkgZXRoZXJuZXQgYWRkcmVzcyAsLi4uICovDQoJcHJpbnRmKCJ0eCVkOiBh ZGRyZXNzICUwMng6JTAyeDolMDJ4OiUwMng6JTAyeDolMDJ4LCIsc2MtPnVu aXQsDQoJCXNjLT5lcGljX21hY2FkZHJbMF0sc2MtPmVwaWNfbWFjYWRkclsx XSxzYy0+ZXBpY19tYWNhZGRyWzJdLA0KCQlzYy0+ZXBpY19tYWNhZGRyWzNd LHNjLT5lcGljX21hY2FkZHJbNF0sc2MtPmVwaWNfbWFjYWRkcls1XSk7DQoN CgkvKiBib2FyZCB0eXBlIGFuZCAuLi4gKi8NCglwcmludGYoIiB0eXBlICIp Ow0KCWZvcihpPTB4MmM7aTwweDMyO2krKykgew0KCQl0bXAgPSBlcGljX3Jl YWRfZWVwcm9tKCBzYywgaSApOw0KCQlwcmludGYoIiVjJWMiLCh1X2ludDhf dCl0bXAsKHVfaW50OF90KSh0bXA+PjgpKTsNCgkJaWYoICcgJyA9PSAodV9p bnQ4X3QpdG1wIHx8ICcgJyA9PSAodV9pbnQ4X3QpKHRtcD4+OCkgKSBicmVh azsNCgl9DQoNCgkvKiBSZWFkIGN1cnJlbnQgbWVkaWEgY29uZmlnIGFuZCBk aXNwbGF5IGl0IHRvbyAqLw0KCWkgPSBlcGljX3JlYWRfcGh5X3JlZ2lzdGVy KCBzYywgRFA4Mzg0MF9CTUNSICk7DQojaWYgZGVmaW5lZChfTkVUX0lGX01F RElBX0hfKQ0KCXRtcCA9IElGTV9FVEhFUjsNCiNlbmRpZg0KCWlmKCBpICYg Qk1DUl9BVVRPTkVHT1RJQVRJT04gKXsNCgkJcHJpbnRmKCIsIEF1dG8tTmVn ICIpOw0KDQoJCS8qIFRvIGF2b2lkIGJ1ZyBpbiBRUzY2MTIgcmVhZCBMUEFS IGVuc3RlYWQgb2YgQk1TUiAqLw0KCQlpID0gZXBpY19yZWFkX3BoeV9yZWdp c3Rlciggc2MsIERQODM4NDBfTFBBUiApOw0KCQlpZiggaSAmIChBTkFSXzEw MF9UWHxBTkFSXzEwMF9UWF9GRCkgKSBwcmludGYoIjEwME1icHMgIik7DQoJ CWVsc2UgcHJpbnRmKCIxME1icHMgIik7DQoJCWlmKCBpICYgKEFOQVJfMTBf RkR8QU5BUl8xMDBfVFhfRkQpICkgcHJpbnRmKCJGRCIpOw0KI2lmIGRlZmlu ZWQoX05FVF9JRl9NRURJQV9IXykNCgkJdG1wIHw9IElGTV9BVVRPOw0KI2Vu ZGlmDQoJfSBlbHNlIHsNCiNpZiAhZGVmaW5lZChfTkVUX0lGX01FRElBX0hf KQ0KCQlpZnAtPmlmX2ZsYWdzIHw9IElGRl9MSU5LMDsNCiNlbmRpZg0KCQlp ZiggaSAmIEJNQ1JfMTAwTUJQUyApIHsNCgkJCXByaW50ZigiLCAxMDBNYnBz ICIpOw0KI2lmIGRlZmluZWQoX05FVF9JRl9NRURJQV9IXykNCgkJCXRtcCB8 PSBJRk1fMTAwX1RYOw0KI2Vsc2UNCgkJCWlmcC0+aWZfZmxhZ3MgfD0gSUZG X0xJTksyOw0KI2VuZGlmDQoJCX0gZWxzZSB7DQoJCQlwcmludGYoIiwgMTBN YnBzICIpOw0KI2lmIGRlZmluZWQoX05FVF9JRl9NRURJQV9IXykNCgkJCXRt cCB8PSBJRk1fMTBfVDsNCiNlbmRpZg0KCQl9DQoJCWlmKCBpICYgQk1DUl9G VUxMX0RVUExFWCApIHsNCgkJCXByaW50ZigiRkQiKTsNCiNpZiBkZWZpbmVk KF9ORVRfSUZfTUVESUFfSF8pDQoJCQl0bXAgfD0gSUZNX0ZEWDsNCiNlbHNl DQoJCQlpZnAtPmlmX2ZsYWdzIHw9IElGRl9MSU5LMTsNCiNlbmRpZg0KCQl9 DQoJfQ0KCXByaW50ZigiXG4iKTsNCg0KCS8qIEluaXQgaWZtZWRpYSBpbnRl cmZhY2UgKi8NCiNpZiBkZWZpbmVkKFNJT0NTSUZNRURJQSkgJiYgIWRlZmlu ZWQoRVBJQ19OT0lGTUVESUEpDQoJaWZtZWRpYV9pbml0KCZzYy0+aWZtZWRp YSwwLGVwaWNfaWZtZWRpYV9jaGFuZ2UsZXBpY19pZm1lZGlhX3N0YXR1cyk7 DQoJaWZtZWRpYV9hZGQoJnNjLT5pZm1lZGlhLElGTV9FVEhFUnxJRk1fMTBf VCwwLE5VTEwpOw0KCWlmbWVkaWFfYWRkKCZzYy0+aWZtZWRpYSxJRk1fRVRI RVJ8SUZNXzEwX1R8SUZNX0xPT1AsMCxOVUxMKTsNCglpZm1lZGlhX2FkZCgm c2MtPmlmbWVkaWEsSUZNX0VUSEVSfElGTV8xMF9UfElGTV9GRFgsMCxOVUxM KTsNCglpZm1lZGlhX2FkZCgmc2MtPmlmbWVkaWEsSUZNX0VUSEVSfElGTV8x MDBfVFgsMCxOVUxMKTsNCglpZm1lZGlhX2FkZCgmc2MtPmlmbWVkaWEsSUZN X0VUSEVSfElGTV8xMDBfVFh8SUZNX0xPT1AsMCxOVUxMKTsNCglpZm1lZGlh X2FkZCgmc2MtPmlmbWVkaWEsSUZNX0VUSEVSfElGTV8xMDBfVFh8SUZNX0ZE WCwwLE5VTEwpOw0KCWlmbWVkaWFfYWRkKCZzYy0+aWZtZWRpYSxJRk1fRVRI RVJ8SUZNX0FVVE8sMCxOVUxMKTsNCglpZm1lZGlhX2FkZCgmc2MtPmlmbWVk aWEsSUZNX0VUSEVSfElGTV9MT09QLDAsTlVMTCk7DQoJaWZtZWRpYV9zZXQo JnNjLT5pZm1lZGlhLCB0bXApOw0KI2VuZGlmDQoNCgkvKiBJZGVudGlmeSBQ SFkgKi8NCglzYy0+cGh5aWQgPSBlcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBz YywgRFA4Mzg0MF9QSFlJRFIxICk8PDY7DQoJc2MtPnBoeWlkfD0gKGVwaWNf cmVhZF9waHlfcmVnaXN0ZXIoIHNjLCBEUDgzODQwX1BIWUlEUjIgKT4+MTAp JjB4M0Y7DQoJaWYoIFFTNjYxMl9PVUkgIT0gc2MtPnBoeWlkICkgcHJpbnRm KCJ0eCVkOiBXQVJOSU5HISBwaHkgdW5rbm93biAoMHgleCksICIsc2MtPnVu aXQsc2MtPnBoeWlkKTsNCg0KCS8qIENoZWNrIGlmIHRoZXJlIGlzIGxpbmsg ZXN0YWJpbHNoZWQgKi8NCgllcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBzYywg RFA4Mzg0MF9CTVNSICk7DQoJaT1lcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBz YywgRFA4Mzg0MF9CTVNSICk7DQoJaWYoICEoaSAmIEJNU1JfTElOS19TVEFU VVMpICkgcHJpbnRmKCJ0eCVkOiBXQVJOSU5HISBubyBsaW5rIGVzdGFiaWxp c2hlZFxuIixzYy0+dW5pdCk7DQoNCglzID0gc3BsaW1wKCk7DQoNCgkvKiBN YXAgaW50ZXJydXB0ICovDQoJaWYoICFwY2lfbWFwX2ludChjb25maWdfaWQs IGVwaWNfaW50cl9ub3JtYWwsICh2b2lkKilzYywgJm5ldF9pbWFzaykgKSB7 DQoJCXByaW50ZigidHglZDogY291bGRuJ3QgbWFwIGludGVycnVwdFxuIix1 bml0KTsNCgkJZnJlZShzYywgTV9ERVZCVUYpOw0KCQlyZXR1cm47DQoJfQ0K DQoJLyogU2V0IHNodXQgZG93biByb3V0aW5lIHRvIHN0b3AgRE1BIHByb2Nl c3NlcyBvbiByZWJvb3QgKi8NCglhdF9zaHV0ZG93bihlcGljX3NodXRkb3du LCBzYywgU0hVVERPV05fUE9TVF9TWU5DKTsNCg0KCS8qICBBdHRhY2ggdG8g aWYgbWFuYWdlciAqLw0KCWlmX2F0dGFjaChpZnApOw0KCWV0aGVyX2lmYXR0 YWNoKGlmcCk7DQoNCiNpZiBOQlBGSUxURVIgPiAwDQoJYnBmYXR0YWNoKGlm cCxETFRfRU4xME1CLCBzaXplb2Yoc3RydWN0IGV0aGVyX2hlYWRlcikpOw0K I2VuZGlmDQoNCglzcGx4KHMpOw0KDQoJcmV0dXJuOw0KfQ0KDQojaWYgZGVm aW5lZChTSU9DU0lGTUVESUEpICYmICFkZWZpbmVkKEVQSUNfTk9JRk1FRElB KQ0Kc3RhdGljIGludA0KZXBpY19pZm1lZGlhX2NoYW5nZSBfX1AoKA0KICAg IHN0cnVjdCBpZm5ldCAqIGlmcCkpDQp7DQoJaWYgKElGTV9UWVBFKCgoZXBp Y19zb2Z0Y190ICopKGlmcC0+aWZfc29mdGMpKS0+aWZtZWRpYS5pZm1fbWVk aWEpICE9IElGTV9FVEhFUikNCiAgICAgICAgCXJldHVybiAoRUlOVkFMKTsN Cg0KCWVwaWNfc2V0X21lZGlhX3NwZWVkKCBpZnAtPmlmX3NvZnRjICk7DQoN CglyZXR1cm4gMDsNCn0NCg0Kc3RhdGljIHZvaWQNCmVwaWNfaWZtZWRpYV9z dGF0dXMgX19QKCgNCiAgICBzdHJ1Y3QgaWZuZXQgKiBpZnAsDQogICAgc3Ry dWN0IGlmbWVkaWFyZXEgKmlmbXIpKQ0Kew0KCWVwaWNfc29mdGNfdCAqc2Mg PSBpZnAtPmlmX3NvZnRjOw0KCXVfaW50MzJfdAlibWNyOw0KCXVfaW50MzJf dAlibXNyOw0KDQoJYm1jciA9IGVwaWNfcmVhZF9waHlfcmVnaXN0ZXIoIHNj LCBEUDgzODQwX0JNQ1IgKTsNCg0KCWVwaWNfcmVhZF9waHlfcmVnaXN0ZXIo IHNjLCBEUDgzODQwX0JNU1IgKTsNCglibXNyID0gZXBpY19yZWFkX3BoeV9y ZWdpc3Rlciggc2MsIERQODM4NDBfQk1TUiApOw0KDQoJaWZtci0+aWZtX2Fj dGl2ZSA9IElGTV9FVEhFUjsNCglpZm1yLT5pZm1fc3RhdHVzID0gSUZNX0FW QUxJRDsNCg0KCWlmKCAhKGJtc3IgJiBCTVNSX0xJTktfU1RBVFVTKSApIHsg DQoJCWlmbXItPmlmbV9hY3RpdmUgfD0gKGJtY3ImQk1DUl9BVVRPTkVHT1RJ QVRJT04pP0lGTV9BVVRPOklGTV9OT05FOw0KCQlyZXR1cm47DQoJfQ0KDQoJ aWZtci0+aWZtX3N0YXR1cyB8PSBJRk1fQUNUSVZFOw0KCWlmbXItPmlmbV9h Y3RpdmUgfD0gKGJtY3ImQk1DUl8xMDBNQlBTKT9JRk1fMTAwX1RYOklGTV8x MF9UOw0KCWlmbXItPmlmbV9hY3RpdmUgfD0gKGJtY3ImQk1DUl9GVUxMX0RV UExFWCk/SUZNX0ZEWDowOw0KCWlmbXItPmlmbV9hY3RpdmUgfD0gKChDU1Jf UkVBRF80KHNjLFRYQ09OKSZUWENPTl9MT09QQkFDS19NT0RFKT09VFhDT05f TE9PUEJBQ0tfTU9ERV9JTlQpP0lGTV9MT09QOjA7DQp9DQojZW5kaWYNCg0K LyoNCiAqIFJlc2V0IGNoaXAsIFBIWSwgYWxsb2NhdGUgcmluZ3MNCiAqIA0K ICogc3BsaW1wKCkgaW52b2tlZCBoZXJlDQogKi8NCnN0YXRpYyBpbnQgDQpl cGljX2luaXQgX19QKCgNCiAgICBlcGljX3NvZnRjX3QgKiBzYykpDQp7ICAg ICAgIA0KCXN0cnVjdCBpZm5ldCAqaWZwID0gJnNjLT5lcGljX2lmOw0KCWlu dCBpLHM7DQogDQoJcyA9IHNwbGltcCgpOw0KDQoJLyogU29mdCByZXNldCB0 aGUgY2hpcCAqLw0KCUNTUl9XUklURV80KCBzYywgR0VOQ1RMLCBHRU5DVExf U09GVF9SRVNFVCApOw0KDQoJLyogUmVzZXQgdGFrZXMgMTUgcGNpIHRpY2tz IHdoaWNoIGRlcGVuZHMgb24gcHJvY2Vzc29yIHNwZWVkICovDQoJREVMQVko MSk7DQoNCgkvKiBXYWtlIHVwICovDQoJQ1NSX1dSSVRFXzQoIHNjLCBHRU5D VEwsIDAgKTsNCg0KCS8qID8/Pz8/PyAqLw0KCUNTUl9XUklURV80KCBzYywg VEVTVDEsIDB4MDAwOCk7DQoNCgkvKiBJbml0aWFsaXplIHJpbmdzICovDQoJ aWYoIGVwaWNfaW5pdF9yaW5ncyggc2MgKSApIHsNCgkJcHJpbnRmKCJ0eCVk OiBmYWlsZWQgdG8gaW5pdGlhbGl6ZSByaW5nc1xuIixzYy0+dW5pdCk7DQoJ CXNwbHgocyk7DQoJCXJldHVybiAtMTsNCgl9CQ0KDQoJLyogR2l2ZSByaW5n cyB0byBFUElDICovDQoJQ1NSX1dSSVRFXzQoIHNjLCBQUkNEQVIsIHZ0b3Bo eXMoIHNjLT5yeF9kZXNjICkgKTsNCglDU1JfV1JJVEVfNCggc2MsIFBUQ0RB UiwgdnRvcGh5cyggc2MtPnR4X2Rlc2MgKSApOw0KDQoJLyogUHV0IG5vZGUg YWRkcmVzcyB0byBFUElDICovDQoJQ1NSX1dSSVRFXzQoIHNjLCBMQU4wLCAo KHVfaW50MTZfdCAqKXNjLT5lcGljX21hY2FkZHIpWzBdICk7DQogICAgICAg IENTUl9XUklURV80KCBzYywgTEFOMSwgKCh1X2ludDE2X3QgKilzYy0+ZXBp Y19tYWNhZGRyKVsxXSApOw0KCUNTUl9XUklURV80KCBzYywgTEFOMiwgKCh1 X2ludDE2X3QgKilzYy0+ZXBpY19tYWNhZGRyKVsyXSApOw0KDQojaWYgZGVm aW5lZChFQVJMWV9UWCkNCgkvKiBTZXQgdHJhbnNtaXQgdGhyZXNob2xkICov DQoJQ1NSX1dSSVRFXzQoIHNjLCBFVFhUSFIsIFRSQU5TTUlUX1RIUkVTSE9M RCApOw0KI2VuZGlmDQoNCglDU1JfV1JJVEVfNCggc2MsIElQRywgMHgxMDEw ICk7DQoNCgkvKiBDb21wdXRlIGFuZCBzZXQgUlhDT04uICovDQoJZXBpY19z ZXRfcnhfbW9kZSggc2MgKTsNCg0KCS8qIFNldCBtZWRpYSBzcGVlZCBtb2Rl ICovDQoJZXBpY19pbml0X3BoeSggc2MgKTsNCgllcGljX3NldF9tZWRpYV9z cGVlZCggc2MgKTsNCg0KCS8qIFNldCBtdWx0aWNhc3QgdGFibGUgKi8NCgll cGljX3NldF9tY190YWJsZSggc2MgKTsNCg0KCS8qIEVuYWJsZSBpbnRlcnJ1 cHRzIGJ5IHNldHRpbmcgdGhlIGludGVycnVwdCBtYXNrLiAqLw0KCUNTUl9X UklURV80KCBzYywgSU5UTUFTSywNCgkJSU5UU1RBVF9SQ0MgfCBJTlRTVEFU X1JRRSB8IElOVFNUQVRfT1ZXIHwgSU5UU1RBVF9SWEUgfA0KCQlJTlRTVEFU X1RYQyB8IElOVFNUQVRfVENDIHwgSU5UU1RBVF9UUUUgfCBJTlRTVEFUX1RY VSB8DQoJCUlOVFNUQVRfRkFUQUwgfA0KCQkoKFFTNjYxMl9PVUkgPT0gc2Mt PnBoeWlkKT9JTlRTVEFUX0dQMjowKSApOw0KDQoJLyogRW5hYmxlIGludGVy cnVwdHMsICBzZXQgZm9yIFBDSSByZWFkIG11bHRpcGxlIGFuZCBldGMgKi8N CglDU1JfV1JJVEVfNCggc2MsIEdFTkNUTCwNCgkJR0VOQ1RMX0VOQUJMRV9J TlRFUlJVUFQgfCBHRU5DVExfTUVNT1JZX1JFQURfTVVMVElQTEUgfA0KCQlH RU5DVExfT05FQ09QWSB8IEdFTkNUTF9SRUNFSVZFX0ZJRk9fVEhSRVNIT0xE NjQgKTsNCg0KCS8qIE1hcmsgaW50ZXJmYWNlIHJ1bm5pbmcgLi4uICovDQoJ aWYoIGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVAgKSBpZnAtPmlmX2ZsYWdzIHw9 IElGRl9SVU5OSU5HOw0KCWVsc2UgaWZwLT5pZl9mbGFncyAmPSB+SUZGX1JV Tk5JTkc7DQoNCgkvKiAuLi4gYW5kIGZyZWUgKi8NCglpZnAtPmlmX2ZsYWdz ICY9IH5JRkZfT0FDVElWRTsNCg0KCS8qIFN0YXJ0IFJ4IHByb2Nlc3MgKi8N CgllcGljX3N0YXJ0X2FjdGl2aXR5KHNjKTsNCg0KCXNwbHgocyk7DQoJcmV0 dXJuIDA7DQp9DQoNCi8qDQogKiBTeW5vcHNpczogY2FsY3VsYXRlIGFuZCBz ZXQgUnggbW9kZQ0KICovDQpzdGF0aWMgdm9pZA0KZXBpY19zZXRfcnhfbW9k ZSgNCiAgICBlcGljX3NvZnRjX3QgKiBzYykNCnsNCgl1X2ludDMyX3QgZmxh Z3MgPSBzYy0+ZXBpY19pZi5pZl9mbGFnczsNCiAgICAgICAgdV9pbnQzMl90 IHJ4Y29uID0gUlhDT05fREVGQVVMVCB8IFJYQ09OX1JFQ0VJVkVfTVVMVElD QVNUX0ZSQU1FUyB8IFJYQ09OX1JFQ0VJVkVfQlJPQURDQVNUX0ZSQU1FUzsN Cg0KCXJ4Y29uIHw9IChmbGFncyAmIElGRl9QUk9NSVNDKT9SWENPTl9QUk9N SVNDVU9VU19NT0RFOjA7DQoNCglDU1JfV1JJVEVfNCggc2MsIFJYQ09OLCBy eGNvbiApOw0KDQoJcmV0dXJuOw0KfQ0KDQovKg0KICogU3lub3BzaXM6IFJl c2V0IFBIWSBhbmQgZG8gUEhZLXNwZWNpYWwgaW5pdGlhbGl6YXRpb246DQog Ki8NCnN0YXRpYyB2b2lkDQplcGljX2luaXRfcGh5IF9fUCgoDQogICAgZXBp Y19zb2Z0Y190ICogc2MpKQ0Kew0KCXVfaW50MzJfdCBpOw0KDQoJLyogUmVz ZXQgUEhZICovDQoJZXBpY193cml0ZV9waHlfcmVnaXN0ZXIoIHNjLCBEUDgz ODQwX0JNQ1IsIEJNQ1JfUkVTRVQgKTsNCglmb3IoaT0wO2k8MHgxMDAwMDA7 aSsrKQ0KCQlpZiggIShlcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBzYywgRFA4 Mzg0MF9CTUNSICkgJiBCTUNSX1JFU0VUKSApIGJyZWFrOw0KDQoJaWYoIGVw aWNfcmVhZF9waHlfcmVnaXN0ZXIoIHNjLCBEUDgzODQwX0JNQ1IgKSAmIEJN Q1JfUkVTRVQgKQ0KCQlwcmludGYoInR4JWQ6IFdBUk5JTkchIGNhbm5vdCBy ZXNldCBQSFlcbiIsc2MtPnVuaXQpOw0KDQoJc3dpdGNoKCBzYy0+cGh5aWQg KXsNCgljYXNlIFFTNjYxMl9PVUk6DQoJCS8qIEluaXQgUVM2NjEyIGFuZCBF UElDIHRvIGdlbmVyYXRlIGludGVycnVwdCB3aGVuIEFOIGNvbXBsZXRlICov DQoJCUNTUl9XUklURV80KCBzYywgTlZDVEwsIE5WQ1RMX0dQMV9PVVRQVVRf RU5BQkxFICk7DQoJCWVwaWNfcmVhZF9waHlfcmVnaXN0ZXIoIHNjLCBRUzY2 MTJfSU5UU1RBVCApOw0KCQllcGljX3dyaXRlX3BoeV9yZWdpc3Rlciggc2Ms IFFTNjYxMl9JTlRNQVNLLCBJTlRNQVNLX1RIVU5ERVJMQU4gfCBJTlRTVEFU X0FOX0NPTVBMRVRFICk7DQoNCgkJLyogRW5hYmxlIFFTNjYxMiBleHRlbmRl ZCBjYWJsZSBsZW5ndGggY2FwYWJpbGl0ZXMgKi8NCgkJZXBpY193cml0ZV9w aHlfcmVnaXN0ZXIoIHNjLCBRUzY2MTJfTUNUTCwgZXBpY19yZWFkX3BoeV9y ZWdpc3Rlciggc2MsUVM2NjEyX01DVEwgKSB8IE1DVExfQlRFWFQgKTsNCgkJ YnJlYWs7DQoJZGVmYXVsdDoNCgkJYnJlYWs7DQoJfQ0KfQ0KDQovKg0KICog U3lub3BzaXM6IFNldCBQSFkgdG8gbWVkaWEgdHlwZSBzcGVjaWZpZWQgYnkg SUZGX0xJTksqIGZsYWdzIG9yDQogKiBpZm1lZGlhIHN0cnVjdHVyZS4NCiAq Lw0Kc3RhdGljIHZvaWQNCmVwaWNfc2V0X21lZGlhX3NwZWVkIF9fUCgoDQog ICAgZXBpY19zb2Z0Y190ICogc2MpKQ0Kew0KCXVfaW50MTZfdCBtZWRpYTsN Cg0KI2lmIGRlZmluZWQoX05FVF9JRl9NRURJQV9IXykNCgl1X2ludDMyX3Qg dGd0bWVkaWEgPSBzYy0+aWZtZWRpYS5pZm1fY3VyLT5pZm1fbWVkaWE7DQoN CglpZiggSUZNX1NVQlRZUEUodGd0bWVkaWEpICE9IElGTV9BVVRPICl7DQoJ CS8qIFNldCBtb2RlICovDQoJCW1lZGlhID0gKElGTV9TVUJUWVBFKHRndG1l ZGlhKT09SUZNXzEwMF9UWCkgPyBCTUNSXzEwME1CUFMgOiAwOw0KCQltZWRp YXw9ICh0Z3RtZWRpYSZJRk1fRkRYKSA/IEJNQ1JfRlVMTF9EVVBMRVggOiAw Ow0KDQoJCXNjLT5lcGljX2lmLmlmX2JhdWRyYXRlID0gDQoJCQkoSUZNX1NV QlRZUEUodGd0bWVkaWEpPT1JRk1fMTAwX1RYKT8xMDAwMDAwMDA6MTAwMDAw MDA7DQoNCgkJZXBpY193cml0ZV9waHlfcmVnaXN0ZXIoIHNjLCBEUDgzODQw X0JNQ1IsIG1lZGlhICk7DQoNCgkJbWVkaWEgPSBUWENPTl9ERUZBVUxUOw0K CQlpZiggdGd0bWVkaWEgJiBJRk1fRkRYICkgbWVkaWEgfD0gVFhDT05fRlVM TF9EVVBMRVg7DQoJCWVsc2UgaWYoIHRndG1lZGlhICYgSUZNX0xPT1AgKSBt ZWRpYSB8PSBUWENPTl9MT09QQkFDS19NT0RFX0lOVDsNCgkJDQoJCUNTUl9X UklURV80KCBzYywgVFhDT04sIG1lZGlhICk7DQoJfQ0KI2Vsc2UNCglzdHJ1 Y3QgaWZuZXQgKmlmcCA9ICZzYy0+ZXBpY19pZjsNCg0KCWlmKCBpZnAtPmlm X2ZsYWdzICYgSUZGX0xJTkswICkgew0KCQkvKiBTZXQgbW9kZSAqLw0KCQlt ZWRpYSA9IChpZnAtPmlmX2ZsYWdzICYgSUZGX0xJTksyKSA/IEJNQ1JfMTAw TUJQUyA6IDA7DQoJCW1lZGlhfD0gKGlmcC0+aWZfZmxhZ3MgJiBJRkZfTElO SzEpID8gQk1DUl9GVUxMX0RVUExFWCA6IDA7DQoNCgkJc2MtPmVwaWNfaWYu aWZfYmF1ZHJhdGUgPSANCgkJCShpZnAtPmlmX2ZsYWdzICYgSUZGX0xJTksy KT8xMDAwMDAwMDA6MTAwMDAwMDA7DQoNCgkJZXBpY193cml0ZV9waHlfcmVn aXN0ZXIoIHNjLCBEUDgzODQwX0JNQ1IsIG1lZGlhICk7DQoNCgkJbWVkaWEg PSBUWENPTl9ERUZBVUxUOw0KCQltZWRpYSB8PSAoaWZwLT5pZl9mbGFncyZJ RkZfTElOSzIpP1RYQ09OX0ZVTExfRFVQTEVYOjA7DQogDQoJCUNTUl9XUklU RV80KCBzYywgVFhDT04sIG1lZGlhICk7DQoJfQ0KI2VuZGlmDQoJICBlbHNl IHsNCgkJc2MtPmVwaWNfaWYuaWZfYmF1ZHJhdGUgPSAxMDAwMDAwMDA7DQoN CgkJQ1NSX1dSSVRFXzQoIHNjLCBUWENPTiwgVFhDT05fREVGQVVMVCApOw0K DQoJCS8qIFNldCBhbmQgcmVzdGFydCBhdXRvbmVnICovDQoJCWVwaWNfd3Jp dGVfcGh5X3JlZ2lzdGVyKCBzYywgRFA4Mzg0MF9CTUNSLA0KCQkJQk1DUl9B VVRPTkVHT1RJQVRJT04gfCBCTUNSX1JFU1RBUlRfQVVUT05FRyApOw0KDQoJ CS8qIElmIGl0IGlzIG5vdCBRUzY2MTIgUEhZLCB0cnkgdG8gZ2V0IHJlc3Vs dCBvZiBhdXRvbmVnLiAqLw0KCQlpZiggUVM2NjEyX09VSSAhPSBzYy0+cGh5 aWQgKSB7DQoJCQkvKiBXYWl0IDMgc2Vjb25kcyBmb3IgdGhlIGF1dG9uZWcg dG8gZmluaXNoDQoJCQkgKiBUaGlzIGlzIHRoZSByZWNvbW1lbmRlZCB0aW1l IGZyb20gdGhlIERQODM4NDBBIGRhdGENCgkJCSAqIHNoZWV0IFNlY3Rpb24g Ny4xDQoJCQkgKi8NCiAgICAgICAgCQlERUxBWSgzMDAwMDAwKTsNCgkJCQ0K CQkJaWYoIGVwaWNfYXV0b25lZyhzYykgPT0gRVBJQ19GVUxMX0RVUExFWCAp DQoJCQkJQ1NSX1dSSVRFXzQoIHNjLCBUWENPTiwgVFhDT05fRlVMTF9EVVBM RVh8VFhDT05fREVGQVVMVCk7DQoJCX0NCgkJLyogRWxzZSBpdCB3aWxsIGJl IGRvbmUgd2hlbiBHUDIgaW50IG9jY3VyZWQgKi8NCgl9DQoNCglyZXR1cm47 DQp9DQoNCi8qDQogKiBUaGlzIGZ1bmN0aW9ucyBnZXQgcmVzdWx0cyBvZiB0 aGUgYXV0b25lZyBwcm9jZXNzZXMgb2YgdGhlIHBoeQ0KICogSXQgaW1wbGVt ZW50cyB0aGUgd29ya2Fyb3VuZCB0aGF0IGlzIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDcuMiAmIDcuMyBvZiB0aGUgDQogKiBEUDgzODQwQSBkYXRhIHNoZWV0 DQogKiBodHRwOi8vd3d3Lm5hdGlvbmFsLmNvbS9kcy9EUC9EUDgzODQwQS5w ZGYNCiAqLw0Kc3RhdGljIGludCANCmVwaWNfYXV0b25lZygNCiAgICBlcGlj X3NvZnRjX3QgKiBzYykNCnsNCglzdHJ1Y3QgaWZuZXQgKmlmcCA9ICZzYy0+ ZXBpY19pZjsNCgl1X2ludDE2X3QgbWVkaWE7DQoJdV9pbnQxNl90IGk7DQoN CiAgICAgICAgLyogQk1TUiBtdXN0IGJlIHJlYWQgdHdpY2UgdG8gdXBkYXRl IHRoZSBsaW5rIHN0YXR1cyBiaXQNCgkgKiBzaW5jZSB0aGF0IGJpdCBpcyBh IGxhdGNoIGJpdA0KICAgICAgICAgKi8NCgllcGljX3JlYWRfcGh5X3JlZ2lz dGVyKCBzYywgRFA4Mzg0MF9CTVNSKTsNCglpID0gZXBpY19yZWFkX3BoeV9y ZWdpc3Rlciggc2MsIERQODM4NDBfQk1TUik7DQogICAgICAgIA0KICAgICAg ICBpZiAoKGkgJiBCTVNSX0xJTktfU1RBVFVTKSAmJiAoaSAmIEJNU1JfQVVU T05FR19DT01QTEVURSkpew0KCQlpID0gZXBpY19yZWFkX3BoeV9yZWdpc3Rl ciggc2MsIERQODM4NDBfTFBBUiApOw0KDQoJCWlmICggaSAmIChBTkFSXzEw MF9UWF9GRHxBTkFSXzEwX0ZEKSApDQoJCQlyZXR1cm4gCUVQSUNfRlVMTF9E VVBMRVg7DQoJCWVsc2UNCgkJCXJldHVybiBFUElDX0hBTEZfRFVQTEVYOw0K ICAgICAgICB9IA0KCWVsc2UgeyAgIC8qQXV0by1uZWdvdGlhdGlvbiBvciBs aW5rIHN0YXR1cyBpcyBub3QgMQ0KCQkgICBUaHVzIHRoZSBhdXRvLW5lZ290 aWF0aW9uIGZhaWxlZCBhbmQgb25lDQoJCSAgIG11c3QgdGFrZSBvdGhlciBt ZWFucyB0byBmaXggaXQuDQoJCSAgKi8NCg0KCQkvKiBBTkVSIG11c3QgYmUg cmVhZCB0d2ljZSB0byBnZXQgdGhlIGNvcnJlY3QgcmVhZGluZyBmb3IgdGhl IA0KCQkgKiBNdWx0aXBsZSBsaW5rIGZhdWx0IGJpdCAtLSBpdCBpcyBhIGxh dGNoZWQgYml0DQoJIAkgKi8NCiAJCWVwaWNfcmVhZF9waHlfcmVnaXN0ZXIo IHNjLCBEUDgzODQwX0FORVIgKTsNCgkJaSA9IGVwaWNfcmVhZF9waHlfcmVn aXN0ZXIoIHNjLCBEUDgzODQwX0FORVIgKTsNCgkNCgkJaWYgKCBpICYgQU5F Ul9NVUxUSVBMRV9MSU5LX0ZBVUxUICkgew0KCQkJLyogaXQgY2FuIGJlIGZv cmNlZCB0byAxMDBNYi9zIEhhbGYtRHVwbGV4ICovDQoJIAkJbWVkaWEgPSBl cGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBzYywgRFA4Mzg0MF9CTUNSICk7DQoJ CQltZWRpYSAmPSB+KEJNQ1JfQVVUT05FR09USUFUSU9OIHwgQk1DUl9GVUxM X0RVUExFWCk7DQoJCQltZWRpYSB8PSBCTUNSXzEwME1CUFM7DQoJCQllcGlj X3dyaXRlX3BoeV9yZWdpc3Rlciggc2MsIERQODM4NDBfQk1DUiwgbWVkaWEg KTsNCgkJDQoJCQkvKiByZWFkIEJNU1IgYWdhaW4gdG8gZGV0ZXJtaW5lIGxp bmsgc3RhdHVzICovDQoJCQllcGljX3JlYWRfcGh5X3JlZ2lzdGVyKCBzYywg RFA4Mzg0MF9CTVNSICk7DQoJCQlpPWVwaWNfcmVhZF9waHlfcmVnaXN0ZXIo IHNjLCBEUDgzODQwX0JNU1IgKTsNCgkJDQoJCQlpZiAoaSAmIEJNU1JfTElO S19TVEFUVVMpew0KCQkJCS8qIHBvcnQgaXMgbGlua2VkIHRvIHRoZSBub24g QXV0by1OZWdvdGlhdGlvbg0KCQkJCSAqIDEwME1icyBwYXJ0bmVyLg0KCQkJ IAkgKi8NCgkJCQlyZXR1cm4gRVBJQ19IQUxGX0RVUExFWDsNCgkJCX0NCgkJ CWVsc2Ugew0KCQkJCW1lZGlhID0gZXBpY19yZWFkX3BoeV9yZWdpc3Rlcigg c2MsIERQODM4NDBfQk1DUik7DQoJCQkJbWVkaWEgJj0gfihCTUNSX0FVVE9O RUdPVElBVElPTiB8IEJNQ1JfRlVMTF9EVVBMRVggfCBCTUNSXzEwME1CUFMp Ow0KCQkJCWVwaWNfd3JpdGVfcGh5X3JlZ2lzdGVyKCBzYywgRFA4Mzg0MF9C TUNSLCBtZWRpYSk7DQoJCQkJZXBpY19yZWFkX3BoeV9yZWdpc3Rlciggc2Ms IERQODM4NDBfQk1TUiApOw0KCQkJCWk9ZXBpY19yZWFkX3BoeV9yZWdpc3Rl ciggc2MsIERQODM4NDBfQk1TUiApOw0KDQoJCQkJaWYgKGkgJiBCTVNSX0xJ TktfU1RBVFVTKSB7DQoJCQkJCS8qcG9ydCBpcyBsaW5rZWQgdG8gdGhlIG5v bg0KCQkJCQkgKiBBdXRvLU5lZ290aWF0aW9uMTBNYnMgcGFydG5lcg0KCQkJ IAkgCSAqLw0KCQkJCQlyZXR1cm4gRVBJQ19IQUxGX0RVUExFWDsNCgkJCQl9 DQoJCQl9DQoJCX0NCgkJLyogSWYgd2UgZ2V0IGhlcmUgd2UgYXJlIG1vc3Qg bGlrZWx5IG5vdCBjb25uZWN0ZWQNCgkJICogc28gbGV0cyBkZWZhdWx0IGl0 IHRvIGhhbGYgZHVwbGV4DQoJCSAqLw0KCQlyZXR1cm4gRVBJQ19IQUxGX0RV UExFWDsNCgl9DQoJDQp9DQoNCi8qDQogKiBTeW5vcHNpczogVGhpcyBmdW5j dGlvbiBzaG91bGQgdXBkYXRlIG11bHRpY2FzdCBoYXNoIHRhYmxlLg0KICog SSBzdXBwb3NlIHRoZXJlIGlzIGEgYnVnIGluIGNoaXBzIE1DIGZpbHRlciBz byB0aGlzIGZ1bmN0aW9uDQogKiBvbmx5IHNldCBpdCB0byByZWNlaXZlIGFs bCBNQyBwYWNrZXRzLiBUaGUgc2Vjb25kIHByb2JsZW0gaXMNCiAqIHRoYXQg d2Ugc2hvdWxkIHdhaXQgZm9yIFRYIGFuZCBSWCBwcm9jZXNzZXMgdG8gc3Rv cCBiZWZvcmUNCiAqIHJlcHJvZ3JhbW1pbmcgTUMgZmlsdGVyLiBUaGUgZXBp Y19zdG9wX2FjdGl2aXR5KCkgYW5kIA0KICogZXBpY19zdGFydF9hY3Rpdml0 eSgpIHNob3VsZCBoZWxwIHRvIGRvIHRoaXMuDQogKi8NCnN0YXRpYyB2b2lk DQplcGljX3NldF9tY190YWJsZSAoDQogICAgZXBpY19zb2Z0Y190ICogc2Mp DQp7DQoJc3RydWN0IGlmbmV0ICppZnAgPSAmc2MtPmVwaWNfaWY7DQoNCglp ZiggaWZwLT5pZl9mbGFncyAmIElGRl9NVUxUSUNBU1QgKXsNCgkJQ1NSX1dS SVRFXzQoIHNjLCBNQzAsIDB4RkZGRiApOw0KCQlDU1JfV1JJVEVfNCggc2Ms IE1DMSwgMHhGRkZGICk7DQoJCUNTUl9XUklURV80KCBzYywgTUMyLCAweEZG RkYgKTsNCgkJQ1NSX1dSSVRFXzQoIHNjLCBNQzMsIDB4RkZGRiApOw0KCX0N Cg0KCXJldHVybjsNCn0NCg0Kc3RhdGljIHZvaWQNCmVwaWNfc2h1dGRvd24o DQogICAgaW50IGhvd3RvLA0KICAgIHZvaWQgKnNjKQ0Kew0KCWVwaWNfc3Rv cChzYyk7DQp9DQoNCi8qIA0KICogU3lub3BzaXM6IFN0YXJ0IHJlY2VpdmUg cHJvY2Vzcywgc2hvdWxkIGNoZWNrIHRoYXQgYWxsIGludGVybmFsIGNoaXAg DQogKiBwb2ludGVycyBhcmUgc2V0IHByb3Blcmx5Lg0KICovDQpzdGF0aWMg dm9pZA0KZXBpY19zdGFydF9hY3Rpdml0eSBfX1AoKA0KICAgIGVwaWNfc29m dGNfdCAqIHNjKSkNCnsNCgkvKiBTdGFydCByeCBwcm9jZXNzICovDQoJQ1NS X1dSSVRFXzQoIHNjLCBDT01NQU5ELCBDT01NQU5EX1JYUVVFVUVEIHwgQ09N TUFORF9TVEFSVF9SWCApOw0KfQ0KDQovKg0KICogU3lub3BzaXM6IENvbXBs ZXRlbHkgc3RvcCBSeCBhbmQgVHggcHJvY2Vzc2VzLiBJZiBUUUUgaXMgc2V0 IGFkZGl0aW9uYWwNCiAqIHBhY2tldCBuZWVkcyB0byBiZSBxdWV1ZWQgdG8g c3RvcCBUeCBETUEuDQogKi8NCnN0YXRpYyB2b2lkDQplcGljX3N0b3BfYWN0 aXZpdHkgX19QKCgNCiAgICBlcGljX3NvZnRjX3QgKiBzYykpDQp7DQoJaW50 IGk7DQoNCgkvKiBTdG9wIFR4IGFuZCBSeCBETUEgKi8NCglDU1JfV1JJVEVf NCggc2MsIENPTU1BTkQsIENPTU1BTkRfU1RPUF9SWCB8IENPTU1BTkRfU1RP UF9SRE1BIHwgQ09NTUFORF9TVE9QX1RETUEpOw0KDQoJLyogV2FpdCBvbmx5 IFJ4IERNQSAqLw0KCWRwcmludGYoKCJ0eCVkOiB3YWl0aW5nIFJ4IERNQSB0 byBzdG9wXG4iLHNjLT51bml0KSk7DQoJZm9yKGk9MDtpPDB4MTAwMDAwO2kr KykNCgkJaWYoIChDU1JfUkVBRF80KHNjLElOVFNUQVQpJklOVFNUQVRfUlhJ RExFKSA9PSBJTlRTVEFUX1JYSURMRSApIGJyZWFrOw0KDQoJaWYoICEoQ1NS X1JFQURfNChzYyxJTlRTVEFUKSZJTlRTVEFUX1JYSURMRSkgKSANCgkJcHJp bnRmKCJ0eCVkOiBjYW4ndCBzdG9wIFJYIERNQVxuIixzYy0+dW5pdCk7DQoN CgkvKiBNYXkgbmVlZCB0byBxdWV1ZSBvbmUgbW9yZSBwYWNrZXQgaWYgVFFF ICovDQoJaWYoIChDU1JfUkVBRF80KCBzYywgSU5UU1RBVCApICYgSU5UU1RB VF9UUUUpICYmDQoJICAgICEoQ1NSX1JFQURfNCggc2MsIElOVFNUQVQgKSAm IElOVFNUQVRfVFhJRExFKSApew0KCQlkcHJpbnRmKCgidHglZDogcXVldWUg bGFzdCBwYWNrZXRcbiIsc2MtPnVuaXQpKTsNCg0KCQkvKiBUdXJuIGl0IHRv IGxvb3BiYWNrIG1vZGUgKi8JDQoJCUNTUl9XUklURV80KCBzYywgVFhDT04s IFRYQ09OX0RFRkFVTFQgfCBUWENPTl9MT09QQkFDS19NT0RFX0lOVCApOw0K DQoJCXNjLT50eF9kZXNjW3NjLT5jdXJfdHhdLmJ1ZmFkZHIgPSB2dG9waHlz KCBzYyApOw0KCQlzYy0+dHhfZGVzY1tzYy0+Y3VyX3R4XS5idWZsZW5ndGgg PSBFVEhFUl9NSU5fTEVOLUVUSEVSX0NSQ19MRU47DQoJCXNjLT50eF9kZXNj W3NjLT5jdXJfdHhdLmNvbnRyb2wgPSAweDE0Ow0KCQlzYy0+dHhfZGVzY1tz Yy0+Y3VyX3R4XS50eGxlbmd0aCA9IEVUSEVSX01JTl9MRU4tRVRIRVJfQ1JD X0xFTjsNCgkJc2MtPnR4X2Rlc2Nbc2MtPmN1cl90eF0uc3RhdHVzID0gMHg4 MDAwOw0KDQoJCUNTUl9XUklURV80KCBzYywgQ09NTUFORCwgQ09NTUFORF9U WFFVRVVFRCApOw0KDQoJCWRwcmludGYoKCJ0eCVkOiB3YWl0aW5nIFR4IERN QSB0byBzdG9wXG4iLHNjLT51bml0KSk7DQoJCS8qIFdhaXQgVFggRE1BIHRv IHN0b3AgKi8NCgkJZm9yKGk9MDtpPDB4MTAwMDAwO2krKykNCgkJCWlmKCAo Q1NSX1JFQURfNChzYyxJTlRTVEFUKSZJTlRTVEFUX1RYSURMRSkgPT0gSU5U U1RBVF9UWElETEUgKSBicmVhazsNCg0KCQlpZiggIShDU1JfUkVBRF80KHNj LElOVFNUQVQpJklOVFNUQVRfVFhJRExFKSApDQoJCQlwcmludGYoInR4JWQ6 IGNhbid0IHN0b3AgVFggRE1BXG4iLHNjLT51bml0KTsNCgl9DQp9DQoNCi8q DQogKiAgU3lub3BzaXM6IFNodXQgZG93biBib2FyZCBhbmQgZGVhbGxvY2F0 ZXMgcmluZ3MuDQogKg0KICogIHNwbGltcCgpIGludm9rZWQgaGVyZQ0KICov DQpzdGF0aWMgdm9pZA0KZXBpY19zdG9wIF9fUCgoDQogICAgZXBpY19zb2Z0 Y190ICogc2MpKQ0Kew0KCWludCBpLHM7DQoNCglzID0gc3BsaW1wKCk7DQoN CglzYy0+ZXBpY19pZi5pZl90aW1lciA9IDA7DQoNCgkvKiBEaXNhYmxlIGlu dGVycnVwdHMgKi8NCglDU1JfV1JJVEVfNCggc2MsIElOVE1BU0ssIDAgKTsN CglDU1JfV1JJVEVfNCggc2MsIEdFTkNUTCwgMCApOw0KDQoJLyogVHJ5IHRv IHN0b3AgUnggYW5kIFRYIHByb2Nlc3NlcyAqLw0KCWVwaWNfc3RvcF9hY3Rp dml0eShzYyk7DQoNCgkvKiBSZXNldCBjaGlwICovDQoJQ1NSX1dSSVRFXzQo IHNjLCBHRU5DVEwsIEdFTkNUTF9TT0ZUX1JFU0VUICk7DQoJREVMQVkoMSk7 DQoNCgkvKiBGcmVlIG1lbW9yeSBhbGxvY2F0ZWQgZm9yIHJpbmdzICovDQoJ ZXBpY19mcmVlX3JpbmdzKHNjKTsNCg0KCS8qIE1hcmsgYXMgc3RvcGVkICov DQoJc2MtPmVwaWNfaWYuaWZfZmxhZ3MgJj0gfklGRl9SVU5OSU5HOw0KDQoJ c3BseChzKTsNCglyZXR1cm47DQp9DQoNCi8qDQogKiBTeW5vcHNpczogVGhp cyBmdW5jdGlvbiBzaG91bGQgZnJlZSBhbGwgbWVtb3J5IGFsbG9jYXRlZCBm b3IgcmluZ3MuDQogKi8gDQpzdGF0aWMgdm9pZA0KZXBpY19mcmVlX3Jpbmdz IF9fUCgoDQogICAgZXBpY19zb2Z0Y190ICogc2MpKQ0Kew0KCWludCBpOw0K DQoJZm9yKGk9MDtpPFJYX1JJTkdfU0laRTtpKyspew0KCQlzdHJ1Y3QgZXBp Y19yeF9idWZmZXIgKmJ1ZiA9IHNjLT5yeF9idWZmZXIgKyBpOw0KCQlzdHJ1 Y3QgZXBpY19yeF9kZXNjICpkZXNjID0gc2MtPnJ4X2Rlc2MgKyBpOw0KCQkN CgkJZGVzYy0+c3RhdHVzID0gMDsNCgkJZGVzYy0+YnVmbGVuZ3RoID0gMDsN CgkJZGVzYy0+YnVmYWRkciA9IDA7DQoNCgkJaWYoIGJ1Zi0+bWJ1ZiApIG1f ZnJlZW0oIGJ1Zi0+bWJ1ZiApOw0KCQlidWYtPm1idWYgPSBOVUxMOw0KCX0N Cg0KCWZvcihpPTA7aTxUWF9SSU5HX1NJWkU7aSsrKXsNCgkJc3RydWN0IGVw aWNfdHhfYnVmZmVyICpidWYgPSBzYy0+dHhfYnVmZmVyICsgaTsNCgkJc3Ry dWN0IGVwaWNfdHhfZGVzYyAqZGVzYyA9IHNjLT50eF9kZXNjICsgaTsNCg0K CQlkZXNjLT5zdGF0dXMgPSAwOw0KCQlkZXNjLT5idWZsZW5ndGggPSAwOw0K CQlkZXNjLT5idWZhZGRyID0gMDsNCg0KCQlpZiggYnVmLT5tYnVmICkgbV9m cmVlbSggYnVmLT5tYnVmICk7DQoJCWJ1Zi0+bWJ1ZiA9IE5VTEw7DQoJfQ0K fQ0KDQovKg0KICogU3lub3BzaXM6ICBBbGxvY2F0ZXMgbWJ1ZnMgZm9yIFJ4 IHJpbmcgYW5kIHBvaW50IFJ4IGRlc2NzIHRvIHRoZW0uDQogKiBQb2ludCBU eCBkZXNjcyB0byBmcmFnbWVudCBsaXN0cy4gQ2hlY2sgdGhhdCBhbGwgZGVz Y3MgYW5kIGZyYWdsaXN0cw0KICogYXJlIGJvdW5kZWQgYW5kIGFsaWduZWQg cHJvcGVybHkuDQogKi8NCnN0YXRpYyBpbnQNCmVwaWNfaW5pdF9yaW5ncyhl cGljX3NvZnRjX3QgKiBzYyl7DQoJaW50IGk7DQoJc3RydWN0IG1idWYgKm07 DQoNCglzYy0+Y3VyX3J4ID0gc2MtPmN1cl90eCA9IHNjLT5kaXJ0eV90eCA9 IHNjLT5wZW5kaW5nX3R4cyA9IDA7DQoNCglmb3IgKGkgPSAwOyBpIDwgUlhf UklOR19TSVpFOyBpKyspIHsNCgkJc3RydWN0IGVwaWNfcnhfYnVmZmVyICpi dWYgPSBzYy0+cnhfYnVmZmVyICsgaTsNCgkJc3RydWN0IGVwaWNfcnhfZGVz YyAqZGVzYyA9IHNjLT5yeF9kZXNjICsgaTsNCg0KCQlkZXNjLT5zdGF0dXMg PSAwOwkJLyogT3duZWQgYnkgZHJpdmVyICovDQoJCWRlc2MtPm5leHQgPSB2 dG9waHlzKCBzYy0+cnhfZGVzYyArICgoaSsxKSVSWF9SSU5HX1NJWkUpICk7 DQoNCgkJaWYoIChkZXNjLT5uZXh0ICYgMykgfHwgKChkZXNjLT5uZXh0ICYg MHhGRkYpICsgc2l6ZW9mKHN0cnVjdCBlcGljX3J4X2Rlc2MpID4gMHgxMDAw ICkgKQ0KCQkJcHJpbnRmKCJ0eCVkOiBXQVJOSU5HISByeF9kZXNjIGlzIG1p c2JvdW5kIG9yIG1pc2FsaWduZWRcbiIsc2MtPnVuaXQpOw0KDQoJCUVQSUNf TUdFVENMVVNURVIoIGJ1Zi0+bWJ1ZiApOw0KCQlpZiggTlVMTCA9PSBidWYt Pm1idWYgKSB7DQoJCQllcGljX2ZyZWVfcmluZ3Moc2MpOw0KCQkJcmV0dXJu IC0xOw0KCQl9DQoJCWRlc2MtPmJ1ZmFkZHIgPSB2dG9waHlzKCBtdG9kKGJ1 Zi0+bWJ1ZixjYWRkcl90KSApOw0KDQoJCWRlc2MtPmJ1Zmxlbmd0aCA9IEVU SEVSX01BWF9GUkFNRV9MRU47DQoJCWRlc2MtPnN0YXR1cyA9IDB4ODAwMDsJ CQkvKiBHaXZlIHRvIEVQSUMgKi8NCg0KCX0NCg0KCWZvciAoaSA9IDA7IGkg PCBUWF9SSU5HX1NJWkU7IGkrKykgew0KCQlzdHJ1Y3QgZXBpY190eF9idWZm ZXIgKmJ1ZiA9IHNjLT50eF9idWZmZXIgKyBpOw0KCQlzdHJ1Y3QgZXBpY190 eF9kZXNjICpkZXNjID0gc2MtPnR4X2Rlc2MgKyBpOw0KDQoJCWRlc2MtPnN0 YXR1cyA9IDA7DQoJCWRlc2MtPm5leHQgPSB2dG9waHlzKCBzYy0+dHhfZGVz YyArICggKGkrMSklVFhfUklOR19TSVpFICkgKTsNCg0KCQlpZiggKGRlc2Mt Pm5leHQgJiAzKSB8fCAoKGRlc2MtPm5leHQgJiAweEZGRikgKyBzaXplb2Yo c3RydWN0IGVwaWNfdHhfZGVzYykgPiAweDEwMDAgKSApDQoJCQlwcmludGYo InR4JWQ6IFdBUk5JTkchIHR4X2Rlc2MgaXMgbWlzYm91bmQgb3IgbWlzYWxp Z25lZFxuIixzYy0+dW5pdCk7DQoNCgkJYnVmLT5tYnVmID0gTlVMTDsNCgkJ ZGVzYy0+YnVmYWRkciA9IHZ0b3BoeXMoIHNjLT50eF9mbGlzdCArIGkgKTsN CgkJaWYoIChkZXNjLT5idWZhZGRyICYgMykgfHwgKChkZXNjLT5idWZhZGRy ICYgMHhGRkYpICsgc2l6ZW9mKHN0cnVjdCBlcGljX2ZyYWdfbGlzdCkgPiAw eDEwMDAgKSApDQoJCQlwcmludGYoInR4JWQ6IFdBUk5JTkchIGZyYWdfbGlz dCBpcyBtaXNib3VuZCBvciBtaXNhbGlnbmVkXG4iLHNjLT51bml0KTsNCgl9 DQoNCglyZXR1cm4gMDsNCn0NCg0KLyoNCiAqIEVFUFJPTSBvcGVyYXRpb24g ZnVuY3Rpb25zDQogKi8NCnN0YXRpYyB2b2lkIGVwaWNfd3JpdGVfZWVwcm9t cmVnIF9fUCgoDQogICAgZXBpY19zb2Z0Y190ICpzYywNCiAgICB1X2ludDhf dCB2YWwpKQ0Kew0KCXVfaW50MTZfdCBpOw0KDQoJQ1NSX1dSSVRFXzEoIHNj LCBFRUNUTCwgdmFsICk7DQoNCglmb3IoIGk9MDtpPDB4RkY7IGkrKykNCgkJ aWYoICEoQ1NSX1JFQURfMSggc2MsIEVFQ1RMICkgJiAweDIwKSApIGJyZWFr Ow0KDQoJcmV0dXJuOw0KfQ0KDQpzdGF0aWMgdV9pbnQ4X3QNCmVwaWNfcmVh ZF9lZXByb21yZWcgX19QKCgNCiAgICBlcGljX3NvZnRjX3QgKnNjKSkNCnsN CglyZXR1cm4gQ1NSX1JFQURfMSggc2MsRUVDVEwgKTsNCn0gIA0KDQpzdGF0 aWMgdV9pbnQ4X3QNCmVwaWNfZWVwcm9tX2Nsb2NrIF9fUCgoDQogICAgZXBp Y19zb2Z0Y190ICpzYywNCiAgICB1X2ludDhfdCB2YWwpKQ0Kew0KCWVwaWNf d3JpdGVfZWVwcm9tcmVnKCBzYywgdmFsICk7DQoJZXBpY193cml0ZV9lZXBy b21yZWcoIHNjLCAodmFsIHwgMHg0KSApOw0KCWVwaWNfd3JpdGVfZWVwcm9t cmVnKCBzYywgdmFsICk7DQoJDQoJcmV0dXJuIGVwaWNfcmVhZF9lZXByb21y ZWcoIHNjICk7DQp9DQoNCnN0YXRpYyB2b2lkDQplcGljX291dHB1dF9lZXBy b213IF9fUCgoDQogICAgZXBpY19zb2Z0Y190ICogc2MsDQogICAgdV9pbnQx Nl90IHZhbCkpDQp7DQoJaW50IGk7ICAgICAgICAgIA0KCWZvciggaSA9IDB4 RjsgaSA+PSAwOyBpLS0pew0KCQlpZiggKHZhbCAmICgxIDw8IGkpKSApIGVw aWNfZWVwcm9tX2Nsb2NrKCBzYywgMHgwQiApOw0KCQllbHNlIGVwaWNfZWVw cm9tX2Nsb2NrKCBzYywgMyk7DQoJfQ0KfQ0KDQpzdGF0aWMgdV9pbnQxNl90 DQplcGljX2lucHV0X2VlcHJvbXcgX19QKCgNCiAgICBlcGljX3NvZnRjX3Qg KnNjKSkNCnsNCglpbnQgaTsNCglpbnQgdG1wOw0KCXVfaW50MTZfdCByZXR2 YWwgPSAwOw0KDQoJZm9yKCBpID0gMHhGOyBpID49IDA7IGktLSkgewkNCgkJ dG1wID0gZXBpY19lZXByb21fY2xvY2soIHNjLCAweDMgKTsNCgkJaWYoIHRt cCAmIDB4MTAgKXsNCgkJCXJldHZhbCB8PSAoMSA8PCBpKTsNCgkJfQ0KCX0N CglyZXR1cm4gcmV0dmFsOw0KfQ0KDQpzdGF0aWMgaW50DQplcGljX3JlYWRf ZWVwcm9tIF9fUCgoDQogICAgZXBpY19zb2Z0Y190ICpzYywNCiAgICB1X2lu dDE2X3QgbG9jKSkNCnsNCglpbnQgaTsNCgl1X2ludDE2X3QgZGF0YXZhbDsN Cgl1X2ludDE2X3QgcmVhZF9jbWQ7DQoNCgllcGljX3dyaXRlX2VlcHJvbXJl Zyggc2MgLCAzKTsNCg0KCWlmKCBlcGljX3JlYWRfZWVwcm9tcmVnKCBzYyAp ICYgMHg0MCApDQoJCXJlYWRfY21kID0gKCBsb2MgJiAweDNGICkgfCAweDE4 MDsNCgllbHNlDQoJCXJlYWRfY21kID0gKCBsb2MgJiAweEZGICkgfCAweDYw MDsNCg0KCWVwaWNfb3V0cHV0X2VlcHJvbXcoIHNjLCByZWFkX2NtZCApOw0K DQogICAgICAgIGRhdGF2YWwgPSBlcGljX2lucHV0X2VlcHJvbXcoIHNjICk7 DQoNCgllcGljX3dyaXRlX2VlcHJvbXJlZyggc2MsIDEgKTsNCgkNCglyZXR1 cm4gZGF0YXZhbDsNCn0NCg0Kc3RhdGljIGludA0KZXBpY19yZWFkX3BoeV9y ZWdpc3RlciBfX1AoKA0KICAgIGVwaWNfc29mdGNfdCAqc2MsDQogICAgdV9p bnQxNl90IGxvYykpDQp7DQoJaW50IGk7DQoNCglDU1JfV1JJVEVfNCggc2Ms IE1JSUNUTCwgKChsb2MgPDwgNCkgfCAweDA2MDEpICk7DQoNCglmb3IoIGk9 MDtpPDB4MTAwMDtpKyspIGlmKCAhKENTUl9SRUFEXzQoIHNjLCBNSUlDVEwg KSYxKSApIGJyZWFrOw0KDQoJcmV0dXJuIENTUl9SRUFEXzQoIHNjLCBNSUlE QVRBICk7DQp9DQoNCnN0YXRpYyB2b2lkDQplcGljX3dyaXRlX3BoeV9yZWdp c3RlciBfX1AoKA0KICAgIGVwaWNfc29mdGNfdCAqIHNjLA0KICAgIHVfaW50 MTZfdCBsb2MsDQogICAgdV9pbnQxNl90IHZhbCkpDQp7DQoJaW50IGk7DQoN CglDU1JfV1JJVEVfNCggc2MsIE1JSURBVEEsIHZhbCApOw0KCUNTUl9XUklU RV80KCBzYywgTUlJQ1RMLCAoKGxvYyA8PCA0KSB8IDB4MDYwMikgKTsNCg0K CWZvciggaT0wO2k8MHgxMDAwO2krKykgaWYoICEoQ1NSX1JFQURfNCggc2Ms IE1JSUNUTCApJjIpICkgYnJlYWs7DQoNCglyZXR1cm47DQp9DQoNCiNpZiBk ZWZpbmVkKEVQSUNfREVCVUcpDQpzdGF0aWMgdm9pZA0KZXBpY19kdW1wX3N0 YXRlIF9fUCgoDQogICAgZXBpY19zb2Z0Y190ICogc2MpKQ0Kew0KCWludCBq Ow0KCXN0cnVjdCBlcGljX3R4X2Rlc2MgKnRkZXNjOw0KCXN0cnVjdCBlcGlj X3J4X2Rlc2MgKnJkZXNjOw0KCXByaW50ZigidHglZDogY3VyX3J4OiAlZCwg cGVuZGluZ190eHM6ICVkLCBkaXJ0eV90eDogJWQsIGN1cl90eDogJWRcbiIs DQoJCXNjLT51bml0LHNjLT5jdXJfcngsc2MtPnBlbmRpbmdfdHhzLHNjLT5k aXJ0eV90eCxzYy0+Y3VyX3R4KTsNCglwcmludGYoInR4JWQ6IENPTU1BTkQ6 IDB4JTA4eCwgSU5UU1RBVDogMHglMDh4XG4iLHNjLT51bml0LENTUl9SRUFE XzQoc2MsQ09NTUFORCksQ1NSX1JFQURfNChzYyxJTlRTVEFUKSk7DQoJcHJp bnRmKCJ0eCVkOiBQUkNEQVI6IDB4JTA4eCwgUFRDREFSOiAweCUwOHhcbiIs c2MtPnVuaXQsQ1NSX1JFQURfNChzYyxQUkNEQVIpLENTUl9SRUFEXzQoc2Ms UFRDREFSKSk7DQoJcHJpbnRmKCJ0eCVkOiBkdW1waW5nIHJ4IGRlc2NyaXB0 b3JzXG4iLHNjLT51bml0KTsNCglmb3Ioaj0wO2o8UlhfUklOR19TSVpFO2or Kyl7DQoJCXJkZXNjID0gc2MtPnJ4X2Rlc2MgKyBqOw0KCQlwcmludGYoImRl c2MlZDogJTRkIDB4JTA0eCwgMHglMDh4LCAlNGQsIDB4JTA4eFxuIiwNCgkJ CWosDQoJCQlyZGVzYy0+cnhsZW5ndGgscmRlc2MtPnN0YXR1cywNCgkJCXJk ZXNjLT5idWZhZGRyLA0KCQkJcmRlc2MtPmJ1Zmxlbmd0aCwNCgkJCXJkZXNj LT5uZXh0DQoJCSk7DQoJfQ0KCXByaW50ZigidHglZDogZHVtcGluZyB0eCBk ZXNjcmlwdG9yc1xuIixzYy0+dW5pdCk7DQoJZm9yKGo9MDtqPFRYX1JJTkdf U0laRTtqKyspew0KCQl0ZGVzYyA9IHNjLT50eF9kZXNjICsgajsNCgkJcHJp bnRmKCJkZXNjJWQ6ICU0ZCAweCUwNHgsIDB4JTA4eCwgMHglMDR4ICU0ZCwg MHglMDh4LCBtYnVmOiAweCUwOHhcbiIsDQoJCQlqLA0KCQkJdGRlc2MtPnR4 bGVuZ3RoLHRkZXNjLT5zdGF0dXMsDQoJCQl0ZGVzYy0+YnVmYWRkciwNCgkJ CXRkZXNjLT5jb250cm9sLHRkZXNjLT5idWZsZW5ndGgsDQoJCQl0ZGVzYy0+ bmV4dCwNCgkJCXNjLT50eF9idWZmZXJbal0ubWJ1Zg0KCQkpOw0KCX0NCn0N CiNlbmRpZg0KI2VuZGlmIC8qIE5QQ0kgPiAwICovDQo= --0-535351022-896843486=:20905-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 20:35:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11323 for freebsd-current-outgoing; Tue, 2 Jun 1998 20:35:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11310 for ; Tue, 2 Jun 1998 20:35:18 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id MAA12885; Wed, 3 Jun 1998 12:54:44 +0930 (CST) Message-ID: <19980603125443.K22406@freebie.lemis.com> Date: Wed, 3 Jun 1998 12:54:43 +0930 From: Greg Lehey To: shimon@simon-shapiro.org, Mike Smith Cc: Karl Pielorz , tcobb , "freebsd-current@freebsd.org" , Michael Hancock Subject: Re: DPT driver fails and panics with Degraded Array References: <199805292208.PAA01191@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Simon Shapiro on Mon, Jun 01, 1998 at 08:51:51PM -0400 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 1 June 1998 at 20:51:51 -0400, Simon Shapiro wrote: > On 29-May-98 Mike Smith wrote: > >>> I am routinely running a Dual DPT with 38 drives on 6 busses. On >>> 3.0-CURRENT SMP. The system did lose disk drives, either >>> intentionally, or by accident. I cannot confirm any of Mr. Cobb's >>> finding. I have not been funished with any data, including the >>> panic point, which I suspect is not in the DPT code. I am still >>> waiting for such data. >> >> I'd just like to point out that the "biodone: buffer not busy" panic >> doesn't come from the DPT driver, but may be caused by it calling >> biodone() on a buffer that the system does not believe is busy. Why would a driver call biodone on a buffer that doens't belong to it? >> These situations are worth analysing, and I hope to see you and Troy >> resolving this one, even if it means that you point the finger >> elsewhere. Definitely. I'm surprised nobody has done it yet. > I got these particularly with tape devices. Especially if there are two > tape drives on the system and yoy try to (for example) cpio to both > independently. I put a ton of debugging code in the DPT driver to try and > catch the DPT sending biodone twice on the same request and am pretty > comfortable the driver is not it. OK, where is the failing biodone called from? > Especially when the st.c peripheral driver will do it almost > consistently, and the disks will almost never do that. Since the > DPT driver does not know a disk from a cucamber, I doubt it is at > fault. But any persistent test cases are very welcome. I find this difficult to follow. Onn the one hand, lots of people (myself included) regularly use the st driver, and I've never seen this behaviour. About the only thing that these panics have in common is the DPT driver. It's easy enough to determine which driver is involved: all you need to do is follow the stack trace to find what devices is involved with the buffer (or just look at bp->b_dev). Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jun 2 21:51:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20706 for freebsd-current-outgoing; Tue, 2 Jun 1998 21:51:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from Mailbox.mcs.net (Mailbox.mcs.com [192.160.127.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20701 for ; Tue, 2 Jun 1998 21:51:05 -0700 (PDT) (envelope-from locke@mcs.net) Received: from locke.pr.mcs.net (locke.pr.mcs.net [205.253.19.243]) by Mailbox.mcs.net (8.8.7/8.8.2) with SMTP id XAA09130 for ; Tue, 2 Jun 1998 23:51:04 -0500 (CDT) Message-Id: <3.0.3.32.19980602235540.031b12a4@popmail.mcs.net> X-Sender: locke@popmail.mcs.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 02 Jun 1998 23:55:40 -0500 To: freebsd-current@FreeBSD.ORG From: Peter Johnson Subject: Support for Adaptec 2940U2W / Ultra2 SCSI? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is the Adaptec 2940U2W SCSI adapter supported by FreeBSD-current? I'm planning on putting FreeBSD on a Seagate ST39102LW off of this card (9.1 GB, 10000 rpm [Cheetah], Ultra2 interface). Although the hardware support claims to support 2940x, this is a fairly new card so I thought I would ask, particular since it is a new type of SCSI as well (up to 80 MB/s) Anyone either A) have this configuration? :) or B) Have tried at least this SCSI card with FreeBSD? Since this drive system will be on a dual PII/400 with 256M of RAM, I can't wait to see how fast 'make world' runs on it. :) Thanks, Peter Johnson locke@mcs.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 00:45:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA19182 for freebsd-current-outgoing; Wed, 3 Jun 1998 00:45:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ceia.nordier.com (slip139-92-122-113.joh.za.ibm.net [139.92.122.113]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA19156 for ; Wed, 3 Jun 1998 00:45:32 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.8/8.6.12) id JAA06017; Wed, 3 Jun 1998 09:35:42 +0200 (SAT) From: Robert Nordier Message-Id: <199806030735.JAA06017@ceia.nordier.com> Subject: Re: TenDRA compiler? In-Reply-To: <26692.896826166@brown.pfcs.com> from Harlan Stenn at "Jun 2, 98 06:22:46 pm" To: Harlan.Stenn@pfcs.com (Harlan Stenn) Date: Wed, 3 Jun 1998 09:35:40 +0200 (SAT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Harlan Stenn wrote: > I just installed the TenDRA compiler on one of my boxes (I used the port). > > Unfortunately, tcc doesn't seem to see any of the system #include files. > > My initial read of the docs hasn't shed any light on the problem. > > What did I miss? Probably ``-Ysystem''. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 01:16:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA26438 for freebsd-current-outgoing; Wed, 3 Jun 1998 01:16:43 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA26429 for ; Wed, 3 Jun 1998 01:16:40 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id IAA19940; Wed, 3 Jun 1998 08:16:22 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA29184; Wed, 3 Jun 1998 10:15:57 +0200 (MET DST) Message-ID: <19980603101552.35895@follo.net> Date: Wed, 3 Jun 1998 10:15:52 +0200 From: Eivind Eklund To: joelh@gnu.org, tlambert@primenet.com Cc: rnordier@nordier.com, current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object versioning References: <199805292120.OAA14978@usr04.primenet.com> <199805300312.WAA02058@detlev.UUCP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199805300312.WAA02058@detlev.UUCP>; from Joel Ray Holveck on Fri, May 29, 1998 at 10:12:28PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, May 29, 1998 at 10:12:28PM -0500, Joel Ray Holveck wrote: > >>> * Possibilities for exploiting the cross-CPU nature of XANDF > >> How are XANDF's cross-cpu capabilities more powerful than gcc's? > > You can distribute "binaries" and localize them to an architecture at > > install time. > > This means you can distribute commercial code that will run on x86, > > Alpha, MIPS, PPC, 68k, VAX, SPARC, etc., etc.. > > Does it have problems with endianness, et al? That is, if a program, > at compile time, needs to know its endianness (or another > architecture-dependant detail), does it still work? Yes. You use if() instead of #ifdef, and TenDRA do dead code elmination at install time. BTW: I just found out that TenDRA _do_ support __asm(). This is supported to a limited degree in the C frontend (it can only send a pure string to the backend, which will typically insert it in the asm output). I'm not certain if this is enough for our needs. > >>> * Better error checking/control > >> How do you mean? > > Full mapping of the error checking and warning space. GCC only maps > > the parts that they thought were important, and then it's done pretty > > haphazardly. > > Mapping, you mean, to diagnostics? Yes. Another neat part of this is that TenDRA indicate what you're in violation of by ISO section - always nice when you have to hit some Linuxer over the head with his violation ;-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 01:30:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA28126 for freebsd-current-outgoing; Wed, 3 Jun 1998 01:30:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA28120 for ; Wed, 3 Jun 1998 01:30:06 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id IAA20485; Wed, 3 Jun 1998 08:29:48 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA29244; Wed, 3 Jun 1998 10:29:23 +0200 (MET DST) Message-ID: <19980603102923.09157@follo.net> Date: Wed, 3 Jun 1998 10:29:23 +0200 From: Eivind Eklund To: Harlan Stenn , current@FreeBSD.ORG Subject: Re: TenDRA compiler? References: <26692.896826166@brown.pfcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <26692.896826166@brown.pfcs.com>; from Harlan Stenn on Tue, Jun 02, 1998 at 06:22:46PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jun 02, 1998 at 06:22:46PM -0400, Harlan Stenn wrote: > I just installed the TenDRA compiler on one of my boxes (I used the port). > > Unfortunately, tcc doesn't seem to see any of the system #include files. > > My initial read of the docs hasn't shed any light on the problem. > > What did I miss? -Ysystem If you don't tell TenDRA otherwise, it will run in its own 'sandbox' (called environment), to make sure you create portable code. -Y tells which environment to select. I beleivve the default is 'iso'; the host environment is 'system'. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 02:19:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA05708 for freebsd-current-outgoing; Wed, 3 Jun 1998 02:19:44 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA05693 for ; Wed, 3 Jun 1998 02:19:36 -0700 (PDT) (envelope-from sinbin.demos.su!bag@kremvax.demos.su) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.5.31] with ESMTP id NAA05727; Wed, 3 Jun 1998 13:15:53 +0400 Received: by sinbin.demos.su id NAA15706; (8.6.12/D) Wed, 3 Jun 1998 13:15:14 +0400 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199806030915.NAA15706@sinbin.demos.su> Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199806020042.RAA02307@dingo.cdrom.com> from "Mike Smith" at "Jun 1, 98 05:42:07 pm" X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: mike@smith.net.au (Mike Smith) Date: Wed, 3 Jun 1998 13:15:14 +0400 (MSD) Cc: tlambert@primenet.com, mike@smith.net.au, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > DEVFS is per-system. You cannot export a DEVFS via NFS (it makes no > > > sense to do so - devices there are only relevant to the host system). > > > > This is a deficiency in NFS, not anything else, in that it can't > > proxy ioctl's via descriptor. A VFS proxy layer (as described in > > Heidemann's thesis, in fact) *could* proxy this data. > > No, it's a direct feature of DEVFS, or more particularly to achieve the > results desired by the original poster you cannot use an NFS-mounted > devfs. results desired by original poster: on nfs server we have: {nfs_srv}# cat /etc/exports /mnt/roots -maproot=0:0 nfs_clnt1 nfs_clnt2 nfs_clnt3 nfs_clnt4 {nfs_srv}# ls -al /mnt/roots/VM1/dev/null crw-rw-rw- 1 root weel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null {nfs_srv}# on nfs client we have: {nfs_clnt1}# mount /dev/sd0s1a on / (local, noatime, writes: sync 6436172 async 3495235)) procfs on /proc (local) nfs_srv:/mnt/roots on /mnt/roots {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null crw-rw-rw- 1 root weel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null ^^^^^^^^^^^ time from nfs_srv {nfs_clnt1}# ls -al /dev/null crw-rw-rw- 1 root wheel 2, 2 3 jun 12:39 /dev/null ^^^^^^^^^^^ local /dev/null time {nfs_clnt1}# chroot /mnt/roots/VM1 /bin/cat /etc/passwd > /dev/null ^^^^^^^^ use /dev/null in chroot environment on nfs {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null crw-rw-rw- 1 root wheel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null ^^^^^^^^^^^ remote time not changed {nfs_clnt1}# ls -al /dev/null crw-rw-rw- 1 root wheel 2, 2 3 jun 12:40 /dev/null ^^^^^^^^^^^ local time changed {nfs_clnt1}# so we use "nfs mounted devices" localy on nfs clients surely local major/minor for devices mast by the same as on the remote server or u mast use device proxy on fs level (not existing now) with "classic" device nodes on file systems it is realy simple to use this scheme with dynamic device id and devices only on devfs mounted, it is very hard to use devices on nfs, especially if u have several nfs clients vith handreds of chrooted "virtual mashines", a lot of mount/unmont devfs and rm/mknod in boot time and before/after of delete/create each VM and on each nfs server/client kill u system and require a number of custom scripts and sync of all manipulation via network (using rsh or other tools) > > > For normal devices that are only operated on via open/close/read/write, > > it makes sens to export a devfs. > > No, it does not. There is no identifying information exported with a > DEVFS node that allows the local system to correctly connect a node > from a remote DEVFS (which may not map to a local driver) to a local > device. > > > This isn't as useful as the true proxy provided by OpenNET, but it's > > a good step in that direction. > > You want to proxy device accesses to devices on the exporting system. > That's a completely different kettle of fish entirely. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 03:05:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA13155 for freebsd-current-outgoing; Wed, 3 Jun 1998 03:05:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from relay1.kar.net (relay1.kar.net [195.5.17.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA13142 for ; Wed, 3 Jun 1998 03:04:59 -0700 (PDT) (envelope-from kushn@mail.kar.net) Received: from olinet.isf.kiev.ua by relay1.kar.net with ESMTP id MAA13941; (8.8.last/vAk3/1.9) Wed, 3 Jun 1998 12:42:30 +0300 (EEST) Received: from kushnir.kiev.ua by olinet.isf.kiev.ua with SMTP id MAA23452; (8.8.last/vAk3/1.9) Wed, 3 Jun 1998 12:33:11 +0300 (EET DST) Date: Wed, 3 Jun 1998 12:40:58 +0300 (EEST) From: Vladimir Kushnir X-Sender: volodya@kushnir.kiev.ua Reply-To: Vladimir Kushnir To: freebsd-current@FreeBSD.ORG Subject: modload doesn't work when OBJFORMAT=elf? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, the subject sais it: modload passes *_mod.o to /usr/bin/ld, which in turn calls /usr/libexec/elf/ld. Of course, this last can't link aout kernel and aout LKM. (BTW, why not make binutils supporting both a.out-i386-freebsd and elf32-i386? They seem to be able to do this, though this would somewhat increase their size, but not by much). Anyway, here's one more of the hardcoded paths: /usr/src/sbin/modload/pathnames.h: #define _PATH_LD "/usr/bin/ld" As an interim cure (sofisticated next to a stone ax, but works, until both kernel and LKMs are all elf) #define _PATH_LD "/usr/libexec/aout/ld" Regards, Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 03:43:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA17016 for freebsd-current-outgoing; Wed, 3 Jun 1998 03:43:05 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from kremvax.demos.su (kremvax.demos.su [194.87.0.20]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA17006 for ; Wed, 3 Jun 1998 03:43:00 -0700 (PDT) (envelope-from sinbin.demos.su!bag@kremvax.demos.su) Received: by kremvax.demos.su (8.6.13/D) from 0@sinbin.demos.su [194.87.5.31] with ESMTP id OAA02451; Wed, 3 Jun 1998 14:37:47 +0400 Received: by sinbin.demos.su id OAA27314; (8.6.12/D) Wed, 3 Jun 1998 14:36:57 +0400 From: bag@sinbin.demos.su (Alex G. Bulushev) Message-Id: <199806031036.OAA27314@sinbin.demos.su> Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199806030915.NAA15706@sinbin.demos.su> from "Alex G. Bulushev" at "Jun 3, 98 01:15:14 pm" X-ELM-OSV: (Our standard violations) no-mime=1; no-hdr-encoding=1 To: bag@sinbin.demos.su (Alex G. Bulushev) Date: Wed, 3 Jun 1998 14:36:57 +0400 (MSD) Cc: mike@smith.net.au, tlambert@primenet.com, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > on nfs client we have: > > {nfs_clnt1}# mount > /dev/sd0s1a on / (local, noatime, writes: sync 6436172 async 3495235)) > procfs on /proc (local) > nfs_srv:/mnt/roots on /mnt/roots > {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null > crw-rw-rw- 1 root weel 2, 2 3 jun 14:27 /mnt/roots/VM1/dev/null > ^^^^^^^^^^^ time from nfs_srv > {nfs_clnt1}# chroot /mnt/roots/VM1 /bin/cat /etc/passwd > /dev/null sorry, correct demonstration is: {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null crw-rw-rw- 1 root wheel 2, 2 3 jun 14:27 /mnt/roots/VM1/dev/null {nfs_clnt1}# chroot /mnt/roots/VM1 /bin/sh # /bin/cat /etc/passwd > /dev/null # exit {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null crw-rw-rw- 1 root wheel 2, 2 3 jun 14:28 /mnt/roots/VM1/dev/null ^^^^^^^^^^^ time changed {nfs_clnt1}# ls -al /dev/null crw-rw-rw- 1 root wheel 2, 2 3 jun 14:28 /dev/null ^^^^^^^^^^^ time changed {nfs_clnt1}# > > > so we use "nfs mounted devices" localy on nfs clients > surely local major/minor for devices mast by the same as on the remote server > or u mast use device proxy on fs level (not existing now) > > with "classic" device nodes on file systems it is realy simple > to use this scheme > > with dynamic device id and devices only on devfs mounted, it is very hard > to use devices on nfs, especially if u have several nfs clients vith handreds > of chrooted "virtual mashines", a lot of mount/unmont devfs and rm/mknod in > boot time and before/after of delete/create each VM and on each nfs > server/client kill u system and require a number of custom scripts and > sync of all manipulation via network (using rsh or other tools) > > > > > > For normal devices that are only operated on via open/close/read/write, > > > it makes sens to export a devfs. > > > > No, it does not. There is no identifying information exported with a > > DEVFS node that allows the local system to correctly connect a node > > from a remote DEVFS (which may not map to a local driver) to a local > > device. > > > > > This isn't as useful as the true proxy provided by OpenNET, but it's > > > a good step in that direction. > > > > You want to proxy device accesses to devices on the exporting system. > > That's a completely different kettle of fish entirely. > > > > -- > > \\ Sometimes you're ahead, \\ Mike Smith > > \\ sometimes you're behind. \\ mike@smith.net.au > > \\ The race is long, and in the \\ msmith@freebsd.org > > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 03:54:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA18273 for freebsd-current-outgoing; Wed, 3 Jun 1998 03:54:37 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from helios.dnttm.ru (root@dnttm-gw.rssi.ru [193.232.0.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA18246 for ; Wed, 3 Jun 1998 03:54:11 -0700 (PDT) (envelope-from dima@tejblum.dnttm.rssi.ru) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id OAA27431; Wed, 3 Jun 1998 14:36:55 +0400 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.8/8.8.7) with ESMTP id OAA02191; Wed, 3 Jun 1998 14:40:25 +0400 (MSD) (envelope-from dima@tejblum.dnttm.rssi.ru) Message-Id: <199806031040.OAA02191@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Eivind Eklund cc: Harlan Stenn , current@FreeBSD.ORG Subject: Re: TenDRA compiler? In-reply-to: Your message of "Wed, 03 Jun 1998 10:29:23 +0200." <19980603102923.09157@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 1998 14:40:25 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund wrote: > On Tue, Jun 02, 1998 at 06:22:46PM -0400, Harlan Stenn wrote: > > I just installed the TenDRA compiler on one of my boxes (I used the port). > > > > Unfortunately, tcc doesn't seem to see any of the system #include files. > > If you don't tell TenDRA otherwise, it will run in its own 'sandbox' > (called environment), to make sure you create portable code. The envirnoment highly isolated from the real life, and that allow TenDRA to compile portable programs which cannot be compiled by any traditional compiler. For example, TenDRA correctly compile following program: ---------------------------------------- #define __sFILE int #include struct wonderful { __sFILE stdout, getc; }; int main(int argc, char** argv) { struct wonderful ww; ww.stdout = 5; ww.getc = 7; fprintf(stdout, "ww=(%d, %d)\n", ww.stdout, ww.getc); return 0; } ----------------------------------------------- :-) Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 04:37:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA25611 for freebsd-current-outgoing; Wed, 3 Jun 1998 04:37:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA25588 for ; Wed, 3 Jun 1998 04:36:49 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id LAA00318; Wed, 3 Jun 1998 11:28:04 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA00394; Wed, 3 Jun 1998 13:27:37 +0200 (MET DST) Message-ID: <19980603132737.53379@follo.net> Date: Wed, 3 Jun 1998 13:27:37 +0200 From: Eivind Eklund To: Vladimir Kushnir , freebsd-current@FreeBSD.ORG Subject: Re: modload doesn't work when OBJFORMAT=elf? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Vladimir Kushnir on Wed, Jun 03, 1998 at 12:40:58PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 03, 1998 at 12:40:58PM +0300, Vladimir Kushnir wrote: > BTW, why not make binutils supporting both a.out-i386-freebsd and > elf32-i386? They seem to be able to do this, though this would > somewhat increase their size, but not by much We use an old and hacked version of binutils for a.out, because the binutils maintainers haven't integrated our changes, and we need them (for shared libs, IIRC). All of this is second hand; I've not actually read the code... Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 05:33:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA03370 for freebsd-current-outgoing; Wed, 3 Jun 1998 05:33:25 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from luke.pmr.com (luke.pmr.com [207.170.114.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03336 for ; Wed, 3 Jun 1998 05:33:13 -0700 (PDT) (envelope-from bob@luke.pmr.com) Received: (from bob@localhost) by luke.pmr.com (8.8.8/8.8.8) id HAA16859; Wed, 3 Jun 1998 07:32:00 -0500 (CDT) (envelope-from bob) Message-ID: <19980603073200.A16652@pmr.com> Date: Wed, 3 Jun 1998 07:32:00 -0500 From: Bob Willcox To: Greg Lehey , shimon@simon-shapiro.org, Mike Smith Cc: Karl Pielorz , tcobb , "freebsd-current@freebsd.org" , Michael Hancock Subject: Re: DPT driver fails and panics with Degraded Array Reply-To: Bob Willcox References: <199805292208.PAA01191@dingo.cdrom.com> <19980603125443.K22406@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19980603125443.K22406@freebie.lemis.com>; from Greg Lehey on Wed, Jun 03, 1998 at 12:54:43PM +0930 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 03, 1998 at 12:54:43PM +0930, Greg Lehey wrote: > On Mon, 1 June 1998 at 20:51:51 -0400, Simon Shapiro wrote: > > On 29-May-98 Mike Smith wrote: > > > >>> I am routinely running a Dual DPT with 38 drives on 6 busses. On > >>> 3.0-CURRENT SMP. The system did lose disk drives, either > >>> intentionally, or by accident. I cannot confirm any of Mr. Cobb's > >>> finding. I have not been funished with any data, including the > >>> panic point, which I suspect is not in the DPT code. I am still > >>> waiting for such data. > >> > >> I'd just like to point out that the "biodone: buffer not busy" panic > >> doesn't come from the DPT driver, but may be caused by it calling > >> biodone() on a buffer that the system does not believe is busy. > > Why would a driver call biodone on a buffer that doens't belong to it? Probably not relavent, but in the DPT device driver that I wrote for AIX I had to put some pretty ugly validity checks in the interrupt code to prevent my driver from trying to do an iodone (AIX's version of biodone) on already completed (or purged, I don't remember for sure...its been over a year now) commands. Seems that the DPT firmware would (on occasion) interrupt with a status packet that pointed to a ccb that my driver had already completed. As I recall this would only happen under heavy load and it was pretty intermittant. As far as I know, it was never actually fixed. -- Bob Willcox While your friend holds you affectionately by both bob@luke.pmr.com your hands you are safe, for you can watch both of Austin, TX his. -- Ambrose Bierce, "The Devil's Dictionary" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 07:29:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20177 for freebsd-current-outgoing; Wed, 3 Jun 1998 07:29:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20162 for ; Wed, 3 Jun 1998 07:29:37 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id IAA22569; Wed, 3 Jun 1998 08:29:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806031429.IAA22569@panzer.plutotech.com> Subject: Re: Support for Adaptec 2940U2W / Ultra2 SCSI? In-Reply-To: <3.0.3.32.19980602235540.031b12a4@popmail.mcs.net> from Peter Johnson at "Jun 2, 98 11:55:40 pm" To: locke@mcs.net (Peter Johnson) Date: Wed, 3 Jun 1998 08:29:34 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Johnson wrote... > Is the Adaptec 2940U2W SCSI adapter supported by FreeBSD-current? I'm > planning on putting FreeBSD on a Seagate ST39102LW off of this card (9.1 > GB, 10000 rpm [Cheetah], Ultra2 interface). Although the hardware support > claims to support 2940x, this is a fairly new card so I thought I would > ask, particular since it is a new type of SCSI as well (up to 80 MB/s) > > Anyone either A) have this configuration? :) or B) Have tried at least > this SCSI card with FreeBSD? I'm not sure whether any one has tested that specific card/drive configuration, but the card (and any other 7890-based board) only works under CAM. See: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/cam/README or ftp://ftp.kdm.org/pub/FreeBSD/cam/README Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 08:44:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03662 for freebsd-current-outgoing; Wed, 3 Jun 1998 08:44:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03651 for ; Wed, 3 Jun 1998 08:44:10 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id IAA07617; Wed, 3 Jun 1998 08:43:42 -0700 (PDT) (envelope-from jdp) Message-Id: <199806031543.IAA07617@austin.polstra.com> To: eivind@yes.no Subject: Re: modload doesn't work when OBJFORMAT=elf? In-Reply-To: <19980603132737.53379@follo.net> References: <19980603132737.53379@follo.net> Organization: Polstra & Co., Seattle, WA Cc: current@FreeBSD.ORG Date: Wed, 03 Jun 1998 08:43:41 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19980603132737.53379@follo.net>, Eivind Eklund wrote: > On Wed, Jun 03, 1998 at 12:40:58PM +0300, Vladimir Kushnir wrote: > > BTW, why not make binutils supporting both a.out-i386-freebsd and > > elf32-i386? They seem to be able to do this, though this would > > somewhat increase their size, but not by much > > We use an old and hacked version of binutils for a.out, because the > binutils maintainers haven't integrated our changes, Well, to be fair, I don't think our changes (and NetBSD's, from which ours were derived) were ever sent to the binutils maintainers. So we can't blame them. It's moot at this point anyway. Our version is years out of date, and hardly resembles the current version of binutils. > and we need them (for shared libs, IIRC). All of this is second > hand; I've not actually read the code... That's the main obstacle -- that binutils doesn't have any support for i386/a.out shared libraries. There are also many, many smaller problems. I made a couple of stabs at fixing the a.out support in binutils, and gave up in frustration each time. Binutils is really hard to work with. It's not really a program, it's a way of life. :-) -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 11:37:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01289 for freebsd-current-outgoing; Wed, 3 Jun 1998 11:37:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01280 for ; Wed, 3 Jun 1998 11:37:32 -0700 (PDT) (envelope-from ckempf@singularity.enigami.com) Received: (from ckempf@localhost) by singularity.enigami.com (8.8.8/8.8.8) id OAA21987; Wed, 3 Jun 1998 14:36:49 -0400 (EDT) (envelope-from ckempf) To: freebsd-current@FreeBSD.ORG Subject: trimdomain? From: Cory Kempf Date: 03 Jun 1998 14:36:49 -0400 In-Reply-To: John Polstra's message of "Wed, 03 Jun 1998 08:43:41 -0700" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So, I tried to shift to elf, and totally hosed me system. It now seems OK again (doing a.out), except that in login.c, there is a call to trimdomain. Unfortunately, when it builds, it can't find that call in the shared libs. Local logins work, but telnets fail. For the moment, I have commented that line out, and it seems to work, but I would like to find the real problem. Anyone know where that code is? I looked in the source code search web page, but nothing came out. Thanks, +C -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: Cory Kempf Macintosh / Unix Consulting & Software Development ckempf@enigami.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 12:37:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12871 for freebsd-current-outgoing; Wed, 3 Jun 1998 12:37:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12841 for ; Wed, 3 Jun 1998 12:36:54 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id LAA00592; Wed, 3 Jun 1998 11:28:23 -0700 (PDT) Message-Id: <199806031828.LAA00592@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bob Willcox cc: Greg Lehey , shimon@simon-shapiro.org, Mike Smith , Karl Pielorz , tcobb , "freebsd-current@freebsd.org" , Michael Hancock Subject: Re: DPT driver fails and panics with Degraded Array In-reply-to: Your message of "Wed, 03 Jun 1998 07:32:00 CDT." <19980603073200.A16652@pmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 1998 11:28:22 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, Jun 03, 1998 at 12:54:43PM +0930, Greg Lehey wrote: > > On Mon, 1 June 1998 at 20:51:51 -0400, Simon Shapiro wrote: > > > On 29-May-98 Mike Smith wrote: > > > > > >>> I am routinely running a Dual DPT with 38 drives on 6 busses. On > > >>> 3.0-CURRENT SMP. The system did lose disk drives, either > > >>> intentionally, or by accident. I cannot confirm any of Mr. Cobb's > > >>> finding. I have not been funished with any data, including the > > >>> panic point, which I suspect is not in the DPT code. I am still > > >>> waiting for such data. > > >> > > >> I'd just like to point out that the "biodone: buffer not busy" panic > > >> doesn't come from the DPT driver, but may be caused by it calling > > >> biodone() on a buffer that the system does not believe is busy. > > > > Why would a driver call biodone on a buffer that doens't belong to it? > > Probably not relavent, but in the DPT device driver that I wrote for AIX > I had to put some pretty ugly validity checks in the interrupt code to > prevent my driver from trying to do an iodone (AIX's version of biodone) > on already completed (or purged, I don't remember for sure...its been > over a year now) commands. Seems that the DPT firmware would (on > occasion) interrupt with a status packet that pointed to a ccb that my > driver had already completed. As I recall this would only happen under > heavy load and it was pretty intermittant. As far as I know, it was > never actually fixed. Actually, this is *extremely* relevant, if the firmware is still doing it and the DPT driver isn't aware of this. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 13:02:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA19038 for freebsd-current-outgoing; Wed, 3 Jun 1998 13:02:21 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18981 for ; Wed, 3 Jun 1998 13:02:08 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id UAA21225; Wed, 3 Jun 1998 20:02:00 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA03839; Wed, 3 Jun 1998 22:01:25 +0200 (MET DST) Message-ID: <19980603220124.63718@follo.net> Date: Wed, 3 Jun 1998 22:01:24 +0200 From: Eivind Eklund To: Cory Kempf , freebsd-current@FreeBSD.ORG Subject: Re: trimdomain? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Cory Kempf on Wed, Jun 03, 1998 at 02:36:49PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 03, 1998 at 02:36:49PM -0400, Cory Kempf wrote: > > > So, I tried to shift to elf, and totally hosed me system. It now seems > OK again (doing a.out), except that in login.c, there is a call to > trimdomain. > > Unfortunately, when it builds, it can't find that call in the shared libs. > Local logins work, but telnets fail. > > For the moment, I have commented that line out, and it seems to work, but > I would like to find the real problem. Anyone know where that code is? > > I looked in the source code search web page, but nothing came out. Here's the only commit that seems relevant. I guess you should update libutil. ----- Forwarded message from Atsushi Murai ----- From: Atsushi Murai Date: Mon, 1 Jun 1998 01:47:05 -0700 (PDT) Message-Id: <199806010847.BAA12337@freefall.freebsd.org> To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-lib@FreeBSD.ORG, cvs-usrbin@FreeBSD.ORG Subject: cvs commit: src/lib/libutil libutil.h logwtmp.c src/usr.bin/login login.c Sender: owner-cvs-committers@FreeBSD.ORG amurai 1998/06/01 01:47:05 PDT Modified files: lib/libutil libutil.h logwtmp.c usr.bin/login login.c Log: Trim a domain part for wtmp as same as showed by "netstat -r". Here is a some example for avoiding a confusion. It asssumes a logged host domain is "spec.co.jp". All example is longer than UT_HOSTNAMELEN value. 1) turbo.tama.spec.co.jp: 192.19.0.2 -> trubo.tama 2) turbo.tama.foo.co.jp : 192.19.0.2 -> 192.19.0.2 3) specgw.spec.co.jp : 202.32.13.1 -> specgw Submitted by: Atsushi Murai Revision Changes Path 1.15 +2 -2 src/lib/libutil/libutil.h 1.6 +40 -1 src/lib/libutil/logwtmp.c 1.35 +5 -1 src/usr.bin/login/login.c ----- End forwarded message ----- Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 14:19:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05023 for freebsd-current-outgoing; Wed, 3 Jun 1998 14:19:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from engulf.net (brandon@engulf.com [207.96.124.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA04954 for ; Wed, 3 Jun 1998 14:18:50 -0700 (PDT) (envelope-from brandon@engulf.net) Received: from localhost (brandon@localhost) by engulf.net (8.8.8/8.8.8) with SMTP id RAA11296 for ; Wed, 3 Jun 1998 17:15:31 -0400 (EDT) Date: Wed, 3 Jun 1998 17:15:18 -0400 (EDT) From: Brandon Lockhart To: current@FreeBSD.ORG Subject: ppp libalias Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I remember there was a discussion, I didn't think this pertained to me. How do we fix this ppp libalias problem? ,--------------------------------,--------------------------------, | Brandon Lockhart | Network Administrator | | brandon@engulf.net | System Administrator | | http://www.engulf.net/brandon/ | IRC Expert | `--------------------------------`--------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 14:47:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10075 for freebsd-current-outgoing; Wed, 3 Jun 1998 14:47:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from stevenson.cogsci.ed.ac.uk (stevenson144.cogsci.ed.ac.uk [129.215.144.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10067 for ; Wed, 3 Jun 1998 14:46:59 -0700 (PDT) (envelope-from richard@cogsci.ed.ac.uk) From: richard@cogsci.ed.ac.uk Received: from cockburn.cogsci.ed.ac.uk (richard@cockburn [129.215.110.48]) by stevenson.cogsci.ed.ac.uk (8.8.7/8.8.7) with SMTP id WAA04876 for ; Wed, 3 Jun 1998 22:46:57 +0100 (BST) Date: Wed, 3 Jun 1998 22:46:56 +0100 Message-Id: <24718.199806032146@cockburn.cogsci.ed.ac.uk> To: freebsd-current@FreeBSD.ORG Subject: kerberised packages Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Several of the packages in packages-current seem to require libkrb.so.3.0. For example: xv, xfig, netpbm. Is this intentional? -- Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 15:46:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA19328 for freebsd-current-outgoing; Wed, 3 Jun 1998 15:46:42 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA19308 for ; Wed, 3 Jun 1998 15:46:36 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id WAA25570 for ; Wed, 3 Jun 1998 22:46:34 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA04569; Thu, 4 Jun 1998 00:46:07 +0200 (MET DST) Message-ID: <19980604004607.56268@follo.net> Date: Thu, 4 Jun 1998 00:46:07 +0200 From: Eivind Eklund To: current@FreeBSD.ORG Subject: Odd VM behaviour Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When I kill -9 a frozen netscape (which has a lot of paged out pages), my machine freeze in mad swapping for several seconds. Is this anticipated behavour? Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 16:22:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26492 for freebsd-current-outgoing; Wed, 3 Jun 1998 16:22:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from bmccane.maxbaud.net ([208.155.166.81]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA26480 for ; Wed, 3 Jun 1998 16:22:41 -0700 (PDT) (envelope-from root@bmccane.maxbaud.net) Received: from localhost (root@localhost) by bmccane.maxbaud.net (8.8.8/8.8.8) with SMTP id SAA08825 for ; Wed, 3 Jun 1998 18:21:49 -0500 (CDT) (envelope-from root@bmccane.maxbaud.net) Date: Wed, 3 Jun 1998 18:21:47 -0500 (CDT) From: Wm Brian McCane To: current@FreeBSD.ORG Subject: softupdate panics Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, I am getting an error/panic with softupdates V1.7. This happens every time I try a make world. After several minutes the system crashes. This is with a kernel sup'd last night. I have /usr/obj, /usr/src mounted with soft updates turned on. panic: handle_workitem_freeblocks: block count brian +-----------------------------------+------------------------------------------+ He rides a cycle of mighty days, and \ Wm Brian and Lori McCane represents the last great schizm among\ McCane Consulting the gods. Evil though he obviously is, \ root@bmccane.cavtech.com he is a mighty figure, this father of \ http://bmccane.cavtech.com/ my spirit, and I respect him as the sons \ http://bmccane.cavtech.com/~pictures/ of old did the fathers of their bodies. \ http://bmccane.cavtech.com/~bmccane/ Roger Zelazny - "Lord of Light" \ +-------------------------------------------+----------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 16:44:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA01711 for freebsd-current-outgoing; Wed, 3 Jun 1998 16:44:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01603 for ; Wed, 3 Jun 1998 16:44:27 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA20063; Wed, 3 Jun 1998 16:44:23 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd019959; Wed Jun 3 16:44:17 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id QAA08803; Wed, 3 Jun 1998 16:44:10 -0700 (MST) From: Terry Lambert Message-Id: <199806032344.QAA08803@usr04.primenet.com> Subject: Re: I see one major problem with DEVFS... To: bag@sinbin.demos.su (Alex G. Bulushev) Date: Wed, 3 Jun 1998 23:44:10 +0000 (GMT) Cc: mike@smith.net.au, tlambert@primenet.com, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG In-Reply-To: <199806030915.NAA15706@sinbin.demos.su> from "Alex G. Bulushev" at Jun 3, 98 01:15:14 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > {nfs_srv}# cat /etc/exports > /mnt/roots -maproot=0:0 nfs_clnt1 nfs_clnt2 nfs_clnt3 nfs_clnt4 > {nfs_srv}# ls -al /mnt/roots/VM1/dev/null > crw-rw-rw- 1 root weel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null > {nfs_srv}# > > on nfs client we have: > > {nfs_clnt1}# mount > /dev/sd0s1a on / (local, noatime, writes: sync 6436172 async 3495235)) > procfs on /proc (local) > nfs_srv:/mnt/roots on /mnt/roots > {nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null ls: /mnt/roots/VM1/dev/null: No such file or directory /dev is a seperate fs. It is no more available to your NFS client machine than any other FS that you haven't mounted locally. > so we use "nfs mounted devices" localy on nfs clients No, you *don't*. You mount your own /dev out of your own kernel's knowledge of your own machine. There is no such thing as NFS client access to NFS mounted device nodes. In point of fact, we should *remove* the specfs references from the NFS client code at this point. The only value a special device nod has is as a marker from NFS clients that don't have a devfs. Specifically, this means non-FreeBSD clients. The specfs references in client/local media FS's are specifically tere right now because devfs is not mandatory (yet). > surely local major/minor for devices mast by the same as on the remote > server or u mast use device proxy on fs level (not existing now) No. It would be impossible for me to netboot my HP340 or my Multia NetBSD off of my Dual P90 FreeBSD box if this were the case, since FreeBSD and NetBSD don't share node-space. The point for a client is to have the major/minor pair, which is interpreted *in the specfs in the client's kernel* to represent a local device (or not). NFS mounted /dev directories are, of course, subject to the same issues of "stalemness" as a local /dev directory in a non-devfs configuration. This is one of the reasons non-devfs configurations suck, and one of the primary spurs to develope devfs in the first place. The /dev directory of a machine should represent *exactly* what local devices do or do not exist -- *on the particular client*. > with "classic" device nodes on file systems it is realy simple > to use this scheme Not really. It is a pain, since servers and clients rarely have precisely the same hardware. It is even *more* of a pain when the OS environment is heterogeneous between the client and the server. You *are* aware that it's currently impossible to netboot a FreeBSD box diskless off a DEC Alpha running OSF/1 at this point because the OSF/1 FS is incapable of representing the requisite FreeBSD minor number space, right? > with dynamic device id and devices only on devfs mounted, it is very hard > to use devices on nfs, especially if u have several nfs clients vith handreds > of chrooted "virtual mashines", a lot of mount/unmont devfs and rm/mknod in > boot time and before/after of delete/create each VM and on each nfs > server/client kill u system and require a number of custom scripts and > sync of all manipulation via network (using rsh or other tools) Not really. The practical fact is that only in special cases would you *ever* want your client device list to contain something other than a perfect representation of the devices on the client. The most common case will be the FTP server that runs in a chroot environment, and it's acceptable to fire off a script (in the background), whose last act is to enable the FTP access. It will most likely be done with the mount / find / grep -v / rm before the system is up to a point where it is useful in any case... it takes only the time for the system calls (no disk I/O; it's an in-memory tree structure) to create the modified chroot environment "/dev". Frankly, the big issue is local permissions differences on systems owned by people too stupid to change the default values away from the defaults in the device descriptor structures, and who want to use chmod/chown instead, and thus require the commands to be persistant in some way other than mtree + rc.dev. It would be trivial to modify the config program (which should die, die, die to be replaced by simple object file agregation) to take arguments like: disk wd0 at wdc0 drive 0 owner root group operator mode 0640 to make said weenies happy. Of course, modifying the config program (which should die, die, die to be replaced by simple object file agregation) is left as an exercise for the weenies. If they could justify their permission requirements, the defaults would be their defaults, and they wouldn't have reason to whine about them. It's only the unjustifiable permissions changes which cause trouble... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 16:51:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02907 for freebsd-current-outgoing; Wed, 3 Jun 1998 16:51:30 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA02890 for ; Wed, 3 Jun 1998 16:51:24 -0700 (PDT) (envelope-from pierre.dampure@k2c.co.uk) Received: (qmail 1765 invoked from network); 3 Jun 1998 23:51:22 -0000 Received: from usera926.uk.uudial.com (HELO jfsebastian) (193.149.69.164) by smtp.dial.pipex.com with SMTP; 3 Jun 1998 23:51:22 -0000 Message-ID: <000c01bd8f49$df778ae0$0242000a@jfsebastian.k2c.co.uk> From: "Pierre Y. Dampure" To: "Brandon Lockhart" , Subject: Re: ppp libalias Date: Thu, 4 Jun 1998 00:46:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, one can always edit /usr/src/usr.sbin/ppp/loadalias.c... -----Original Message----- From: Brandon Lockhart To: current@FreeBSD.ORG Date: 04 June 1998 00:14 Subject: ppp libalias >I remember there was a discussion, I didn't think this pertained to me. >How do we fix this ppp libalias problem? > > ,--------------------------------,--------------------------------, > | Brandon Lockhart | Network Administrator | > | brandon@engulf.net | System Administrator | > | http://www.engulf.net/brandon/ | IRC Expert | > `--------------------------------`--------------------------------' > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 16:51:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02930 for freebsd-current-outgoing; Wed, 3 Jun 1998 16:51:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02900 for ; Wed, 3 Jun 1998 16:51:29 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA01739; Wed, 3 Jun 1998 15:44:42 -0700 (PDT) Message-Id: <199806032244.PAA01739@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: bag@sinbin.demos.su (Alex G. Bulushev), eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Wed, 03 Jun 1998 23:44:10 -0000." <199806032344.QAA08803@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 1998 15:44:42 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You *are* aware that it's currently impossible to netboot a FreeBSD > box diskless off a DEC Alpha running OSF/1 at this point because the > OSF/1 FS is incapable of representing the requisite FreeBSD minor > number space, right? Actually, it is possible as long as you don't want disks on your workstation. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 17:19:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10105 for freebsd-current-outgoing; Wed, 3 Jun 1998 17:19:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10027 for ; Wed, 3 Jun 1998 17:18:52 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id AAA27823; Thu, 4 Jun 1998 00:18:48 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA05380; Thu, 4 Jun 1998 02:18:20 +0200 (MET DST) Message-ID: <19980604021816.09262@follo.net> Date: Thu, 4 Jun 1998 02:18:16 +0200 From: Eivind Eklund To: Terry Lambert Cc: current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <199806030915.NAA15706@sinbin.demos.su> <199806032344.QAA08803@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806032344.QAA08803@usr04.primenet.com>; from Terry Lambert on Wed, Jun 03, 1998 at 11:44:10PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 03, 1998 at 11:44:10PM +0000, Terry Lambert wrote: > [...] Of course, modifying the config program (which should die, > die, die to be replaced by simple object file agregation) is left as > an exercise for the weenies. [...] This isn't a simple exercise, and it is even less simple than it looks at first. There is a _lot_ of incest in there. Examples of things that need to be fixed: * The use of 'UNION' in vfs_syscalls.c * The use of COMPAT_43 at all * The use of defines to shift the tuner in the brooktree driver * The use of defines to set options for the AHC driver * The dependency of the Linux module on COMPAT_43 * The existance of 'maxusers' and all the constants that depend on it * The way 1/3 of the the kernel is dependent on 'INET' * The use of defines instead of variables to control kernel PPP * The way 'QUOTA' change things in all the filesystems * The way the BOOTP options are used all through the kernel * Some other way of setting the panic reboot time * Move SPX_HACK to a sysctl, including creating proper infrastructure around it (or possible just decide that we're going to throw this options away - I don't know if anybody use it) Most of these are reasonably sized projects, and many of them can easily be expressed as small enough patches that they'll have a large chance of being committed more or less directly. If you want the removal of config to happen, _do something about it_. Don't just bitch - help us progress to a stage where we can at least see that we've got a chance of ever reaching the target! Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 17:24:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11657 for freebsd-current-outgoing; Wed, 3 Jun 1998 17:24:33 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11510 for ; Wed, 3 Jun 1998 17:24:06 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA27363; Wed, 3 Jun 1998 17:23:59 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd027262; Wed Jun 3 17:23:49 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA12127; Wed, 3 Jun 1998 17:23:44 -0700 (MST) From: Terry Lambert Message-Id: <199806040023.RAA12127@usr04.primenet.com> Subject: Re: I see one major problem with DEVFS... To: mike@smith.net.au (Mike Smith) Date: Thu, 4 Jun 1998 00:23:43 +0000 (GMT) Cc: tlambert@primenet.com, bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG In-Reply-To: <199806032244.PAA01739@dingo.cdrom.com> from "Mike Smith" at Jun 3, 98 03:44:42 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You *are* aware that it's currently impossible to netboot a FreeBSD > > box diskless off a DEC Alpha running OSF/1 at this point because the > > OSF/1 FS is incapable of representing the requisite FreeBSD minor > > number space, right? > > Actually, it is possible as long as you don't want disks on your > workstation. Sory; it's been too long since I've been forced into a Sun indoctrination camp... the correct terminology from Sun is "dataless"; ie: with local disk, usually only for swap, but getting / and /usr via NFS. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 17:29:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA12860 for freebsd-current-outgoing; Wed, 3 Jun 1998 17:29:06 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA12790 for ; Wed, 3 Jun 1998 17:28:42 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id JAA05099; Thu, 4 Jun 1998 09:57:18 +0930 (CST) Message-ID: <19980604095717.A22406@freebie.lemis.com> Date: Thu, 4 Jun 1998 09:57:17 +0930 From: Greg Lehey To: Mike Smith , Bob Willcox Cc: shimon@simon-shapiro.org, Karl Pielorz , tcobb , "freebsd-current@freebsd.org" , Michael Hancock Subject: Re: DPT driver fails and panics with Degraded Array References: <19980603073200.A16652@pmr.com> <199806031828.LAA00592@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806031828.LAA00592@dingo.cdrom.com>; from Mike Smith on Wed, Jun 03, 1998 at 11:28:22AM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 3 June 1998 at 11:28:22 -0700, Mike Smith wrote: >> On Wed, Jun 03, 1998 at 12:54:43PM +0930, Greg Lehey wrote: >>> On Mon, 1 June 1998 at 20:51:51 -0400, Simon Shapiro wrote: >>>> On 29-May-98 Mike Smith wrote: >>>> >>>>>> I am routinely running a Dual DPT with 38 drives on 6 busses. On >>>>>> 3.0-CURRENT SMP. The system did lose disk drives, either >>>>>> intentionally, or by accident. I cannot confirm any of Mr. Cobb's >>>>>> finding. I have not been funished with any data, including the >>>>>> panic point, which I suspect is not in the DPT code. I am still >>>>>> waiting for such data. >>>>> >>>>> I'd just like to point out that the "biodone: buffer not busy" panic >>>>> doesn't come from the DPT driver, but may be caused by it calling >>>>> biodone() on a buffer that the system does not believe is busy. >>> >>> Why would a driver call biodone on a buffer that doens't belong to it? >> >> Probably not relavent, but in the DPT device driver that I wrote for AIX >> I had to put some pretty ugly validity checks in the interrupt code to >> prevent my driver from trying to do an iodone (AIX's version of biodone) >> on already completed (or purged, I don't remember for sure...its been >> over a year now) commands. Seems that the DPT firmware would (on >> occasion) interrupt with a status packet that pointed to a ccb that my >> driver had already completed. As I recall this would only happen under >> heavy load and it was pretty intermittant. As far as I know, it was >> never actually fixed. > > Actually, this is *extremely* relevant, if the firmware is still doing > it and the DPT driver isn't aware of this. This would normally cause a 'biodone: buffer already done' message, which is a warning, not a panic. The only way I could think of this happening on a valid buffer (apart from the obvious of calling it while it wasn't busy) would be if something messed around with other buffer flags. I haven't been following this thread very carefully--were the panics associated with SMP only? If so, how is mutual exclusion performed in the bottom half of SMP drivers? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 17:30:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA13345 for freebsd-current-outgoing; Wed, 3 Jun 1998 17:30:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA13281 for ; Wed, 3 Jun 1998 17:30:28 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA00603; Wed, 3 Jun 1998 19:30:15 -0500 (EST) (envelope-from toor) Message-Id: <199806040030.TAA00603@dyson.iquest.net> Subject: Re: Odd VM behaviour In-Reply-To: <19980604004607.56268@follo.net> from Eivind Eklund at "Jun 4, 98 00:46:07 am" To: eivind@yes.no (Eivind Eklund) Date: Wed, 3 Jun 1998 19:30:15 -0500 (EST) Cc: current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Eivind Eklund said: > > When I kill -9 a frozen netscape (which has a lot of paged out pages), > my machine freeze in mad swapping for several seconds. Is this > anticipated behavour? > I have seen that on Netscape 3.0. It seems that recent -current is better than older versions of -current and 2.2. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 17:38:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA14930 for freebsd-current-outgoing; Wed, 3 Jun 1998 17:38:57 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA14854 for ; Wed, 3 Jun 1998 17:38:37 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id QAA02030; Wed, 3 Jun 1998 16:30:51 -0700 (PDT) Message-Id: <199806032330.QAA02030@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: Mike Smith , Bob Willcox , shimon@simon-shapiro.org, Karl Pielorz , tcobb , "freebsd-current@freebsd.org" , Michael Hancock Subject: Re: DPT driver fails and panics with Degraded Array In-reply-to: Your message of "Thu, 04 Jun 1998 09:57:17 +0930." <19980604095717.A22406@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 1998 16:30:50 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >>> Why would a driver call biodone on a buffer that doens't belong to it? > >> > >> Probably not relavent, but in the DPT device driver that I wrote for AIX > >> I had to put some pretty ugly validity checks in the interrupt code to > >> prevent my driver from trying to do an iodone (AIX's version of biodone) > >> on already completed (or purged, I don't remember for sure...its been > >> over a year now) commands. Seems that the DPT firmware would (on > >> occasion) interrupt with a status packet that pointed to a ccb that my > >> driver had already completed. As I recall this would only happen under > >> heavy load and it was pretty intermittant. As far as I know, it was > >> never actually fixed. > > > > Actually, this is *extremely* relevant, if the firmware is still doing > > it and the DPT driver isn't aware of this. > > This would normally cause a 'biodone: buffer already done' message, > which is a warning, not a panic. The only way I could think of this > happening on a valid buffer (apart from the obvious of calling it > while it wasn't busy) would be if something messed around with other > buffer flags. It would be an issue if the buf struct had been recycled, but hadn't yet been marked busy, or if the buf pointer was invalid (the business check is the very first check in biodone()). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 17:44:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16178 for freebsd-current-outgoing; Wed, 3 Jun 1998 17:44:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16143; Wed, 3 Jun 1998 17:44:32 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id AAA29281; Thu, 4 Jun 1998 00:44:31 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA05548; Thu, 4 Jun 1998 02:44:03 +0200 (MET DST) Message-ID: <19980604024402.14414@follo.net> Date: Thu, 4 Jun 1998 02:44:02 +0200 From: Eivind Eklund To: dyson@FreeBSD.ORG Cc: current@FreeBSD.ORG Subject: Re: Odd VM behaviour References: <19980604004607.56268@follo.net> <199806040030.TAA00603@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806040030.TAA00603@dyson.iquest.net>; from John S. Dyson on Wed, Jun 03, 1998 at 07:30:15PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jun 03, 1998 at 07:30:15PM -0500, John S. Dyson wrote: > Eivind Eklund said: > > > > When I kill -9 a frozen netscape (which has a lot of paged out pages), > > my machine freeze in mad swapping for several seconds. Is this > > anticipated behavour? > > I have seen that on Netscape 3.0. It seems that recent -current is > better than older versions of -current and 2.2. My kernel was only missing this revision 1.100 (vm_page.c) date: 1998/06/02 05:50:08; author: dyson; state: Exp; lines: +5 -15 Cleanup and remove some dead code from the initialization. and this revision 1.122 (vm_pageout.c) date: 1998/06/02 05:39:13; author: dyson; state: Exp; lines: +2 -2 Correct sleep priority. Should be the most recent policy. I've not updated more recently than that due to not having find an urge to re-integrate the vput() changes in the NFS layer yet. They seem to work fine, BTW. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 20:00:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA09718 for freebsd-current-outgoing; Wed, 3 Jun 1998 20:00:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09708 for ; Wed, 3 Jun 1998 20:00:06 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.8) id XAA02003; Wed, 3 Jun 1998 23:00:02 -0400 (EDT) (envelope-from wollman) Date: Wed, 3 Jun 1998 23:00:02 -0400 (EDT) From: Garrett Wollman Message-Id: <199806040300.XAA02003@khavrinen.lcs.mit.edu> To: Eivind Eklund Cc: Terry Lambert , current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-Reply-To: <19980604021816.09262@follo.net> References: <199806030915.NAA15706@sinbin.demos.su> <199806032344.QAA08803@usr04.primenet.com> <19980604021816.09262@follo.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > If you want the removal of config to happen, _do something about it_. A lot of us don't. Most of us who don't are the same ones as learned long ago to filter out mail matching ^From:.*tlambert@.*primenet\.com. Terry has been complaining about config for five years now, and while the current config is a mess, I don't believe that there is serious disagreement about the need for such a tool. (I think this goes particularly for those of us who operate machines that people actually depend upon on a day-to-day basis.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 21:09:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA20206 for freebsd-current-outgoing; Wed, 3 Jun 1998 21:09:31 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA20201 for ; Wed, 3 Jun 1998 21:09:29 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id VAA19762; Wed, 3 Jun 1998 21:08:37 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Thu, 04 Jun 1998 00:23:43 -0000." <199806040023.RAA12127@usr04.primenet.com> Date: Wed, 03 Jun 1998 21:08:37 -0700 Message-ID: <19758.896933317@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > You *are* aware that it's currently impossible to netboot a FreeBSD > > > box diskless off a DEC Alpha running OSF/1 at this point because the > > > OSF/1 FS is incapable of representing the requisite FreeBSD minor > > > number space, right? > > > > Actually, it is possible as long as you don't want disks on your > > workstation. > > Sory; it's been too long since I've been forced into a Sun indoctrination > camp... the correct terminology from Sun is "dataless"; ie: with local > disk, usually only for swap, but getting / and /usr via NFS. Yes, but it sounds to me like he's recommending the dickless configuration instead. - Jordan P.S. No, that's not a typo, that's ALSO the correct Sun terminology if you've ever spent any time hanging around a Sun campus. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 22:56:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04655 for freebsd-current-outgoing; Wed, 3 Jun 1998 22:56:56 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ha1.rdc1.az.home.com (siteadm@ha1.rdc1.az.home.com [24.1.240.66]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04646 for ; Wed, 3 Jun 1998 22:56:53 -0700 (PDT) (envelope-from straka@home.com) Received: from home.com ([24.1.209.47]) by ha1.rdc1.az.home.com (Netscape Mail Server v2.02) with ESMTP id AAA10132 for ; Wed, 3 Jun 1998 22:56:51 -0700 Message-ID: <35763722.C34EEF4E@home.com> Date: Wed, 03 Jun 1998 22:56:51 -0700 From: "Richard S. Straka" X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: strange behavior with signal latencies Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I wrote a small test program to look at latencies of user space processes waking up on the delivery of signals. The program (which is included in this e-mail) sigsuspend's waiting for a SIGALARM which is being delivered at 10ms. Upon receipt of the signal, the process wakes up and records time from the receipt of the last signal using gettimeofday, then suspends waiting for the next signal. This test was run on both my P133 running current which was cvsuped on 30 May, and also my 486-100 running 2.2.6R. Both machines were otherwise completely idle and the program was run using rtprio 16. In looking at the results, I noticed that that the current box exhibited a 2300 microsecond additional delay every 10th signal or at 100ms intervals. Also, occationally a signal is missed. I have also noticed recently using top and systat that current has been consuming between 1.6% and 3.1% of my P133 in interrupt handling. This seems to correspond to the latancy I am seeing with the signal test code. I changed the quantum interval using sysctl to 20 ticks. This had no effect, the 2300 microsecond latency still appeared at 10Hz. The results with 2.2.6R on the 486-100 box showed no signs of the latency and appeared to always reliably wakeup on every signal. Also, when the machine is completely idle, the interrupt load is 0.0%, occationally jumping to 0.4% when the disks sync. What in the system is generating the additional processor load at 10Hz and why am I occationally missing signals? Regards, Richard Straka straka@home.com P.S. Here are the test results and the source listing of the my code Nominally there should be 10000 microseconds between signals. P133 running current cvsuped on 30 May. 9923 10017 9985 9993 10003 12353 Notice the extra 2353 microseconds 7690 9963 9993 10011 9995 10085 9990 9932 9990 12343 7660 10062 9936 10007 9990 10014 9991 9994 10004 12342 7656 10007 10038 9972 20012 Here I missed a signal completely 9978 10011 9985 12357 7641 10004 9996 10014 13837 6201 9957 19988 12364 7652 10001 9988 10021 9983 10041 9965 20020 Missed another one 11174 8796 10012 10001 9994 10006 9969 10047 9945 10038 12298 7691 9957 9988 10006 9984 9995 9999 10008 9981 12336 7652 9999 9992 10002 9987 9994 10000 9991 10006 12368 7615 9997 9989 10006 9986 9994 9999 10013 9986 12349 7648 10005 9996 10032 9970 9997 10006 486-100 running 2.2.6R. 9775 10024 9921 10000 10000 10026 9974 10000 9999 10028 9978 9995 10000 10026 9974 10000 9999 10029 9972 10000 10031 9999 9970 10000 10000 10027 9973 10030 9969 10028 10054 9925 9994 10027 9973 10000 9999 10028 9973 10000 10031 9999 9970 10000 9999 10027 9974 10000 10000 10026 9979 9995 9999 10028 9973 10000 10000 10027 9973 10000 10034 10022 9945 9999 9999 10027 9974 10000 9999 10027 10005 9969 9999 10027 9974 10000 10000 10029 9989 10091 9976 9961 9953 10001 10000 10026 9974 10000 9999 10027 9979 9995 9999 10027 9974 10032 9968 10027 9972 10000 Source listing of code sigtime.c #include #include #include #include #include #define NITER 100 void sighandler(); void main(void) { sigset_t sigmask; struct sigaction sigvec; struct timeval time; struct timeval timelast; int i; int dt; int dtstore[NITER]; sigemptyset(&sigmask); sigvec.sa_handler = sighandler; sigvec.sa_mask = sigmask; sigvec.sa_flags = 0; ualarm(10000,10000); sigaction(SIGALRM,&sigvec,0); sigsuspend(&sigmask); gettimeofday(&time, NULL); for(i=0;i Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA12233 for freebsd-current-outgoing; Wed, 3 Jun 1998 23:53:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA12208 for ; Wed, 3 Jun 1998 23:53:50 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id IAA14709; Thu, 4 Jun 1998 08:51:54 +0200 (CEST) To: "Richard S. Straka" cc: current@FreeBSD.ORG Subject: Re: strange behavior with signal latencies In-reply-to: Your message of "Wed, 03 Jun 1998 22:56:51 PDT." <35763722.C34EEF4E@home.com> Date: Thu, 04 Jun 1998 08:51:53 +0200 Message-ID: <14707.896943113@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <35763722.C34EEF4E@home.com>, "Richard S. Straka" writes: >I wrote a small test program to look at latencies of user space >processes waking up on the delivery of signals. Hi Richard, This is very interesting work. The time keeping code in -current is entirely new, so it is not a given that it is actually a latency, it could be a genuine bug... A few pointers: 1. Use clock_gettime(2) on -current, then you get nanoseconds (-stable cannot do that, it will just give you microseconds * 1000). 2. Do you have ntpd enabled on either machine ? 3. Try to do the "/dev/io" trick and wiggle a line on your printerport and then use a 'scope or counter to verify your data. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jun 3 23:57:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13078 for freebsd-current-outgoing; Wed, 3 Jun 1998 23:57:59 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles348.castles.com [208.214.167.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13073 for ; Wed, 3 Jun 1998 23:57:56 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA00712; Wed, 3 Jun 1998 22:53:35 -0700 (PDT) Message-Id: <199806040553.WAA00712@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Richard S. Straka" cc: current@FreeBSD.ORG Subject: Re: strange behavior with signal latencies In-reply-to: Your message of "Wed, 03 Jun 1998 22:56:51 PDT." <35763722.C34EEF4E@home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 1998 22:53:35 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I wrote a small test program to look at latencies of user space > processes waking up on the delivery of signals. The program (which is > included in this e-mail) sigsuspend's waiting for a SIGALARM which is > being delivered at 10ms. Upon receipt of the signal, the process wakes > up and records time from the receipt of the last signal using > gettimeofday, then suspends waiting for the next signal. This test was > run on both my P133 running current which was cvsuped on 30 May, and > also my 486-100 running 2.2.6R. Both machines were otherwise completely > idle and the program was run using rtprio 16. > > In looking at the results, I noticed that that the current box exhibited > a 2300 microsecond additional delay every 10th signal or at 100ms > intervals. Also, occationally a signal is missed. I have also noticed > recently using top and systat that current has been consuming between > 1.6% and 3.1% of my P133 in interrupt handling. This seems to > correspond to the latancy I am seeing with the signal test code. I > changed the quantum interval using sysctl to 20 ticks. This had no > effect, the 2300 microsecond latency still appeared at 10Hz. > > The results with 2.2.6R on the 486-100 box showed no signs of the > latency and appeared to always reliably wakeup on every signal. Also, > when the machine is completely idle, the interrupt load is 0.0%, > occationally jumping to 0.4% when the disks sync. > > What in the system is generating the additional processor load at 10Hz > and why am I occationally missing signals? I can't answer the second, but I suspect that you have a different set of drivers active between the two systems, and one of those active on the -current system is scheduling a watchdog routine at hz/10. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 07:59:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20018 for freebsd-current-outgoing; Thu, 4 Jun 1998 07:59:31 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id HAA19998 for ; Thu, 4 Jun 1998 07:59:10 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 11667 invoked by uid 1000); 4 Jun 1998 16:00:46 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980603125443.K22406@freebie.lemis.com> Date: Thu, 04 Jun 1998 12:00:46 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Greg Lehey Subject: Re: DPT driver fails and panics with Degraded Array Cc: Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jun-98 Greg Lehey wrote: > Why would a driver call biodone on a buffer that doens't belong to it? The block belongs to it. Only it gets marked as done somehow. >>> These situations are worth analysing, and I hope to see you and Troy >>> resolving this one, even if it means that you point the finger >>> elsewhere. > > Definitely. I'm surprised nobody has done it yet. I posted some notes on this issue several months ago, with no response. >> I got these particularly with tape devices. Especially if there are two >> tape drives on the system and yoy try to (for example) cpio to both >> independently. I put a ton of debugging code in the DPT driver to try >> and >> catch the DPT sending biodone twice on the same request and am pretty >> comfortable the driver is not it. > > OK, where is the failing biodone called from? >From the DPT driver. Let me clarify the statement above; There was a printf in the driver, just above the biodone call. The driver also contains state info as to biodone was called or not (actually, biodone state is implicit from other states). In every case where the biodone failure occured, there was no prior call to biodone. I.E. the offending call was the first call. I even went as far as putting counters around these calls. It always stayed at zero. Since the greatest sensitivity was in the st.c, and st.c is new in CAM, I basically dropped the ball. Especially when I did not have this problem in 3.0, from very early on. > I find this difficult to follow. Onn the one hand, lots of people > (myself included) regularly use the st driver, and I've never seen > this behaviour. About the only thing that these panics have in common > is the DPT driver. It's easy enough to determine which driver is > involved: all you need to do is follow the stack trace to find what > devices is involved with the buffer (or just look at bp->b_dev). Are you using two tape drives, and write to both concurrently, using 64k blocks? Are you running disk I/O at 1500-1900 operations per second? Is the SCSI controller you use capable of causing biodone to be called within less than 1us from the driver being called? The fact that the DPT driver causes this problem does not automatically vindicate the DPT driver code. I would LOVE for it to be so because this is the part of the FreeBSD kernel I understand the best. Stack traces were analyzed, but did not reveal anything interesting. It is entirely possible that the fast response from the DPT causes a race condition elsewhere. Without cooperation from others who understand the other parts of the kernel better than I do, it is difficult for me to analyze it much farther beyond ``I am pretty confident it is not a coding error in the driver or the immediate code that calls it. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 08:00:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20147 for freebsd-current-outgoing; Thu, 4 Jun 1998 08:00:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from serv.unibest.ru (serv.unibest.ru [194.87.33.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA20129 for ; Thu, 4 Jun 1998 08:00:09 -0700 (PDT) (envelope-from osa@unibest.ru) Received: (qmail 19237 invoked from network); 4 Jun 1998 15:00:06 -0000 Received: from unknown (HELO hole.etrust.ru) (192.168.30.2) by serv.unibest.ru with SMTP; 4 Jun 1998 15:00:06 -0000 Date: Thu, 4 Jun 1998 19:03:21 +0400 (MSD) From: Ozz!!! X-Sender: osa@hole.etrust.ru To: FreeBSD-current mail-list Subject: Strange in vi ??? or UFS ??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! Have a strange: $ pwd /etc/ppp $ ls -al ..... .... -rw------- 1 root wheel 78 30 Apr 08:45 pap-secrets .... .... $ vi pap-secrets Error: pap-secrets: Permission denied. pap-secrets: unmodified, readonly: line 1 Press any key to continue: then I type Enter & vi create a new file... Hmmm.. If I can't read pap-secrets, why vi run & create new file ??? I think vi said: pap-secrets: Permission denied & quit ??? Sorry 4 bad English. Rgdz, oZZ, osa@unibest.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 08:11:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA22529 for freebsd-current-outgoing; Thu, 4 Jun 1998 08:11:05 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA22490 for ; Thu, 4 Jun 1998 08:10:52 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 11831 invoked by uid 1000); 4 Jun 1998 16:12:30 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980603073200.A16652@pmr.com> Date: Thu, 04 Jun 1998 12:12:30 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Bob Willcox Subject: Re: DPT driver fails and panics with Degraded Array Cc: Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Mike Smith , Greg Lehey Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jun-98 Bob Willcox wrote: ... >> Why would a driver call biodone on a buffer that doens't belong to it? > > Probably not relavent, but in the DPT device driver that I wrote for AIX > I had to put some pretty ugly validity checks in the interrupt code to > prevent my driver from trying to do an iodone (AIX's version of biodone) > on already completed (or purged, I don't remember for sure...its been > over a year now) commands. Seems that the DPT firmware would (on > occasion) interrupt with a status packet that pointed to a ccb that my > driver had already completed. As I recall this would only happen under > heavy load and it was pretty intermittant. As far as I know, it was > never actually fixed. The FreeBSD driver actually does exactly that. I encountered exactly that situation in earlier firmware revisions (7H1 or so). I put more defenses in the driver than necessary. Later revisions of the firmware (7L0 or so) took care of the problem, but the defensive code stayed, as #ifdef`s. Many of these problems are actually (arguabbly?) induced by timing problems on the PCI bus. Certain PCI-PCI bridges (or even motherboard ``main'' chipsets will deliver interrupts, I/O bus transactions and memory transactions out of order when hammered very rapidly, under heavy load, or both. We proved it clearly with certain ``industrial'' computers, and certain motherboards, by making the symptoms go away (or drastically change) as you move the DPT, video cards, Ethernet cards, etc. from slot to slot. If one is really paranoid, one can enable DPT_VERIFY_HINTR to get this code back. Even more severe cases of paranoia can be satisfied by enabling DPT_HANDLE_TIMEOUTS. For those who are as sick as I am, you can define an DPT_INTR_DELAY as some small integer. What these do is, in the order listed: DPT_VERIFY_HINTR: Mark and stamp each CCB so as to guarantee that it is not handled twice. DPT_HANDLE_TIMEOUTS: turn on elaborate mechanism that will track transactions (CCBs) that seem to linger on beyond their useful life. DPT_INTR_DELAY: Will cause the interrupt service routine to spin a little bit, giving the hardware chance to settle a bit before dpt_intr gets all excited about it. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 08:15:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23317 for freebsd-current-outgoing; Thu, 4 Jun 1998 08:15:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA23249 for ; Thu, 4 Jun 1998 08:14:57 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 11909 invoked by uid 1000); 4 Jun 1998 16:16:35 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19980604095717.A22406@freebie.lemis.com> Date: Thu, 04 Jun 1998 12:16:35 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Greg Lehey Subject: Re: DPT driver fails and panics with Degraded Array Cc: Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Bob Willcox , Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 04-Jun-98 Greg Lehey wrote: ... >>> I had to put some pretty ugly validity checks in the interrupt code to >>> prevent my driver from trying to do an iodone (AIX's version of >>> biodone) >>> on already completed (or purged, I don't remember for sure...its been >>> over a year now) commands. Seems that the DPT firmware would (on >>> occasion) interrupt with a status packet that pointed to a ccb that my >>> driver had already completed. As I recall this would only happen under >>> heavy load and it was pretty intermittant. As far as I know, it was >>> never actually fixed. >> >> Actually, this is *extremely* relevant, if the firmware is still doing >> it and the DPT driver isn't aware of this. > > This would normally cause a 'biodone: buffer already done' message, > which is a warning, not a panic. The only way I could think of this > happening on a valid buffer (apart from the obvious of calling it > while it wasn't busy) would be if something messed around with other > buffer flags. I haven't been following this thread very > carefully--were the panics associated with SMP only? If so, how is > mutual exclusion performed in the bottom half of SMP drivers? Actually this is a 2.2 (UP :-) problem. Not a 3.0, and not an SMP for sure. Actually, SMP interrupt service is slow enough that this probably never has a chance to show at all. Simon (We are getting about 2/3 the interrupts/sec under SMP. Last we checked which was about 2 months ago). --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 08:18:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA24484 for freebsd-current-outgoing; Thu, 4 Jun 1998 08:18:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA24351 for ; Thu, 4 Jun 1998 08:18:05 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 11955 invoked by uid 1000); 4 Jun 1998 16:19:44 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199806032330.QAA02030@dingo.cdrom.com> Date: Thu, 04 Jun 1998 12:19:44 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT driver fails and panics with Degraded Array Cc: Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Bob Willcox , Greg Lehey Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 03-Jun-98 Mike Smith wrote: ... >> This would normally cause a 'biodone: buffer already done' message, >> which is a warning, not a panic. The only way I could think of this >> happening on a valid buffer (apart from the obvious of calling it >> while it wasn't busy) would be if something messed around with other >> buffer flags. > > It would be an issue if the buf struct had been recycled, but hadn't > yet been marked busy, or if the buf pointer was invalid (the business > check is the very first check in biodone()). Is this code surrounded by splhigh() ? If not, it is entirely possible for that to happen. Due to the caching/quieing nature of the DPT, especially the PM3334, and the multi-threaded nature of the DPT driver, for several interrupts to be issued less than 1us apart. This means that there will be several hardware interrupts and several soft interrupts generated in a very short period of time. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 08:24:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25977 for freebsd-current-outgoing; Thu, 4 Jun 1998 08:24:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA25947 for ; Thu, 4 Jun 1998 08:24:33 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 12042 invoked by uid 1000); 4 Jun 1998 16:26:09 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FB1D@freya.circle.net> Date: Thu, 04 Jun 1998 12:26:09 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: tcobb Subject: RE: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 02-Jun-98 tcobb wrote: ... >> BTW, for this to exist, the DPT firmware has to be rather sick. I can >> rplicate this scsnario with some broken, unpublished versions of the >> firmware. > > In your test case, please try to replicate this problem with the > firmware version available for download from DPT's site right now. That > was the version I used on my card (or, at least, the one available mid > last week). While logically an excellent idea, it is a bit impractical. I tested several firmware versions, and rejected them for instability. This was noted to my DPT technical/OEM contact. The version I use currently, is 7LR. I tried later versions but they did very ugly things to my RAID-5 arrays. Not the symptoms you describe, but just as ugly. The firmware versions I use are always available from my ftp server. Maybe I should include the firmware with the driver release. That is difficult to do as it is a copyrighted material, NOT under Berkeley license. I am open to suggenstions. The thing that is pretty clear here, is that we need a way to make a ``FreeBSD-Certified'' firmware revision known and available. Let me inquire as to what can be done beyond what we are already doing. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 08:59:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02488 for freebsd-current-outgoing; Thu, 4 Jun 1998 08:59:09 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02472 for ; Thu, 4 Jun 1998 08:59:00 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id IAA03951; Thu, 4 Jun 1998 08:58:52 -0700 (PDT) (envelope-from jdp) Message-Id: <199806041558.IAA03951@austin.polstra.com> To: mike@smith.net.au Subject: Re: ppp cannot find libalias In-Reply-To: <199806021711.KAA01018@antipodes.cdrom.com> References: <199806021711.KAA01018@antipodes.cdrom.com> Organization: Polstra & Co., Seattle, WA Cc: current@FreeBSD.ORG Date: Thu, 04 Jun 1998 08:58:52 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199806021711.KAA01018@antipodes.cdrom.com>, Mike Smith wrote: > Are there any disagreements with the basic idea, ie. use rtfindfile() > to locate files requested by dlopen() if they do not contain path > components? No objection from me. I think it's the best solution. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 09:06:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03800 for freebsd-current-outgoing; Thu, 4 Jun 1998 09:06:32 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03746 for ; Thu, 4 Jun 1998 09:06:23 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id JAA04042; Thu, 4 Jun 1998 09:05:57 -0700 (PDT) (envelope-from jdp) Message-Id: <199806041605.JAA04042@austin.polstra.com> To: brandon@engulf.net Subject: Re: ppp libalias In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: current@FreeBSD.ORG Date: Thu, 04 Jun 1998 09:05:57 -0700 From: John Polstra Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Brandon Lockhart wrote: > I remember there was a discussion, I didn't think this pertained to me. > How do we fix this ppp libalias problem? The easiest work-around is to create a symlink "/usr/lib/libalias.so.2.5" that points to "/usr/lib/aout/libalias.so.2.5". -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 09:10:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04705 for freebsd-current-outgoing; Thu, 4 Jun 1998 09:10:05 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pozo.com (pozo.pozo.com [207.201.8.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04621 for ; Thu, 4 Jun 1998 09:09:52 -0700 (PDT) (envelope-from root@pozo.com) Received: from localhost (root@localhost) by pozo.com (8.8.8/8.8.8) with SMTP id JAA00834 for ; Thu, 4 Jun 1998 09:09:26 -0700 (PDT) (envelope-from root@pozo.com) Date: Thu, 4 Jun 1998 09:09:26 -0700 (PDT) From: Manfred Antar To: current@FreeBSD.ORG Subject: libalias in ppp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shouldn't ppp be looking for libalias in /usr/lib/aout I deleted all files in /usr/lib. ppp alias wont work unless you change locadalias.c from #define _PATH_ALIAS_PREFIX "/usr/lib/libalias.so.2." to #define _PATH_ALIAS_PREFIX "/usr/lib/aout/libalias.so.2." Manfred ============================== || mantar@netcom.com || || pozo@infinex.com || || Ph. (415) 681-6235 || ============================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 09:43:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11831 for freebsd-current-outgoing; Thu, 4 Jun 1998 09:43:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11826 for ; Thu, 4 Jun 1998 09:43:19 -0700 (PDT) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.8/8.8.5) id LAA08617 for current@freebsd.org; Thu, 4 Jun 1998 11:43:19 -0500 (CDT) From: Kevin Day Message-Id: <199806041643.LAA08617@home.dragondata.com> Subject: I have no idea what happened. :) To: current@FreeBSD.ORG Date: Thu, 4 Jun 1998 11:43:19 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm not sure what happened, can someone help me understand this? Jun 4 11:00:07 shell identd[15808]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:00:07 shell identd[15808]: k_getuid retries: 1 Jun 4 11:04:22 shell identd[16104]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:06:45 shell /kernel: swap_pager: suggest more swap space: 254 MB Jun 4 11:09:33 shell identd[16495]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16500]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16475]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16563]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16577]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16603]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16636]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16286]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16469]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16461]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16293]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16457]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16471]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16273]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16510]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16504]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:09:33 shell identd[16515]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:04 shell identd[16748]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:04 shell last message repeated 2 times Jun 4 11:10:05 shell identd[16763]: getbuf: bad address (00009370 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:06 shell identd[16771]: getbuf: bad address (00009370 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:06 shell identd[16769]: getbuf: bad address (00009370 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:06 shell identd[16770]: getbuf: bad address (00009370 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:06 shell identd[16748]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:06 shell identd[16799]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:06 shell identd[16763]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:06 shell identd[16800]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:06 shell identd[16802]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:07 shell identd[16769]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:07 shell identd[16807]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:07 shell identd[16769]: k_getuid: kvm_getprocs Jun 4 11:10:07 shell identd[16809]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:07 shell identd[16771]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:07 shell identd[16819]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:07 shell identd[16812]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:07 shell identd[16814]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:07 shell identd[16770]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:07 shell identd[16748]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:07 shell identd[16763]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:10:08 shell identd[16770]: k_getuid retries: 2 Jun 4 11:10:08 shell identd[16771]: k_getuid retries: 2 Jun 4 11:10:08 shell identd[16748]: k_getuid retries: 5 Jun 4 11:10:08 shell identd[16763]: k_getuid retries: 3 Jun 4 11:10:09 shell identd[16822]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:10 shell identd[16831]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:10 shell identd[16836]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:10 shell identd[16829]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:10 shell identd[16830]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:10 shell identd[16837]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:15 shell identd[16847]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:10:50 shell ftpd[16741]: getpeername (ftpd): Socket is not connected Jun 4 11:06:55 home /usr/sbin/ypbind[481]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Jun 4 11:07:00 home /usr/sbin/ypbind[481]: NIS server [204.137.237.2] for domain "dragondata.com" OK (on an odd note - 204.137.237.2 *is* home. How can home's nis not be responding?) Jun 4 11:10:56 shell ftpd[16744]: getpeername (ftpd): Socket is not connected Jun 4 11:11:04 shell identd[17287]: getbuf: bad address (00000001 not in f0100000-0xFFC00000) - ofiles Jun 4 11:11:04 shell identd[17289]: getbuf: bad address (00000001 not in f0100000-0xFFC00000) - ofiles Jun 4 11:11:04 shell identd[17288]: getbuf: bad address (00000001 not in f0100000-0xFFC00000) - ofiles Jun 4 11:11:04 shell identd[17289]: getbuf: bad address (00000003 not in f0100000-0xFFC00000) - ofiles Jun 4 11:11:04 shell ftpd[16745]: getpeername (ftpd): Socket is not connected Jun 4 11:11:06 shell identd[17289]: getbuf: bad address (00000017 not in f0100000-0xFFC00000) - ofiles Jun 4 11:11:06 shell identd[17287]: k_getuid: ofiles malloc failed Jun 4 11:11:06 shell identd[17289]: getbuf: bad address (8304c483 not in f0100000-0xFFC00000) - ofile Jun 4 11:11:06 shell identd[17288]: k_getuid: ofiles malloc failed Jun 4 11:11:07 shell identd[17289]: k_getuid: ofiles malloc failed Jun 4 11:11:08 shell ftpd[16749]: getpeername (ftpd): Socket is not connected Jun 4 11:11:08 shell ftpd[16777]: getpeername (ftpd): Socket is not connected Jun 4 11:11:09 shell ftpd[16779]: getpeername (ftpd): Socket is not connected Jun 4 11:11:09 shell ftpd[16755]: getpeername (ftpd): Socket is not connected Jun 4 11:11:09 shell ftpd[16801]: getpeername (ftpd): Socket is not connected Jun 4 11:11:10 shell ftpd[16752]: getpeername (ftpd): Socket is not connected Jun 4 11:11:13 shell ftpd[16761]: getpeername (ftpd): Socket is not connected Jun 4 11:11:14 shell ftpd[16844]: getpeername (ftpd): Socket is not connected Jun 4 11:11:16 shell ftpd[16783]: getpeername (ftpd): Socket is not connected Jun 4 11:11:18 shell ftpd[16759]: getpeername (ftpd): Socket is not connected Jun 4 11:11:19 shell ftpd[16781]: getpeername (ftpd): Socket is not connected Jun 4 11:07:26 home /usr/sbin/ypbind[481]: NIS server [204.137.237.2] for domain "dragondata.com" not responding Jun 4 11:07:26 home /usr/sbin/ypbind[481]: NIS server [204.137.237.2] for domain "dragondata.com" OK Jun 4 11:11:21 shell ftpd[16824]: getpeername (ftpd): Socket is not connected Jun 4 11:11:22 shell ftpd[16778]: getpeername (ftpd): Socket is not connected Jun 4 11:11:23 shell ftpd[16798]: getpeername (ftpd): Socket is not connected Jun 4 11:11:23 shell ftpd[16795]: getpeername (ftpd): Socket is not connected Jun 4 11:11:24 shell ftpd[16792]: getpeername (ftpd): Socket is not connected Jun 4 11:11:26 shell ftpd[16789]: getpeername (ftpd): Socket is not connected Jun 4 11:11:29 shell ftpd[16845]: getpeername (ftpd): Socket is not connected Jun 4 11:11:33 shell inetd[177]: ftp/tcp server failing (looping), service terminated Jun 4 11:11:34 shell ftpd[16853]: getpeername (ftpd): Socket is not connected Jun 4 11:11:38 shell ftpd[16916]: getpeername (ftpd): Socket is not connected Jun 4 11:15:05 shell identd[18287]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:15:05 shell identd[18287]: getbuf: bad address (00000014 not in f0100000-0xFFC00000) - ofile Jun 4 11:15:05 shell identd[18287]: k_getuid retries: 2 Jun 4 11:17:22 shell /kernel: swap_pager: out of swap space Jun 4 11:17:22 shell /kernel: pid 279 (eggdrop), uid 1037, was killed: out of swap space Jun 4 11:17:22 shell last message repeated 2 times Jun 4 11:17:25 shell /kernel: swap_pager: out of swap space Jun 4 11:17:25 shell /kernel: pid 3208 (eggdrop), uid 1112, was killed: out of swap space Jun 4 11:17:25 shell Jun 4 11:17:25sshd[: fatal: Jun 4 11:17:25 shell Jun 4 11:17:25sshd[: fatal: Jun 4 11:17:25 shell /kernel: pid 3208 (eggdrop), uid 1112, was killed: out of swap space Jun 4 11:17:25 shell Jun 4 11:17:25identd[: Connection from Jun 4 11:17:25 shell last message repeated 3 times Jun 4 11:17:25 shell /kernel: pid 3208 (eggdrop), uid 1112, was killed: out of swap space Jun 4 11:17:26 shell /kernel: swap_pager: out of swap space Jun 4 11:17:26 shell /kernel: pid 26864 (eggdrop), uid 1037, was killed: out of swap space Jun 4 11:17:26 shell Jun 4 11:17:26sshd[: fatal: Jun 4 11:17:26 shell Jun 4 11:17:26sshd[: fatal: Jun 4 11:17:26 shell identd[19738]: getbuf: bad address (00040000 not in f0100000-0xFFC00000) - ofiles Jun 4 11:17:27 shell /kernel: swap_pager: out of swap space Jun 4 11:17:27 shell Jun 4 11:17:27identd[: Connection from Jun 4 11:17:27 shell last message repeated 2 times Jun 4 11:17:27 shell /kernel: pid 26307 (eggdrop), uid 1142, was killed: out of swap space Jun 4 11:17:27 shell /kernel: swap_pager: out of swap space Jun 4 11:17:27 shell Jun 4 11:17:27identd[: Connection from Jun 4 11:17:27 shell last message repeated 7 times Jun 4 11:17:28 shell Jun 4 11:17:28identd[: Connection from Jun 4 11:17:28 shell last message repeated 10 times Jun 4 11:17:28 shell /kernel: pid 4141 (eggdrop), uid 1016, was killed: out of swap space Jun 4 11:17:28 shell Jun 4 11:17:28identd[: Connection from Jun 4 11:17:28 shell last message repeated 5 times Jun 4 11:17:28 shell Jun 4 11:17:28sshd[: fatal: Jun 4 11:17:29 shell Jun 4 11:17:29identd[: Connection from Jun 4 11:17:29 shell last message repeated 7 times Jun 4 11:17:29 shell /kernel: pid 18313 (eggdrop), uid 1105, was killed: out of swap space Jun 4 11:17:29 shell identd[19737]: getbuf: bad address (000035a0 not in f0100000-0xFFC00000) - ofiles Jun 4 11:17:29 shell identd[19738]: getbuf: bad address (000035a0 not in f0100000-0xFFC00000) - ofiles Jun 4 11:17:30 shell /kernel: swap_pager: out of swap space Jun 4 11:17:30 shell /kernel: pid 19738 (identd), uid 0, was killed: out of swap space Jun 4 11:17:30 shell Jun 4 11:17:30identd[: Connection from Jun 4 11:17:30 shell last message repeated 2 times Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: log: Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: fatal: Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: log: Jun 4 11:17:30 shell Jun 4 11:17:30identd[: Connection from Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: fatal: Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: fatal: Jun 4 11:17:30 shell Jun 4 11:17:30identd[: Connection from Jun 4 11:17:30 shell last message repeated 3 times Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: fatal: Jun 4 11:17:30 shell /kernel: pid 4844 (eggdrop), uid 1200, was killed: out of swap space Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: fatal: Jun 4 11:17:30 shell Jun 4 11:17:30identd[: Connection from Jun 4 11:17:30 shell Jun 4 11:17:30identd[: Connection from Jun 4 11:17:30 shell Jun 4 11:17:30sshd[: fatal: Jun 4 11:17:31 shell /kernel: swap_pager: out of swap space Jun 4 11:17:31 shell /kernel: pid 19737 (identd), uid 0, was killed: out of swap space Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell Jun 4 11:17:31identd[: Connection from Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell Jun 4 11:17:31identd[: Connection from Jun 4 11:17:31 shell last message repeated 2 times Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell Jun 4 11:17:31identd[: Connection from Jun 4 11:17:31 shell last message repeated 3 times Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell Jun 4 11:17:31identd[: Connection from Jun 4 11:17:31 shell Jun 4 11:17:31identd[: Connection from Jun 4 11:17:31 shell Jun 4 11:17:31sshd[: fatal: Jun 4 11:17:31 shell last message repeated 2 times Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:32 shell Jun 4 11:17:32identd[: Connection from Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:32 shell last message repeated 4 times Jun 4 11:17:32 shell Jun 4 11:17:32identd[: Connection from Jun 4 11:17:32 shell last message repeated 7 times Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:32 shell last message repeated 2 times Jun 4 11:17:32 shell Jun 4 11:17:32identd[: Connection from Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:32 shell Jun 4 11:17:32identd[: Connection from Jun 4 11:17:32 shell last message repeated 3 times Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:32 shell last message repeated 5 times Jun 4 11:17:32 shell Jun 4 11:17:32identd[: Connection from Jun 4 11:17:32 shell last message repeated 2 times Jun 4 11:17:32 shell Jun 4 11:17:32sshd[: fatal: Jun 4 11:17:33 shell Jun 4 11:17:33sshd[: fatal: Jun 4 11:17:33 shell /kernel: pid 927 (eggdrop), uid 1162, was killed: out of swap space Jun 4 11:17:33 shell /kernel: swap_pager: out of swap space Jun 4 11:17:33 shell Jun 4 11:17:33sshd[: fatal: Jun 4 11:17:33 shell last message repeated 2 times Jun 4 11:17:33 shell Jun 4 11:17:33identd[: Connection from Jun 4 11:17:33 shell last message repeated 4 times Jun 4 11:17:33 shell Jun 4 11:17:33sshd[: fatal: Jun 4 11:17:33 shell last message repeated 5 times Jun 4 11:17:34 shell /kernel: pid 14612 (eggdrop), uid 1122, was killed: out of swap space Jun 4 11:17:34 shell /kernel: swap_pager: out of swap space Jun 4 11:17:34 shell Jun 4 11:17:34identd[: Connection from Jun 4 11:17:35 shell last message repeated 2 times Jun 4 11:17:35 shell Jun 4 11:17:35identd[: Connection from Jun 4 11:17:35 shell last message repeated 9 times Jun 4 11:17:35 shell Jun 4 11:17:35sshd[: fatal: Jun 4 11:17:35 shell /kernel: pid 14503 (eggdrop), uid 1122, was killed: out of swap space Jun 4 11:17:35 shell Jun 4 11:17:35sshd[: fatal: Jun 4 11:17:35 shell last message repeated 3 times Jun 4 11:17:35 shell /kernel: swap_pager: out of swap space Jun 4 11:17:36 shell Jun 4 11:17:36identd[: Connection from Jun 4 11:17:36 shell last message repeated 2 times Jun 4 11:17:36 shell Jun 4 11:17:36sshd[: fatal: Jun 4 11:17:36 shell Jun 4 11:17:36identd[: Connection from Jun 4 11:17:36 shell Jun 4 11:17:36identd[: Connection from Jun 4 11:17:36 shell Jun 4 11:17:36sshd[: fatal: Jun 4 11:17:36 shell Jun 4 11:17:36identd[: Connection from Jun 4 11:17:36 shell last message repeated 2 times Jun 4 11:17:36 shell Jun 4 11:17:36sshd[: fatal: Jun 4 11:17:36 shell last message repeated 2 times Jun 4 11:17:36 shell Jun 4 11:17:36identd[: Connection from Jun 4 11:17:36 shell /kernel: pid 5795 (eggdrop1.0p), uid 1188, was killed: out of swap space Jun 4 11:17:36 shell Jun 4 11:17:36identd[: Connection from Jun 4 11:17:36 shell /kernel: swap_pager: out of swap space Jun 4 11:17:37 shell Jun 4 11:17:37identd[: Connection from Jun 4 11:17:37 shell last message repeated 4 times Jun 4 11:17:37 shell Jun 4 11:17:37sshd[: fatal: Jun 4 11:17:37 shell Jun 4 11:17:37identd[: Connection from Jun 4 11:17:37 shell /kernel: pid 6895 (eggdrop), uid 1182, was killed: out of swap space Jun 4 11:17:37 shell Jun 4 11:17:37sshd[: fatal: Jun 4 11:17:37 shell /kernel: swap_pager: out of swap space Jun 4 11:17:37 shell /kernel: pid 15027 (eggdrop), uid 1095, was killed: out of swap space Jun 4 11:17:38 shell /kernel: swap_pager: out of swap space Jun 4 11:17:38 shell Jun 4 11:17:38identd[: Connection from Jun 4 11:17:38 shell last message repeated 2 times Jun 4 11:17:38 shell Jun 4 11:17:38sshd[: fatal: Jun 4 11:17:38 shell Jun 4 11:17:38sshd[: fatal: Jun 4 11:17:38 shell Jun 4 11:17:38identd[: Connection from Jun 4 11:17:38 shell Jun 4 11:17:38sshd[: fatal: Jun 4 11:17:38 shell last message repeated 4 times Jun 4 11:17:38 shell Jun 4 11:17:38identd[: Connection from Jun 4 11:17:38 shell Jun 4 11:17:38sshd[: fatal: Jun 4 11:17:38 shell last message repeated 2 times Jun 4 11:17:38 shell Jun 4 11:17:38identd[: Connection from Jun 4 11:17:38 shell Jun 4 11:17:38sshd[: fatal: Jun 4 11:17:38 shell Jun 4 11:17:38sshd[: fatal: Jun 4 11:17:38 shell Jun 4 11:17:38identd[: Connection from Jun 4 11:17:39 shell Jun 4 11:17:39identd[: Connection from Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39identd[: Connection from Jun 4 11:17:39 shell last message repeated 5 times Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39identd[: Connection from Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39identd[: Connection from Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell /kernel: pid 13629 (eggdrop), uid 1169, was killed: out of swap space Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39identd[: Connection from Jun 4 11:17:39 shell last message repeated 6 times Jun 4 11:17:39 shell Jun 4 11:17:39sshd[: fatal: Jun 4 11:17:39 shell Jun 4 11:17:39identd[: Connection from Jun 4 11:17:39 shell /kernel: pid 22932 (eggdrop), uid 1127, was killed: out of swap space Jun 4 11:17:40 shell /kernel: swap_pager: out of swap space Jun 4 11:17:40 shell Jun 4 11:17:40sshd[: fatal: Jun 4 11:17:40 shell last message repeated 4 times Jun 4 11:17:40 shell /kernel: pid 8231 (eggdrop), uid 1046, was killed: out of swap space Jun 4 11:17:40 shell /kernel: swap_pager: out of swap space Jun 4 11:17:40 shell Jun 4 11:17:40identd[: Connection from Jun 4 11:17:40 shell Jun 4 11:17:40identd[: Connection from Jun 4 11:17:41 shell Jun 4 11:17:41identd[: Connection from Jun 4 11:17:41 shell last message repeated 2 times Jun 4 11:17:41 shell Jun 4 11:17:41sshd[: fatal: Jun 4 11:17:41 shell Jun 4 11:17:41identd[: Connection from Jun 4 11:17:41 shell Jun 4 11:17:41identd[: Connection from Jun 4 11:17:41 shell Jun 4 11:17:41sshd[: fatal: Jun 4 11:17:41 shell /kernel: pid 8984 (eggdrop), uid 1128, was killed: out of swap space Jun 4 11:17:41 shell Jun 4 11:17:41identd[: Connection from Jun 4 11:17:41 shell /kernel: swap_pager: out of swap space Jun 4 11:17:41 shell Jun 4 11:17:41sshd[: log: Jun 4 11:17:41 shell Jun 4 11:17:41identd[: Connection from Jun 4 11:17:41 shell /kernel: pid 20666 (eggdrop), uid 1167, was killed: out of swap space Jun 4 11:17:42 shell Jun 4 11:17:41identd[: Connection from Jun 4 11:17:42 shell last message repeated 2 times Jun 4 11:17:43 shell /kernel: swap_pager: out of swap space Jun 4 11:17:43 shell Jun 4 11:17:43sshd[: fatal: Jun 4 11:17:43 shell last message repeated 2 times Jun 4 11:17:43 shell Jun 4 11:17:43identd[: Connection from Jun 4 11:17:43 shell /kernel: pid 7432 (eggdrop), uid 1182, was killed: out of swap space Jun 4 11:17:45 shell identd[20165]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:45 shell identd[20169]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:45 shell identd[20178]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:45 shell identd[20164]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:45 shell identd[18441]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:46 shell identd[20173]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:46 shell identd[18443]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Jun 4 11:17:46 shell identd[20188]: from: 205.230.20.20 (mail.mis.isidesign.com) EMPTY REQUEST Then, I telnet to shell.. Trying 204.137.237.8... Connected to shell. Escape character is '^]'. inetd in free(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too low to make sense. inetd in free(): warning: junk pointer, too low to make sense. inetd in realloc(): warning: junk pointer, too low to make sense. login: I do an uptime: 11:20AM up 4 days, 23:29, 5 users, load averages: 196.96, 188.06, 87.32 What did they do to me, and what can I do to stop it? :) This is a current machine, from Apr 25th... Is it just a case of flooding me with identd connects, then later ftp connects? Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 10:27:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA19285 for freebsd-current-outgoing; Thu, 4 Jun 1998 10:27:19 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from vortex.starix.net (syko@vortex.starix.net [208.219.83.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19277 for ; Thu, 4 Jun 1998 10:27:17 -0700 (PDT) (envelope-from syko@starix.net) Received: from localhost (syko@localhost) by vortex.starix.net (8.7.6/8.7.3) with SMTP id NAA02833; Thu, 4 Jun 1998 13:25:28 -0400 X-Authentication-Warning: vortex.starix.net: syko owned process doing -bs Date: Thu, 4 Jun 1998 13:25:28 -0400 (EDT) From: Dusk Auriel Sykotik To: Ozz!!! cc: FreeBSD-current mail-list Subject: Re: Strange in vi ??? or UFS ??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are you root? pap-secrets is owned by root, if your not root, you wouldn't be able to read it with those permissions. to check whether your root or not, you can type whoami. also, are those multiple rows of four dots just a typo you added, or is that actually in the ls output? if it is, something is very screwed up :| You also may want to check the permissions for the directory your in... there are a few rare instances you could have an ls for a directory you don't have read permission for, such as if permissions were changed after the ls, but before your attempt to open the file in vi. try opening the file in another text editor? I have limited experience with vi, so I don't know exactly what it takes to make it give the error it gave you, try emacs, pico, or if its available on your syste, ee is nice. /******************************************* * Syko, AKA Matt Harris In The Real World * * Visit SykotikMUSH! * vortex.starix.net 6300 * Visit TechnoNet! * /server Dark.NY.US.TechnoNet.Net * Visit Cabalnet! * /server dark-temple.md.us.cabalnet.org * * ******************************************/ On Thu, 4 Jun 1998, Ozz!!! wrote: > > Hi! > Have a strange: > > $ pwd > /etc/ppp > $ ls -al > ..... > .... > -rw------- 1 root wheel 78 30 Apr 08:45 pap-secrets > .... > .... > $ vi pap-secrets > Error: pap-secrets: Permission denied. > pap-secrets: unmodified, readonly: line 1 > Press any key to continue: > > then I type Enter & vi create a new file... > Hmmm.. > If I can't read pap-secrets, why vi run & create new file ??? > I think vi said: pap-secrets: Permission denied & quit ??? > > Sorry 4 bad English. > > Rgdz, > oZZ, > osa@unibest.ru > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 11:13:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28412 for freebsd-current-outgoing; Thu, 4 Jun 1998 11:13:50 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28358 for ; Thu, 4 Jun 1998 11:13:35 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (root@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id UAA11311; Thu, 4 Jun 1998 20:13:21 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id UAA04402; Thu, 4 Jun 1998 20:13:14 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199806041813.UAA04402@greenpeace.grondar.za> To: richard@cogsci.ed.ac.uk cc: freebsd-current@FreeBSD.ORG Subject: Re: kerberised packages Date: Thu, 04 Jun 1998 20:13:14 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG wrote: > Several of the packages in packages-current seem to require libkrb.so.3.0. > For example: xv, xfig, netpbm. Is this intentional? Hmm. This means that these port where built on a machine with kerberised X. Probably only a good idea for those folk with kerberised X. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 11:42:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA04808 for freebsd-current-outgoing; Thu, 4 Jun 1998 11:42:49 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from engulf.net (root@engulf.com [207.96.124.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA04782 for ; Thu, 4 Jun 1998 11:42:37 -0700 (PDT) (envelope-from brandon@engulf.net) Received: from localhost (brandon@localhost) by engulf.net (8.8.8/8.8.8) with SMTP id OAA16264 for ; Thu, 4 Jun 1998 14:33:19 -0400 (EDT) Date: Thu, 4 Jun 1998 14:33:18 -0400 (EDT) From: Brandon Lockhart To: current@FreeBSD.ORG Subject: More current PPP problems... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For some reason, when I am using the newest version of PPP (Downloaded and installed last saturday), I can not complete a connection. This is what happens. I start ppp with "ppp -alias engulf". I then type "dial". It opens my modem and begins to dial. It then waits for the connect. It attempts to log in, and this is what happens. tun0: LCP: deflink: RecvConfigReq(2) state = Ack-Rcvd tun0: LCP: MRU[4] 1006 tun0: LCP: ACCMAP[6] 0x000a 0000 tun0: LCP: PROTOCOMP[2] tun0: LCP: ACFCOMP[2] tun0: LCP: ENDDISC[9] MAC 00:c0:7b:71:84:14 tun0: LCP: deflink: SendConfigNak(2) state = Ack-Rcvd tun0: LCP: MRU[4] 2000 tun0: HDLC: hdlc_Output tun0: HDLC: ff 03 c0 21 03 02 00 08 01 04 07 d0 8c 9b tun0: HDLC: hdlc_Input tun0: HDLC: ff 03 c0 21 03 02 00 1b 01 04 03 ee 02 06 00 0a tun0: HDLC: 00 00 07 02 08 02 13 09 03 c0 00 7b 71 84 14 55 tun0: HDLC: 50 It does this about 5 times, then into some different headers. The other headers basically say that the remote end asked the connection to be terminated (It sends ands receives a TerminationReq). I can use my /stand/ppp fine. Except the alias enable yes is looking for libalias.so.2.4, and I have 2.5, and it won't load correctly. Any clue why I can dialup with the old copy, but not the new one? This is my /etc/ppp/ppp.conf file. default: set device /dev/cuaa1 set speed 115200 set log local +Phase set log local +Chat set log local +Connect set log local +hdlc set log local +LCP set log local +IPCP set log local +CCP set log local +tun deny lqr set mtu 2000 set mru 2000 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" engulf: set phone 4106269606 set login "TIMEOUT 5 ogin:--ogin: brandon word: " set timeout 120 set redial 10.3 90 set reconnect 1 900 ,--------------------------------,--------------------------------, | Brandon Lockhart | Network Administrator | | brandon@engulf.net | System Administrator | | http://www.engulf.net/brandon/ | IRC Expert | `--------------------------------`--------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 11:48:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06222 for freebsd-current-outgoing; Thu, 4 Jun 1998 11:48:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA06167 for ; Thu, 4 Jun 1998 11:47:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00849; Thu, 4 Jun 1998 10:41:23 -0700 (PDT) Message-Id: <199806041741.KAA00849@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , Michael Hancock , "freebsd-current@freebsd.org" , tcobb , Karl Pielorz , Bob Willcox , Greg Lehey Subject: Re: DPT driver fails and panics with Degraded Array In-reply-to: Your message of "Thu, 04 Jun 1998 12:19:44 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jun 1998 10:41:23 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > On 03-Jun-98 Mike Smith wrote: > > .... > > >> This would normally cause a 'biodone: buffer already done' message, > >> which is a warning, not a panic. The only way I could think of this > >> happening on a valid buffer (apart from the obvious of calling it > >> while it wasn't busy) would be if something messed around with other > >> buffer flags. > > > > It would be an issue if the buf struct had been recycled, but hadn't > > yet been marked busy, or if the buf pointer was invalid (the business > > check is the very first check in biodone()). > > Is this code surrounded by splhigh() ? If not, it is entirely possible for > that to happen. Due to the caching/quieing nature of the DPT, especially > the PM3334, and the multi-threaded nature of the DPT driver, for several > interrupts to be issued less than 1us apart. This means that there will be > several hardware interrupts and several soft interrupts generated in a very > short period of time. The possibilities I mentioned above are only relevant if the DPT is calling biodone() more than once in error. If you're confident that this is not happening, then the above is not relevant. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 11:52:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07384 for freebsd-current-outgoing; Thu, 4 Jun 1998 11:52:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA07282 for ; Thu, 4 Jun 1998 11:51:59 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA29790; Thu, 4 Jun 1998 11:51:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd029747; Thu Jun 4 11:51:54 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id LAA03682; Thu, 4 Jun 1998 11:51:51 -0700 (MST) From: Terry Lambert Message-Id: <199806041851.LAA03682@usr05.primenet.com> Subject: Re: I see one major problem with DEVFS... To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Thu, 4 Jun 1998 18:51:51 +0000 (GMT) Cc: eivind@yes.no, tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <199806040300.XAA02003@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Jun 3, 98 11:00:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If you want the removal of config to happen, _do something about it_. > > A lot of us don't. Most of us who don't are the same ones as learned > long ago to filter out mail matching ^From:.*tlambert@.*primenet\.com. > Terry has been complaining about config for five years now, and while > the current config is a mess, I don't believe that there is serious > disagreement about the need for such a tool. (I think this goes > particularly for those of us who operate machines that people actually > depend upon on a day-to-day basis.) 1) Barriers for new users should be removed, even if they are sacred cows. Yes, this is an opinion, but I believe it is one that is beneficial to the FreeBSD project, and is (or should) be held by others who advocate FreeBSD. 2) The config program is a barrier for new users. This isn't an opinion. It's a fact. People who have never used the config program in FreeBSD are unlikely to have experience with a similar program in the environment they came from, be it Linux or be it Windows. Let's actually address the issue you raise: What task can you perform with config that you don't think you would be able to perform without config? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 12:34:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA18586 for freebsd-current-outgoing; Thu, 4 Jun 1998 12:34:36 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from engulf.net (brandon@engulf.com [207.96.124.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA18550 for ; Thu, 4 Jun 1998 12:34:25 -0700 (PDT) (envelope-from brandon@engulf.net) Received: from localhost (brandon@localhost) by engulf.net (8.8.8/8.8.8) with SMTP id PAA17288 for ; Thu, 4 Jun 1998 15:31:52 -0400 (EDT) Date: Thu, 4 Jun 1998 15:31:32 -0400 (EDT) From: Brandon Lockhart To: current@FreeBSD.ORG Subject: More current PPP problems... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG For some reason, when I am using the newest version of PPP (Downloaded and installed last saturday), I can not complete a connection. This is what happens. I start ppp with "ppp -alias engulf". I then type "dial". It opens my modem and begins to dial. It then waits for the connect. It attempts to log in, and this is what happens. tun0: LCP: deflink: RecvConfigReq(2) state = Ack-Rcvd tun0: LCP: MRU[4] 1006 tun0: LCP: ACCMAP[6] 0x000a 0000 tun0: LCP: PROTOCOMP[2] tun0: LCP: ACFCOMP[2] tun0: LCP: ENDDISC[9] MAC 00:c0:7b:71:84:14 tun0: LCP: deflink: SendConfigNak(2) state = Ack-Rcvd tun0: LCP: MRU[4] 2000 tun0: HDLC: hdlc_Output tun0: HDLC: ff 03 c0 21 03 02 00 08 01 04 07 d0 8c 9b tun0: HDLC: hdlc_Input tun0: HDLC: ff 03 c0 21 03 02 00 1b 01 04 03 ee 02 06 00 0a tun0: HDLC: 00 00 07 02 08 02 13 09 03 c0 00 7b 71 84 14 55 tun0: HDLC: 50 It does this about 5 times, then into some different headers. The other headers basically say that the remote end asked the connection to be terminated (It sends ands receives a TerminationReq). I can use my /stand/ppp fine. Except the alias enable yes is looking for libalias.so.2.4, and I have 2.5, and it won't load correctly. Any clue why I can dialup with the old copy, but not the new one? This is my /etc/ppp/ppp.conf file. default: set device /dev/cuaa1 set speed 115200 set log local +Phase set log local +Chat set log local +Connect set log local +hdlc set log local +LCP set log local +IPCP set log local +CCP set log local +tun deny lqr set mtu 2000 set mru 2000 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" engulf: set phone 4106269606 set login "TIMEOUT 5 ogin:--ogin: brandon word: " set timeout 120 set redial 10.3 90 set reconnect 1 900 The PPP I am using (from /stand) is looking for /usr/lib/libalias.so.2.4, I made a link symlink from 2.4 and 2.5 to aout/libalias.so.2.5, but it will still not alias enable yes correctly. ,--------------------------------,--------------------------------, | Brandon Lockhart | Network Administrator | | brandon@engulf.net | System Administrator | | http://www.engulf.net/brandon/ | IRC Expert | `--------------------------------`--------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 12:46:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA20458 for freebsd-current-outgoing; Thu, 4 Jun 1998 12:46:27 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA20429 for ; Thu, 4 Jun 1998 12:46:22 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA08146; Thu, 4 Jun 1998 19:46:13 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA20317; Thu, 4 Jun 1998 21:45:41 +0200 (MET DST) Message-ID: <19980604214541.64381@follo.net> Date: Thu, 4 Jun 1998 21:45:41 +0200 From: Eivind Eklund To: Terry Lambert , Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <199806040300.XAA02003@khavrinen.lcs.mit.edu> <199806041851.LAA03682@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806041851.LAA03682@usr05.primenet.com>; from Terry Lambert on Thu, Jun 04, 1998 at 06:51:51PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jun 04, 1998 at 06:51:51PM +0000, Terry Lambert wrote: > What task can you perform with config that you don't think you would > be able to perform without config? Configure and compile the FreeBSD kernel without doing large changes compared to the present source. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 13:05:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA23377 for freebsd-current-outgoing; Thu, 4 Jun 1998 13:05:46 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.camalott.com (root@[208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA23362 for ; Thu, 4 Jun 1998 13:05:41 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-90.camalott.com [208.229.74.90] (may be forged)) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id PAA22267; Thu, 4 Jun 1998 15:04:16 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id PAA03968; Thu, 4 Jun 1998 15:05:09 -0500 (CDT) (envelope-from joelh) Date: Thu, 4 Jun 1998 15:05:09 -0500 (CDT) Message-Id: <199806042005.PAA03968@detlev.UUCP> To: tlambert@primenet.com CC: wollman@khavrinen.lcs.mit.edu, eivind@yes.no, tlambert@primenet.com, current@FreeBSD.ORG In-reply-to: <199806041851.LAA03682@usr05.primenet.com> (message from Terry Lambert on Thu, 4 Jun 1998 18:51:51 +0000 (GMT)) Subject: Re: I see one major problem with DEVFS... From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199806041851.LAA03682@usr05.primenet.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 2) The config program is a barrier for new users. > This isn't an opinion. It's a fact. People who have never used the > config program in FreeBSD are unlikely to have experience with a > similar program in the environment they came from, be it Linux or > be it Windows. I had no problem at all with the config program when I started with BSD. And FreeBSD has the handbook that spells it out easily. -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 14:20:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA11144 for freebsd-current-outgoing; Thu, 4 Jun 1998 14:20:31 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp03.primenet.com (daemon@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA11080 for ; Thu, 4 Jun 1998 14:20:16 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id OAA18414; Thu, 4 Jun 1998 14:20:05 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd018327; Thu Jun 4 14:19:55 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA12140; Thu, 4 Jun 1998 14:19:49 -0700 (MST) From: Terry Lambert Message-Id: <199806042119.OAA12140@usr08.primenet.com> Subject: Re: I see one major problem with DEVFS... To: joelh@gnu.org Date: Thu, 4 Jun 1998 21:19:49 +0000 (GMT) Cc: tlambert@primenet.com, wollman@khavrinen.lcs.mit.edu, eivind@yes.no, current@FreeBSD.ORG In-Reply-To: <199806042005.PAA03968@detlev.UUCP> from "Joel Ray Holveck" at Jun 4, 98 03:05:09 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 2) The config program is a barrier for new users. > > > > This isn't an opinion. It's a fact. People who have never used the > > config program in FreeBSD are unlikely to have experience with a > > similar program in the environment they came from, be it Linux or > > be it Windows. > > I had no problem at all with the config program when I started with > BSD. And FreeBSD has the handbook that spells it out easily. You are not a "people", you are an "engineer". A "people" would not have known there was a handbook, nor that the kernel would ever have reason to need to be recompiled, let alone that it was possible to read something to get the information. To paraphrase Nate's law: "the complexity has to live somewhere"; I personally prefer that it live, not in user space code, and not in kernel space code, but in the architecture. Have you ever been to an amusement park with gas powered cars that are on a cement ridge, much like a slot car? These parks never have problems with the animal ride train barrelling into a slot car, flying off the tracks into a bridge abuttment, and then the bridge collapsing on the passgenger cars of the train to the gleeful howls of the tabloid press. Unlike most so-called "modern" countries, the car and train systems at amusement parks are architected such that they do not have intersecting domains. In the same way, OS's must be architected such that there is never a domain containing both members of the set "complex task" and the set "standard user interface" simultaneously. Note the use of the adjective "standard" before accusing me of wanting to "dumb down" UNIX. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jun 4 14:36:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14442 for freebsd-current-outgoing; Thu, 4 Jun 1998 14:36:47 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14397 for ; Thu, 4 Jun 1998 14:36:34 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id XAA22300 for ; Thu, 4 Jun 1998 23:36:11 +0200 (MET DST) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Thu, 4 Jun 1998 23:36:10 +0200 (MET DST) Mime-Version: 1.0 To: current@FreeBSD.ORG Subject: Strange ppp behaviour Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-email-address-1: dag-erli@ifi.uio.no (for private or study-related mail) X-email-address-2: dagsm@hypnotech.no (for job-related mail) X-email-address-3: des@FreeBSD.org (for FreeBSD-related mail) X-email-address-4: finrod@ewox.org (for demoscene-related mail) X-disclaimer-1: I speak only for myself. The views expressed in this message X-disclaimer-2: are not those of the University of Oslo, the FreeBSD project, X-disclaimer-3: or any other organization or company to which I am or have at X-disclaimer-4: some time been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 04 Jun 1998 23:36:09 +0200 Message-ID: Lines: 135 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FreeBSD niobe.ewox.org 3.0-CURRENT FreeBSD 3.0-CURRENT #1: Thu Jun 4 10:55:29 CEST 1998 finrod@niobe.ewox.org:/usr/src/sys/compile/niobe i386 (this is the same machine that used to run 2.2.6-STABLE under the name valinor.ewox.org) I have had strange problems with ppp (segmenation faults, to be precise). I checked out an older version (31/05/1998) which exhibited the same symptoms: ppp