From owner-freebsd-current Sun May 31 00:10:40 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mi@aldan.algebra.com>
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<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL39 (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
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.
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <julian@whistle.com>
To: Tom Jackson <toj@gorillanet.gorilla.net>
cc: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: IP Packet Aliasing Broke?
In-Reply-To: <19980530210320.35350@TOJ.org>
Message-ID: <Pine.BSF.3.95.980531001110.10668E-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <julian@whistle.com>
To: Brian Feldman <brianfeldman@hotmail.com>
cc: freebsd-current@FreeBSD.ORG
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <19980531042432.16101.qmail@m2.findmail.com>
Message-ID: <Pine.BSF.3.95.980530234338.10668D-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mi@aldan.algebra.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <graphix@iastate.edu>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <ianh@tortuga.com.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mcdougall@ameritech.net>
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 <graphix@iastate.edu>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <l0313030bb195de7042c4@[208.2.87.10]> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <tlambert@primenet.com>
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: <Pine.BSF.3.95.980530154859.10304C-100000@current1.whistle.com> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <tlambert@primenet.com>
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: <Pine.SV4.3.95.980531080819.3937A-100000@parkplace.cet.co.jp> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <kpielorz@tdx.co.uk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <peter@netplex.com.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <graphix@iastate.edu>
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 <paulz@trantor.stuyts.nl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <julian@whistle.com>
To: Karl Pielorz <kpielorz@tdx.co.uk>
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: <Pine.BSF.3.95.980531041801.10668M-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <michael_class@hp.com>
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 <opt_devfs.h>
+
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/conf.h>
***************
*** 18,23 ****
--- 20,31 ----
#include <scsi/scsiconf.h>
#include <scsi/scsi_driver.h>
+ 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: <owner-freebsd-current@FreeBSD.ORG>
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 <eculp@ver1.telmex.net.mx>
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 <paulz@trantor.stuyts.nl>
CC: Kent A Vander Velden <graphix@iastate.edu>, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <tlambert@primenet.com>
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 <phk@critter.freebsd.dk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <sanewo@ba2.so-net.ne.jp>
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 <dnelson@emsphone.com> 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 <URL:mailto:sanewo@ba2.so-net.ne.jp>
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 <christos@ee.cornell.edu>
* Steven Wallace <swallace@freebsd.org>
* Wolfram Schneider <wosch@FreeBSD.org>
@@ -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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <Pine.BSF.3.95.980530234338.10668D-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <Pine.BSF.3.95.980530234338.10668D-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: IP Packet Aliasing Broke?
In-Reply-To: <Pine.BSF.3.95.980531001110.10668E-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <toor@dyson.iquest.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
Message-Id: <199805311453.KAA18088@khavrinen.lcs.mit.edu>
To: Takanori Saneto <sanewo@ba2.so-net.ne.jp>
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
<<On 31 May 1998 19:55:28 +0900, Takanori Saneto <sanewo@ba2.so-net.ne.jp> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
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 <sanewo@ba2.so-net.ne.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <199805311453.KAA18088@khavrinen.lcs.mit.edu>
Garrett Wollman <wollman@khavrinen.lcs.mit.edu> said:
><<On 31 May 1998 19:55:28 +0900, Takanori Saneto <sanewo@ba2.so-net.ne.jp> 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 <URL:mailto:sanewo@ba2.so-net.ne.jp>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <nathan@rtfm.net>
To: Takanori Saneto <sanewo@ba2.so-net.ne.jp>, current@FreeBSD.ORG
Subject: Re: top -osize
Mail-Followup-To: Takanori Saneto <sanewo@ba2.so-net.ne.jp>,
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <current@FreeBSD.ORG>; 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 <jake@checker.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <l0313030fb196e885c687@[208.2.87.10]>
In-Reply-To: <199805311003.DAA20637@usr04.primenet.com>
References: <l0313030bb195de7042c4@[208.2.87.10]> 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 <tlambert@primenet.com>
From: Richard Wackerbarth <rkw@dataplex.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <l03130310b196ef2053d9@[208.2.87.10]>
In-Reply-To: <19980531052120.41610@follo.net>
References: <l03130309b195d4c6fd5b@[208.2.87.10]>; 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> <l03130309b195d4c6fd5b@[208.2.87.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Eivind Eklund <eivind@yes.no>
From: Richard Wackerbarth <rkw@dataplex.net>
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.<architecture>
> > ../../*/conf/options.FreeBSD.<architecture>
> >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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <abial@nask.pl>
X-Sender: abial@korin.warman.org.pl
To: Julian Elischer <julian@whistle.com>
cc: Brian Feldman <brianfeldman@hotmail.com>, freebsd-current@FreeBSD.ORG
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <Pine.BSF.3.95.980530234338.10668D-100000@current1.whistle.com>
Message-ID: <Pine.NEB.3.95.980531185623.21023A-100000@korin.warman.org.pl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <graphix@iastate.edu>, 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: <xzpemxajs57.fsf@skejdbrimir.ifi.uio.no>
Lines: 8
X-Mailer: Gnus v5.5/Emacs 19.34
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Adam McDougall <mcdougall@ameritech.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <jhay@mikom.csir.co.za>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <jmacd@paris.CS.Berkeley.EDU>
To: Paul van der Zwan <paulz@trantor.stuyts.nl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <joes@shasta.wstein.com>
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 <pgr> joes@wstein.com <e-mail>
* 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <garbanzo@hooked.net>
X-Sender: garbanzo@zippy.dyn.ml.org
To: Ollivier Robert <roberto@keltia.freenix.fr>
cc: current@FreeBSD.ORG
Subject: Re: ELF preparation step 2 done
In-Reply-To: <19980527230443.A23502@keltia.freenix.fr>
Message-ID: <Pine.BSF.3.96.980531104201.603A-100000@zippy.dyn.ml.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <michaelh@cet.co.jp>
To: Terry Lambert <tlambert@primenet.com>
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: <Pine.SV4.3.95.980601033450.7241A-100000@parkplace.cet.co.jp>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <freebsd-current@FreeBSD.ORG>; 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 <toj@gorillanet.gorilla.net>
To: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: IP Packet Aliasing Broke?
Mail-Followup-To: FreeBSD Current <freebsd-current@FreeBSD.ORG>
References: <19980530210320.35350@TOJ.org> <Pine.BSF.3.95.980531001110.10668E-100000@current1.whistle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <Pine.BSF.3.95.980531001110.10668E-100000@current1.whistle.com>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <julian@whistle.com>
To: Brian Feldman <brianfeldman@hotmail.com>
cc: freebsd-current@FreeBSD.ORG
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <19980531143902.9769.qmail@m2.findmail.com>
Message-ID: <Pine.BSF.3.95.980531120742.11289A-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <julian@whistle.com>
To: Andrzej Bialecki <abial@nask.pl>
cc: Brian Feldman <brianfeldman@hotmail.com>, freebsd-current@FreeBSD.ORG
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <Pine.NEB.3.95.980531185623.21023A-100000@korin.warman.org.pl>
Message-ID: <Pine.BSF.3.95.980531120859.11289B-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <julian@whistle.com>
To: Micha Class <michael_class@hp.com>
cc: current@FreeBSD.ORG
Subject: Re: scsi-uk and DEVFS
In-Reply-To: <3571407E.D3D078E1@hp.com>
Message-ID: <Pine.BSF.3.95.980531121711.11289D-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <julian@whistle.com>
To: John Hay <jhay@mikom.csir.co.za>
cc: current@FreeBSD.ORG
Subject: Re: ports and the aout lib directory
In-Reply-To: <199805311730.TAA02921@zibbi.mikom.csir.co.za>
Message-ID: <Pine.BSF.3.95.980531121350.11289C-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <root@dyn.ml.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <graphix@iastate.edu>,
current@FreeBSD.ORG
Subject: Re: kernel config
In-reply-to: Your message of "31 May 1998 18:56:36 +0200."
<xzpemxajs57.fsf@skejdbrimir.ifi.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 31 May 1998 11:43:18 -0700
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> Adam McDougall <mcdougall@ameritech.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mike@smith.net.au>
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: <yzsn2bykyrz.fsf@sicily.odyssey.cs.cmu.edu>
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 <mike@smith.net.au> 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
> <expletive>
> # 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eculp@ver1.telmex.net.mx>
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" <graphix@iastate.edu>
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 <paulz@trantor.stuyts.nl> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <peter@netplex.com.au>
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 <dom@myrddin.demon.co.uk>
Message-Id: <E0ygEll-0000xJ-00.qmail@myrddin.demon.co.uk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <joes@shasta.wstein.com>
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 <peter@netplex.com.au>
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 <pgr> joes@wstein.com <e-mail>
> * 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: <owner-freebsd-current@FreeBSD.ORG>
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 <dom@myrddin.demon.co.uk>
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."
<E0ygEll-0000xJ-00.qmail@myrddin.demon.co.uk>
Date: Mon, 01 Jun 1998 04:41:37 +0800
From: Peter Wemm <peter@netplex.com.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <tcobb@staff.circle.net>
cc: "'Mike Smith'" <mike@smith.net.au>,
"'shimon@simon-shapiro.org'" <shimon@simon-shapiro.org>,
"freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
"freebsd-current@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 <mike@smith.net.au>
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: <DPT RAID-5 07M0> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <Pine.SV4.3.95.980601033450.7241A-100000@parkplace.cet.co.jp> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mike@smith.net.au>
cc: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?=
),
mcdougall@ameritech.net, Kent A Vander Velden <graphix@iastate.edu>,
current@FreeBSD.ORG
From: "Louis A. Mamakos" <louie@TransSys.COM>
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 <mcdougall@ameritech.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <scrappy@hub.org>
To: freebsd-current@FreeBSD.ORG
cc: freebsd-scsi@FreeBSD.ORG
Subject: May29th kernel with May20th CAM drivers: panic?
Message-ID: <Pine.BSF.3.96.980531174216.448B-100000@hub.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Richard Wackerbarth <rkw@dataplex.net>
Cc: current@FreeBSD.ORG
Subject: Re: How about /usr/ports/kernel ?
References: <l03130309b195d4c6fd5b@[208.2.87.10]>; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <l03130309b195d4c6fd5b@[208.2.87.10]> <19980531052120.41610@follo.net> <l03130310b196ef2053d9@[208.2.87.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <l03130310b196ef2053d9@[208.2.87.10]>; 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.<architecture>
>>> ../../*/conf/options.FreeBSD.<architecture>
>>> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: fd crash (in isa_dmastart)
In-Reply-To: <Pine.BSF.3.95.980531120742.11289A-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: fd crash (in isa_dmastart) (more clarifications)
In-Reply-To: <Pine.BSF.3.95.980531120742.11289A-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <l0313030fb196e885c687@[208.2.87.10]> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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" <ken@plutotech.com>
Message-Id: <199805312220.QAA04786@panzer.plutotech.com>
Subject: Re: May29th kernel with May20th CAM drivers: panic?
In-Reply-To: <Pine.BSF.3.96.980531174216.448B-100000@hub.org> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <scrappy@hub.org>
To: "Kenneth D. Merry" <ken@plutotech.com>
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: <Pine.BSF.3.96.980531182600.448F-100000@hub.org>
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: <Digital 21140A Fast Ethernet> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <jb@cimlogic.com.au>
Message-Id: <199805312243.IAA15578@cimlogic.com.au>
Subject: Re: ELF preparation step 2 done
In-Reply-To: <Pine.BSF.3.96.980531104201.603A-100000@zippy.dyn.ml.org> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.org>; 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 <current@FreeBSD.org>; 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" <sepotvin@videotron.ca>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <julian@whistle.com>
To: The Super-User <root@dyn.ml.org>
cc: freebsd-current@FreeBSD.ORG
Subject: Re: really bad inodedep crash
In-Reply-To: <19980531154208.A4224@dyn.ml.org>
Message-ID: <Pine.BSF.3.95.980531160709.11289H-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mike@smith.net.au>
cc: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?=
),
mcdougall@ameritech.net, Kent A Vander Velden <graphix@iastate.edu>,
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" <jkh@time.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> > Adam McDougall <mcdougall@ameritech.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: really bad inodedep crash
In-Reply-To: <Pine.BSF.3.95.980531160709.11289H-100000@current1.whistle.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <Pine.BSF.3.95.980531160709.11289H-100000@current1.whistle.com> 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" <dyson@FreeBSD.ORG>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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 <Address 0xf14e3000 out of bounds>, length=512, chan=2)
# at ./@/i386/isa/isa.c:908
##3 0xf0208eca in isa_dmastart (flags=537919504,
# addr=0xf14e3000 <Address 0xf14e3000 out of bounds>, 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 <repeats 31 times>}, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <Studded@san.rr.com>
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 <luigi@labinfo.iet.unipi.it>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; Mon, 1 Jun 1998 10:25:30 +1000 (EST)
Message-ID: <015b01bd8cf4$23f4da40$e34a05cb@alpine.iaccess>
From: "Andrew Specht" <andrew@iaccess.com.au>
To: <freebsd-current@FreeBSD.ORG>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mi@aldan.algebra.com>
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<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL39 (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
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,
-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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Studded <Studded@san.rr.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mi@aldan.algebra.com>
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<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL39 (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 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. Ok, how about Java byte
code?
=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.
How about buying Java byte code Motif library and compiling it into
native binary for all your hardware regardless of the CPU type? Or
is XANDF better suited as an intermidiate between source and native?
Is it so much better suited that it is worth it to have yet another
format?
-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:26:21 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <brianfeldman@hotmail.com>
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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Mikhail Teterin <mi@aldan.algebra.com>, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <l03130301b1977e68fd4e@[208.2.87.10]>
In-Reply-To: <199805312213.PAA16988@usr06.primenet.com>
References: <l0313030fb196e885c687@[208.2.87.10]> 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 <tlambert@primenet.com>
From: Richard Wackerbarth <rkw@dataplex.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mi@aldan.algebra.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>, freebsd-current@FreeBSD.ORG
Subject: Re: ELF preparation step 2 done
References: <19980601000502.9689.qmail@m2.findmail.com>
From: The & of all Evil <root@enigami.com>
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: <x7lnrh6cmh.fsf@singularity.enigami.com>
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" <brianfeldman@hotmail.com> 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: <http://www.enigami.com/~ckempf/chipmerchant.html>
Cory Kempf Macintosh / Unix Consulting & Software Development
ckempf@enigami.com <http://www.enigami.com/~ckempf/>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <andrew@iaccess.com.au>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <jkh@time.cdrom.com>
cc: Mike Smith <mike@smith.net.au>, dag-erli@ifi.uio.no,
mcdougall@ameritech.net, Kent A Vander Velden <graphix@iastate.edu>,
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 <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> > > Adam McDougall <mcdougall@ameritech.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <jb@cimlogic.com.au>
Message-Id: <199806010421.OAA16535@cimlogic.com.au>
Subject: Re: ELF preparation step 2 done
In-Reply-To: <x7lnrh6cmh.fsf@singularity.enigami.com> 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" <brianfeldman@hotmail.com> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <n@nectar.com>
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 <nfs/nfs.h>. 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 <n@nectar.com>
-----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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <andrew@iaccess.com.au>
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 <dg@root.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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 <nfs/nfs.h>. 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 <nfs/nqfs.h>. At least mount_nfs.c
previously had to #define KERNEL before including <nfs/nfs.h> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <scrappy@hub.org>
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."
<Pine.BSF.3.96.980531174216.448B-100000@hub.org>
From: David Greenman <dg@root.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <current@FreeBSD.ORG>; 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 <dstenn@fanfic.org>
To: FreeBSD Current <current@FreeBSD.ORG>
Subject: Discussion of ELF
Message-ID: <Pine.BSF.3.96.980601014819.397K-100000@fanfic.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <n@nectar.com>
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 <bde@zeta.org.au>
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 <n@nectar.com>
On 1 June 1998 at 15:24, Bruce Evans <bde@zeta.org.au> 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 <nfs/nqfs.h>. At least mount_nfs.c
> previously had to #define KERNEL before including <nfs/nfs.h> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <bde@zeta.org.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <n@nectar.com>
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 <bde@zeta.org.au>
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 <bde@zeta.org.au> 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 <n@nectar.com>
-----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: <owner-freebsd-current@FreeBSD.ORG>
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 <bde@zeta.org.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <jhay@mikom.csir.co.za>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <jb@cimlogic.com.au>
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 <peter@netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
John Birrell wrote:
> The & of all Evil wrote:
> > "Brian Feldman" <brianfeldman@hotmail.com> 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 <peter@netplex.com.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <tlambert@primenet.com>
Cc: current@FreeBSD.ORG
Subject: Service Location Protocol
References: <199805292330.QAA23999@usr05.primenet.com>
From: Dom Mitchell <dom@myrddin.demon.co.uk>
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: <E0ygOdT-0000C9-00.qmail@myrddin.demon.co.uk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Terry Lambert <tlambert@primenet.com> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Mon, 1 Jun 1998 02:51:00 -0400 (EDT)
Date: Mon, 1 Jun 1998 02:50:33 -0400 (EDT)
From: Brandon Lockhart <brandon@engulf.net>
To: current@FreeBSD.ORG
Subject: Big problems.
Message-ID: <Pine.BSF.3.96.980601024252.432A-100000@engulf.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <jhay@mikom.csir.co.za>
cc: dg@root.com, andrew@iaccess.com.au, freebsd-current@FreeBSD.ORG
From: "Gary Palmer" <gpalmer@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>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.org>; 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" <sepotvin@videotron.ca>
Organization: IBM Canada Ltd.
X-Mailer: Mozilla 4.05 [en] (X11; U; FreeBSD 3.0-CURRENT i386)
MIME-Version: 1.0
To: Peter Wemm <peter@netplex.com.au>, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <brandon@engulf.net>
cc: current@FreeBSD.ORG
Subject: Re: Big problems.
In-reply-to: Your message of "Mon, 01 Jun 1998 02:50:33 EDT."
<Pine.BSF.3.96.980601024252.432A-100000@engulf.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 01 Jun 1998 00:37:49 -0700
From: Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <jhay@mikom.csir.co.za>
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 <dg@root.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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 <dg@root.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mike@smith.net.au>
cc: Brandon Lockhart <brandon@engulf.net>, 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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <jmacd@paris.CS.Berkeley.EDU>
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 <paulz@trantor.stuyts.nl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <l03130303b197eeb76060@[208.2.87.10]>
In-Reply-To: <19980531235232.04296@follo.net>
References: <l03130310b196ef2053d9@[208.2.87.10]>; from Richard
Wackerbarth on Sun, May 31, 1998 at 11:50:33AM -0500
<l03130309b195d4c6fd5b@[208.2.87.10]>;
<199805301346.PAA29505@labinfo.iet.unipi.it>;
<199805301346.PAA29505@labinfo.iet.unipi.it>
<19980530182913.04478@follo.net> <l03130309b195d4c6fd5b@[208.2.87.10]>
<19980531052120.41610@follo.net> <l03130310b196ef2053d9@[208.2.87.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Eivind Eklund <eivind@yes.no>
From: Richard Wackerbarth <rkw@dataplex.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <schilling@fokus.gmd.de>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <hometeam@techpower.net>
To: current@FreeBSD.ORG
Subject: compile error
Message-ID: <Pine.BSF.3.96.980601080107.25605A-100000@techpower.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <schilling@fokus.gmd.de>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <schilling@fokus.gmd.de>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <schilling@fokus.gmd.de>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <peter@netplex.com.au>
Subject: Re: ELF preparation step 2 done
References: <199806011159.TAA08567@spinner.netplex.com.au>
Cc: John Birrell <jb@cimlogic.com.au>, freebsd-current@FreeBSD.ORG
From: The & of all Evil <root@enigami.com>
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: <x7k9715l04.fsf@singularity.enigami.com>
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 <peter@netplex.com.au> 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: <http://www.enigami.com/~ckempf/chipmerchant.html>
Cory Kempf Macintosh / Unix Consulting & Software Development
ckempf@enigami.com <http://www.enigami.com/~ckempf/>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <benst@terminus.stuyts.nl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <dawes@rf900.physics.usyd.edu.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
Subject: Re: ELF preparation step 2 done
In-Reply-To: <x7lnrh6cmh.fsf@singularity.enigami.com>
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" <brianfeldman@hotmail.com> 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: <http://www.enigami.com/~ckempf/chipmerchant.html>
>
> Cory Kempf Macintosh / Unix Consulting & Software Development
> ckempf@enigami.com <http://www.enigami.com/~ckempf/>
>
> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Richard Wackerbarth <rkw@dataplex.net>,
Terry Lambert <tlambert@primenet.com>
Cc: current@FreeBSD.ORG
Subject: XANDF (was Re: Fix for undefined "__error" and discussion of shared object)
References: <l0313030fb196e885c687@[208.2.87.10]> <199805312213.PAA16988@usr06.primenet.com> <l03130301b1977e68fd4e@[208.2.87.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <l03130301b1977e68fd4e@[208.2.87.10]>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <brianfeldman@hotmail.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.org>; 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 <current@FreeBSD.org>; 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" <sepotvin@videotron.ca>
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 <bsd.own.mk>
-
.if exists(/etc/make.conf)
.include </etc/make.conf>
.endif
--- 243,250 ----
.endif
.if exists(/etc/make.conf)
.include </etc/make.conf>
.endif
+
+ .include <bsd.own.mk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <n@nectar.com>
In-reply-to: <Pine.BSF.3.96.980601080107.25605A-100000@techpower.net>
References: <Pine.BSF.3.96.980601080107.25605A-100000@techpower.net>
Subject: Re: compile error
To: Jt <hometeam@techpower.net>
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 <n@nectar.com>
On 1 June 1998 at 8:03, Jt <hometeam@techpower.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <brianfeldman@hotmail.com>
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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <benedict@echonyc.com>
Reply-To: ben@rosengart.com
To: Terry Lambert <tlambert@primenet.com>
cc: Richard Wackerbarth <rkw@dataplex.net>, current@FreeBSD.ORG
Subject: Re: Fix for undefined "__error" and discussion of shared object
In-Reply-To: <199805312213.PAA16988@usr06.primenet.com>
Message-ID: <Pine.GSO.3.96.980601113738.16765D-100000@echonyc.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <brianfeldman@hotmail.com>
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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <jkh@time.cdrom.com>
cc: Mike Smith <mike@smith.net.au>, Brandon Lockhart <brandon@engulf.net>,
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <eculp@ver1.telmex.net.mx>
Organization: Mexico Communicates, S.C.
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.14 i586)
MIME-Version: 1.0
To: Brian Feldman <brianfeldman@hotmail.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <jkh@time.cdrom.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mike@smith.net.au>
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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <schilling@fokus.gmd.de>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
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
<<On Sun, 31 May 1998 22:20:10 -0700, David Greenman <dg@root.com> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <schilling@fokus.gmd.de>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <schilling@fokus.gmd.de>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <toasty@home.dragondata.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <alk@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Face: O9M"E%K;(f-Go/XDxL+pCxI5<W_e*r7B8ojMD.5+qDgOp4/\gTQEgbOoBqf:Vtl*aW:<;9/
UIVk'U^XhYg+v#r~*X<$Q=_ik@5:%E}pl]9|9|:]WLW8n:fLgg0~cfwWRBQxK/HSG0b1D/gljJC$qp
b=HDF@+"H<|fXy`w#$8#6A"!F:>*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 <eivind@yes.no>:
> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <jmacd@paris.CS.Berkeley.EDU>
To: Paul van der Zwan <paulz@trantor.stuyts.nl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <schilling@fokus.gmd.de>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mi@video-collage.com>
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<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL35 (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.
=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...
-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 11:12:06 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
Message-Id: <199806011811.OAA22409@khavrinen.lcs.mit.edu>
To: Mike Smith <mike@smith.net.au>
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
<<On Mon, 01 Jun 1998 08:13:18 -0700, Mike Smith <mike@smith.net.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <benst@terminus.stuyts.nl>
Date: Mon, 1 Jun 98 20:25:49 +0200
To: "Brian Feldman" <brianfeldman@hotmail.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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 <peter@netplex.com.au>
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 <peter@netplex.com.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Richard Wackerbarth <rkw@dataplex.net>
Cc: current@FreeBSD.ORG
Subject: Re: How about /usr/ports/kernel ?
References: <l03130310b196ef2053d9@[208.2.87.10]>; <l03130309b195d4c6fd5b@[208.2.87.10]>; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <l03130309b195d4c6fd5b@[208.2.87.10]> <19980531052120.41610@follo.net> <l03130310b196ef2053d9@[208.2.87.10]> <19980531235232.04296@follo.net> <l03130303b197eeb76060@[208.2.87.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <l03130303b197eeb76060@[208.2.87.10]>; 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/<arch>/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 <bsd.subdir.mk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <l03130301b1977e68fd4e@[208.2.87.10]> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <abial@nask.pl>
X-Sender: abial@korin.warman.org.pl
To: freebsd-current@FreeBSD.ORG
Subject: "swaps on generic" - what a name...
Message-ID: <Pine.NEB.3.95.980601210249.21800B-100000@korin.warman.org.pl>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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 <peter@netplex.com.au>
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 <peter@netplex.com.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <brianfeldman@hotmail.com>, 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 <peter@netplex.com.au>
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 <peter@netplex.com.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386)
MIME-Version: 1.0
To: "Alex G. Bulushev" <bag@sinbin.demos.su>
CC: Eivind Eklund <eivind@yes.no>, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <eivind@yes.no>
To: Julian Elischer <julian@whistle.com>,
"Alex G. Bulushev" <bag@sinbin.demos.su>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <schilling@fokus.gmd.de>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mi@video-collage.com>
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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <jkh@time.cdrom.com>
cc: Mike Smith <mike@smith.net.au>, 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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <kpielorz@tdx.co.uk>
Organization: TDX
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Mikhail Teterin <mi@video-collage.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
cc: Mike Smith <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: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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Andrzej Bialecki <abial@nask.pl>, freebsd-current@FreeBSD.ORG
Subject: Re: "swaps on generic" - what a name...
References: <Pine.NEB.3.95.980601210249.21800B-100000@korin.warman.org.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <Pine.NEB.3.95.980601210249.21800B-100000@korin.warman.org.pl>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mi@video-collage.com>
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<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL35 (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 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.
-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 14:29:41 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <dufault@hda.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bde@zeta.org.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <mi@video-collage.com>
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<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL35 (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
Karl Pielorz once stated:
=> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <E0ygOdT-0000C9-00.qmail@myrddin.demon.co.uk> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <mi@video-collage.com>
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 <peter@netplex.com.au>
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 <peter@netplex.com.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <toasty@home.dragondata.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <hetzels@westbend.net>
To: "Mike Smith" <mike@smith.net.au>
Cc: <current@FreeBSD.ORG>
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 <mike@smith.net.au>
>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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <l03130308b19893b523d4@[208.2.87.10]>
In-Reply-To: <199806011904.MAA04619@usr01.primenet.com>
References: <l03130301b1977e68fd4e@[208.2.87.10]> 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 <tlambert@primenet.com>
From: Richard Wackerbarth <rkw@dataplex.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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" <jwd@unx.sas.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <dyson@FreeBSD.ORG>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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> <Pine.BSF.3.95.980531001110.10668E-100000@current1.whistle.com> <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 <jdp@polstra.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <XFMail.980601204642.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Karl Pielorz <kpielorz@tdx.co.uk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980601205151.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Mike Smith <mike@smith.net.au>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980601210624.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: tcobb <tcobb@staff.circle.net>
Subject: RE: DPT Redux
Cc: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
"freebsd-scsi@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: <DPT RAID-5 07M0> 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<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
> 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: <Intel 82437VX PCI cache memory controller> rev 0x02 on pci0.0.0
> chip1: <Intel 82371SB PCI to ISA bridge> rev 0x01 on pci0.7.0
> dpt0: <DPT Caching SCSI RAID Controller> 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: <DPT RAID-1 07M0> 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: <DPT RAID-5 07M0> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980601212113.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Mike Smith <mike@smith.net.au>
Subject: Re: DPT Redux
Cc: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
"freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980601212333.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Mike Smith <mike@smith.net.au>
Subject: Re: DPT Redux
Cc: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
"freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>
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: <DPT RAID-5 07M0> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980601213014.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: tcobb <tcobb@staff.circle.net>
Subject: RE: DPT driver fails and panics with Degraded Array
Cc: Karl Pielorz <kpielorz@tdx.co.uk>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
"freebsd-scsi@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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Tue, 2 Jun 1998 00:36:08 GMT
Date: Tue, 2 Jun 1998 00:36:08 +0000 (GMT)
From: Alfred Perlstein <perlsta@fang.cs.sunyit.edu>
To: current@FreeBSD.ORG
Subject: Re: forwarded message from Kevin Street
In-Reply-To: <13683.30076.606912.433434@kstreet.interlog.com>
Message-ID: <Pine.BSF.3.95.980601235235.3680A-100000@fang.cs.sunyit.edu>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.org>; 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" <pierre.dampure@k2c.co.uk>
To: <current@FreeBSD.ORG>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.org>; 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" <pierre.dampure@k2c.co.uk>
To: <peter@netplex.com.au>
Cc: <current@FreeBSD.ORG>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <gurney_j@efn.org>
To: The Hermit Hacker <scrappy@hub.org>
Cc: "Kenneth D. Merry" <ken@plutotech.com>, freebsd-current@FreeBSD.ORG,
freebsd-scsi@FreeBSD.ORG
Subject: Re: May29th kernel with May20th CAM drivers: panic?
References: <199805312220.QAA04786@panzer.plutotech.com> <Pine.BSF.3.96.980531182600.448F-100000@hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <Pine.BSF.3.96.980531182600.448F-100000@hub.org>; from The Hermit Hacker on Sun, May 31, 1998 at 06:29:28PM -0400
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
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: <Digital 21140A Fast Ethernet> 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 <Digital 21041 Ethernet> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <dufault@hda.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <kkennawa@physics.adelaide.edu.au>
X-Sender: kkennawa@bragg
To: freebsd-current@FreeBSD.ORG
Subject: removing /usr/src/sys/compile/XXX
Message-Id: <Pine.OSF.3.90.980602232030.5251A-100000@bragg>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <kkennawa@physics.adelaide.edu.au>
X-Sender: kkennawa@bragg
To: freebsd-current@FreeBSD.ORG
Subject: Old kernels not compatible with elf-changes?
Message-Id: <Pine.OSF.3.90.980602235448.19167A-100000@bragg>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Alfred Perlstein <perlsta@fang.cs.sunyit.edu>, current@FreeBSD.ORG
Subject: Re: forwarded message from Kevin Street
References: <13683.30076.606912.433434@kstreet.interlog.com> <Pine.BSF.3.95.980601235235.3680A-100000@fang.cs.sunyit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <Pine.BSF.3.95.980601235235.3680A-100000@fang.cs.sunyit.edu>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Kris Kennaway <kkennawa@physics.adelaide.edu.au>,
freebsd-current@FreeBSD.ORG
Subject: Re: removing /usr/src/sys/compile/XXX
References: <Pine.OSF.3.90.980602232030.5251A-100000@bragg>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <Pine.OSF.3.90.980602232030.5251A-100000@bragg>; 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 <whatever>" - 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <kkennawa@physics.adelaide.edu.au>
X-Sender: kkennawa@bragg
To: Eivind Eklund <eivind@yes.no>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: removing /usr/src/sys/compile/XXX
In-Reply-To: <19980602163053.16755@follo.net>
Message-Id: <Pine.OSF.3.90.980603010310.23563A-100000@bragg>
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 <whatever>" - 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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" <mishania@demos.su>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
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 <wollman@khavrinen.lcs.mit.edu> 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:
# <<On Sun, 31 May 1998 22:20:10 -0700, David Greenman <dg@root.com> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <kkennawa@physics.adelaide.edu.au>
X-Sender: kkennawa@bragg
To: Eivind Eklund <eivind@yes.no>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: removing /usr/src/sys/compile/XXX
In-Reply-To: <19980602163053.16755@follo.net>
Message-Id: <Pine.OSF.3.90.980603014712.24056A-100000@bragg>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <karl@mcs.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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" <jmb>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <jared@puck.nether.net>
To: =?iso-8859-1?Q?Dag-Erling_Coidan_Sm=F8rgrav?= <dag-erli@ifi.uio.no>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: kernel panics..
References: <19980527002414.A3954@puck.nether.net> <xzp3edvkd3b.fsf@gjallarhorn.ifi.uio.no>
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 <jared@puck.nether.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <mike@smith.net.au>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
"freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>
Subject: Re: DPT Redux
In-reply-to: Your message of "Mon, 01 Jun 1998 21:21:13 EDT."
<XFMail.980601212113.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 02 Jun 1998 10:07:18 -0700
From: Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <hetzels@westbend.net>
cc: "Mike Smith" <mike@smith.net.au>, 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 <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> From: Mike Smith <mike@smith.net.au>
>
> >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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980602171305.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Mike Smith <mike@smith.net.au>
Subject: Re: DPT Redux
Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
"freebsd-current@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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <street@iname.com>
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
<panic>
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 <Address 0xf446b000 out of bounds>, length=512, chan=2)
at ../../i386/isa/isa.c:900
#3 0xf01abe26 in isa_dmastart (flags=537919504,
addr=0xf446b000 <Address 0xf446b000 out of bounds>, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <KYYT59H8>; Tue, 2 Jun 1998 18:12:38 -0400
Message-ID: <509A2986E5C5D111B7DD0060082F32A402FB1D@freya.circle.net>
From: tcobb <tcobb@staff.circle.net>
To: "'shimon@simon-shapiro.org'" <shimon@simon-shapiro.org>,
Mike Smith
<mike@smith.net.au>
Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
"freebsd-current@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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <SAA27605-Harlan.Stenn@pfcs.com> for <current@freebsd.org>;
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 <PAA18777-harlan@pfcs.com> for <current@freebsd.org>;
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 <SAA26696-harlan@pfcs.com> for <current@freebsd.org>;
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<m88'RZQA.<2]zo&R
I8nHuPumSNjsAN&WGhll?v}1#%)~2%QI~4Vs%IuWb#OmZmKck_1Ee&C\k&vJ}BWx:Bb#Mx8>: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 <Harlan.Stenn@pfcs.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <jb@cimlogic.com.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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: <Pine.OSF.3.90.980602235448.19167A-100000@bragg>
References: <Pine.OSF.3.90.980602235448.19167A-100000@bragg>
Organization: Polstra & Co., Seattle, WA
Cc: current@FreeBSD.ORG
Date: Tue, 02 Jun 1998 17:43:00 -0700
From: John Polstra <jdp@polstra.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <Pine.OSF.3.90.980602235448.19167A-100000@bragg>,
Kris Kennaway <kkennawa@physics.adelaide.edu.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <hetzels@westbend.net>
To: "Mike Smith" <mike@smith.net.au>
Cc: <current@FreeBSD.ORG>
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 <mike@smith.net.au>
>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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <joelh@gnu.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Tue, 2 Jun 1998 21:05:35 -0400 (EDT)
Date: Tue, 2 Jun 1998 21:05:25 -0400 (EDT)
From: Brandon Lockhart <brandon@engulf.net>
To: current@FreeBSD.ORG
Subject: Let me guess...
Message-ID: <Pine.BSF.3.96.980602210424.3639A-100000@engulf.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <FreeBSD-current@FreeBSD.org>; 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 <FreeBSD-current@FreeBSD.org>; Wed, 3 Jun 1998 10:11:26 +0700 (NSS)
Date: Wed, 3 Jun 1998 10:11:26 +0700 (NSS)
From: Ustimenko Semen <semen@iclub.nsu.ru>
To: FreeBSD-current@FreeBSD.ORG
Subject: volonteers need to test tx driver :-)
Message-ID: <Pine.BSF.3.96.980603100249.20905B-300000@iclub.nsu.ru>
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: <Pine.BSF.3.96.980603101126.20905C@iclub.nsu.ru>
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: <Pine.BSF.3.96.980603101126.20905D@iclub.nsu.ru>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <grog@lemis.com>
To: shimon@simon-shapiro.org, Mike Smith <mike@smith.net.au>
Cc: Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Subject: Re: DPT driver fails and panics with Degraded Array
References: <199805292208.PAA01191@dingo.cdrom.com> <XFMail.980601205151.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <XFMail.980601205151.shimon@simon-shapiro.org>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <locke@mcs.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <rnordier@nordier.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Harlan Stenn <Harlan.Stenn@pfcs.com>, 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <kushn@mail.kar.net>
X-Sender: volodya@kushnir.kiev.ua
Reply-To: Vladimir Kushnir <kushn@mail.kar.net>
To: freebsd-current@FreeBSD.ORG
Subject: modload doesn't work when OBJFORMAT=elf?
Message-ID: <Pine.BSF.3.96.980603121722.269A-100000@kushnir.kiev.ua>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
cc: Harlan Stenn <Harlan.Stenn@pfcs.com>, 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 <dima@tejblum.dnttm.rssi.ru>
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 <stdio.h>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Vladimir Kushnir <kushn@mail.kar.net>, freebsd-current@FreeBSD.ORG
Subject: Re: modload doesn't work when OBJFORMAT=elf?
References: <Pine.BSF.3.96.980603121722.269A-100000@kushnir.kiev.ua>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <Pine.BSF.3.96.980603121722.269A-100000@kushnir.kiev.ua>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bob@pmr.com>
To: Greg Lehey <grog@lemis.com>, shimon@simon-shapiro.org,
Mike Smith <mike@smith.net.au>
Cc: Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Subject: Re: DPT driver fails and panics with Degraded Array
Reply-To: Bob Willcox <bob@luke.pmr.com>
References: <199805292208.PAA01191@dingo.cdrom.com> <XFMail.980601205151.shimon@simon-shapiro.org> <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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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" <ken@plutotech.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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: <Pine.BSF.3.96.980603121722.269A-100000@kushnir.kiev.ua> <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 <jdp@polstra.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <19980603132737.53379@follo.net>,
Eivind Eklund <eivind@yes.no> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <ckempf@singularity.enigami.com>
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: <x7vhqixrge.fsf_-_@singularity.enigami.com>
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: <http://www.enigami.com/~ckempf/chipmerchant.html>
Cory Kempf Macintosh / Unix Consulting & Software Development
ckempf@enigami.com <http://www.enigami.com/~ckempf/>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <bob@luke.pmr.com>
cc: Greg Lehey <grog@lemis.com>, shimon@simon-shapiro.org,
Mike Smith <mike@smith.net.au>, Karl Pielorz <kpielorz@tdx.co.uk>,
tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Cory Kempf <ckempf@singularity.enigami.com>, freebsd-current@FreeBSD.ORG
Subject: Re: trimdomain?
References: <x7vhqixrge.fsf_-_@singularity.enigami.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <x7vhqixrge.fsf_-_@singularity.enigami.com>; 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 <amurai@FreeBSD.ORG> -----
From: Atsushi Murai <amurai@FreeBSD.ORG>
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 <amurai@spec.co.jp>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Wed, 3 Jun 1998 17:15:31 -0400 (EDT)
Date: Wed, 3 Jun 1998 17:15:18 -0400 (EDT)
From: Brandon Lockhart <brandon@engulf.net>
To: current@FreeBSD.ORG
Subject: ppp libalias
Message-ID: <Pine.BSF.3.96.980603171448.11284A-100000@engulf.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <freebsd-current@freebsd.org>; 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <eivind@yes.no>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <root@bmccane.maxbaud.net>
To: current@FreeBSD.ORG
Subject: softupdate panics
Message-ID: <Pine.BSF.3.96.980603181725.7103A-100000@bmccane>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <pierre.dampure@k2c.co.uk>
To: "Brandon Lockhart" <brandon@engulf.net>, <current@FreeBSD.ORG>
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 <brandon@engulf.net>
To: current@FreeBSD.ORG <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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Terry Lambert <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <grog@lemis.com>
To: Mike Smith <mike@smith.net.au>, Bob Willcox <bob@luke.pmr.com>
Cc: shimon@simon-shapiro.org, Karl Pielorz <kpielorz@tdx.co.uk>,
tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <dyson@FreeBSD.ORG>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <grog@lemis.com>
cc: Mike Smith <mike@smith.net.au>, Bob Willcox <bob@luke.pmr.com>,
shimon@simon-shapiro.org, Karl Pielorz <kpielorz@tdx.co.uk>,
tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <eivind@yes.no>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <wollman@khavrinen.lcs.mit.edu>
Message-Id: <199806040300.XAA02003@khavrinen.lcs.mit.edu>
To: Eivind Eklund <eivind@yes.no>
Cc: Terry Lambert <tlambert@primenet.com>, 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
<<On Thu, 4 Jun 1998 02:18:16 +0200, Eivind Eklund <eivind@yes.no> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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" <jkh@time.cdrom.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <current@FreeBSD.ORG>; 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" <straka@home.com>
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 <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>
#include <signal.h>
#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<NITER;i++) {
timelast.tv_sec = time.tv_sec;
timelast.tv_usec = time.tv_usec;
sigsuspend(&sigmask);
gettimeofday(&time, NULL);
dt = (time.tv_sec-timelast.tv_sec)*1000000 +
(time.tv_usec-timelast.tv_usec);
dtstore[i] = dt;
}
for(i=0;i<NITER;i++) printf("%d\n",dtstore[i]);
}
void sighandler()
{
}
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:53:59 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <straka@home.com>
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 <phk@critter.freebsd.dk>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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" <straka@home.com>
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 <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980604120046.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Greg Lehey <grog@lemis.com>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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!!! <osa@unibest.ru>
X-Sender: osa@hole.etrust.ru
To: FreeBSD-current mail-list <freebsd-current@FreeBSD.ORG>
Subject: Strange in vi ??? or UFS ???
Message-ID: <Pine.BSF.3.96.980604185544.326A-100000@hole.etrust.ru>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980604121230.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Bob Willcox <bob@luke.pmr.com>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>, Greg Lehey <grog@lemis.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980604121635.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Greg Lehey <grog@lemis.com>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Bob Willcox <bob@luke.pmr.com>, Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980604121944.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: Mike Smith <mike@smith.net.au>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Bob Willcox <bob@luke.pmr.com>, Greg Lehey <grog@lemis.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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: <XFMail.980604122609.shimon@simon-shapiro.org>
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 <shimon@simon-shapiro.org>
To: tcobb <tcobb@staff.circle.net>
Subject: RE: DPT Redux
Cc: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
"freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG>,
Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <jdp@polstra.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <199806021711.KAA01018@antipodes.cdrom.com>,
Mike Smith <mike@smith.net.au> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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: <Pine.BSF.3.96.980603171448.11284A-100000@engulf.net>
References: <Pine.BSF.3.96.980603171448.11284A-100000@engulf.net>
Organization: Polstra & Co., Seattle, WA
Cc: current@FreeBSD.ORG
Date: Thu, 04 Jun 1998 09:05:57 -0700
From: John Polstra <jdp@polstra.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <Pine.BSF.3.96.980603171448.11284A-100000@engulf.net>,
Brandon Lockhart <brandon@engulf.net> 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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; 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 <root@pozo.com>
To: current@FreeBSD.ORG
Subject: libalias in ppp
Message-ID: <Pine.BSF.3.96.980604090607.829A-100000@pozo.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <toasty@home.dragondata.com>
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
<snip out about 500 of these>
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
<another huge snip>
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
<another big snip>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <syko@starix.net>
To: Ozz!!! <osa@unibest.ru>
cc: FreeBSD-current mail-list <freebsd-current@FreeBSD.ORG>
Subject: Re: Strange in vi ??? or UFS ???
In-Reply-To: <Pine.BSF.3.96.980604185544.326A-100000@hole.etrust.ru>
Message-ID: <Pine.LNX.3.95.980604132123.2817A-100000@vortex.starix.net>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@freebsd.org>; 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 <mark@grondar.za>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Thu, 4 Jun 1998 14:33:19 -0400 (EDT)
Date: Thu, 4 Jun 1998 14:33:18 -0400 (EDT)
From: Brandon Lockhart <brandon@engulf.net>
To: current@FreeBSD.ORG
Subject: More current PPP problems...
Message-ID: <Pine.BSF.3.96.980604141645.16179A-100000@engulf.net>
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: <My Password>"
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: <owner-freebsd-current@FreeBSD.ORG>
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 <freebsd-current@FreeBSD.ORG>; 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 <mike@smith.net.au>, Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Bob Willcox <bob@luke.pmr.com>, Greg Lehey <grog@lemis.com>
Subject: Re: DPT driver fails and panics with Degraded Array
In-reply-to: Your message of "Thu, 04 Jun 1998 12:19:44 EDT."
<XFMail.980604121944.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 Jun 1998 10:41:23 -0700
From: Mike Smith <mike@smith.net.au>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@freebsd.org>; 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 <current@freebsd.org>; Thu, 4 Jun 1998 15:31:52 -0400 (EDT)
Date: Thu, 4 Jun 1998 15:31:32 -0400 (EDT)
From: Brandon Lockhart <brandon@engulf.net>
To: current@FreeBSD.ORG
Subject: More current PPP problems...
Message-ID: <Pine.BSF.3.96.980604153034.17280A-100000@engulf.net>
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: <My Password>"
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <eivind@yes.no>
To: Terry Lambert <tlambert@primenet.com>,
Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <joelh@gnu.org>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <tlambert@primenet.com>
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: <owner-freebsd-current@FreeBSD.ORG>
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 <current@FreeBSD.ORG>; 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 <current@FreeBSD.ORG>; 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: <xzpiumg97ee.fsf@hrotti.ifi.uio.no>
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 <label> dials, then segfaults as it changes
from dialing mode to login mode. The problems disappeared when I
rewrote my ppp.conf file.
Here are the log messages from three consecutive attempts:
Jun 4 22:31:18 niobe ppp[866]: Phase: Using interface: tun0
Jun 4 22:31:18 niobe ppp[866]: Phase: deflink: Created in closed state
Jun 4 22:31:18 niobe ppp[866]: Phase: bundle: Establish
Jun 4 22:31:18 niobe ppp[866]: Phase: deflink: closed -> opening
Jun 4 22:31:18 niobe ppp[866]: Phase: PPP Started (interactive mode).
Jun 4 22:31:18 niobe ppp[866]: Phase: deflink: Connected!
Jun 4 22:31:18 niobe ppp[866]: Phase: deflink: opening -> dial
Jun 4 22:31:18 niobe ppp[866]: Phase: Phone: 22596790
Jun 4 22:31:34 niobe ppp[866]: Phase: deflink: dial -> login
Jun 4 22:32:21 niobe ppp[870]: Phase: Using interface: tun0
Jun 4 22:32:21 niobe ppp[870]: Phase: deflink: Created in closed state
Jun 4 22:32:21 niobe ppp[870]: Phase: bundle: Establish
Jun 4 22:32:21 niobe ppp[870]: Phase: deflink: closed -> opening
Jun 4 22:32:21 niobe ppp[870]: Phase: PPP Started (interactive mode).
Jun 4 22:32:21 niobe ppp[870]: Phase: deflink: Connected!
Jun 4 22:32:21 niobe ppp[870]: Phase: deflink: opening -> dial
Jun 4 22:32:21 niobe ppp[870]: Phase: Phone: 22596790
Jun 4 22:32:37 niobe ppp[870]: Phase: deflink: dial -> login
Here's what gdb says about the core dump (had to recompile ppp with
-ggdb to get this - is there any option to the standard makefiles
which prevents install from stripping binaries? -DNOSTRIP ostl)
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 `ppp'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/libexec/ld.so...done.
Reading symbols from /usr/lib/aout/libutil.so.2.2...done.
Reading symbols from /usr/lib/aout/libz.so.2.0...done.
Reading symbols from /usr/lib/aout/libcrypt.so.2.0...done.
Reading symbols from /usr/lib/aout/libc.so.3.1...done.
Reading symbols from /usr/lib/libalias.so.2.5...done.
#0 0x7255 in chat_UpdateSet (d=0x4a01c, r=0xefbfdb48, w=0xefbfdac8,
e=0xefbfda48, n=0xefbfda44) at /usr/src/usr.sbin/ppp/chat.c:207
207 needcr = c->state == CHAT_SEND && *c->argptr != '!';
(gdb) l
202 * c->argptr now temporarily points into c->script (via c->argv)
203 * If it's an expect-send-expect sequence, we've just got the correct
204 * portion of that sequence.
205 */
206
207 needcr = c->state == CHAT_SEND && *c->argptr != '!';
208
209 /* We leave room for a potential HDLC header in the target string */
210 ExpandString(c, c->argptr, c->exp + 2, sizeof c->exp - 2, needcr);
211
(gdb) bt
#0 0x7255 in chat_UpdateSet (d=0x4a01c, r=0xefbfdb48, w=0xefbfdac8,
e=0xefbfda48, n=0xefbfda44) at /usr/src/usr.sbin/ppp/chat.c:207
#1 0xe6bf in datalink_UpdateSet (d=0x4a000, r=0xefbfdb48, w=0xefbfdac8,
e=0xefbfda48, n=0xefbfda44) at /usr/src/usr.sbin/ppp/datalink.c:264
#2 0x2d46 in bundle_UpdateSet (d=0x2f18c, r=0xefbfdb48, w=0xefbfdac8,
e=0xefbfda48, n=0xefbfda44) at /usr/src/usr.sbin/ppp/bundle.c:486
#3 0x1d0b9 in DoLoop (bundle=0x2f18c) at /usr/src/usr.sbin/ppp/main.c:451
#4 0x1cf71 in main (argc=2, argv=0xefbfdcf4)
at /usr/src/usr.sbin/ppp/main.c:432
(gdb) i args
d = (struct descriptor *) 0x4a01c
r = (fd_set *) 0xefbfdb48
w = (fd_set *) 0xefbfdac8
e = (fd_set *) 0xefbfda48
n = (int *) 0xefbfda44
(gdb) quit
The contents of ppp.conf and ppp.linkup follow (yes, I know ppp.conf
is slightly bogus, but it worked fine on 2.2.6 and on 3.0-SNAP from
1998-02-22):
(ppp.conf)
default:
set device /dev/cuaa0
set speed 115200
set ctsrts on
disable lqr
deny lqr
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATZ OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT"
alias enable yes
usit:
allow users finrod dagsm
set phone 22596790
accept pap
set authname undiclosed
set authkey undisclosed
set login "TIMEOUT 5 name:-\\r-name:"
set timeout 600
set openmode active
dial
(ppp.linkup)
MYADDR:
delete ALL
add 0 0 HISADDR
I rewrote ppp.conf from scratch (or rather, from a recent version of
ppp.conf.sample):
default:
allow user finrod
alias enable yes
set log Phase Chat Connect Carrier LCP IPCP CCP tun command
set device /dev/cuaa0
set speed 115200
set ctsrts on
deny lqr
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
usit:
set phone 22596790
accept pap
set login
set authname undisclosed
set authkey undisclosed
set timeout 120
set ifaddr 0 0
dial
--
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 Thu Jun 4 14:40:55 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id OAA15242
for freebsd-current-outgoing; Thu, 4 Jun 1998 14:40:55 -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 OAA15183
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 14:40:42 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp01.primenet.com (8.8.8/8.8.8) id OAA26381;
Thu, 4 Jun 1998 14:40:40 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp01.primenet.com, id smtpd026330; Thu Jun 4 14:40:34 1998
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id OAA13434;
Thu, 4 Jun 1998 14:40:29 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199806042140.OAA13434@usr08.primenet.com>
Subject: Re: I see one major problem with DEVFS...
To: eivind@yes.no (Eivind Eklund)
Date: Thu, 4 Jun 1998 21:40:29 +0000 (GMT)
Cc: tlambert@primenet.com, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG
In-Reply-To: <19980604214541.64381@follo.net> from "Eivind Eklund" at Jun 4, 98 09:45:41 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
> > 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
OK...
> without doing large changes compared to the present source.
This is one of those sacred cows I was talking about...
ELF is going to get us part way there, and it's a "large change
relative to the current way things are".
The big issue here is *only* the boot blocks, since aggregation
is a matter of "what is default in the kernel" and "what objects
are linked into the 'installed' subdirectory from the 'available'
subdirectory".
A secondardy issue comes into play *only* if you want to dictate
the ability to change the agregation of a post-linked kernel. I
personally feel that this is a worthwhile goal, even though it
means that you must place discrete drivers into discrete ELF
sections so that an image archiver can insert or extract them at
will.
If there's a "config" after this point, it's a UI to toggle hard
links and an ELF image archiver interface to be called when the
user selects "create a custom kernel".
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 15:08:09 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id PAA19993
for freebsd-current-outgoing; Thu, 4 Jun 1998 15:08:09 -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 PAA19947
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 15:08:03 -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 WAA12423;
Thu, 4 Jun 1998 22:07:59 GMT
Received: (from eivind@localhost)
by bitbox.follo.net (8.8.8/8.8.6) id AAA21128;
Fri, 5 Jun 1998 00:07:27 +0200 (MET DST)
Message-ID: <19980605000726.58908@follo.net>
Date: Fri, 5 Jun 1998 00:07:26 +0200
From: Eivind Eklund <eivind@yes.no>
To: Terry Lambert <tlambert@primenet.com>
Cc: current@FreeBSD.ORG
Subject: Re: I see one major problem with DEVFS...
References: <19980604214541.64381@follo.net> <199806042140.OAA13434@usr08.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
In-Reply-To: <199806042140.OAA13434@usr08.primenet.com>; from Terry Lambert on Thu, Jun 04, 1998 at 09:40:29PM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Thu, Jun 04, 1998 at 09:40:29PM +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
>
> OK...
>
> > without doing large changes compared to the present source.
>
> This is one of those sacred cows I was talking about...
>
>
> ELF is going to get us part way there, and it's a "large change
> relative to the current way things are".
Not in kernel terms. It has impact in a relatively limited number of
places.
> The big issue here is *only* the boot blocks, since aggregation
> is a matter of "what is default in the kernel" and "what objects
> are linked into the 'installed' subdirectory from the 'available'
> subdirectory".
This is just plain wrong. If you want to get rid of config, you got
to move the functions it presently handle somewhere else, and
eliminate the blocks to using pure aggregation one by one.
I gave you a list of about 10 things that have to be fixed before we
can get rid of config (or something else that basically do the
function of config, including separate compilation with differing
defines).
If you have some other way of handling those issues, that's fine - but
they have to be handled! And believe me, I'd like to have a system
that didn't need config, too - I just don't believe it can happen
without somebody putting down a lot of work towards that end,
ruthlessly eliminating obstacle by obstacle.
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 15:29:24 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id PAA23650
for freebsd-current-outgoing; Thu, 4 Jun 1998 15:29:24 -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 PAA23603
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 15:29:15 -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 IAA23654;
Fri, 5 Jun 1998 08:29:11 +1000
Date: Fri, 5 Jun 1998 08:29:11 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199806042229.IAA23654@godzilla.zeta.org.au>
To: current@FreeBSD.ORG, straka@home.com
Subject: Re: strange behavior with signal latencies
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
>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.
The results show no signs of latency with -current on a P5/133 here.
This should be relatively easy to debug - just find whatever is causing
the abnormal interrupt load. I suspect it is an interrupt handler looping.
Bruce
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 15:31:08 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id PAA24158
for freebsd-current-outgoing; Thu, 4 Jun 1998 15:31:08 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23915;
Thu, 4 Jun 1998 15:30:14 -0700 (PDT)
(envelope-from se@dialup124.zpr.uni-koeln.de)
Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124])
by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id AAA29556;
Fri, 5 Jun 1998 00:29:41 +0200 (MET DST)
Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id AAA01002; Fri, 5 Jun 1998 00:01:02 +0200 (CEST)
X-Face: "<d]#=8pzx);RzeqSKI86OVa7=!0/(uRa.+B.9Z9\eNUn@UG?!`y7yt2dFNn%k4'.}](uE%
yCO)$e&Y1%3EO~ifu6Q-#YUM&JZ't,}JkPnAz,8Dj33u%@GBi%[Y#LHz$]h7a<p4)-jKI7~sKjlP-^
EvA[G;]v&0]W!EL%shs,{7x0|oqN4YVIs5,NI#,V{9"WF):5&RkOhyj*#-IAG}Tnu;YCF,d
Message-ID: <19980605000101.27550@mi.uni-koeln.de>
Date: Fri, 5 Jun 1998 00:01:01 +0200
From: Stefan Esser <se@FreeBSD.ORG>
To: shimon@simon-shapiro.org, Bob Willcox <bob@luke.pmr.com>
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>, Greg Lehey <grog@lemis.com>,
Stefan Esser <se@FreeBSD.ORG>
Subject: Re: DPT driver fails and panics with Degraded Array
Mail-Followup-To: shimon@simon-shapiro.org, Bob Willcox <bob@luke.pmr.com>,
Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>, Greg Lehey <grog@lemis.com>,
Stefan Esser <se@freebsd.org>
References: <19980603073200.A16652@pmr.com> <XFMail.980604121230.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89i
In-Reply-To: <XFMail.980604121230.shimon@simon-shapiro.org>; from Simon Shapiro on Thu, Jun 04, 1998 at 12:12:30PM -0400
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 1998-06-04 12:12 -0400, Simon Shapiro <shimon@simon-shapiro.org> wrote:
> 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.
This is a design "feature" of PCI, actually, and well documented.
The interrupt lines are directly connected to the chip-set (or
possibly the CPU in non-Intel PCI systems) and for that reason,
there may for example be as many outstanding memory writes in
write-buffers as their FIFO depths allow, when the end-of-transfer
interrupt is recognized by the CPU.
There is a documented protocol to flush all write buffers: Just
read some device register at the start of the interrupt handler
(i.e. before trying to access common data structures in memory,
that are used for communication between CPU and an intelligent
device). The read will be blocked until all buffers are flushed.
> 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.
Is this really necessary with certain revisions of the DPT
firmware ? Reading a device register should delay just for
the minimum time required. Did you try that ?
Regards, STefan
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 17:02:31 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id RAA12139
for freebsd-current-outgoing; Thu, 4 Jun 1998 17:02:31 -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 RAA11972
for <freebsd-current@FreeBSD.ORG>; Thu, 4 Jun 1998 17:01:29 -0700 (PDT)
(envelope-from grog@freebie.lemis.com)
Received: (from grog@localhost)
by freebie.lemis.com (8.9.0/8.9.0) id JAA02078;
Fri, 5 Jun 1998 09:30:46 +0930 (CST)
Message-ID: <19980605093046.J768@freebie.lemis.com>
Date: Fri, 5 Jun 1998 09:30:46 +0930
From: Greg Lehey <grog@lemis.com>
To: shimon@simon-shapiro.org
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>
Subject: Re: DPT driver fails and panics with Degraded Array
References: <19980603125443.K22406@freebie.lemis.com> <XFMail.980604120046.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <XFMail.980604120046.shimon@simon-shapiro.org>; from Simon Shapiro on Thu, Jun 04, 1998 at 12:00:46PM -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
X-Mutt-References: <XFMail.980604120046.shimon@simon-shapiro.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Thu, 4 June 1998 at 12:00:46 -0400, Simon Shapiro wrote:
>
> 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.
That in itself is normal enough. How come it's not 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.
>>
>> Definitely. I'm surprised nobody has done it yet.
>
> I posted some notes on this issue several months ago, with no response.
Sorry, I've been too busy with my own stuff...
>>> 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.
I don't know the driver, but I'm surprised you need to maintain
separate information. I'd use the state in the bp->b_flags.
> 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 haven't seen a driver called st.c in CAM. They've changed the
names, and the tape driver is now called scsi_sa.c. st.c is the old
tape driver. How do you determine "greatest sensitivity"?
In any case, I can't see how a different driver can influence things.
Heavy tape I/O may help the problem to show itself, but I can't think
it's in any way to blame.
>> 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?
Occasionally.
> 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?
Well, I suppose each of the controllers could generate a number of
interrupts per second, so sooner or later that scenario would arise.
But as I said above, there's nothing to point to the st driver except
it's the new kid on the block. What you have said points fairly and
squarely to the DPT driver as the culprit.
> 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.
OK. What happens if you analyse the buffer header before calling
biodone and just ignore it if it's not busy?
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 Thu Jun 4 17:05:05 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id RAA12694
for freebsd-current-outgoing; Thu, 4 Jun 1998 17:05:05 -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 RAA12524
for <freebsd-current@FreeBSD.ORG>; Thu, 4 Jun 1998 17:04:21 -0700 (PDT)
(envelope-from grog@freebie.lemis.com)
Received: (from grog@localhost)
by freebie.lemis.com (8.9.0/8.9.0) id JAA02086;
Fri, 5 Jun 1998 09:33:49 +0930 (CST)
Message-ID: <19980605093349.K768@freebie.lemis.com>
Date: Fri, 5 Jun 1998 09:33:49 +0930
From: Greg Lehey <grog@lemis.com>
To: shimon@simon-shapiro.org
Cc: Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Bob Willcox <bob@luke.pmr.com>, Mike Smith <mike@smith.net.au>
Subject: Re: DPT driver fails and panics with Degraded Array
References: <19980604095717.A22406@freebie.lemis.com> <XFMail.980604121635.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <XFMail.980604121635.shimon@simon-shapiro.org>; from Simon Shapiro on Thu, Jun 04, 1998 at 12:16:35PM -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 Thu, 4 June 1998 at 12:16:35 -0400, Simon Shapiro wrote:
>
> 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.
Good to hear.
> Actually, SMP interrupt service is slow enough that this probably never has
> a chance to show at all.
No way. Murphy is particularly unforgiving when it comes to race
conditions in interrupt handlers. Have 50 interrupts a second from
two processors, and sooner or later you're going to hit it.
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 Thu Jun 4 17:58:52 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id RAA23088
for freebsd-current-outgoing; Thu, 4 Jun 1998 17:58:52 -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 RAA23008;
Thu, 4 Jun 1998 17:58:19 -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 QAA02937;
Thu, 4 Jun 1998 16:53:30 -0700 (PDT)
Message-Id: <199806042353.QAA02937@dingo.cdrom.com>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Stefan Esser <se@FreeBSD.ORG>
cc: shimon@simon-shapiro.org, Bob Willcox <bob@luke.pmr.com>,
Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>, Greg Lehey <grog@lemis.com>
Subject: Re: DPT driver fails and panics with Degraded Array
In-reply-to: Your message of "Fri, 05 Jun 1998 00:01:01 +0200."
<19980605000101.27550@mi.uni-koeln.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 Jun 1998 16:53:30 -0700
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> On 1998-06-04 12:12 -0400, Simon Shapiro <shimon@simon-shapiro.org> wrote:
> > 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.
>
> This is a design "feature" of PCI, actually, and well documented.
>
> The interrupt lines are directly connected to the chip-set (or
> possibly the CPU in non-Intel PCI systems) and for that reason,
> there may for example be as many outstanding memory writes in
> write-buffers as their FIFO depths allow, when the end-of-transfer
> interrupt is recognized by the CPU.
In case the clarification is of use; the idea here is that interrupt
handlers will have some overhead, and the interrupt handler can be
starting before the device's other activities have finished.
Synchronisation is then performed as Stefan describes at the last moment
to maximise concurrency.
--
\\ 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 19:22:55 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id TAA06567
for freebsd-current-outgoing; Thu, 4 Jun 1998 19:22:55 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA06552
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 19:22:43 -0700 (PDT)
(envelope-from luoqi@lor.watermarkgroup.com)
Received: (from luoqi@localhost)
by lor.watermarkgroup.com (8.8.8/8.8.8) id WAA15564;
Thu, 4 Jun 1998 22:21:30 -0400 (EDT)
(envelope-from luoqi)
Date: Thu, 4 Jun 1998 22:21:30 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <199806050221.WAA15564@lor.watermarkgroup.com>
To: brandon@engulf.net, jdp@polstra.com
Subject: Re: ppp libalias
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> Brandon Lockhart <brandon@engulf.net> 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".
I don't see any compelling reason why dynamic loading is really needed.
IMHO, this is just a bad programming practice.
> --
> John Polstra jdp@polstra.com
> John D. Polstra & Co., Inc. Seattle, Washington USA
> "Self-knowledge is always bad news." -- John Barth
-lq
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 22:46:41 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id WAA07824
for freebsd-current-outgoing; Thu, 4 Jun 1998 22:46:41 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.125.27.73])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA07802
for <current@freebsd.org>; Thu, 4 Jun 1998 22:46:34 -0700 (PDT)
(envelope-from ache@lsd.relcom.eu.net)
Received: (from ache@localhost)
by lsd.relcom.eu.net (8.8.8/8.8.8) id JAA03159;
Fri, 5 Jun 1998 09:46:29 +0400 (MSD)
(envelope-from ache)
Message-ID: <19980605094628.A1232@nagual.pp.ru>
Date: Fri, 5 Jun 1998 09:46:28 +0400
From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: current@FreeBSD.ORG
Subject: lorder problem: aout vs. elf
Mail-Followup-To: current@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
Organization: Biomechanoid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
lorder.sh have hardcoded /usr/bin in PATH so can't find 'nm'
I see no easy way to determine aout / elf building system from shell
script to find proper path for 'nm'
--
Andrey A. Chernov
http://www.nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
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 23:07:32 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA12266
for freebsd-current-outgoing; Thu, 4 Jun 1998 23:07:32 -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 XAA12201
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 23:07:05 -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 OAA28813;
Fri, 5 Jun 1998 14:06:27 +0800 (WST)
(envelope-from peter@spinner.netplex.com.au)
Message-Id: <199806050606.OAA28813@spinner.netplex.com.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: John Polstra <jdp@polstra.com>
cc: mike@smith.net.au, current@FreeBSD.ORG
Subject: Re: ppp cannot find libalias
In-reply-to: Your message of "Thu, 04 Jun 1998 08:58:52 MST."
<199806041558.IAA03951@austin.polstra.com>
Date: Fri, 05 Jun 1998 14:06:26 +0800
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
John Polstra wrote:
> In article <199806021711.KAA01018@antipodes.cdrom.com>,
> Mike Smith <mike@smith.net.au> 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.
It's the way it happens in SVR4/386. I was suprised that we were not
doing this already.
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
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 23:20:40 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA14969
for freebsd-current-outgoing; Thu, 4 Jun 1998 23:20:40 -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 XAA14949;
Thu, 4 Jun 1998 23:20: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 OAA28939;
Fri, 5 Jun 1998 14:20:29 +0800 (WST)
(envelope-from peter@spinner.netplex.com.au)
Message-Id: <199806050620.OAA28939@spinner.netplex.com.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: dyson@FreeBSD.ORG
cc: eivind@yes.no (Eivind Eklund), current@FreeBSD.ORG
Subject: Re: Odd VM behaviour
In-reply-to: Your message of "Wed, 03 Jun 1998 19:30:15 EST."
<199806040030.TAA00603@dyson.iquest.net>
Date: Fri, 05 Jun 1998 14:20:29 +0800
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
"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.
I've seen it too. What I find odd is that there is so much intense paging
supposedly just to free the address space. I'm curious why it pages in
anything (much) just to free it all up. :-) A kill -9 doesn't cause any
execution, so it shouldn't be the result of signal handlers firing up and
paging data in etc.
Of course, if the paging is a result of trying to free up space for
temporary VM tables etc, then maybe that's different - but it still seems
awfully big.
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
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 23:33:33 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA16913
for freebsd-current-outgoing; Thu, 4 Jun 1998 23:33:33 -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 XAA16889
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 23:33:17 -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 OAA29086;
Fri, 5 Jun 1998 14:32:50 +0800 (WST)
(envelope-from peter@spinner.netplex.com.au)
Message-Id: <199806050632.OAA29086@spinner.netplex.com.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf
In-reply-to: Your message of "Fri, 05 Jun 1998 09:46:28 +0400."
<19980605094628.A1232@nagual.pp.ru>
Date: Fri, 05 Jun 1998 14:32:49 +0800
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= wrote:
> lorder.sh have hardcoded /usr/bin in PATH so can't find 'nm'
>
> I see no easy way to determine aout / elf building system from shell
> script to find proper path for 'nm'
I have been using something along the lines of this:
Index: lorder.sh
===================================================================
RCS file: /home/ncvs/src/usr.bin/lorder/lorder.sh,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 lorder.sh
--- lorder.sh 1994/05/27 12:32:05 1.1.1.1
+++ lorder.sh 1998/06/05 06:22:06
@@ -37,6 +37,17 @@
PATH=/bin:/usr/bin
export PATH
+NMARGS=""
+
+if [ "x$1" = "x-elf" ]; then
+ NMARGS="-elf"
+ shift
+fi
+if [ "x$1" = "x-aout" ]; then
+ NMARGS="-aout"
+ shift
+fi
+
# only one argument is a special case, just output the name twice
case $# in
0)
@@ -62,7 +73,7 @@
#
# if the line has " U " it's a globally undefined symbol, put it into
# the reference file.
-nm -go $* | sed "
+nm ${NMARGS} -go $* sed "
/:$/ {
s/://
s/.*/& &/
However, I am very with it and the other places where I've had to do this,
such as install. I was considering a couple tweaks to the wrappers to do
auto detection of formats. Things like size, nm, strip, strings, etc can
look at their files to see what format they are.
This was the nice thing about having the binutils stuff reading a.out, it
didn't matter what sort of file a utility was give, it just worked. (or
didn't, as the case may be with the stale a.out binutils support.)
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
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 23:36:18 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA17287
for freebsd-current-outgoing; Thu, 4 Jun 1998 23:36:18 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from antipodes.cdrom.com (castles187.castles.com [208.214.165.187])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17221
for <current@FreeBSD.ORG>; Thu, 4 Jun 1998 23:35:58 -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 WAA00495;
Thu, 4 Jun 1998 22:31:09 -0700 (PDT)
Message-Id: <199806050531.WAA00495@antipodes.cdrom.com>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Luoqi Chen <luoqi@watermarkgroup.com>
cc: brandon@engulf.net, jdp@polstra.com, current@FreeBSD.ORG
Subject: Re: ppp libalias
In-reply-to: Your message of "Thu, 04 Jun 1998 22:21:30 EDT."
<199806050221.WAA15564@lor.watermarkgroup.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 Jun 1998 22:31:09 -0700
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> > Brandon Lockhart <brandon@engulf.net> 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".
>
> I don't see any compelling reason why dynamic loading is really needed.
> IMHO, this is just a bad programming practice.
Plenty of good reasons, most of them related to size.
--
\\ 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 23:43:46 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA18612
for freebsd-current-outgoing; Thu, 4 Jun 1998 23:43:46 -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 XAA18582;
Thu, 4 Jun 1998 23:43:18 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id BAA00586;
Fri, 5 Jun 1998 01:43:04 -0500 (EST)
(envelope-from toor)
Message-Id: <199806050643.BAA00586@dyson.iquest.net>
Subject: Re: Odd VM behaviour
In-Reply-To: <199806050620.OAA28939@spinner.netplex.com.au> from Peter Wemm at "Jun 5, 98 02:20:29 pm"
To: peter@netplex.com.au (Peter Wemm)
Date: Fri, 5 Jun 1998 01:43:04 -0500 (EST)
Cc: dyson@FreeBSD.ORG, eivind@yes.no, current@FreeBSD.ORG
From: "John S. Dyson" <dyson@FreeBSD.ORG>
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
Peter Wemm said:
> "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.
>
> I've seen it too. What I find odd is that there is so much intense paging
> supposedly just to free the address space. I'm curious why it pages in
> anything (much) just to free it all up. :-) A kill -9 doesn't cause any
> execution, so it shouldn't be the result of signal handlers firing up and
> paging data in etc.
>
> Of course, if the paging is a result of trying to free up space for
> temporary VM tables etc, then maybe that's different - but it still seems
> awfully big.
>
There are some severe bugs in that area. While working on the improved
SMP VM stuff, I have found some more window conditions. Maybe the fixes
will help.
--
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 Thu Jun 4 23:44:45 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA18748
for freebsd-current-outgoing; Thu, 4 Jun 1998 23:44:45 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.125.27.73])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18683;
Thu, 4 Jun 1998 23:44:16 -0700 (PDT)
(envelope-from ache@lsd.relcom.eu.net)
Received: (from ache@localhost)
by lsd.relcom.eu.net (8.8.8/8.8.8) id KAA28026;
Fri, 5 Jun 1998 10:43:52 +0400 (MSD)
(envelope-from ache)
Message-ID: <19980605104351.A23931@nagual.pp.ru>
Date: Fri, 5 Jun 1998 10:43:51 +0400
From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: Peter Wemm <peter@netplex.com.au>
Cc: current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
Mail-Followup-To: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG,
ports@freebsd.org
References: <19980605094628.A1232@nagual.pp.ru> <199806050632.OAA29086@spinner.netplex.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <199806050632.OAA29086@spinner.netplex.com.au>; from peter@netplex.com.au on Fri, Jun 05, 1998 at 02:32:49PM +0800
Organization: Biomechanoid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Fri, Jun 05, 1998 at 02:32:49PM +0800, Peter Wemm wrote:
> -nm -go $* | sed "
> +nm ${NMARGS} -go $* sed "
Your patch not work since there is no 'nm' in /bin:/usr/bin hardcoded
in first line of the script.
> However, I am very with it and the other places where I've had to do this,
> such as install. I was considering a couple tweaks to the wrappers to do
> auto detection of formats. Things like size, nm, strip, strings, etc can
> look at their files to see what format they are.
I expect lots of problems with GNU Configure scripts (for ports), they
never search nm,ar,ranlib in .../aout
We must provide symlinks from
/usr/bin/xxx -> /usr/libexec/{elf or aout}/xxx
otherwise lots of ports will be broken.
> This was the nice thing about having the binutils stuff reading a.out, it
> didn't matter what sort of file a utility was give, it just worked. (or
> didn't, as the case may be with the stale a.out binutils support.)
Not reading expected but writing too (f.e. ranlib and ar), so allowing
reading not helps much.
--
Andrey A. Chernov
http://www.nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 00:36:16 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id AAA27217
for freebsd-current-outgoing; Fri, 5 Jun 1998 00:36:16 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA27184
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 00:36:11 -0700 (PDT)
(envelope-from luoqi@lor.watermarkgroup.com)
Received: (from luoqi@localhost)
by lor.watermarkgroup.com (8.8.8/8.8.8) id DAA17278;
Fri, 5 Jun 1998 03:35:36 -0400 (EDT)
(envelope-from luoqi)
Date: Fri, 5 Jun 1998 03:35:36 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <199806050735.DAA17278@lor.watermarkgroup.com>
To: mike@smith.net.au
Subject: Re: ppp libalias
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> > > Brandon Lockhart <brandon@engulf.net> 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".
> >
> > I don't see any compelling reason why dynamic loading is really needed.
> > IMHO, this is just a bad programming practice.
>
> Plenty of good reasons, most of them related to size.
Could you be more specific? I don't quite understand. The library itself
is not big, 6 pages (5 text, 1 data, excluding 4 pages of bss). If you don't
use the -alias option, text and bss will not be touched, and you will waste
1 page of data (modified by relocation). If you use the -alias option,
then the memory usage should be the same. We might end up saving some space
if the code to load and unload the library is removed and let ld.so do the
job during startup.
>
> --
> \\ 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
-lq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 01:37:46 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id BAA06319
for freebsd-current-outgoing; Fri, 5 Jun 1998 01:37:46 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.125.27.73])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06290;
Fri, 5 Jun 1998 01:37:38 -0700 (PDT)
(envelope-from ache@lsd.relcom.eu.net)
Received: (from ache@localhost)
by lsd.relcom.eu.net (8.8.8/8.8.8) id MAA23030;
Fri, 5 Jun 1998 12:37:37 +0400 (MSD)
(envelope-from ache)
Message-ID: <19980605123736.A20838@nagual.pp.ru>
Date: Fri, 5 Jun 1998 12:37:36 +0400
From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
Mail-Followup-To: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG,
ports@freebsd.org
References: <19980605094628.A1232@nagual.pp.ru> <199806050632.OAA29086@spinner.netplex.com.au> <19980605104351.A23931@nagual.pp.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.91.1i
In-Reply-To: <19980605104351.A23931@nagual.pp.ru>; from ache@nagual.pp.ru on Fri, Jun 05, 1998 at 10:43:51AM +0400
Organization: Biomechanoid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Fri, Jun 05, 1998 at 10:43:51AM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
> I expect lots of problems with GNU Configure scripts (for ports), they
> never search nm,ar,ranlib in .../aout
>
> We must provide symlinks from
> /usr/bin/xxx -> /usr/libexec/{elf or aout}/xxx
> otherwise lots of ports will be broken.
/usr/lib/libc.a (now moved to /usr/lib/aout) is also often parsed by GNU
Configure :-(
It sounds like almost every GNU Configure port should be changed to
reflect new aout subdirectories to preserve previous state. It is wrong
move indeed for elf version. It looks like libraries and /usr/bin symlinks
are only solution.
--
Andrey A. Chernov
http://www.nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 01:47:52 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id BAA08016
for freebsd-current-outgoing; Fri, 5 Jun 1998 01:47:52 -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 BAA07982
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 01:47:43 -0700 (PDT)
(envelope-from jb@cimlogic.com.au)
Received: (from jb@localhost)
by cimlogic.com.au (8.8.8/8.8.7) id SAA29998;
Fri, 5 Jun 1998 18:49:26 +1000 (EST)
(envelope-from jb)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199806050849.SAA29998@cimlogic.com.au>
Subject: Re: lorder problem: aout vs. elf
In-Reply-To: <199806050632.OAA29086@spinner.netplex.com.au> from Peter Wemm at "Jun 5, 98 02:32:49 pm"
To: peter@netplex.com.au (Peter Wemm)
Date: Fri, 5 Jun 1998 18:49:26 +1000 (EST)
Cc: ache@nagual.pp.ru, 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
Peter Wemm wrote:
> Index: lorder.sh
> ===================================================================
> RCS file: /home/ncvs/src/usr.bin/lorder/lorder.sh,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 lorder.sh
> --- lorder.sh 1994/05/27 12:32:05 1.1.1.1
> +++ lorder.sh 1998/06/05 06:22:06
> @@ -37,6 +37,17 @@
> PATH=/bin:/usr/bin
> export PATH
One of the problems with this script is that it assumes it knows best.
During a make world, the version of nm that should be executed is in
WORLDTMP. Assuming paths is not good practice.
--
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 Fri Jun 5 01:56:14 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id BAA09683
for freebsd-current-outgoing; Fri, 5 Jun 1998 01:56:14 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.125.27.73])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA09674
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 01:56:09 -0700 (PDT)
(envelope-from ache@lsd.relcom.eu.net)
Received: (from ache@localhost)
by lsd.relcom.eu.net (8.8.8/8.8.8) id MAA04894;
Fri, 5 Jun 1998 12:55:24 +0400 (MSD)
(envelope-from ache)
Message-ID: <19980605125523.A28805@nagual.pp.ru>
Date: Fri, 5 Jun 1998 12:55:23 +0400
From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: John Birrell <jb@cimlogic.com.au>, Peter Wemm <peter@netplex.com.au>
Cc: current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf
Mail-Followup-To: John Birrell <jb@cimlogic.com.au>,
Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG
References: <199806050632.OAA29086@spinner.netplex.com.au> <199806050849.SAA29998@cimlogic.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <199806050849.SAA29998@cimlogic.com.au>; from jb@cimlogic.com.au on Fri, Jun 05, 1998 at 06:49:26PM +1000
Organization: Biomechanoid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Fri, Jun 05, 1998 at 06:49:26PM +1000, John Birrell wrote:
> Peter Wemm wrote:
> > Index: lorder.sh
> > ===================================================================
> > RCS file: /home/ncvs/src/usr.bin/lorder/lorder.sh,v
> > retrieving revision 1.1.1.1
> > diff -u -r1.1.1.1 lorder.sh
> > --- lorder.sh 1994/05/27 12:32:05 1.1.1.1
> > +++ lorder.sh 1998/06/05 06:22:06
> > @@ -37,6 +37,17 @@
> > PATH=/bin:/usr/bin
> > export PATH
>
> One of the problems with this script is that it assumes it knows best.
> During a make world, the version of nm that should be executed is in
> WORLDTMP. Assuming paths is not good practice.
Even if this lines will be deleted, there is no /usr/libexec/aout in the
default PATH anycase, only /usr/bin is there. It means that users can't
call f.e. 'size' or 'strings' now. Since default PATH is hardcoded as
#define in paths.h, no simple changes possible (in some cases login.conf
or csh.cshrc PATH settings tricks are not desired).
--
Andrey A. Chernov
http://www.nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 02:03:16 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id CAA11066
for freebsd-current-outgoing; Fri, 5 Jun 1998 02:03:16 -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 CAA10930
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 02:02:44 -0700 (PDT)
(envelope-from jb@cimlogic.com.au)
Received: (from jb@localhost)
by cimlogic.com.au (8.8.8/8.8.7) id TAA00163;
Fri, 5 Jun 1998 19:04:44 +1000 (EST)
(envelope-from jb)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199806050904.TAA00163@cimlogic.com.au>
Subject: Re: lorder problem: aout vs. elf
In-Reply-To: <19980605125523.A28805@nagual.pp.ru> from "[______ ______]" at "Jun 5, 98 12:55:23 pm"
To: ache@nagual.pp.ru (=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=)
Date: Fri, 5 Jun 1998 19:04:44 +1000 (EST)
Cc: jb@cimlogic.com.au, peter@netplex.com.au, 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
[______ ______] wrote:
> Even if this lines will be deleted, there is no /usr/libexec/aout in the
> default PATH anycase, only /usr/bin is there. It means that users can't
> call f.e. 'size' or 'strings' now. Since default PATH is hardcoded as
> #define in paths.h, no simple changes possible (in some cases login.conf
> or csh.cshrc PATH settings tricks are not desired).
NetBSD uses scripts that use ${NM} and have
PATH=/bin:/usr/bin
export PATH
as a fallback in case NM doesn't evaluate to anything sensible.
This style allows the build process to define which nm it needs.
This could be applied to ports too.
--
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 Fri Jun 5 03:42:19 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id DAA23268
for freebsd-current-outgoing; Fri, 5 Jun 1998 03:42: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 DAA23225
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 03:42:05 -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 SAA00714;
Fri, 5 Jun 1998 18:41:35 +0800 (WST)
(envelope-from peter@spinner.netplex.com.au)
Message-Id: <199806051041.SAA00714@spinner.netplex.com.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: John Birrell <jb@cimlogic.com.au>, Peter Wemm <peter@netplex.com.au>,
current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf
In-reply-to: Your message of "Fri, 05 Jun 1998 12:55:23 +0400."
<19980605125523.A28805@nagual.pp.ru>
Date: Fri, 05 Jun 1998 18:41:34 +0800
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= wrote:
> On Fri, Jun 05, 1998 at 06:49:26PM +1000, John Birrell wrote:
> > Peter Wemm wrote:
> > > Index: lorder.sh
> > > ===================================================================
> > > RCS file: /home/ncvs/src/usr.bin/lorder/lorder.sh,v
> > > retrieving revision 1.1.1.1
> > > diff -u -r1.1.1.1 lorder.sh
> > > --- lorder.sh 1994/05/27 12:32:05 1.1.1.1
> > > +++ lorder.sh 1998/06/05 06:22:06
> > > @@ -37,6 +37,17 @@
> > > PATH=/bin:/usr/bin
> > > export PATH
> >
> > One of the problems with this script is that it assumes it knows best.
> > During a make world, the version of nm that should be executed is in
> > WORLDTMP. Assuming paths is not good practice.
>
> Even if this lines will be deleted, there is no /usr/libexec/aout in the
> default PATH anycase, only /usr/bin is there. It means that users can't
> call f.e. 'size' or 'strings' now. Since default PATH is hardcoded as
> #define in paths.h, no simple changes possible (in some cases login.conf
> or csh.cshrc PATH settings tricks are not desired).
Huh????? We *have* /usr/bin/{ar,nm,aout,ld,as,size,strings,strip,...},
these are links to objformat, which is a redirector to the /usr/lib/
{aout,elf} backend.
So, "/usr/bin/nm" gets the system default (either /usr/libexec/aout/nm or
/usr/libexec/elf/nm depending on the user's or system preference), while "/
usr/bin/nm -elf" forces execution of /usr/libexec/elf/nm, and the same for
-aout.
> --
> Andrey A. Chernov
> http://www.nagual.pp.ru/~ache/
> MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
>
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 03:51:54 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id DAA24398
for freebsd-current-outgoing; Fri, 5 Jun 1998 03:51:54 -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 DAA24382;
Fri, 5 Jun 1998 03:51:42 -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 SAA00749;
Fri, 5 Jun 1998 18:51:16 +0800 (WST)
(envelope-from peter@spinner.netplex.com.au)
Message-Id: <199806051051.SAA00749@spinner.netplex.com.au>
X-Mailer: exmh version 2.0.2 2/24/98
To: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-reply-to: Your message of "Fri, 05 Jun 1998 12:37:36 +0400."
<19980605123736.A20838@nagual.pp.ru>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 05 Jun 1998 18:51:15 +0800
From: Peter Wemm <peter@netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
=3D?koi8-r?B?4c7E0sXKIP7F0s7P1w=3D=3D?=3D wrote:
> On Fri, Jun 05, 1998 at 10:43:51AM +0400, =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=
=CF=D7 wrote:
> > I expect lots of problems with GNU Configure scripts (for ports), the=
y
> > never search nm,ar,ranlib in .../aout
> > =
> > We must provide symlinks from =
> > /usr/bin/xxx -> /usr/libexec/{elf or aout}/xxx
> > otherwise lots of ports will be broken.
> =
> /usr/lib/libc.a (now moved to /usr/lib/aout) is also often parsed by GN=
U
> Configure :-(
Huh?? Such as? Almost all the GNU configure scripts test for presense o=
f =
libc routines by a compile attempt. I've never seen an autoconf script =
use ar/nm.
I think you are thinking of elm, perl5 etc which use Metaconfig. *that* =
uses ar/nm/etc and you have to tell it where the library is and how to ge=
t =
a list of symbols.
> It sounds like almost every GNU Configure port should be changed to
> reflect new aout subdirectories to preserve previous state. It is wrong=
> move indeed for elf version. It looks like libraries and /usr/bin symli=
nks
> are only solution. =
As I said before, the /usr/bin paths are already there and have been sinc=
e =
day one:
peter@beast[6:50pm]~src/usr.bin/lorder-203> l -i /usr/bin | grep 8468
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 ar*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 as*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 ld*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 nm*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 objformat*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 ranlib*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 size*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 strings*
8468 5 -r-xr-xr-x 9 bin bin 4424 May 30 17:47 strip*
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 04:00:34 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id EAA25531
for freebsd-current-outgoing; Fri, 5 Jun 1998 04:00:34 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.125.27.73])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA25524
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 04:00:28 -0700 (PDT)
(envelope-from ache@lsd.relcom.eu.net)
Received: (from ache@localhost)
by lsd.relcom.eu.net (8.8.8/8.8.8) id PAA18091;
Fri, 5 Jun 1998 15:00:05 +0400 (MSD)
(envelope-from ache)
Message-ID: <19980605150004.A15856@nagual.pp.ru>
Date: Fri, 5 Jun 1998 15:00:04 +0400
From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: Peter Wemm <peter@netplex.com.au>
Cc: John Birrell <jb@cimlogic.com.au>, current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf
Mail-Followup-To: Peter Wemm <peter@netplex.com.au>,
John Birrell <jb@cimlogic.com.au>, current@FreeBSD.ORG
References: <19980605125523.A28805@nagual.pp.ru> <199806051041.SAA00714@spinner.netplex.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <199806051041.SAA00714@spinner.netplex.com.au>; from peter@netplex.com.au on Fri, Jun 05, 1998 at 06:41:34PM +0800
Organization: Biomechanoid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Fri, Jun 05, 1998 at 06:41:34PM +0800, Peter Wemm wrote:
> Huh????? We *have* /usr/bin/{ar,nm,aout,ld,as,size,strings,strip,...},
> these are links to objformat, which is a redirector to the /usr/lib/
> {aout,elf} backend.
Yes, I find /usr/bin links, sorry, it was error in my setup.
Valid point still: /usr/lib/libc.a often checked by GNU Configure (it
finds resolver, crypt, etc. stuff there), we need to handle this somehow
without fixing all ports which depends.
--
Andrey A. Chernov
http://www.nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 04:06:20 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id EAA27160
for freebsd-current-outgoing; Fri, 5 Jun 1998 04:06:20 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.125.27.73])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA27123;
Fri, 5 Jun 1998 04:06:13 -0700 (PDT)
(envelope-from ache@lsd.relcom.eu.net)
Received: (from ache@localhost)
by lsd.relcom.eu.net (8.8.8/8.8.8) id PAA20378;
Fri, 5 Jun 1998 15:05:54 +0400 (MSD)
(envelope-from ache)
Message-ID: <19980605150554.B15856@nagual.pp.ru>
Date: Fri, 5 Jun 1998 15:05:54 +0400
From: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
To: Peter Wemm <peter@netplex.com.au>
Cc: current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
Mail-Followup-To: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG,
ports@FreeBSD.ORG
References: <19980605123736.A20838@nagual.pp.ru> <199806051051.SAA00749@spinner.netplex.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <199806051051.SAA00749@spinner.netplex.com.au>; from peter@netplex.com.au on Fri, Jun 05, 1998 at 06:51:15PM +0800
Organization: Biomechanoid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Fri, Jun 05, 1998 at 06:51:15PM +0800, Peter Wemm wrote:
> > /usr/lib/libc.a (now moved to /usr/lib/aout) is also often parsed by GNU
> > Configure :-(
>
> Huh?? Such as? Almost all the GNU configure scripts test for presense of
> libc routines by a compile attempt. I've never seen an autoconf script
Yes, but I see at least three times when /usr/lib/libc.so.3.1 will
be nm'ed by Configure. I can't remember which ports affected right now,
but soon somebody hit in this and we'll see...
--
Andrey A. Chernov
http://www.nagual.pp.ru/~ache/
MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 06:42:06 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id GAA22974
for freebsd-current-outgoing; Fri, 5 Jun 1998 06:42:06 -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 GAA22865
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 06:41:58 -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 AAA27145;
Fri, 5 Jun 1998 06:41:50 -0700
Message-ID: <3577F59D.983C4EE4@home.com>
Date: Fri, 05 Jun 1998 06:41:49 -0700
From: "Richard S. Straka" <straka@home.com>
X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386)
MIME-Version: 1.0
To: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG
Subject: Re: strange behavior with signal latencies
References: <199806042229.IAA23654@godzilla.zeta.org.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Bruce Evans wrote:
> >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.
>
> The results show no signs of latency with -current on a P5/133 here.
>
> This should be relatively easy to debug - just find whatever is causing
> the abnormal interrupt load. I suspect it is an interrupt handler looping.
>
> Bruce
It turned out to be the de driver. I am currently using two of these cards
in a firewall/natd configuration. Thanks for the help.
BTW, these latancy times really go out the window (10+ms ) when
the system is loaded with disk writing or network activity. I have performed
similar tests on an Ultra 30 box running Solaris 2.6. Even under extreme
loading, the latencies stay below 1ms (its no VxWorks, but it ain't bad for
soft
realtime). It appears that Solaris does very little work in hardware
interrupts,
defering work to preemtable kernel threads which are under control of the
scheduler. They offer a realtime scheduling class which has higher priority
than their system scheduling class. The amount of work we currently do in
FreeBSD in hardware and software interrupts coupled with the
non-preemtable nature of kernel activity precludes us from doing even
soft realtime work.
Regards,
Richard Straka
straka@home.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 06:56:50 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id GAA25051
for freebsd-current-outgoing; Fri, 5 Jun 1998 06:56:50 -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 GAA24843;
Fri, 5 Jun 1998 06:55:11 -0700 (PDT)
(envelope-from bob@luke.pmr.com)
Received: (from bob@localhost)
by luke.pmr.com (8.8.8/8.8.8) id IAA09892;
Fri, 5 Jun 1998 08:54:59 -0500 (CDT)
(envelope-from bob)
Message-ID: <19980605085459.A9510@pmr.com>
Date: Fri, 5 Jun 1998 08:54:59 -0500
From: Bob Willcox <bob@pmr.com>
To: shimon@simon-shapiro.org, Bob Willcox <bob@luke.pmr.com>,
Michael Hancock <michaelh@cet.co.jp>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>,
Mike Smith <mike@smith.net.au>, Greg Lehey <grog@lemis.com>,
Stefan Esser <se@FreeBSD.ORG>
Subject: Re: DPT driver fails and panics with Degraded Array
Reply-To: Bob Willcox <bob@luke.pmr.com>
References: <19980603073200.A16652@pmr.com> <XFMail.980604121230.shimon@simon-shapiro.org> <19980605000101.27550@mi.uni-koeln.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <19980605000101.27550@mi.uni-koeln.de>; from Stefan Esser on Fri, Jun 05, 1998 at 12:01:01AM +0200
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Fri, Jun 05, 1998 at 12:01:01AM +0200, Stefan Esser wrote:
> On 1998-06-04 12:12 -0400, Simon Shapiro <shimon@simon-shapiro.org> wrote:
> > 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.
>
> This is a design "feature" of PCI, actually, and well documented.
>
> The interrupt lines are directly connected to the chip-set (or
> possibly the CPU in non-Intel PCI systems) and for that reason,
> there may for example be as many outstanding memory writes in
> write-buffers as their FIFO depths allow, when the end-of-transfer
> interrupt is recognized by the CPU.
>
> There is a documented protocol to flush all write buffers: Just
> read some device register at the start of the interrupt handler
> (i.e. before trying to access common data structures in memory,
> that are used for communication between CPU and an intelligent
> device). The read will be blocked until all buffers are flushed.
Hmm, well my AIX device driver did this. The first thing it did was to
read the HA_AUX_STATUS register on the adapter to see if an interrupt
was pending for it (a pretty common thing to do I think). Note that I
never saw the problem running on my (Motorola) UP test system. Bull saw
it quite regularly on their MP systems, though.
--
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 Fri Jun 5 07:28:35 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id HAA00545
for freebsd-current-outgoing; Fri, 5 Jun 1998 07:28:35 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from totally.damaged.org (totally.damaged.org [198.142.63.35])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00389
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 07:28:14 -0700 (PDT)
(envelope-from simon@totally.damaged.org)
Received: (from simon@localhost)
by totally.damaged.org (8.8.8/8.8.8) id AAA01057
for freebsd-current@freebsd.org; Sat, 6 Jun 1998 00:27:52 +1000 (EST)
(envelope-from simon)
Message-ID: <XFMail.980606002749.chaos@oz.org>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="_=XFMail.1.3.p0.FreeBSD:980606002748:25661=_"
Date: Sat, 06 Jun 1998 00:27:49 +1000 (EST)
From: Simon Coggins <chaos@oz.org>
To: freebsd-current@FreeBSD.ORG
Subject: Problem with libc_r and blocking.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
This message is in MIME format
--_=XFMail.1.3.p0.FreeBSD:980606002748:25661=_
Content-Type: text/plain; charset=us-ascii
I've come across a problem trying to use c_r on freebsd-current. In the
configure script of Roxen (http://www.roxen.com) web server, if you try and
make the package use freebsd's libc_r (it takes alittle hacking in configure)
when it find the threads functions correctly. But when it gets to test
how to set things non-blocking it freezes and locks up.
I've attached the .c file of what configure is doing when this happends if you
compile this with
gcc -pthread -D_THREAD_SAFE -o tst thread_test.c
and run it it will lock up if you leave off -pthread it works correctly.
Anyone out there have any idea? (are there plans to improve the threads support
in freebsd?) I was looking thru the archives and didn't see much in the way of
development info.
Regards
Simon
+---------------------------------------------------------------+
| Email: chaos@ultra.net.au, chaos@oz.org, simon@bofh.com.au |
| http://www.ultra.net.au/~chaos Ultranet Technical Admin. |
| Chaos on IRC, IRC Operator for the OzORG Network |
+---------------------------------------------------------------+
---
"I stopped believing in Santa Claus when I was six. Mother took me to
see him in a department store and he asked for my autograph."
-- Shirley Temple
--_=XFMail.1.3.p0.FreeBSD:980606002748:25661=_
Content-Disposition: attachment; filename="thread_test.c"
Content-Transfer-Encoding: base64
Content-Description: thread_test.c
Content-Type: application/octet-stream; name=thread_test.c; SizeOnDisk=1078
I2luY2x1ZGUgPHNpZ25hbC5oPgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPGVycm5vLmg+
CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lz
L3NvY2tldC5oPgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPHN5cy9maWxpby5oPgojaW5j
bHVkZSA8c3lzL3NvY2tpby5oPgoKaW50IHNldF9ub25ibG9ja2luZyhpbnQgZmQsaW50IHdoaWNo
KQp7CglmcHJpbnRmKHN0ZGVyciwgInNldF9ub25ibG9ja2luZygpXG4iKTsKICByZXR1cm4gZmNu
dGwoZmQsIEZfU0VURkwsIHdoaWNoP0ZOREVMQVk6MCk7Cn0KCmludCBxdWVyeV9ub25ibG9ja2lu
ZyhpbnQgZmQpCnsKCWZwcmludGYoc3RkZXJyLCAicXVlcnlfbm9uYmxvY2tpbmcoKVxuIik7CiAg
cmV0dXJuIGZjbnRsKGZkLCBGX0dFVEZMLCAwKSAmIEZOREVMQVk7Cn0KCmludCBzZXRfY2xvc2Vf
b25fZXhlYyhpbnQgZmQsIGludCB3aGljaCkKewoJZnByaW50ZihzdGRlcnIsICJzZXRfY2xvc2Vf
b25fZXhlYygpXG4iKTsKICByZXR1cm4gZmNudGwoZmQsIEZfU0VURkQsICEhd2hpY2gpOwp9Cgp2
b2lkIHNpZ2Fscm1faGFuZGxlcjAoaW50IHRtcCkgeyBleGl0KDApOyB9CnZvaWQgc2lnYWxybV9o
YW5kbGVyMShpbnQgdG1wKQp7CiAgZnByaW50ZihzdGRlcnIsIkZhaWxlZCBpbiBhbGFybSBoYW5k
bGVyIDFcbiIpOwogIGV4aXQoMSk7Cn0KCmludCBtYWluKCkKewogIGludCB0bXBbMl07CiAgY2hh
ciBmb29bMTAwMF07CgogIHRtcFswXT0wOwogIHRtcFsxXT0wOwoKCWZwcmludGYoc3Rkb3V0LCAi
VGVzdGluZyEhIVxuIik7CiAgc2V0X25vbmJsb2NraW5nKHRtcFswXSwxKTsKICBzaWduYWwoU0lH
QUxSTSwgc2lnYWxybV9oYW5kbGVyMSk7CiAgYWxhcm0oMSk7CiAgcmVhZCh0bXBbMF0sZm9vLDk5
OSk7CiAgc2V0X25vbmJsb2NraW5nKHRtcFswXSwwKTsKICBzaWduYWwoU0lHQUxSTSwgc2lnYWxy
bV9oYW5kbGVyMCk7CiAgYWxhcm0oMSk7CiAgcmVhZCh0bXBbMF0sZm9vLDk5OSk7CiAgZnByaW50
ZihzdGRlcnIsIkZhaWxlZCBhdCBlbmQgb2YgbWFpbi5cbiIpOwogIGV4aXQoMSk7Cn0KCg==
--_=XFMail.1.3.p0.FreeBSD:980606002748:25661=_--
End of MIME message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 09:06:44 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id JAA18611
for freebsd-current-outgoing; Fri, 5 Jun 1998 09:06:44 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from antipodes.cdrom.com (castles182.castles.com [208.214.165.182])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA18603
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 09:06: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 IAA01027;
Fri, 5 Jun 1998 08:02:07 -0700 (PDT)
Message-Id: <199806051502.IAA01027@antipodes.cdrom.com>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Luoqi Chen <luoqi@watermarkgroup.com>
cc: mike@smith.net.au, current@FreeBSD.ORG
Subject: Re: ppp libalias
In-reply-to: Your message of "Fri, 05 Jun 1998 03:35:36 EDT."
<199806050735.DAA17278@lor.watermarkgroup.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Jun 1998 08:02:07 -0700
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> > > > Brandon Lockhart <brandon@engulf.net> 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".
> > >
> > > I don't see any compelling reason why dynamic loading is really needed.
> > > IMHO, this is just a bad programming practice.
> >
> > Plenty of good reasons, most of them related to size.
>
> Could you be more specific? I don't quite understand. The library itself
> is not big, 6 pages (5 text, 1 data, excluding 4 pages of bss). If you don't
> use the -alias option, text and bss will not be touched, and you will waste
> 1 page of data (modified by relocation). If you use the -alias option,
> then the memory usage should be the same. We might end up saving some space
> if the code to load and unload the library is removed and let ld.so do the
> job during startup.
The library occupies about 25k in its static form. This means that ppp
is 25k bigger if you link it in.
If you are building, eg. a router floppy, or (the original reason) the
install floppy, and space is *tight*, having this module optional at
runtime means you can use the standard ppp binary without having to do
a custom rebuild.
A better fix for this would be to be able to "soft-link" shared
libraries; ie. have the runtime linker do the work and leave you with a
vector indicating what had and hadn't been found. This would be 100%
unportable though.
--
\\ 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 Fri Jun 5 09:29:19 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id JAA22482
for freebsd-current-outgoing; Fri, 5 Jun 1998 09:29:19 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from antipodes.cdrom.com (castles182.castles.com [208.214.165.182])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA22461
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 09:29:14 -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 IAA01204;
Fri, 5 Jun 1998 08:24:39 -0700 (PDT)
Message-Id: <199806051524.IAA01204@antipodes.cdrom.com>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Richard S. Straka" <straka@home.com>
cc: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG
Subject: Re: strange behavior with signal latencies
In-reply-to: Your message of "Fri, 05 Jun 1998 06:41:49 PDT."
<3577F59D.983C4EE4@home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Jun 1998 08:24:39 -0700
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> BTW, these latancy times really go out the window (10+ms ) when
> the system is loaded with disk writing or network activity. I have performed
> similar tests on an Ultra 30 box running Solaris 2.6. Even under extreme
> loading, the latencies stay below 1ms (its no VxWorks, but it ain't bad for
> soft realtime). It appears that Solaris does very little work in hardware
> interrupts,
> defering work to preemtable kernel threads which are under control of the
> scheduler. They offer a realtime scheduling class which has higher priority
> than their system scheduling class. The amount of work we currently do in
> FreeBSD in hardware and software interrupts coupled with the
> non-preemtable nature of kernel activity precludes us from doing even
> soft realtime work.
I guess that depends on your hardware selection and your definition of
"soft". I've certainly done "soft" realtime work on FreeBSD with a
considerable degree of success (the company's still in business too...).
A lot of PC hardware takes an inordinate amount of handholding,
although your point about the amount of work we chain off interrupt
handlers is quite valid. One can argue that this is an artifact of
tuning for UP performance, while using scheduled threads is very
definitely an optimisation for the MP case.
--
\\ 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 Fri Jun 5 10:54:01 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id KAA08886
for freebsd-current-outgoing; Fri, 5 Jun 1998 10:54:01 -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 KAA08850
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 10:53:56 -0700 (PDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id NAA22894 for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 13:53:56 -0400 (EDT)
Date: Fri, 5 Jun 1998 13:53:55 -0400 (EDT)
From: The Hermit Hacker <scrappy@hub.org>
To: freebsd-current@FreeBSD.ORG
Subject: cvs related question...
Message-ID: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Hi...
A couple of weeks back, I decided that in order to work with the
CAM drivers, and keep my kernel/OS alittle more in sync, I would remove
the 'tag=.' line from my CVSup and download the whole repository, then
checkout the source tree, apply the CAM drivers and then update as
required...
Today I figured out that this hasn't quite been working as
expected...my source tree is locked at 'May20th', which is what I checked
out in order to sync in the CAM drivers...
I'm figuring that has to be something I can do to 'kick' it
forward again, so taht its current vs 'May20th'...but am not sure what.
Could someone that knows more about this then I do please tell me
what I need to do? Assuming that there is?
Thanks...
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 11:07:32 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id LAA11086
for freebsd-current-outgoing; Fri, 5 Jun 1998 11:07:32 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from ConSys.COM ([209.141.107.2])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11076
for <current@freebsd.org>; Fri, 5 Jun 1998 11:07:30 -0700 (PDT)
(envelope-from rcarter@pinyon.org)
Received: (from pinyon@localhost)
by ConSys.COM (8.8.6/8.8.6) id KAA15423
for current@freebsd.org; Fri, 5 Jun 1998 10:32:31 -0700 (MST)
Date: Fri, 5 Jun 1998 10:32:31 -0700 (MST)
From: "Russell L. Carter" <rcarter@pinyon.org>
Message-Id: <199806051732.KAA15423@ConSys.COM>
To: current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Just a note on what kinds of fun lorder can provide,
I have spent two evenings recovering my system back from mangling
all my libs. Funny how all you really need to build
a system by hand is a spare libc.so.3.1 8-(). Like that
one sitting in /usr/lib just by luck because I was too
lazy to noschg it when I blew the rest away... Anyway,
when I sat down to get to know that troll^H^H^H^Helf
somehow lorder got installed as an executable zero
length file, and "ar cq libeverybody.a `lorder ${OBJS} | tsort`"
fails silently, where a valid lib format file is created but
no .o's are added, and there is an ampersand in the target
in bsd.lib.mk that keeps these sordid goings on extra
clean and quiet. So that valid but empty lib gets installed...
*ouch*. This goes on for while, and then things get
interesting... My major blunder was to attempt to trip
trap across the bridge with just a make all install.
I will make buildworld
I will make buildworld
I will make buildworld...
Now on to figuring out if it really is softupdates
causing my -bleeding-edge-current to wedge once a day.
Wheee! It's a bumpy ride right now... 8-)
Russell
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 11:30:36 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id LAA15585
for freebsd-current-outgoing; Fri, 5 Jun 1998 11:30:36 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15479
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 11:30:18 -0700 (PDT)
(envelope-from skynyrd@opus.cts.cwu.edu)
Received: from localhost (skynyrd@localhost)
by opus.cts.cwu.edu (8.8.8/8.8.8) with SMTP id LAA16733;
Fri, 5 Jun 1998 11:30:04 -0700 (PDT)
(envelope-from skynyrd@opus.cts.cwu.edu)
Date: Fri, 5 Jun 1998 11:30:03 -0700 (PDT)
From: Chris Timmons <skynyrd@opus.cts.cwu.edu>
To: "Richard S. Straka" <straka@home.com>
cc: current@FreeBSD.ORG
Subject: Re: strange behavior with signal latencies
In-Reply-To: <3577F59D.983C4EE4@home.com>
Message-ID: <Pine.BSF.3.96.980605112526.15337E-100000@opus.cts.cwu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
The fxp (intel etherexpress pro 100b/100+ driver) is known to be more
efficient with time spent in interrupt context. The cards are now well
under $100 each, too.
-Chris
On Fri, 5 Jun 1998, Richard S. Straka wrote:
> It turned out to be the de driver. I am currently using two of these cards
> in a firewall/natd configuration. Thanks for the help.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 12:12:56 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id MAA23263
for freebsd-current-outgoing; Fri, 5 Jun 1998 12:12:56 -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 MAA23241
for <current@freebsd.org>; Fri, 5 Jun 1998 12:12:40 -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 OAA16947 for <current@freebsd.org>; Fri, 5 Jun 1998 14:14:33 GMT
Date: Fri, 5 Jun 1998 14:14:33 +0000 (GMT)
From: Alfred Perlstein <perlsta@fang.cs.sunyit.edu>
To: current@FreeBSD.ORG
Subject: current build breakage
Message-ID: <Pine.BSF.3.95.980605141258.16941A-100000@fang.cs.sunyit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
as of ~11am EST on -current:
missing: ./tmp (created)
missing: ./tmp/vi.recover (created)
missing: ./yp (created)
if [ -d /usr/obj/usr/src/tmp/usr/share/locale ] ; then cd
/usr/obj/usr/src/tmp/usr/share/locale; for l in da_DK de_AT de_CH
de_DE en_AU en_CA en_GB en_US es_ES fi_FI fr_BE fr_CA fr_CH fr_FR is_IS
it_CH it_IT nl_BE nl_NL no_NO pt_PT sv_SE ; do if [ -h $l.ISO_8859-1 ];
then rm $l.ISO_8859-1; fi ; done; fi
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr
mtree: line 58: unknown keyword nochange
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
#
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 13:32:50 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA07214
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:32:50 -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 NAA07193
for <current@freebsd.org>; Fri, 5 Jun 1998 13:32:42 -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 NAA15296;
Fri, 5 Jun 1998 13:32:32 -0700 (PDT)
(envelope-from jdp)
Message-Id: <199806052032.NAA15296@austin.polstra.com>
To: scrappy@hub.org
Subject: Re: cvs related question...
In-Reply-To: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>
References: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>
Organization: Polstra & Co., Seattle, WA
Cc: current@FreeBSD.ORG
Date: Fri, 05 Jun 1998 13:32:32 -0700
From: John Polstra <jdp@polstra.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>,
The Hermit Hacker <scrappy@hub.org> wrote:
> expected...my source tree is locked at 'May20th', which is what I checked
> out in order to sync in the CAM drivers...
>
> I'm figuring that has to be something I can do to 'kick' it
> forward again, so taht its current vs 'May20th'...but am not sure what.
Use the "-A" option to cvs when you do your update. Specifically:
cvs -q upd -APd
is a good command to use.
--
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 Fri Jun 5 13:33:26 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA07298
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:33:26 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from dan.emsphone.com (dan@dan.emsphone.com [199.67.51.101])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07223
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 13:32:52 -0700 (PDT)
(envelope-from dan@dan.emsphone.com)
Received: (from dan@localhost)
by dan.emsphone.com (8.8.8/8.8.8) id PAA08986;
Fri, 5 Jun 1998 15:32:42 -0500 (CDT)
(envelope-from dan)
Message-ID: <19980605153242.A8721@emsphone.com>
Date: Fri, 5 Jun 1998 15:32:42 -0500
From: Dan Nelson <dnelson@emsphone.com>
To: The Hermit Hacker <scrappy@hub.org>, freebsd-current@FreeBSD.ORG
Subject: Re: cvs related question...
References: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.92.8i
In-Reply-To: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>; from "The Hermit Hacker" on Fri Jun 5 13:53:55 GMT 1998
X-OS: FreeBSD 2.2.6-STABLE
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In the last episode (Jun 05), The Hermit Hacker said:
> A couple of weeks back, I decided that in order to work with
> the CAM drivers, and keep my kernel/OS alittle more in sync, I would
> remove the 'tag=.' line from my CVSup and download the whole
> repository, then checkout the source tree, apply the CAM drivers and
> then update as required...
>
> Today I figured out that this hasn't quite been working as
> expected...my source tree is locked at 'May20th', which is what I
> checked out in order to sync in the CAM drivers...
Check the CVS directory of one of your source subdirs for a "Tag" file.
If "Tag" file exists, a "cvs update" will always stay in sync with
whatever tag is listed in that file. It's most useful when Tag is
TRELENG_2_2; i.e. tracking the -stable branch.
You probably did a "cvs -q update -dP -D 05/02/1998", which locked you
-on current as of May 20.
Try a "cvs -q update -dP -r HEAD", to force cvs to track -current as of
now.
-Dan Nelson
dnelson@emsphone.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 13:50:55 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA11271
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:50:55 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11171
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 13:50:37 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
by sax.sax.de (8.8.8/8.8.8) with UUCP id WAA23080
for freebsd-current@freebsd.org; Fri, 5 Jun 1998 22:50:30 +0200 (CEST)
(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.8/8.8.5) id WAA18658;
Fri, 5 Jun 1998 22:31:30 +0200 (MET DST)
Date: Fri, 5 Jun 1998 22:31:30 +0200 (MET DST)
Message-Id: <199806052031.WAA18658@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
References: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>
In-Reply-To: <Pine.BSF.3.96.980605135052.4758M-100000@hub.org>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: cvs related question...
X-Original-Newsgroups: local.freebsd.current
To: freebsd-current@FreeBSD.ORG
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
The Hermit Hacker <scrappy@hub.org> wrote:
> Today I figured out that this hasn't quite been working as
> expected...my source tree is locked at 'May20th', which is what I checked
> out in order to sync in the CAM drivers...
A `sticky' date, as CVS calls it. All explicitly mentioned dates,
tags or revisions are sticky.
You can update it to another (sticky) version with -r or -D, or you
can unstick all tags/dates with -A.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 13:51:11 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA11337
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:51:11 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11246
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 13:50:46 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
by sax.sax.de (8.8.8/8.8.8) with UUCP id WAA23088
for freebsd-current@freebsd.org; Fri, 5 Jun 1998 22:50:44 +0200 (CEST)
(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.8/8.8.5) id WAA18669;
Fri, 5 Jun 1998 22:38:29 +0200 (MET DST)
Date: Fri, 5 Jun 1998 22:38:29 +0200 (MET DST)
Message-Id: <199806052038.WAA18669@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
References: <Pine.NEB.3.95.980601210249.21800B-100000@korin.warman.org.pl>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: "swaps on generic" - what a name...
X-Original-Newsgroups: local.freebsd.current
To: freebsd-current@FreeBSD.ORG
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Andrzej Bialecki <abial@nask.pl> wrote:
> 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.
It is. And IMHO, our GENERIC kernel should also use it instead of
specifying an explicit root device.
> Could it be expressed better in terms of normal kernel option, say
> "options ASK_ROOT"?
ASK_ROOT should be possible with all kernels, regardless of whether
they are using a generic root device (i.e., they always have to adjust
the root device to the boot device) or not. There's no reason i could
see to prevent explicitly specified kernels to allow for a -a option.
So it's probably best as
config kernel generic
to say there's no predefined root device.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 13:51:27 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA11404
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:51:27 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11310
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 13:50:59 -0700 (PDT)
(envelope-from j@uriah.heep.sax.de)
Received: (from uucp@localhost)
by sax.sax.de (8.8.8/8.8.8) with UUCP id WAA23093
for freebsd-current@freebsd.org; Fri, 5 Jun 1998 22:50:54 +0200 (CEST)
(envelope-from j@uriah.heep.sax.de)
Received: (from j@localhost)
by uriah.heep.sax.de (8.8.8/8.8.5) id WAA18695;
Fri, 5 Jun 1998 22:46:54 +0200 (MET DST)
Date: Fri, 5 Jun 1998 22:46:54 +0200 (MET DST)
Message-Id: <199806052046.WAA18695@uriah.heep.sax.de>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Organization: Private BSD site, Dresden
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E
References: <19980530065508.30647@follo.net>
<15536.896512211@critter.freebsd.dk>
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: The pathname contains a character with... (Was: I see one major problem with DEVFS...)
X-Original-Newsgroups: local.freebsd.current
To: freebsd-current@FreeBSD.ORG
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Poul-Henning Kamp <phk@critter.freebsd.dk> wrote:
> The POLA way is:
>
> (4) use undelete(2) for what it is intended to do.
Funny you mention it. :-)
ERRORS
The undelete() succeeds unless:
...
[EINVAL] The pathname contains a character with the high-order bit
set.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I thought we've already removed all traces of this stone-age message,
but hey, here's yet another instance. ;-)
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 13:53:39 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA11836
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:53:39 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from mail.camalott.com (root@mail.camalott.com [208.203.140.2])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11653;
Fri, 5 Jun 1998 13:52:49 -0700 (PDT)
(envelope-from joelh@gnu.org)
Received: from detlev.UUCP (tex-31.camalott.com [208.229.74.31] (may be forged))
by mail.camalott.com (8.8.7/8.8.5) with ESMTP id PAA32175;
Fri, 5 Jun 1998 15:51:05 -0500
Received: (from joelh@localhost)
by detlev.UUCP (8.8.8/8.8.8) id PAA00410;
Fri, 5 Jun 1998 15:51:44 -0500 (CDT)
(envelope-from joelh)
Date: Fri, 5 Jun 1998 15:51:44 -0500 (CDT)
Message-Id: <199806052051.PAA00410@detlev.UUCP>
To: ache@nagual.pp.ru
CC: peter@netplex.com.au, current@FreeBSD.ORG, ports@FreeBSD.ORG
In-reply-to: <19980605150554.B15856@nagual.pp.ru> (message from
=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= on Fri, 5 Jun 1998 15:05:54 +0400)
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
From: Joel Ray Holveck <joelh@gnu.org>
Reply-to: joelh@gnu.org
References: <19980605123736.A20838@nagual.pp.ru> <199806051051.SAA00749@spinner.netplex.com.au> <19980605150554.B15856@nagual.pp.ru>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
>>> /usr/lib/libc.a (now moved to /usr/lib/aout) is also often parsed by GNU
>>> Configure :-(
>> Huh?? Such as? Almost all the GNU configure scripts test for presense of
>> libc routines by a compile attempt. I've never seen an autoconf script
> Yes, but I see at least three times when /usr/lib/libc.so.3.1 will
> be nm'ed by Configure. I can't remember which ports affected right now,
> but soon somebody hit in this and we'll see...
If these are GNU programs, please let me know. GNU programs generally
shouldn't rely on compilation internals like that.
Happy hacking,
joelh
--
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 Fri Jun 5 13:57:34 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA12656
for freebsd-current-outgoing; Fri, 5 Jun 1998 13:57:34 -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 NAA12549
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 13:56:51 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.8/8.8.8) id NAA28263;
Fri, 5 Jun 1998 13:56:43 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp02.primenet.com, id smtpd028215; Fri Jun 5 13:56:34 1998
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id NAA03615;
Fri, 5 Jun 1998 13:56:25 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199806052056.NAA03615@usr08.primenet.com>
Subject: Re: Problem with libc_r and blocking.
To: chaos@oz.org (Simon Coggins)
Date: Fri, 5 Jun 1998 20:56:24 +0000 (GMT)
Cc: freebsd-current@FreeBSD.ORG
In-Reply-To: <XFMail.980606002749.chaos@oz.org> from "Simon Coggins" at Jun 6, 98 00:27:49 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
> I've come across a problem trying to use c_r on freebsd-current. In the
> configure script of Roxen (http://www.roxen.com) web server, if you try and
> make the package use freebsd's libc_r (it takes alittle hacking in configure)
> when it find the threads functions correctly. But when it gets to test
> how to set things non-blocking it freezes and locks up.
>
> I've attached the .c file of what configure is doing when this happends if you
> compile this with
>
> gcc -pthread -D_THREAD_SAFE -o tst thread_test.c
>
> and run it it will lock up if you leave off -pthread it works correctly.
>
> Anyone out there have any idea? (are there plans to improve the threads
> support in freebsd?) I was looking thru the archives and didn't see much
> in the way of development info.
Worked fine for me...
hermes% cc -o thread_test thread_test.c
hermes% ./thread_test
Testing!!!
set_nonblocking()
set_nonblocking()
hermes%
hermes% cc -o thread_test -D_THREAD_SAFE thread_test.c -lc_r
hermes% ./thread_test
Testing!!!
set_nonblocking()
set_nonblocking()
hermes%
This is on my FreeBSD 2.2-STABLE (post 2.2.5, before the 2.2.6 release)
box. The _THREAD_SAFE is not necessary on -current, and the -pthread
isn't in my compiler (that I've been able to tell), but all it does
is "-lc_r" before the implied "-lc".. the same thing I did explicitly,
above, with the command I used.
Supposedly, Julian Elisher checked in all of my and Jeremy Allison's
patches to both 2.2.6 and -current.
One of these patches dealt *precisely* with this problem; the ioctl
was not wrapped. Other changes dealt with fcntl( , F_DUPFD, ), which
was also not wrapped, huge changes to error reporting, and signal
handling and other various changes.
I presume you are running 2.2.5-release or earlier... if so, upgrade.
If you plan on using C++ with threads, use gcc 2.8.x with Jeremy's
patches for per thread exception stacks. This means you should get
the code from -ports, NOT from FSF! And *DON'T* use egcs at all.
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 Fri Jun 5 14:22:57 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id OAA18505
for freebsd-current-outgoing; Fri, 5 Jun 1998 14:22:57 -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 OAA18382;
Fri, 5 Jun 1998 14:22:23 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp04.primenet.com (8.8.8/8.8.8) id OAA07219;
Fri, 5 Jun 1998 14:22:04 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp04.primenet.com, id smtpd007047; Fri Jun 5 14:21:50 1998
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id OAA04575;
Fri, 5 Jun 1998 14:21:39 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199806052121.OAA04575@usr08.primenet.com>
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
To: ache@nagual.pp.ru (=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=)
Date: Fri, 5 Jun 1998 21:21:39 +0000 (GMT)
Cc: peter@netplex.com.au, current@FreeBSD.ORG, ports@FreeBSD.ORG
In-Reply-To: <19980605123736.A20838@nagual.pp.ru> from "=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=" at Jun 5, 98 12:37:36 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 expect lots of problems with GNU Configure scripts (for ports), they
> > never search nm,ar,ranlib in .../aout
> >
> > We must provide symlinks from
> > /usr/bin/xxx -> /usr/libexec/{elf or aout}/xxx
> > otherwise lots of ports will be broken.
>
> /usr/lib/libc.a (now moved to /usr/lib/aout) is also often parsed by GNU
> Configure :-(
>
> It sounds like almost every GNU Configure port should be changed to
> reflect new aout subdirectories to preserve previous state. It is wrong
> move indeed for elf version. It looks like libraries and /usr/bin symlinks
> are only solution.
I have not considered (yet) how one should interpret variant symbolic
links based not on data in the environment, but on data known to the
kernel. This is problematic.
My gut feeling would be to put variant symbolic links in, and use a
dollarsign ("$") to designate a kernel variant keyword:
ln -s "/usr/lib.\${\$imgact}" /usr/lib
The a.out images would get /usr/lib.aout, the ELF would get /usr/lib.elf.
The gzip and shell would set it apropriately for the interpreter.
Pretty obviously, the semantics are "${<var>}", so the lookup code
can definitively tell the end of the <var>. Since "$" is not allowed
in an environment variable, we can steal it as a name-space escape.
To escape the "${" escape, "${$$" could be used. So:
ln -s "/usr/lib.\${\$\$imgact}" /usr/lib
ls -l /usr/lib
... /usr/lib -> /usr/lib.${$$imgact}
which would actually reference the file /usr/lib.${imgact}, instead of
expanding the imgact variable.
This would typically never be needed, since re-quotation in a shell
script would tend to blow away the value anyway.
---
Unfortunately, variant symbolic links would still not be useful based
on environment variables, since FreeBSD programs don't force the
environment variables to use some rational standard referential model
(like "logical names" -- basically, the env is hung off the proc
structure instead of stuffed into kernel-inaccessible data space).
The main "bugaboo" here is the use of the "envp" in the execve(2)
system call.
The way I would deal with this is to note that POSIX does not mandate
its functions be system calls rather than library routines. But this
would lose binary backward compatability. 8-(. Far be it for me
to stand in the way of the code being backward. Compatible.
This means that you would need an envp-to-logical name translator in
the kernel; it would need to know "atom=value" rules, at a minimum.
This is a tiny amount of code, but would displease some people.
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 Fri Jun 5 14:49:24 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id OAA23019
for freebsd-current-outgoing; Fri, 5 Jun 1998 14:49:24 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from isf.kiev.ua (sunone.isf.kiev.ua [194.44.162.131])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22995
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 14:49:10 -0700 (PDT)
(envelope-from kushn@mail.kar.net)
Received: from olinet.isf.kiev.ua by isf.kiev.ua with ESMTP id AAA21154;
(8.8.7/2.b2) Sat, 6 Jun 1998 00:46:00 +0300 (EET DST)
Received: from kushnir.kiev.ua by olinet.isf.kiev.ua with SMTP id AAA10217;
(8.8.last/vAk3/1.9) Sat, 6 Jun 1998 00:27:42 +0300 (EET DST)
Date: Sat, 6 Jun 1998 00:35:09 +0300 (EEST)
From: Vladimir Kushnir <kushn@mail.kar.net>
X-Sender: volodya@kushnir.kiev.ua
Reply-To: Vladimir Kushnir <kushn@mail.kar.net>
To: freebsd-current@FreeBSD.ORG
Subject: building a.out pieces of buildworld?
Message-ID: <Pine.BSF.3.96.980606002500.24910A-101000@kushnir.kiev.ua>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1539019671-897082428=:24910"
Content-ID: <Pine.BSF.3.96.980606003451.24910C@kushnir.kiev.ua>
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-1539019671-897082428=:24910
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.BSF.3.96.980606003451.24910D@kushnir.kiev.ua>
Hello,
Wouldn't it make sence to build a.out progs (and bootloader - unless
we're going to boot elf real soon) as a.out independently of
{OBJ,BIN}FORMAT? It doesn't take too much - just add '-aout' flags to some
Makefiles.
Regards,
Vladimir
--0-1539019671-897082428=:24910
Content-Type: APPLICATION/OCTET-STREAM; NAME="makefiles-aout.diff.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.3.96.980606003348.24910B@kushnir.kiev.ua>
Content-Description: makefiles-aout.diff
H4sICM1heDUAA21ha2VmaWxlcy1hb3V0LmRpZmYA5Rtrc6JK9rP3V/RWUrVJ
BhFBfFDr7kUhGe/4SKmZ1ExtlYWAhhsFC3AmmSn/+57uBgREktwxr7tTmdAc
+pzu8+zTpztnZ2eILc3tdWntuezUskuaV+ppt+bMWpis7i8L566F/ljbCImI
5yWxJlXqqNxo1H8rFov7URNogsRxUrlM0c6S//A79GD4BiKvCBUKC8vzLXvO
6mhpep42Nz1oOlPP1/Rb3Fr7q7VfpDNErqkZ8PDWU8+c447/JTS8++XUWeD3
b6brWY4Nre+u5WOUu6W2WDg6bgF20KRozvTP4vHJXPMm0Jo57lLzT+Hj8c/2
oH8++ajKijocbX77B2qfd+WL0Ydmodg5PmHbV0OlMzyFfrKidPrt7pWiblD8
U0l37Jk1D4YpKoOuMrmQR6iojDoX4y/Nb45lwIvpuo7bhOFnmq8tot6jq9Zk
pF701P54Inc7F/1mBTqfD1W1NVIm8uBqDB2JRqgooVV8h6LUYD7oDQn0jHjH
wpqWdG9dsoR6Nc83hLLEi3HfyERMI2G8/Z5RZmqhXxwVZq6zlNDvJ0enETGR
raKTlunemgvz/hSJJZ4vNcqk93HHkFDYkfmGyqxAPbfEiSU8ZpkMXkNTw0Tq
3QodY5a36kDBv6LS7bTak1G7DcKd2U7RWVpgMq62NIsrx7J90wXEQeuPUbNQ
0F2fYx2kf/hAG/MA4IXPAAAY7a4q9887XRWrXmNB9aENY6YDC341pqkpvijr
WfpvMOUoMMIPpSDRp45tGdypvcFORRgAF9Fh1u3hmIOH8qUv9zpt+Bo4zaZE
EVHRwcCxPLxQx9gFgUxXAeRBDIyKd6joxvvRKQT8SWErexqzlaXjycTHDvvD
eL8/fsAj/D+SpuGYnv1PH5Foc48Mc2XaBnLsQDQMmoLe/BvLQ/Dj35jI1DzL
9Hz0XbsnxkUkGljXC0iU2tGLy/XRwx5Qupkre5kRthEM/s8TAnf2Crz3nDZ8
FHBm2jrMHs3Wxtw0kAYtx0VbN/UeOVcy1VeZYCRN71HiPOgcsY1YNmQSi4VE
x+30R2O52yWDDy6/bCj1Vqc/uO7Dy5y+XAwv4WWJKpUKAHDw3MCyTHIXYixh
5H8RY3m8n7yqyRx8ms9mOI+e6WHNh2Zq3r1Hk62p4/ilqeV4pLE3Z4ONSU3i
EjnbAyRS6EI9P3urMDwXRr9tmqu0BoMxZJ9NYIi2gCMKHMvtTyEYtzdJRGUw
aclKuVJJgj+rI3kyurq8HAzH8YQaBHktD/tUn6GBtHBcn2nrhc8ga4Y05Jmu
BanxynF9HNbnkNjMke+gqYnWHrUeyLU9BxIqDEDtQY8kW+hEu9VQyTC/lXz/
3uBOWZq9EaYDL34FpqkJvjjrWfoXOUasbvP3AjFg4kXYqDwDJQEzA7r1B6OP
8lBVmoUv6oi89+R+ExgcjYedy2bIir+2tenCRL61NDG/Kw1npZCQMrAWW3jP
R1z+1rxfubDzY5AO7jZ1NR+4smy09IAKFvi13Bn/p1kQOY4j2sNTjmXfh5gy
7CB911rR2IChna8qBlo/zAD2jDxlqaUqMjU+llVjRlgyR6mA2zgc6TDfFfkS
+4zjHOUlBcOsxEBbqrZzY7iUavStYMB0Z80tDDnBG+mNrKnXFHjk3VqrZhlv
1ptljq9MiXqqVaYmxNLXJ039+CdRyGYXDBrZPD8DWUFaNx4K0WVOEvn9ITpF
IB2gqxJfyQnQVYbnDxigO7GFkmWj5SNJvE0o5cXpo3j0U1tXF4cNYCRKE84P
F6X/IufZwfqZ+c8M1QIjNt5ZqBaYKvd3D9V1pia+01DdYGrVv1Oovv1hrR4M
1oLEC/uD9Q6JNHpFEus54boROyeIhRYIUZ9kRRk2j0/I8xTvsEgUO8GP01TX
r51L3GHQaw/6o0FXbXJ3wnmdkrz94WvWAu+Mgt3F5NPXsdzp0j3OSVc5xZsZ
vKVxor7o+CTW8zQkdIPL6QlCuOidTYj23RLCPQNCrGXri7Vhon9NPYNduc6c
Xd7+mwbxBiNwMRM7rDw+xDptff8xAqKbwIOJKU3u6cLKMmfb9B+05ipY5H5r
TlNI5x6wveT3G7PAM0I9NGYaqCHU4sO00tIwdQrsDRQIwKIobldF6FQcwNKt
9M/xacdw0CNR+vhn0MIL9lDtDtoYhJ/YAjBQHn2aJNbfv0jpKE4rtCRETOmy
3aG/J5/VvjIAA/y5fdkEnxT1c6etBp/oy2aXzqTdlUejoBdpb5LjHvVHdaHB
YSbCE6LJtQJ9rhWgei5fdceTntoDY1a4cMmkMg8c5pVkHh0u/P+IPsv8KxxT
2SZclCBJ+EKCAgQkIEmek5Y8ImEJiKWOTwInZHVnmf60BL90nSXyfM31edZ1
kKCLXANCh+3h4VgH1NJVolyzj4pjlFSgiSYEGxVtx/MNyGEykihIoerbidRT
CWCo23JVqOMSRkQe+GlElgniELfJ3JsQB7XSQwsFoYwUEwE0lWM+LLbMfLHM
1GuxDMGeEs7wGWIG/5BODdsjqX/G3khDaVQ6LrFOab7ZygOFdU38OyyLxiuf
waIFuAFVpxSRL23igg2y0WTRlDCdqIzCeCxQJFl7OOF06dSeUsU9katA27/M
VEjnwDwRSenPpSjWX66ienGeWnDHDDYIOMinEzkzZNepUZw4BOO4S1Sc7dKK
aZKwHQr71xWYYDZHXS/IK9kR8Uy9HktX35BzRvut9KEGXYzfsYsenrNXctQM
RkL73WXmb+Gur85x1rbJ1b4/tG3iy1KF279tSlNIYzdy7womSraFvYXH6KZX
WGUKSpe4ibPZcaenDq4wNGilDp2eUgd99RO3eC33zYnkDZ3HVeqMWAltJ534
c7np7AvXdvFMxVClvzTTt1fSFZga905LuhWmVn7fJd3orrabe807feaWgZZG
KUe1siytQ+oX0/nlcHDRLGhurApDijBgUOadqZcCWw1jSDyiAQpebgF7hS+6
sDrSXPJLv7G+4SvJECB80/bxfWXDXJjkmrJ557ua7uNr0JYXXVFeOgRh5Vq2
T64/rxaabpKLd+BCZTxBlp6W4dlv1f7U2YfXml+Ph6TuF4aRe4+5LpWFLOXH
8XZxwrvP2dqv7Wi/AOQiQeAXfPXcMTxykXG7elxri8WDhXB+e2P4qfSpch4c
JSlBe5nrPYJUqWYJMIaWRqlInJAnv+qO/Ozl1v5Qlv09JLLqjsgeJJkw6ccK
y9VsfBM+T2CixHFZAkuh7qKV8wrsTFRfpOxRarksRo4ZueJ0bS2MrdNRGtDw
nbV+k7CluIejdBJGogX1yIBEmQLECIDrzZ8v5fFHnEamcEnxmokuLr8MPztx
69BcJe0Er+O5VsJHh4NJK0kg7voin/eXR6Fj7YsimHauhD/sOMVj/QIv3vY8
/8+teInLjCRp3F08ITccP8Q1Jf+MjK/y2K7ACiTuY3u1l2lO4mp54aC+ZXrH
l8LsKs+VqKGTnmDnIf+ogBCKnZFua+4YutTup+aE4KxMgwoJX3lNf/gfA18i
qok3AAA=
--0-1539019671-897082428=:24910--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 14:52:04 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id OAA23467
for freebsd-current-outgoing; Fri, 5 Jun 1998 14:52: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 OAA23418
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 14:51:58 -0700 (PDT)
(envelope-from jb@cimlogic.com.au)
Received: (from jb@localhost)
by cimlogic.com.au (8.8.8/8.8.7) id HAA06632;
Sat, 6 Jun 1998 07:54:15 +1000 (EST)
(envelope-from jb)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199806052154.HAA06632@cimlogic.com.au>
Subject: Re: Problem with libc_r and blocking.
In-Reply-To: <XFMail.980606002749.chaos@oz.org> from Simon Coggins at "Jun 6, 98 00:27:49 am"
To: chaos@oz.org (Simon Coggins)
Date: Sat, 6 Jun 1998 07:54:15 +1000 (EST)
Cc: 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
Simon Coggins wrote:
>
> I've come across a problem trying to use c_r on freebsd-current. In the
> configure script of Roxen (http://www.roxen.com) web server, if you try and
> make the package use freebsd's libc_r (it takes alittle hacking in configure)
> when it find the threads functions correctly. But when it gets to test
> how to set things non-blocking it freezes and locks up.
I'll look at this as soon as I can.
--
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 Fri Jun 5 15:10:22 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id PAA26288
for freebsd-current-outgoing; Fri, 5 Jun 1998 15:10:22 -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 PAA26174
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 15:10:01 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp01.primenet.com (8.8.8/8.8.8) id PAA22584;
Fri, 5 Jun 1998 15:09:57 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp01.primenet.com, id smtpd022544; Fri Jun 5 15:09:52 1998
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id PAA06934;
Fri, 5 Jun 1998 15:09:38 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199806052209.PAA06934@usr08.primenet.com>
Subject: Re: I see one major problem with DEVFS...
To: eivind@yes.no (Eivind Eklund)
Date: Fri, 5 Jun 1998 22:09:38 +0000 (GMT)
Cc: tlambert@primenet.com, current@FreeBSD.ORG
In-Reply-To: <19980605000726.58908@follo.net> from "Eivind Eklund" at Jun 5, 98 00:07:26 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
> > The big issue here is *only* the boot blocks, since aggregation
> > is a matter of "what is default in the kernel" and "what objects
> > are linked into the 'installed' subdirectory from the 'available'
> > subdirectory".
>
> This is just plain wrong. If you want to get rid of config, you got
> to move the functions it presently handle somewhere else, and
> eliminate the blocks to using pure aggregation one by one.
I remember your list; I think we should seperate "code presence" from
"conditional compilation", and eliminate all "conditional compilation".
I'll respond to your conditional compilation issues on a case-by-case
basis:
* The use of 'UNION' in vfs_syscalls.c
This is there because the auio.uio_resid is not being
properly adjusted by the UNIONFS VOP_READDIR when the
upper vnode's data is exhausted.
The repeat entry elimination in readdir(3) is also
broken -- getdirentries(2) is capable of returning
duplicate entries, but nowhere is this noted.
It is the job of the unionfs to take care of this problem
on behalf of callers to it.
The unionfs is broken.
Dike the code out of here, and put it in (in "#if 0"
form) in the miscfs/union/union_vops.c in the union_readdir
code.
* The use of COMPAT_43 at all
Remove this entirely. Make the code always be there.
Comment before and after it, if you care.
* The dependency of the Linux module on COMPAT_43
with COMPAT_43 always there, this goes away.
* The way 1/3 of the the kernel is dependent on 'INET'
This is wrong. I count the net/if_*.c files, the net/route.c
file, debug code in netipx/netns, and a bunch of stupid
ethernet drivers that care about the protocols that are going
to be run on the card for bogus organizational reasons.
This has more to do with the lack of a DDI/DKI for address
family registration than anything else.
Since I've written code to do this twice before, it's
probably someone else's turn, unless you can guarantee
a commit this time.
* The way the BOOTP options are used all through the kernel
Whoever is using this should add the necessary SYSINIT to
make it start working again, once it is impossible to define
BOOTP at compile time via "config".
The VFS root volume handling is problematic because the
fact that it's pure idiocy to disctinguish root mounts
from non-root mounts in the first place.
I have railed on this before, but lack of support for the
idea has foiled integration of my soloution.
The basic idea would be to seperate the mount procedure into
the FS specific code, which only made a mount structure entry,
and the mapping into the FS hierarchy and NFS volume export,
which would all be in common code. This would necessitate
a VFS_MOUNTEDON VFSOP to set the "last mounted on" for FS's
that supported this information (like FFS); it would be a
NULL op for those that didn't (like CD9660, MSDOSFS, etc.).
* Some other way of setting the panic reboot time
Default it large, and let it be sysctl'ed down if the
machine can boot that far.
* 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)
This is the correct thing to do. Remove the ability to
use it by removing the ability to set the variable, and
let someone who needs it convert the conditional code
into a sysctl.
* The way 'QUOTA' change things in all the filesystems
Either default it on (#define QUOTA 1), or do the same as
for the SPX_HACK: leave it for whoever uses it. If it's
defaulted on, leave the reduction in kernel size to whoever
uses it.
The correct implementation will make a QUOTAFS stacking
layer, such that all FS's can use quotas, and no conditional
compilation is ever required.
I have seperated these out for special treatment:
* The existance of 'maxusers' and all the constants that depend on it
* The use of defines to set options for the AHC driver
* The use of defines to shift the tuner in the brooktree driver
* The use of defines instead of variables to control kernel PPP
These are all things which can be manifested on or off or
to a particular value, and then the people who care about
them can put in the work to make them runtime configurable
(sysctl or whatever).
The major issue with these is that the code that depends on
them may not take kindly to runtime changes of value.
It may be worthwhile to make these -D's in the Makefile
for the kernel, until such time as someone cares to resolve
them. I can give you a set of Makefile rules for dealing
with dependencies on things like ".maxusers=*", if you
don't want to trivially code them up yourself.
> I gave you a list of about 10 things that have to be fixed before we
> can get rid of config (or something else that basically do the
> function of config, including separate compilation with differing
> defines).
The issue is one of conditional compilation within a compilation unit,
and not selection of compilation units, I think. I think this is a
resolvable problem, which can be made to put the work on the people
who care (personally, I care about QUOTA, so I'd probably end up
making work for myself on that one, unless it was defaulted on, and
you made work for people who wanted smaller kernels, instead of for
me).
> If you have some other way of handling those issues, that's fine - but
> they have to be handled! And believe me, I'd like to have a system
> that didn't need config, too - I just don't believe it can happen
> without somebody putting down a lot of work towards that end,
> ruthlessly eliminating obstacle by obstacle.
Is the above ruthless enough for a first pass? If you will sign off
on it, I'll code it up.
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 Fri Jun 5 15:55:18 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id PAA01107
for freebsd-current-outgoing; Fri, 5 Jun 1998 15:33:55 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from totally.damaged.org (totally.damaged.org [198.142.63.35])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA01045
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 15:33:44 -0700 (PDT)
(envelope-from simon@totally.damaged.org)
Received: (from simon@localhost)
by totally.damaged.org (8.8.8/8.8.8) id IAA05748;
Sat, 6 Jun 1998 08:33:27 +1000 (EST)
(envelope-from simon)
Message-ID: <XFMail.980606083326.chaos@oz.org>
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: <199806052056.NAA03615@usr08.primenet.com>
Date: Sat, 06 Jun 1998 08:33:26 +1000 (EST)
From: Simon Coggins <chaos@oz.org>
To: Terry Lambert <tlambert@primenet.com>
Subject: Re: Problem with libc_r and blocking.
Cc: freebsd-current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
As per the first line of my message I'm running -current :)
FreeBSD totally 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Wed Jun 3 23:41:37 EST
1998
On 05-Jun-98 Terry Lambert wrote:
>> I've come across a problem trying to use c_r on freebsd-current. In the
>> configure script of Roxen (http://www.roxen.com) web server, if you try and
>> make the package use freebsd's libc_r (it takes alittle hacking in
>> configure)
>> when it find the threads functions correctly. But when it gets to test
>> how to set things non-blocking it freezes and locks up.
>>
>> I've attached the .c file of what configure is doing when this happends if
>> you
>> compile this with
>>
>> gcc -pthread -D_THREAD_SAFE -o tst thread_test.c
>>
>> and run it it will lock up if you leave off -pthread it works correctly.
>>
>> Anyone out there have any idea? (are there plans to improve the threads
>> support in freebsd?) I was looking thru the archives and didn't see much
>> in the way of development info.
>
> Worked fine for me...
>
> hermes% cc -o thread_test thread_test.c
> hermes% ./thread_test
> Testing!!!
> set_nonblocking()
> set_nonblocking()
> hermes%
>
>
> hermes% cc -o thread_test -D_THREAD_SAFE thread_test.c -lc_r
> hermes% ./thread_test
> Testing!!!
> set_nonblocking()
> set_nonblocking()
> hermes%
>
> This is on my FreeBSD 2.2-STABLE (post 2.2.5, before the 2.2.6 release)
> box. The _THREAD_SAFE is not necessary on -current, and the -pthread
> isn't in my compiler (that I've been able to tell), but all it does
> is "-lc_r" before the implied "-lc".. the same thing I did explicitly,
> above, with the command I used.
>
>
> Supposedly, Julian Elisher checked in all of my and Jeremy Allison's
> patches to both 2.2.6 and -current.
>
> One of these patches dealt *precisely* with this problem; the ioctl
> was not wrapped. Other changes dealt with fcntl( , F_DUPFD, ), which
> was also not wrapped, huge changes to error reporting, and signal
> handling and other various changes.
>
> I presume you are running 2.2.5-release or earlier... if so, upgrade.
>
>
> If you plan on using C++ with threads, use gcc 2.8.x with Jeremy's
> patches for per thread exception stacks. This means you should get
> the code from -ports, NOT from FSF! And *DON'T* use egcs at all.
>
>
> Terry Lambert
> terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
Regards
Simon
+---------------------------------------------------------------+
| Email: chaos@ultra.net.au, chaos@oz.org, simon@bofh.com.au |
| http://www.ultra.net.au/~chaos Ultranet Technical Admin. |
| Chaos on IRC, IRC Operator for the OzORG Network |
+---------------------------------------------------------------+
---
Hanlon's Razor:
Never attribute to malice that which is adequately explained by
stupidity.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 16:09:20 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id QAA07405
for freebsd-current-outgoing; Fri, 5 Jun 1998 16:09:20 -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 QAA07393
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 16:09:15 -0700 (PDT)
(envelope-from jb@cimlogic.com.au)
Received: (from jb@localhost)
by cimlogic.com.au (8.8.8/8.8.7) id JAA06982;
Sat, 6 Jun 1998 09:11:34 +1000 (EST)
(envelope-from jb)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199806052311.JAA06982@cimlogic.com.au>
Subject: Re: Problem with libc_r and blocking.
In-Reply-To: <199806052056.NAA03615@usr08.primenet.com> from Terry Lambert at "Jun 5, 98 08:56:24 pm"
To: tlambert@primenet.com (Terry Lambert)
Date: Sat, 6 Jun 1998 09:11:34 +1000 (EST)
Cc: chaos@oz.org, 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
Terry Lambert wrote:
> Worked fine for me...
No, the problem as reported exists. I have a fix that I'm just running
a few tests on. Remember that -current differs from -stable.
--
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 Fri Jun 5 16:25:19 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id QAA10459
for freebsd-current-outgoing; Fri, 5 Jun 1998 16:25:19 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from totally.damaged.org (totally.damaged.org [198.142.63.35])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10449
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 16:25:14 -0700 (PDT)
(envelope-from simon@totally.damaged.org)
Received: (from simon@localhost)
by totally.damaged.org (8.8.8/8.8.8) id JAA19607;
Sat, 6 Jun 1998 09:24:56 +1000 (EST)
(envelope-from simon)
Message-ID: <XFMail.980606092455.chaos@oz.org>
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: <199806052311.JAA06982@cimlogic.com.au>
Date: Sat, 06 Jun 1998 09:24:55 +1000 (EST)
From: Simon Coggins <chaos@oz.org>
To: John Birrell <jb@cimlogic.com.au>
Subject: Re: Problem with libc_r and blocking.
Cc: freebsd-current@FreeBSD.ORG, (Terry Lambert) <tlambert@primenet.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 05-Jun-98 John Birrell wrote:
> Terry Lambert wrote:
>> Worked fine for me...
>
> No, the problem as reported exists. I have a fix that I'm just running
> a few tests on. Remember that -current differs from -stable.
>
That was quick! :) Any ETA on a release of it?
Regards
Simon
+---------------------------------------------------------------+
| Email: chaos@ultra.net.au, chaos@oz.org, simon@bofh.com.au |
| http://www.ultra.net.au/~chaos Ultranet Technical Admin. |
| Chaos on IRC, IRC Operator for the OzORG Network |
+---------------------------------------------------------------+
---
The world is coming to an end ... SAVE YOUR BUFFERS!!!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 16:30:00 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id QAA11246
for freebsd-current-outgoing; Fri, 5 Jun 1998 16:30:00 -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 QAA11228
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 16:29:55 -0700 (PDT)
(envelope-from jb@cimlogic.com.au)
Received: (from jb@localhost)
by cimlogic.com.au (8.8.8/8.8.7) id JAA07063;
Sat, 6 Jun 1998 09:32:25 +1000 (EST)
(envelope-from jb)
From: John Birrell <jb@cimlogic.com.au>
Message-Id: <199806052332.JAA07063@cimlogic.com.au>
Subject: Re: Problem with libc_r and blocking.
In-Reply-To: <XFMail.980606092455.chaos@oz.org> from Simon Coggins at "Jun 6, 98 09:24:55 am"
To: chaos@oz.org (Simon Coggins)
Date: Sat, 6 Jun 1998 09:32:25 +1000 (EST)
Cc: jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG, tlambert@primenet.com
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
Simon Coggins wrote:
> That was quick! :) Any ETA on a release of it?
I'll commit it now.
I'm still working on another problem with thread specific data that
shows up in the ACE tests (as reported by Amancio).
--
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 Fri Jun 5 17:01:42 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id RAA16190
for freebsd-current-outgoing; Fri, 5 Jun 1998 17:01:42 -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 RAA16174
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 17:01:33 -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 TAA10173;
Fri, 5 Jun 1998 19:00:38 -0500
Received: (from joelh@localhost)
by detlev.UUCP (8.8.8/8.8.8) id TAA00646;
Fri, 5 Jun 1998 19:01:33 -0500 (CDT)
(envelope-from joelh)
Date: Fri, 5 Jun 1998 19:01:33 -0500 (CDT)
Message-Id: <199806060001.TAA00646@detlev.UUCP>
To: rcarter@pinyon.org
CC: current@FreeBSD.ORG
In-reply-to: <199806051732.KAA15423@ConSys.COM> (rcarter@pinyon.org)
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
From: Joel Ray Holveck <joelh@gnu.org>
Reply-to: joelh@gnu.org
References: <199806051732.KAA15423@ConSys.COM>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> My major blunder was to attempt to trip
> trap across the bridge with just a make all install.
Funny, I was under the impression that make all install worked fine.
Then back to my earlier question... Is there a way to not have to
rebuild the whole world, only what's changed?
Thanks,
joelh
--
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 Fri Jun 5 18:36:00 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id SAA29242
for freebsd-current-outgoing; Fri, 5 Jun 1998 18:36:00 -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 SAA29232
for <current@freebsd.org>; Fri, 5 Jun 1998 18:35:54 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id UAA00595
for current@freebsd.org; Fri, 5 Jun 1998 20:35:51 -0500 (EST)
(envelope-from toor)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199806060135.UAA00595@dyson.iquest.net>
Subject: New SMP perf/quality snapshot
To: current@FreeBSD.ORG
Date: Fri, 5 Jun 1998 20:35:51 -0500 (EST)
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 have placed a new SMP quality/performance snapshot on:
http://www.freebsd.org/~dyson/sysjun05.diff.gz
If this works out, it will be the basis for alot of bugfixes
in -current, related to both SMP and UP problems. Note that
this code has been tested only on a P6 machine, in both
UP and SMP mode. The P5 codepaths are slightly different, and
might have a bug or two. If this appears to work okay, I'll
ready the (P5 and earlier) codepaths, and move forward with it.
John
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 19:12:52 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id TAA03945
for freebsd-current-outgoing; Fri, 5 Jun 1998 19:12:52 -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 TAA03720
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 19:11:13 -0700 (PDT)
(envelope-from grog@freebie.lemis.com)
Received: (from grog@localhost)
by freebie.lemis.com (8.9.0/8.9.0) id LAA08945;
Sat, 6 Jun 1998 11:40:34 +0930 (CST)
Message-ID: <19980606114034.T768@freebie.lemis.com>
Date: Sat, 6 Jun 1998 11:40:34 +0930
From: Greg Lehey <grog@lemis.com>
To: shimon@simon-shapiro.org
Cc: Mike Smith <mike@smith.net.au>, Bob Willcox <bob@luke.pmr.com>,
Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Subject: Re: DPT driver fails and panics with Degraded Array
References: <19980605093349.K768@freebie.lemis.com> <XFMail.980605160450.shimon@simon-shapiro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <XFMail.980605160450.shimon@simon-shapiro.org>; from Simon Shapiro on Fri, Jun 05, 1998 at 04:04:50PM -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 Fri, 5 June 1998 at 16:04:50 -0400, Simon Shapiro wrote:
> On 05-Jun-98 Greg Lehey wrote:
>>> Actually, SMP interrupt service is slow enough that this probably never
>>> has
>>> a chance to show at all.
>>
>> No way. Murphy is particularly unforgiving when it comes to race
>> conditions in interrupt handlers. Have 50 interrupts a second from
>> two processors, and sooner or later you're going to hit it.
>
> Then my theory as to what causes it is useless :-) Still, SMP is the least
> sensitive (as in ``never seen here'') to this problem.
This would suggest that the problem is elsewhere, then.
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 Fri Jun 5 21:39:33 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id VAA18254
for freebsd-current-outgoing; Fri, 5 Jun 1998 21:39:33 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from ConSys.COM ([209.141.107.2])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA18249
for <current@freebsd.org>; Fri, 5 Jun 1998 21:39:32 -0700 (PDT)
(envelope-from rcarter@psf.Pinyon.ORG)
Received: from psf.Pinyon.ORG (ip-17-230.prc.primenet.com [207.218.17.230])
by ConSys.COM (8.8.6/8.8.6) with ESMTP id VAA17522;
Fri, 5 Jun 1998 21:39:27 -0700 (MST)
Received: from psf.Pinyon.ORG (localhost [127.0.0.1])
by psf.Pinyon.ORG (8.8.8/8.8.7) with ESMTP id VAA16873;
Fri, 5 Jun 1998 21:37:51 -0700 (MST)
Message-Id: <199806060437.VAA16873@psf.Pinyon.ORG>
X-Mailer: exmh version 2.0.2 2/24/98
To: joelh@gnu.org, current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-reply-to: Your message of "Fri, 05 Jun 1998 19:01:33 EST."
<199806060001.TAA00646@detlev.UUCP>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 05 Jun 1998 21:37:50 -0700
From: "Russell L. Carter" <rcarter@pinyon.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
>
> > My major blunder was to attempt to trip
> > trap across the bridge with just a make all install.
>
> Funny, I was under the impression that make all install worked fine.
> Then back to my earlier question... Is there a way to not have to
> rebuild the whole world, only what's changed?
*Usually*, cvsup ; make all install (actually: make all ; snoop around ;
make install) works just fine. But I should have known better,
obviously moving libs and the batch of changes to support elf
is one of them thar paradigm shifts that demand a trifle more
attention to the build. No big deal, I almost hosed my 2nd
-current in 5 years, but rescued it from the brink. That's
not a bad record, and a major tribute to the architecture of
the world build process.
Anyway, I am now back to happy make worlds, oh what a feeling!
Cheers,
Russell
>
> Thanks,
> joelh
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 21:48:53 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id VAA19548
for freebsd-current-outgoing; Fri, 5 Jun 1998 21:48:53 -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 VAA19543
for <current@FreeBSD.ORG>; Fri, 5 Jun 1998 21:48:52 -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 VAA03291;
Fri, 5 Jun 1998 21:48:44 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
To: Alfred Perlstein <perlsta@fang.cs.sunyit.edu>
cc: current@FreeBSD.ORG
Subject: Re: current build breakage
In-reply-to: Your message of "Fri, 05 Jun 1998 14:14:33 -0000."
<Pine.BSF.3.95.980605141258.16941A-100000@fang.cs.sunyit.edu>
Date: Fri, 05 Jun 1998 21:48:43 -0700
Message-ID: <3287.897108523@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Do it again (and use the buildworld target, of course). I've already
committed a fix.
> as of ~11am EST on -current:
>
> missing: ./tmp (created)
> missing: ./tmp/vi.recover (created)
> missing: ./yp (created)
> if [ -d /usr/obj/usr/src/tmp/usr/share/locale ] ; then cd
> /usr/obj/usr/src/tmp/usr/share/locale; for l in da_DK de_AT de_CH
> de_DE en_AU en_CA en_GB en_US es_ES fi_FI fr_BE fr_CA fr_CH fr_FR is_IS
> it_CH it_IT nl_BE nl_NL no_NO pt_PT sv_SE ; do if [ -h $l.ISO_8859-1 ];
> then rm $l.ISO_8859-1; fi ; done; fi
> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr
> mtree: line 58: unknown keyword nochange
> *** Error code 1
>
> Stop.
> *** Error code 1
>
> Stop.
> *** Error code 1
>
> Stop.
> #
>
> -Alfred
>
>
> 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 Fri Jun 5 22:18:28 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id WAA22747
for freebsd-current-outgoing; Fri, 5 Jun 1998 22:18:28 -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 WAA22730;
Fri, 5 Jun 1998 22:18:23 -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 WAA03559;
Fri, 5 Jun 1998 22:17:57 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
To: Terry Lambert <tlambert@primenet.com>
cc: ache@nagual.pp.ru (=?koi8-r?B?4c7E0sXKIP7F0s7P1w==?=),
peter@netplex.com.au, current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-reply-to: Your message of "Fri, 05 Jun 1998 21:21:39 -0000."
<199806052121.OAA04575@usr08.primenet.com>
Date: Fri, 05 Jun 1998 22:17:56 -0700
Message-ID: <3555.897110276@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> My gut feeling would be to put variant symbolic links in, and use a
> dollarsign ("$") to designate a kernel variant keyword:
>
> ln -s "/usr/lib.\${\$imgact}" /usr/lib
Yuck. That's gross and you know it's gross, so I won't even try to
argue the point. Why the gratuitous complication? Just accept $foo
or ${foo} as the usual convention and, if you're absolutely dead-set
against having the kernel grub around in the user's actual environment
for this information, have it look in a logical name table someplace
with a new sysctl()'ish API for frobbing it. Too bad sysctl(8)
doesn't allow one to add new variables dynamically when the system is
up, you could even use sysctl for this one.
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Fri Jun 5 22:21:21 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id WAA23231
for freebsd-current-outgoing; Fri, 5 Jun 1998 22:21: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 WAA23226
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 22:21:20 -0700 (PDT)
(envelope-from shimon@sendero.simon-shapiro.org)
Received: (qmail 29233 invoked by uid 1000); 5 Jun 1998 21:23:12 -0000
Message-ID: <XFMail.980605172312.shimon@simon-shapiro.org>
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: <19980605093046.J768@freebie.lemis.com>
Date: Fri, 05 Jun 1998 17:23:12 -0400 (EDT)
Reply-To: shimon@simon-shapiro.org
Organization: The Simon Shapiro Foundation
From: Simon Shapiro <shimon@simon-shapiro.org>
To: Greg Lehey <grog@lemis.com>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Mike Smith <mike@smith.net.au>, Karl Pielorz <kpielorz@tdx.co.uk>,
tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 05-Jun-98 Greg Lehey wrote:
> On Thu, 4 June 1998 at 12:00:46 -0400, Simon Shapiro wrote:
>>
>> 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.
>
> That in itself is normal enough. How come it's not busy?
I dunno. From the driver, when biodone needs to be called, I enter a
critical section, move the block to the proper queue, call biodone, clear
some bits, and release critical section. Maybe something times out some
blocks? I tried for a while to trace it down, but found nothing
interesting.
...
> I don't know the driver, but I'm surprised you need to maintain
> separate information. I'd use the state in the bp->b_flags.
I do not replicate b_flags. I do maintain some other state bits in regards
to the DPT state machine.
>> 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 haven't seen a driver called st.c in CAM. They've changed the
> names, and the tape driver is now called scsi_sa.c. st.c is the old
> tape driver. How do you determine "greatest sensitivity"?
If I run (including in 3.0, and SMP) two cpio sessions to two tape drives,
the system panics. I can access multiple disks, or multiple CD-ROMs
without error, but it is easiest to induce an error with two tape drives.
> In any case, I can't see how a different driver can influence things.
> Heavy tape I/O may help the problem to show itself, but I can't think
> it's in any way to blame.
Next time I am running multiple tape drives, I will write dowm the failure
mode. But things happen like when one tape is rewinding, the other one
stops writing as it suddenly ``is'' at EOT. Stuff like that.
Please do not go chasing code, as this is a horrible way to describe a
problem. I'll post more specifics at a later date.
...
>> Are you using two tape drives, and write to both concurrently, using 64k
>> blocks?
>
> Occasionally.
Without failure? That's good.
>> 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?
>
> Well, I suppose each of the controllers could generate a number of
> interrupts per second, so sooner or later that scenario would arise.
> But as I said above, there's nothing to point to the st driver except
> it's the new kid on the block. What you have said points fairly and
> squarely to the DPT driver as the culprit.
I fail to see how. Read my comments carefully. I am not of the opinion
that the tape driver is at fault. I simply say that I observe the failure
most dramatically when using DAT drives as destination.
For example, last time I tried, I could not write tapes with any blocking
factor other than 512 bytes, and still be able to read the tape correctly.
When writing to disks, this restriction does not apply. Since the code in
the DPT driver is the same, regardless of the nature of the target (or its
address), I naively assumed the DPT driver is not the culprit.
> OK. What happens if you analyse the buffer header before calling
> biodone and just ignore it if it's not busy?
I dunno. Excellent suggestion. I'll try that. Anyone willing to test
that?
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 Fri Jun 5 22:22:50 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id WAA23630
for freebsd-current-outgoing; Fri, 5 Jun 1998 22:22:50 -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 WAA23610
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 22:22:42 -0700 (PDT)
(envelope-from shimon@sendero.simon-shapiro.org)
Received: (qmail 6245 invoked by uid 1000); 5 Jun 1998 21:24:33 -0000
Message-ID: <XFMail.980605172433.shimon@simon-shapiro.org>
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: <19980605000101.27550@mi.uni-koeln.de>
Date: Fri, 05 Jun 1998 17:24:33 -0400 (EDT)
Reply-To: shimon@simon-shapiro.org
Organization: The Simon Shapiro Foundation
From: Simon Shapiro <shimon@simon-shapiro.org>
To: Stefan Esser <se@FreeBSD.ORG>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Greg Lehey <grog@lemis.com>, Mike Smith <mike@smith.net.au>,
Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>, Bob Willcox <bob@luke.pmr.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 04-Jun-98 Stefan Esser wrote:
...
>> 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.
>
> Is this really necessary with certain revisions of the DPT
> firmware ? Reading a device register should delay just for
> the minimum time required. Did you try that ?
No, it is not necessary. Yes, this is how the DPT driver works.
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 Fri Jun 5 22:51:27 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id WAA26518
for freebsd-current-outgoing; Fri, 5 Jun 1998 22:51:27 -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 WAA26512;
Fri, 5 Jun 1998 22:51:24 -0700 (PDT)
(envelope-from tlambert@usr08.primenet.com)
Received: (from daemon@localhost)
by smtp01.primenet.com (8.8.8/8.8.8) id WAA29960;
Fri, 5 Jun 1998 22:51:23 -0700 (MST)
Received: from usr08.primenet.com(206.165.6.208)
via SMTP by smtp01.primenet.com, id smtpd029926; Fri Jun 5 22:51:18 1998
Received: (from tlambert@localhost)
by usr08.primenet.com (8.8.5/8.8.5) id WAA29701;
Fri, 5 Jun 1998 22:50:49 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199806060550.WAA29701@usr08.primenet.com>
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Sat, 6 Jun 1998 05:50:49 +0000 (GMT)
Cc: tlambert@primenet.com, ache@nagual.pp.ru, peter@netplex.com.au,
current@FreeBSD.ORG, ports@FreeBSD.ORG
In-Reply-To: <3555.897110276@time.cdrom.com> from "Jordan K. Hubbard" at Jun 5, 98 10:17:56 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
> > My gut feeling would be to put variant symbolic links in, and use a
> > dollarsign ("$") to designate a kernel variant keyword:
> >
> > ln -s "/usr/lib.\${\$imgact}" /usr/lib
>
> Yuck. That's gross and you know it's gross, so I won't even try to
> argue the point. Why the gratuitous complication? Just accept $foo
> or ${foo} as the usual convention and, if you're absolutely dead-set
> against having the kernel grub around in the user's actual environment
> for this information, have it look in a logical name table someplace
> with a new sysctl()'ish API for frobbing it.
The backslash has to do with the double quotes (as opposed to using
single quote).
> Too bad sysctl(8)
> doesn't allow one to add new variables dynamically when the system is
> up, you could even use sysctl for this one.
I wanted to make it so you could avoid the escape. If it's not an issue
(I have a damn hard time finding an example of a legacy implementation
that depends on it... I suspect there are none), then making the escape
non-transparent is a better method.
This was sort of a preemptive strike against people who would bitch on
principle rather than fact... we know who we are... 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 Fri Jun 5 23:04:11 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA28096
for freebsd-current-outgoing; Fri, 5 Jun 1998 23:04:11 -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 XAA28085
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 23:04:09 -0700 (PDT)
(envelope-from shimon@sendero.simon-shapiro.org)
Received: (qmail 14947 invoked by uid 1000); 5 Jun 1998 19:59:19 -0000
Message-ID: <XFMail.980605155919.shimon@simon-shapiro.org>
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: <19980605085459.A9510@pmr.com>
Date: Fri, 05 Jun 1998 15:59:19 -0400 (EDT)
Reply-To: shimon@simon-shapiro.org
Organization: The Simon Shapiro Foundation
From: Simon Shapiro <shimon@simon-shapiro.org>
To: Bob Willcox <bob@luke.pmr.com>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Stefan Esser <se@FreeBSD.ORG>, Greg Lehey <grog@lemis.com>,
Mike Smith <mike@smith.net.au>, Karl Pielorz <kpielorz@tdx.co.uk>,
tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 05-Jun-98 Bob Willcox wrote:
> On Fri, Jun 05, 1998 at 12:01:01AM +0200, Stefan Esser wrote:
>> On 1998-06-04 12:12 -0400, Simon Shapiro <shimon@simon-shapiro.org>
>> wrote:
>> > 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.
>>
>> This is a design "feature" of PCI, actually, and well documented.
>>
>> The interrupt lines are directly connected to the chip-set (or
>> possibly the CPU in non-Intel PCI systems) and for that reason,
>> there may for example be as many outstanding memory writes in
>> write-buffers as their FIFO depths allow, when the end-of-transfer
>> interrupt is recognized by the CPU.
>>
>> There is a documented protocol to flush all write buffers: Just
>> read some device register at the start of the interrupt handler
>> (i.e. before trying to access common data structures in memory,
>> that are used for communication between CPU and an intelligent
>> device). The read will be blocked until all buffers are flushed.
>
> Hmm, well my AIX device driver did this. The first thing it did was to
> read the HA_AUX_STATUS register on the adapter to see if an interrupt
> was pending for it (a pretty common thing to do I think). Note that I
> never saw the problem running on my (Motorola) UP test system. Bull saw
> it quite regularly on their MP systems, though.
So does the DPT driver for FreeBSD. It is in the publicly available source
code :-)
DPTs position was that they are PCI compliant. This position proved
correct when the failed system was replaced with one sporting a later
generation PCI-PCI bridge. It worked correctly.
I have a feeling that anyone who have written a DPT driver suffered to some
degree through the same issues. These low level hardware dependencies were
ironed out long ago. Not in small part due to execellent support from Mark
Salyzyn from DPT and Mike Neuffer who wrote the Linux DPT drivers.
As to the relevance of this thread to the origin, my experience tells me
that if these issues are part of the equation, they show up very early and
very severely, and not in the manner posted here. The conditional code in
the FreeBSD driver (in particular the 2.2 version) is well documented by
now and can be used to verify the source of the problem, if any.
Simon
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 Fri Jun 5 23:05:57 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA28409
for freebsd-current-outgoing; Fri, 5 Jun 1998 23:05:57 -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 XAA28404
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 23:05:56 -0700 (PDT)
(envelope-from shimon@sendero.simon-shapiro.org)
Received: (qmail 23929 invoked by uid 1000); 5 Jun 1998 20:01:08 -0000
Message-ID: <XFMail.980605160108.shimon@simon-shapiro.org>
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: <199806041741.KAA00849@dingo.cdrom.com>
Date: Fri, 05 Jun 1998 16:01:08 -0400 (EDT)
Reply-To: shimon@simon-shapiro.org
Organization: The Simon Shapiro Foundation
From: Simon Shapiro <shimon@simon-shapiro.org>
To: Mike Smith <mike@smith.net.au>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Greg Lehey <grog@lemis.com>, Bob Willcox <bob@luke.pmr.com>,
Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 04-Jun-98 Mike Smith wrote:
>>
>> 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.
I will not swear the driver does not call biodone twice (in error), but I
could never prove that it does. Neither from logical/code analysis, nor
from observation.
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 Fri Jun 5 23:09:43 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA28924
for freebsd-current-outgoing; Fri, 5 Jun 1998 23:09:43 -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 XAA28919
for <freebsd-current@FreeBSD.ORG>; Fri, 5 Jun 1998 23:09:39 -0700 (PDT)
(envelope-from shimon@sendero.simon-shapiro.org)
Received: (qmail 12781 invoked by uid 1000); 5 Jun 1998 20:04:50 -0000
Message-ID: <XFMail.980605160450.shimon@simon-shapiro.org>
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: <19980605093349.K768@freebie.lemis.com>
Date: Fri, 05 Jun 1998 16:04:50 -0400 (EDT)
Reply-To: shimon@simon-shapiro.org
Organization: The Simon Shapiro Foundation
From: Simon Shapiro <shimon@simon-shapiro.org>
To: Greg Lehey <grog@lemis.com>
Subject: Re: DPT driver fails and panics with Degraded Array
Cc: Mike Smith <mike@smith.net.au>, Bob Willcox <bob@luke.pmr.com>,
Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>,
"freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>,
Michael Hancock <michaelh@cet.co.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On 05-Jun-98 Greg Lehey wrote:
...
>> Actually, SMP interrupt service is slow enough that this probably never
>> has
>> a chance to show at all.
>
> No way. Murphy is particularly unforgiving when it comes to race
> conditions in interrupt handlers. Have 50 interrupts a second from
> two processors, and sooner or later you're going to hit it.
Then my theory as to what causes it is useless :-) Still, SMP is the least
sensitive (as in ``never seen here'') to this problem.
As an aside, I cannot, under SMP get the same number of I/Os per second as
UP. Is it a FreeBSD thing, or Simon/DPT thing?
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 Fri Jun 5 23:28:23 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA00816
for freebsd-current-outgoing; Fri, 5 Jun 1998 23:28:23 -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 XAA00810
for <freebsd-current@freebsd.org>; Fri, 5 Jun 1998 23:28:14 -0700 (PDT)
(envelope-from joelh@gnu.org)
Received: from detlev.UUCP (tex-63.camalott.com [208.229.74.63] (may be forged))
by mail.camalott.com (8.8.7/8.8.5) with ESMTP id BAA29770;
Sat, 6 Jun 1998 01:27:16 -0500
Received: (from joelh@localhost)
by detlev.UUCP (8.8.8/8.8.8) id BAA08835;
Sat, 6 Jun 1998 01:28:11 -0500 (CDT)
(envelope-from joelh)
Date: Sat, 6 Jun 1998 01:28:11 -0500 (CDT)
Message-Id: <199806060628.BAA08835@detlev.UUCP>
To: freebsd-current@FreeBSD.ORG
Subject: gcc 2.8.1 port
From: Joel Ray Holveck <joelh@gnu.org>
Reply-to: joelh@gnu.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
I'm looking at updating our gcc 2.8.1 port to allow for our recent
a.out/elf split. If possible, I'd like to add support for both elf
and a.out in one compiler while I'm at it. I had in mind just
changing the freebsd.h file. Is this possible to do, just by updating
freebsd.h? But from what I can tell, the .h file can handle it.
Is the situation probably stable enough that I can go ahead and do
this, and not have to redo it next week?
Finally, is anybody else working on this, or has somebody already
written it?
Happy hacking,
joelh
--
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 Sat Jun 6 00:40:38 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id AAA05732
for freebsd-current-outgoing; Sat, 6 Jun 1998 00:40:38 -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 AAA05713
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 00:40:12 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id CAA10046;
Sat, 6 Jun 1998 02:30:48 -0500 (EST)
(envelope-from toor)
Message-Id: <199806060730.CAA10046@dyson.iquest.net>
Subject: Re: New SMP perf/quality snapshot (Update)
In-Reply-To: <199806060135.UAA00595@dyson.iquest.net> from "John S. Dyson" at "Jun 5, 98 08:35:51 pm"
To: toor@dyson.iquest.net (John S. Dyson)
Date: Sat, 6 Jun 1998 02:30:48 -0500 (EST)
Cc: current@FreeBSD.ORG
From: "John S. Dyson" <dyson@FreeBSD.ORG>
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 S. Dyson said:
> I have placed a new SMP quality/performance snapshot on:
>
> http://www.freebsd.org/~dyson/sysjun05.diff.gz
>
> If this works out, it will be the basis for alot of bugfixes
> in -current, related to both SMP and UP problems. Note that
> this code has been tested only on a P6 machine, in both
> UP and SMP mode. The P5 codepaths are slightly different, and
> might have a bug or two. If this appears to work okay, I'll
> ready the (P5 and earlier) codepaths, and move forward with it.
>
New file:
http://www.freebsd.org/~dyson/sysjun06.diff.gz
Bugfixes, improvement of zero idle loop, disable PPro zero
optimizations for now (looks like algorithmic bug of some
kind.)
--
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 Sat Jun 6 01:49:21 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id BAA08876
for freebsd-current-outgoing; Sat, 6 Jun 1998 01:49:21 -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 BAA08871;
Sat, 6 Jun 1998 01:49:16 -0700 (PDT)
(envelope-from mantar@netcom.com)
Received: from dual (DUAL [192.168.0.2])
by pozo.com (8.8.8/8.8.8) with SMTP id BAA00324;
Sat, 6 Jun 1998 01:49:14 -0700 (PDT)
(envelope-from mantar@netcom.com)
Message-Id: <199806060849.BAA00324@pozo.com>
X-Sender: null@192.168.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Date: Sat, 06 Jun 1998 01:49:13 -0700
To: dyson@FreeBSD.ORG
From: Manfred Antar <mantar@netcom.com>
Subject: Re: New SMP perf/quality snapshot (Update)
Cc: current@FreeBSD.ORG
In-Reply-To: <199806060730.CAA10046@dyson.iquest.net>
References: <199806060135.UAA00595@dyson.iquest.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
At 02:30 AM 6/6/98 -0500, you wrote:
>John S. Dyson said:
>> I have placed a new SMP quality/performance snapshot on:
>>
>> http://www.freebsd.org/~dyson/sysjun05.diff.gz
>>
>> If this works out, it will be the basis for alot of bugfixes
>> in -current, related to both SMP and UP problems. Note that
>> this code has been tested only on a P6 machine, in both
>> UP and SMP mode. The P5 codepaths are slightly different, and
>> might have a bug or two. If this appears to work okay, I'll
>> ready the (P5 and earlier) codepaths, and move forward with it.
>>
>
>New file:
>
>http://www.freebsd.org/~dyson/sysjun06.diff.gz
>
>Bugfixes, improvement of zero idle loop, disable PPro zero
>optimizations for now (looks like algorithmic bug of some
>kind.)
>
>--
John I just tried this on a Intel PR440FX dual 180 ppro.
The system locks up just after login:
I can't get into debugger, the machine is frozen.
I have xdm running. could it be that when the Xserver is about to start
it locks up the machine ?
The video card is a matrox millennium w/4mb vram.
That's the only card plugged into the system.
There is one seagate 4gig drive running off the embedded aic7880.
Should I do a make world with the new files before building a kernel ?
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 Sat Jun 6 04:12:05 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id EAA24525
for freebsd-current-outgoing; Sat, 6 Jun 1998 04:12:05 -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 EAA24509
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 04:12:02 -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 VAA10115;
Sat, 6 Jun 1998 21:11:58 +1000
Date: Sat, 6 Jun 1998 21:11:58 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199806061111.VAA10115@godzilla.zeta.org.au>
To: bde@zeta.org.au, current@FreeBSD.ORG, straka@home.com
Subject: Re: strange behavior with signal latencies
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
>BTW, these latancy times really go out the window (10+ms ) when
>the system is loaded with disk writing or network activity. I have performed
>similar tests on an Ultra 30 box running Solaris 2.6. Even under extreme
>loading, the latencies stay below 1ms (its no VxWorks, but it ain't bad for
>soft
>realtime). It appears that Solaris does very little work in hardware
>interrupts,
>defering work to preemtable kernel threads which are under control of the
>scheduler. They offer a realtime scheduling class which has higher priority
>than their system scheduling class. The amount of work we currently do in
>FreeBSD in hardware and software interrupts coupled with the
>non-preemtable nature of kernel activity precludes us from doing even
>soft realtime work.
Even software interrupts can be masked for several clock ticks if the
system is overloaded. It is easy to overload systems using silly hardware
configurations. E.g., take any modern IDE drive with a throughput
of 9MB connected to an old PIO1 interface with a throughput of 3MB.
Then writing a 1MB will take at least 1/3 second entirely in the kernel,
and if the kernel manages to queue 1MB of buffers, accessing them will
take at least 1/3 second entirely in h/w interrupt handlers (unless the
disk has to seek).
Fix: don't use silly hardware configurations :-).
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 04:36:27 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id EAA26325
for freebsd-current-outgoing; Sat, 6 Jun 1998 04:36:27 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA26319
for <current@freebsd.org>; Sat, 6 Jun 1998 04:36:24 -0700 (PDT)
(envelope-from rb@gid.co.uk)
Received: from gid.co.uk (uucp@localhost)
by isbalham.ist.co.uk (8.8.7/8.8.7) with UUCP id MAA13101
for freebsd.org!current; Sat, 6 Jun 1998 12:35:33 +0100 (BST)
(envelope-from rb@gid.co.uk)
Received: from [194.32.164.2] by seagoon.gid.co.uk; Sat, 6 Jun 1998 12:31:51 +0100 (BST)
X-Sender: rb@194.32.164.1
Message-Id: <l03020908b19ed8f9add6@[194.32.164.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 6 Jun 1998 12:38:16 +0100
To: current@FreeBSD.ORG
From: Bob Bishop <rb@gid.co.uk>
Subject: Spurious SIGXCPU
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Hi,
Just had a buildworld stop during cleaning up the object tree with:
===> sbin/mount_union
*** Signal 24
Stop.
*** Error code 1 [etc]
Doesn't seem to be repeatable. This is with src-cur 3401
--
Bob Bishop (0118) 977 4017 international code +44 118
rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 06:24:03 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id GAA02144
for freebsd-current-outgoing; Sat, 6 Jun 1998 06:24:03 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from IAEhv.nl (root@iaehv.IAEhv.nl [194.151.64.2])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA02112
for <current@freebsd.org>; Sat, 6 Jun 1998 06:23:59 -0700 (PDT)
(envelope-from wjw@surf.IAEhv.nl)
Received: from surf.IAEhv.nl (root@surf.IAEhv.nl [194.151.66.2])
by IAEhv.nl (8.8.7/8.8.7) with ESMTP id PAA23237;
Sat, 6 Jun 1998 15:23:58 +0200 (CEST)
Received: (from wjw@localhost)
by surf.IAEhv.nl (8.8.7/8.8.7) id PAA08967;
Sat, 6 Jun 1998 15:23:58 +0200 (MET DST)
Date: Sat, 6 Jun 1998 15:23:58 +0200 (MET DST)
From: Willem Jan Withagen <wjw@surf.IAEhv.nl>
Message-Id: <199806061323.PAA08967@surf.IAEhv.nl>
To: jkh@time.cdrom.com
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
X-Newsgroups: list.freebsd.current
In-Reply-To: <3555.897110276@time.cdrom.com>
References: <199806052121.OAA04575@usr08.primenet.com>
Organization: Internet Access Eindhoven, the Netherlands
Cc: current@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <3555.897110276@time.cdrom.com> you write:
>> My gut feeling would be to put variant symbolic links in, and use a
>> dollarsign ("$") to designate a kernel variant keyword:
>>
>> ln -s "/usr/lib.\${\$imgact}" /usr/lib
>
>Yuck. That's gross and you know it's gross, so I won't even try to
>argue the point. Why the gratuitous complication? Just accept $foo
>or ${foo} as the usual convention and, if you're absolutely dead-set
>against having the kernel grub around in the user's actual environment
>for this information, have it look in a logical name table someplace
>with a new sysctl()'ish API for frobbing it. Too bad sysctl(8)
>doesn't allow one to add new variables dynamically when the system is
>up, you could even use sysctl for this one.
I do not want to debate the actual implemented syntax. But comming from
Apollo Domain OS this "feature" was one the the first things I missed when
going to "real" Unix. So I would really find this an enhancement to FreeBSD.
Apollo Domain OS had three faces: BSD, SysV and Domain OS and depending the
OStype ENV you set, you would get the different types of programma's lib's
etc. This all due to the "variant symbolic links".
I myself used it al lot to switch between several versions of home-made
compiler-tools, and to maintain several versions of the /usr/local and
/usr/experiment trees on one file server without all the hassle of redoing
all links once a system would get upgraded.
Now for the syntax, one would just do:
ln -s '/usr/lib.${imgact}' /usr/lib
So the file/link name would contain the expansion text.
Too bad I don't really have the time to do serious programming any longer,
as this would be fun to do.
--WjW
--
Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606
P.O. 928, 5600 AX Eindhoven, The Netherlands
Full Internet connectivity for only fl 12.95 a month.
Call now, and login as 'new'.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 06:29:17 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id GAA02576
for freebsd-current-outgoing; Sat, 6 Jun 1998 06:29:17 -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 GAA02568
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 06:29:13 -0700 (PDT)
(envelope-from pierre.dampure@k2c.co.uk)
Received: (qmail 19360 invoked from network); 6 Jun 1998 13:29:08 -0000
Received: from userb013.uk.uudial.com (HELO jfsebastian) (193.149.69.250)
by smtp.dial.pipex.com with SMTP; 6 Jun 1998 13:29:08 -0000
Message-ID: <002001bd914e$7460cee0$0242000a@jfsebastian.k2c.co.uk>
From: "Pierre Y. Dampure" <pierre.dampure@k2c.co.uk>
To: <dyson@FreeBSD.ORG>, "John S. Dyson" <toor@dyson.iquest.net>
Cc: <current@FreeBSD.ORG>
Subject: Re: New SMP perf/quality snapshot (Update)
Date: Sat, 6 Jun 1998 14:24:21 +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
Just finished a make world w/ your mods on -current CVSupped 11:30AM BST
(BTW, there's a cock-up with the LKM version of ipfw that breaks make world
at the moment).
I AM PLEASED TO REPORT THAT MODULA-3 MOW BUILDS PERFECTLY OK UNDER AN SMP
KERNEL W/ YOUR MODS APPLIED !!! (for those who do not remember, building
Modula-3 under an SMP kernel was broken for the last two months).
However, there is still this nagging issue of silo overflows at an alarming
rate; this does not show if I do not apply your mods.
Congratulations for the improvements !
Best Regards,
Pierre Y.
-----Original Message-----
From: John S. Dyson <dyson@FreeBSD.ORG>
To: John S. Dyson <toor@dyson.iquest.net>
Cc: current@FreeBSD.ORG <current@FreeBSD.ORG>
Date: 06 June 1998 08:57
Subject: Re: New SMP perf/quality snapshot (Update)
>John S. Dyson said:
>> I have placed a new SMP quality/performance snapshot on:
>>
>> http://www.freebsd.org/~dyson/sysjun05.diff.gz
>>
>> If this works out, it will be the basis for alot of bugfixes
>> in -current, related to both SMP and UP problems. Note that
>> this code has been tested only on a P6 machine, in both
>> UP and SMP mode. The P5 codepaths are slightly different, and
>> might have a bug or two. If this appears to work okay, I'll
>> ready the (P5 and earlier) codepaths, and move forward with it.
>>
>
>New file:
>
>http://www.freebsd.org/~dyson/sysjun06.diff.gz
>
>Bugfixes, improvement of zero idle loop, disable PPro zero
>optimizations for now (looks like algorithmic bug of some
>kind.)
>
>--
>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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 07:08:33 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id HAA05626
for freebsd-current-outgoing; Sat, 6 Jun 1998 07:08:33 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from thing.dyn.ml.org (root@dyn1-tnt13-164.detroit.mi.ameritech.net [199.179.188.164])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA05620
for <current@freebsd.org>; Sat, 6 Jun 1998 07:08:30 -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 KAA02429
for <current@freebsd.org>; Sat, 6 Jun 1998 10:08:29 -0400 (EDT)
(envelope-from mcdougall@ameritech.net)
Message-ID: <35794D5B.5791AF34@ameritech.net>
Date: Sat, 06 Jun 1998 10:08:28 -0400
From: Adam McDougall <mcdougall@ameritech.net>
Reply-To: mcdougall@ameritech.net
X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 3.0-CURRENT i386)
MIME-Version: 1.0
To: current@FreeBSD.ORG
Subject: breakage in ipfw lkm
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
I didnt see any other emails about this so..
===> ipfw
cc -O -pipe -DIPFIREWALL -DIPFIREWALL_MODULE -aout -DKERNEL
-DACTUALLY_LKM_NOT_KERNEL -Wreturn-type -Wcomment -Wredundant-decls
-Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wuninitialized -ansi -nostdinc -I-
-I/usr/obj/asynch/src/lkm/ipfw -I/usr/obj/asynch/src/lkm/ipfw/@ -c
/asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c
/asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c: In function `ip_fw_chk':
/asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c:617:
`ip_divert_in_cookie' undeclared (first use this function)
/asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c:617: (Each undeclared
identifier is reported only once
/asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c:617: for each function it
appears in.)
*** Error code 1
Stop.
*** Error code 1
Stop.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 08:12:21 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id IAA11158
for freebsd-current-outgoing; Sat, 6 Jun 1998 08:12:21 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from news1.gtn.com (news1.gtn.com [192.109.159.3])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11150;
Sat, 6 Jun 1998 08:12:15 -0700 (PDT)
(envelope-from andreas@klemm.gtn.com)
Received: (from uucp@localhost)
by news1.gtn.com (8.8.6/8.8.6) with UUCP id RAA19647;
Sat, 6 Jun 1998 17:00:07 +0200 (MET DST)
Received: (from andreas@localhost)
by klemm.gtn.com (8.8.8/8.8.8) id QAA22365;
Sat, 6 Jun 1998 16:22:54 +0200 (CEST)
(envelope-from andreas)
Message-ID: <19980606162254.A21933@klemm.gtn.com>
Date: Sat, 6 Jun 1998 16:22:54 +0200
From: Andreas Klemm <andreas@klemm.gtn.com>
To: dyson@FreeBSD.ORG, "John S. Dyson" <toor@dyson.iquest.net>
Cc: current@FreeBSD.ORG
Subject: Re: New SMP perf/quality snapshot (Update)
References: <199806060135.UAA00595@dyson.iquest.net> <199806060730.CAA10046@dyson.iquest.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <199806060730.CAA10046@dyson.iquest.net>; from John S. Dyson on Sat, Jun 06, 1998 at 02:30:48AM -0500
X-Disclaimer: A free society is one where it is safe to be unpopular
X-Operating-System: FreeBSD 3.0-CURRENT SMP
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Sat, Jun 06, 1998 at 02:30:48AM -0500, John S. Dyson wrote:
> New file:
> http://www.freebsd.org/~dyson/sysjun06.diff.gz
> Bugfixes, improvement of zero idle loop, disable PPro zero
> optimizations for now (looks like algorithmic bug of some
> kind.)
While trying to compile with softupdate ...
cc -c -O -pipe -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit
-Wnested-ex
terns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wunini
tialized -ansi -nostdinc -I- -I. -I../.. -I/usr/include -DTELES_HAS_MEMCPYB
-DP
SM_ACCEL=1 -DNMBCLUSTER=4096 -DSOMAXCONN=256 -DKERNEL -include opt_global.h
../
../ufs/ffs/ffs_softdep.c
../../ufs/ffs/ffs_softdep.c: In function `softdep_setup_freeblocks':
../../ufs/ffs/ffs_softdep.c:1668: structure has no member named `lh_first'
../../ufs/ffs/ffs_softdep.c:1669: structure has no member named `lh_first'
../../ufs/ffs/ffs_softdep.c: At top level:
../../ufs/ffs/ffs_softdep.c:2680: warning: function declaration isn't a
prototyp
e
../../ufs/ffs/ffs_softdep.c: In function `softdep_sync_metadata':
../../ufs/ffs/ffs_softdep.c:3722: structure has no member named `lh_first'
../../ufs/ffs/ffs_softdep.c:3733: structure has no member named `lh_first'
../../ufs/ffs/ffs_softdep.c:3832: structure has no member named `le_next'
../../ufs/ffs/ffs_softdep.c:3833: structure has no member named `le_next'
../../ufs/ffs/ffs_softdep.c:3869: structure has no member named `lh_first'
../../ufs/ffs/ffs_softdep.c:3680: warning: `bp' might be used uninitialized in
t
his function
*** Error code 1
In the meantime I will remove option SOFTUPDATES
--
Andreas Klemm http://www.FreeBSD.ORG/~andreas
What gives you 90% more speed, for example, in kernel compilation ?
http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html
"NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP''
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 08:45:13 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id IAA15169
for freebsd-current-outgoing; Sat, 6 Jun 1998 08:45:13 -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 IAA15155
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 08:45: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 IAA08609;
Sat, 6 Jun 1998 08:45:01 -0700 (PDT)
(envelope-from jkh@time.cdrom.com)
To: Willem Jan Withagen <wjw@surf.IAEhv.nl>
cc: current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-reply-to: Your message of "Sat, 06 Jun 1998 15:23:58 +0200."
<199806061323.PAA08967@surf.IAEhv.nl>
Date: Sat, 06 Jun 1998 08:45:01 -0700
Message-ID: <8605.897147901@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> I do not want to debate the actual implemented syntax. But comming from
> Apollo Domain OS this "feature" was one the the first things I missed when
> going to "real" Unix. So I would really find this an enhancement to FreeBSD.
So would I - I've also used Domain/OS and miss variant symlinks
quite a bit. It's been a FRI (Frequently Requested Item) for years,
but nobody has done an implementation. :-(
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 10:08:17 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id KAA23699
for freebsd-current-outgoing; Sat, 6 Jun 1998 10:08:17 -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 KAA23694
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 10:08:15 -0700 (PDT)
(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id KAA11756;
Sat, 6 Jun 1998 10:04:27 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
via SMTP by alpo.whistle.com, id smtpd011753; Sat Jun 6 17:04:24 1998
Date: Sat, 6 Jun 1998 10:04:21 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Adam McDougall <mcdougall@ameritech.net>
cc: current@FreeBSD.ORG
Subject: Re: breakage in ipfw lkm
In-Reply-To: <35794D5B.5791AF34@ameritech.net>
Message-ID: <Pine.BSF.3.95.980606100201.22014A-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
OK that'd be my fault
will fix asap
julian
On Sat, 6 Jun 1998, Adam McDougall wrote:
> I didnt see any other emails about this so..
>
> ===> ipfw
> cc -O -pipe -DIPFIREWALL -DIPFIREWALL_MODULE -aout -DKERNEL
> -DACTUALLY_LKM_NOT_KERNEL -Wreturn-type -Wcomment -Wredundant-decls
> -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Winline -Wuninitialized -ansi -nostdinc -I-
> -I/usr/obj/asynch/src/lkm/ipfw -I/usr/obj/asynch/src/lkm/ipfw/@ -c
> /asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c
> /asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c: In function `ip_fw_chk':
>
> /asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c:617:
> `ip_divert_in_cookie' undeclared (first use this function)
> /asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c:617: (Each undeclared
> identifier is reported only once
> /asynch/src/lkm/ipfw/../../sys/netinet/ip_fw.c:617: for each function it
> appears in.)
> *** Error code 1
>
> Stop.
> *** Error code 1
>
> Stop.
>
>
>
> 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 Sat Jun 6 10:18:37 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id KAA24656
for freebsd-current-outgoing; Sat, 6 Jun 1998 10:18:37 -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 KAA24651;
Sat, 6 Jun 1998 10:18:35 -0700 (PDT)
(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
by alpo.whistle.com (8.8.5/8.8.5) id KAA11982;
Sat, 6 Jun 1998 10:17:09 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
via SMTP by alpo.whistle.com, id smtpd011980; Sat Jun 6 17:17:05 1998
Date: Sat, 6 Jun 1998 10:17:03 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: "John S. Dyson" <dyson@FreeBSD.ORG>
cc: "John S. Dyson" <toor@dyson.iquest.net>, current@FreeBSD.ORG
Subject: Re: New SMP perf/quality snapshot (Update)
In-Reply-To: <199806060730.CAA10046@dyson.iquest.net>
Message-ID: <Pine.BSF.3.95.980606101302.22014C-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
John, one of the changes you asked kirk and I to implement was
the change do a simple tailq (stailq) to a doubly linked list.
Kirk asked the reason that you thought this was a speed improvement
but I think it was at a time that you were being pressured
elsewhere and couldn't answer.
If you could supply this answer then kirk might implememt the
change in his sources and we can keep in step again..
I notice that your patches include this change so I'm anxious
to get everything sync'd up again..
julian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 10:29:52 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id KAA25940
for freebsd-current-outgoing; Sat, 6 Jun 1998 10:29:52 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25931
for <current@freebsd.org>; Sat, 6 Jun 1998 10:29:48 -0700 (PDT)
(envelope-from dfr@nlsystems.com)
Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2])
by nlsystems.com (8.8.8/8.8.5) with ESMTP id SAA05730;
Sat, 6 Jun 1998 18:31:15 +0100 (BST)
Date: Sat, 6 Jun 1998 18:31:15 +0100 (BST)
From: Doug Rabson <dfr@nlsystems.com>
To: =?koi8-r?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf
In-Reply-To: <19980605094628.A1232@nagual.pp.ru>
Message-ID: <Pine.BSF.3.95q.980606182852.421Q-100000@herring.nlsystems.com>
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 Fri, 5 Jun 1998, [koi8-r] áÎÄÒÅÊ þÅÒÎÏ× wrote:
> lorder.sh have hardcoded /usr/bin in PATH so can't find 'nm'
>
> I see no easy way to determine aout / elf building system from shell
> script to find proper path for 'nm'
On top of that, lorder relies on the undocumented a.out nm habit of
prepending 'filename:' to the list of symbols for each file. I have a fix
for this on my work machine.
--
Doug Rabson Mail: dfr@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 951 1891
Fax: +44 181 381 1039
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 10:49:18 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id KAA28503
for freebsd-current-outgoing; Sat, 6 Jun 1998 10:49:18 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from news1.gtn.com (news1.gtn.com [194.77.0.15])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA28467;
Sat, 6 Jun 1998 10:49:04 -0700 (PDT)
(envelope-from andreas@klemm.gtn.com)
Received: (from uucp@localhost)
by news1.gtn.com (8.8.6/8.8.6) with UUCP id TAA02858;
Sat, 6 Jun 1998 19:45:09 +0200 (MET DST)
Received: (from andreas@localhost)
by klemm.gtn.com (8.8.8/8.8.8) id TAA06660;
Sat, 6 Jun 1998 19:04:04 +0200 (CEST)
(envelope-from andreas)
Message-ID: <19980606190404.A5934@klemm.gtn.com>
Date: Sat, 6 Jun 1998 19:04:04 +0200
From: Andreas Klemm <andreas@klemm.gtn.com>
To: dyson@FreeBSD.ORG, "John S. Dyson" <toor@dyson.iquest.net>
Cc: current@FreeBSD.ORG
Subject: Re: New SMP perf/quality snapshot (Update)
References: <199806060135.UAA00595@dyson.iquest.net> <199806060730.CAA10046@dyson.iquest.net> <19980606162254.A21933@klemm.gtn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <19980606162254.A21933@klemm.gtn.com>; from Andreas Klemm on Sat, Jun 06, 1998 at 04:22:54PM +0200
X-Disclaimer: A free society is one where it is safe to be unpopular
X-Operating-System: FreeBSD 3.0-CURRENT SMP
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On Sat, Jun 06, 1998 at 04:22:54PM +0200, Andreas Klemm wrote:
>
> In the meantime I will remove option SOFTUPDATES
Well -current of today and your latest patches...
Tried to boot tow times.
The first time the machine hang during booting when starting
up network services.
The second time I could login, bit system hang after starting up X11
with kde. One xterm came up then the machine hangs ...
Tyan Titan PRO S1668, 2 x 200 MHz PPro.
--
Andreas Klemm http://www.FreeBSD.ORG/~andreas
What gives you 90% more speed, for example, in kernel compilation ?
http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html
"NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP''
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 11:00:42 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id LAA00405
for freebsd-current-outgoing; Sat, 6 Jun 1998 11:00:42 -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 LAA00399;
Sat, 6 Jun 1998 11:00:36 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id NAA04677;
Sat, 6 Jun 1998 13:00:28 -0500 (EST)
(envelope-from toor)
Message-Id: <199806061800.NAA04677@dyson.iquest.net>
Subject: Re: New SMP perf/quality snapshot (Update)
In-Reply-To: <19980606162254.A21933@klemm.gtn.com> from Andreas Klemm at "Jun 6, 98 04:22:54 pm"
To: andreas@klemm.gtn.com (Andreas Klemm)
Date: Sat, 6 Jun 1998 13:00:28 -0500 (EST)
Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG
From: "John S. Dyson" <dyson@FreeBSD.ORG>
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
Andreas Klemm said:
> On Sat, Jun 06, 1998 at 02:30:48AM -0500, John S. Dyson wrote:
> > New file:
> > http://www.freebsd.org/~dyson/sysjun06.diff.gz
> > Bugfixes, improvement of zero idle loop, disable PPro zero
> > optimizations for now (looks like algorithmic bug of some
> > kind.)
>
> While trying to compile with softupdate ...
>
....
>
> In the meantime I will remove option SOFTUPDATES
>
Softupdates has to be upgraded to work with the SMP fixes. The
changes are minor, but still significant in improvement.
--
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 Sat Jun 6 11:03:28 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id LAA00804
for freebsd-current-outgoing; Sat, 6 Jun 1998 11:03:28 -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 LAA00797;
Sat, 6 Jun 1998 11:03:24 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id NAA04683;
Sat, 6 Jun 1998 13:02:39 -0500 (EST)
(envelope-from toor)
Message-Id: <199806061802.NAA04683@dyson.iquest.net>
Subject: Re: New SMP perf/quality snapshot (Update)
In-Reply-To: <199806060849.BAA00324@pozo.com> from Manfred Antar at "Jun 6, 98 01:49:13 am"
To: mantar@netcom.com (Manfred Antar)
Date: Sat, 6 Jun 1998 13:02:39 -0500 (EST)
Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG
From: "John S. Dyson" <dyson@FreeBSD.ORG>
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
Manfred Antar said:
> >
> >--
> John I just tried this on a Intel PR440FX dual 180 ppro.
> The system locks up just after login:
> I can't get into debugger, the machine is frozen.
> I have xdm running. could it be that when the Xserver is about to start
> it locks up the machine ?
> The video card is a matrox millennium w/4mb vram.
> That's the only card plugged into the system.
> There is one seagate 4gig drive running off the embedded aic7880.
> Should I do a make world with the new files before building a kernel ?
> Manfred
>
The only problems that I suspect are with ps, libkvm, etc. :-(. I'll
check it on my providence MB based SMP box also (I have one of those
things.) I'll try to reply after checking the code on that box.
--
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 Sat Jun 6 11:13:03 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id LAA01997
for freebsd-current-outgoing; Sat, 6 Jun 1998 11:13:03 -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 LAA01991
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 11:13:00 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id NAA04735;
Sat, 6 Jun 1998 13:12:49 -0500 (EST)
(envelope-from toor)
Message-Id: <199806061812.NAA04735@dyson.iquest.net>
Subject: Re: strange behavior with signal latencies
In-Reply-To: <3577F59D.983C4EE4@home.com> from "Richard S. Straka" at "Jun 5, 98 06:41:49 am"
To: straka@home.com (Richard S. Straka)
Date: Sat, 6 Jun 1998 13:12:49 -0500 (EST)
Cc: bde@zeta.org.au, current@FreeBSD.ORG
From: "John S. Dyson" <dyson@FreeBSD.ORG>
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
Richard S. Straka said:
>
> BTW, these latancy times really go out the window (10+ms ) when
> the system is loaded with disk writing or network activity. I have performed
> similar tests on an Ultra 30 box running Solaris 2.6. Even under extreme
> loading, the latencies stay below 1ms (its no VxWorks, but it ain't bad for
> soft
> realtime). It appears that Solaris does very little work in hardware
> interrupts,
> defering work to preemtable kernel threads which are under control of the
> scheduler. They offer a realtime scheduling class which has higher priority
> than their system scheduling class. The amount of work we currently do in
> FreeBSD in hardware and software interrupts coupled with the
> non-preemtable nature of kernel activity precludes us from doing even
> soft realtime work.
>
I would *love* to be able to support such a scheme, without a performance
hit. Where an improvement (in overall performance) might be seen is
in the SMP world, or where you need realtime. We will soon have much
of the low level support for such a scheme (except for the interrupt
handling methods.) I can guess that *someday* it will be reasonable for
us to do that, but we tend to be evolutionary rather than revolutionary
in our movements.
I have been thinking in the background of a reasonable realtime scheme.
--
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 Sat Jun 6 11:27:48 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id LAA03839
for freebsd-current-outgoing; Sat, 6 Jun 1998 11:27:48 -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 LAA03834
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 11:27: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 OAA16010;
Sat, 6 Jun 1998 14:27:44 -0400 (EDT)
(envelope-from wollman)
Date: Sat, 6 Jun 1998 14:27:44 -0400 (EDT)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <199806061827.OAA16010@khavrinen.lcs.mit.edu>
To: Willem Jan Withagen <wjw@surf.IAEhv.nl>
Cc: jkh@time.cdrom.com, current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-Reply-To: <199806061323.PAA08967@surf.IAEhv.nl>
References: <199806052121.OAA04575@usr08.primenet.com>
<3555.897110276@time.cdrom.com>
<199806061323.PAA08967@surf.IAEhv.nl>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
<<On Sat, 6 Jun 1998 15:23:58 +0200 (MET DST), Willem Jan Withagen <wjw@surf.IAEhv.nl> said:
> I do not want to debate the actual implemented syntax. But comming from
> Apollo Domain OS this "feature" was one the the first things I missed when
> going to "real" Unix. So I would really find this an enhancement to FreeBSD.
If we really wanted to get variant symlinks, I would suggest copying
the already-fairly-well-known syntax of AFS, `@name_of_parameter'. As
the metasyntactic variable suggests, these should be (a fairly small
number of) parameters which hold system-wide. (Indeed, given the
existence of the sysctlbyname interface in the kernel, one could
simply kick them off in that direction.)
-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 Sat Jun 6 12:04:16 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id MAA07767
for freebsd-current-outgoing; Sat, 6 Jun 1998 12:04:16 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from antipodes.cdrom.com (castles171.castles.com [208.214.165.171])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07756
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 12:04: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 KAA01286;
Sat, 6 Jun 1998 10:59:37 -0700 (PDT)
Message-Id: <199806061759.KAA01286@antipodes.cdrom.com>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
cc: Willem Jan Withagen <wjw@surf.IAEhv.nl>, jkh@time.cdrom.com,
current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-reply-to: Your message of "Sat, 06 Jun 1998 14:27:44 EDT."
<199806061827.OAA16010@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 06 Jun 1998 10:59:37 -0700
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> <<On Sat, 6 Jun 1998 15:23:58 +0200 (MET DST), Willem Jan Withagen <wjw@surf.IAEhv.nl> said:
>
> > I do not want to debate the actual implemented syntax. But comming from
> > Apollo Domain OS this "feature" was one the the first things I missed when
> > going to "real" Unix. So I would really find this an enhancement to FreeBSD.
>
> If we really wanted to get variant symlinks, I would suggest copying
> the already-fairly-well-known syntax of AFS, `@name_of_parameter'. As
> the metasyntactic variable suggests, these should be (a fairly small
> number of) parameters which hold system-wide. (Indeed, given the
> existence of the sysctlbyname interface in the kernel, one could
> simply kick them off in that direction.)
Ok. I did actually look at how this could be implemented last time it
came up, and I think it would be *reasonably* straightforward.
Can you clarify the AFS syntax a little more? Is there a delimiter
around the 'name'? If not, are variant components only allowed to be
entire path entities? How do you put more than one entry based on a
single parameter into a given directory? Or are you forced to duplicate
information across more than one parameter?
--
\\ 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 Sat Jun 6 12:15:17 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id MAA08973
for freebsd-current-outgoing; Sat, 6 Jun 1998 12:15:17 -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 MAA08968
for <current@freebsd.org>; Sat, 6 Jun 1998 12:15:15 -0700 (PDT)
(envelope-from paulz@trantor.stuyts.nl)
Received: from stuyts by alushta.NL.net with UUCP id <3969-15255>; Sat, 6 Jun 1998 21:15:06 +0200
Received: from trantor.stuyts.nl (uucp@localhost)
by terminus.stuyts.nl (8.8.8/8.8.8) with UUCP id VAA20648
for current@freebsd.org; Sat, 6 Jun 1998 21:01:03 +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 UAA02011
for <current@freebsd.org>; Sat, 6 Jun 1998 20:59:42 +0200 (MET DST)
Message-Id: <199806061859.UAA02011@trantor.stuyts.nl>
X-Mailer: exmh version 2.0.2 2/24/98
To: current@FreeBSD.ORG
Subject: make buildworld fails make hierarchy
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 06 Jun 1998 20:59:42 +0200
From: Paul van der Zwan <paulz@trantor.stuyts.nl>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Current today fails in 'make hierarchy' :
mtree -deU -f /usr/source/src/etc/mtree/BSD.root.dist -p /usr/obj/usr/source/src/tmp/
mtree -deU -f /usr/source/src/etc/mtree/BSD.var.dist -p /usr/obj/usr/source/src/tmp/var
mtree: /usr/obj/usr/source/src/tmp/var: No such file or directory
*** Error code 1
Stop.
*** Error code 1
Stop.
*** Error code 1
Stop.
On my system /usr/src is a symlink to /usr/source/src and /usr/obj to
/scratch/obj. This has worked since 2.1.x days..
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 Sat Jun 6 12:18:35 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id MAA09414
for freebsd-current-outgoing; Sat, 6 Jun 1998 12:18:35 -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 MAA09395;
Sat, 6 Jun 1998 12:18:27 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id OAA06021;
Sat, 6 Jun 1998 14:18:21 -0500 (EST)
(envelope-from toor)
Message-Id: <199806061918.OAA06021@dyson.iquest.net>
Subject: Re: New SMP perf/quality snapshot (Update)
In-Reply-To: <Pine.BSF.3.95.980606101302.22014C-100000@current1.whistle.com> from Julian Elischer at "Jun 6, 98 10:17:03 am"
To: julian@whistle.com (Julian Elischer)
Date: Sat, 6 Jun 1998 14:18:20 -0500 (EST)
Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG
From: "John S. Dyson" <dyson@FreeBSD.ORG>
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:
>
> John, one of the changes you asked kirk and I to implement was
> the change do a simple tailq (stailq) to a doubly linked list.
>
> Kirk asked the reason that you thought this was a speed improvement
> but I think it was at a time that you were being pressured
> elsewhere and couldn't answer.
>
> If you could supply this answer then kirk might implememt the
> change in his sources and we can keep in step again..
>
> I notice that your patches include this change so I'm anxious
> to get everything sync'd up again..
>
The reason is the way that we maintain the dirty list in vfs_subr.
We need to place the metadata at the end of the dirty list. This
might not be very useful for softupdates, but is very valuable for
-async. We were incorrectly flushing metadata first (and unnecessarily)
for -async.
There is a very measurable performance improvement with this change.
--
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 Sat Jun 6 12:58:05 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id MAA14080
for freebsd-current-outgoing; Sat, 6 Jun 1998 12:58:05 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from pcpsj.pfcs.com (S0x1YRXGCvJZK/clOePAr/v/dyKneV4A@harlan.fred.net [205.252.219.31])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA14033
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 12:58:01 -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 <PAA18767-Harlan.Stenn@pfcs.com> for <current@FreeBSD.ORG>;
Sat, 6 Jun 1998 15:57:56 -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 <MAA28571-harlan@pfcs.com> for <current@FreeBSD.ORG>;
Sat, 6 Jun 1998 12:57:55 -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 <PAA20694-harlan@pfcs.com> for <current@FreeBSD.ORG>;
Sat, 6 Jun 1998 15:57:54 -0400 (EDT)
X-Mailer: exmh version 2.0.2 2/24/98
To: current@FreeBSD.ORG
Subject: Re: lorder problem: aout vs. elf (and GNU Configure problem too)
In-Reply-To: Mike Smith's (mike@smith.net.au) message
dated Sat, 06 Jun 1998 10:59:37. <199806061759.KAA01286@antipodes.cdrom.com>
X-Face: "csXK}xnnsH\h_ce`T#|pM]tG,6Xu.{3Rb\]&XJgVyTS'w{E+|-(}n<m88'RZQA.<2]zo&R
I8nHuPumSNjsAN&WGhll?v}1#%)~2%QI~4Vs%IuWb#OmZmKck_1Ee&C\k&vJ}BWx:Bb#Mx8>: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: Sat, 06 Jun 1998 15:57:54 -0400
Message-ID: <20690.897163074@brown.pfcs.com>
From: Harlan Stenn <Harlan.Stenn@pfcs.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> If we really wanted to get variant symlinks, I would suggest copying
> the already-fairly-well-known syntax of AFS, `@name_of_parameter'. As
> the metasyntactic variable suggests, these should be (a fairly small
> number of) parameters which hold system-wide.
I've used the functionality provided by Pyramid back in the old days, not
AFS.
Does AFS have a fixed number of parameter names across the system, or are
the *values* fixed across the system?
If it's the latter, this seems much less useful.
For example, one session may want a.out while another wants elf.
Just to name an example.
H
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 13:08:48 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA15708
for freebsd-current-outgoing; Sat, 6 Jun 1998 13:08:48 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from sanewo.ba2.so-net.ne.jp (root@p84b484.sng2.ap.so-net.ne.jp [210.132.180.132])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15700
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 13:08:39 -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 FAA28080;
Sun, 7 Jun 1998 05:08:04 +0900 (JST)
(envelope-from sanewo@ba2.so-net.ne.jp)
Message-Id: <199806062008.FAA28080@sanewo.ba2.so-net.ne.jp>
To: Nathan Dorfman <nathan@rtfm.net>
Cc: current@FreeBSD.ORG
Subject: Re: top -osize
In-reply-to: nathan@rtfm.net's message of Sun, 31 May 1998 11:46:27 -0400.
<19980531114627.A580@rtfm.net>
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI 1.5.2 - "Kurobe")
Content-Type: text/plain; charset=US-ASCII
Date: Sun, 07 Jun 1998 05:08:03 +0900
From: SANETO Takanori <sanewo@ba2.so-net.ne.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
In article <19980531114627.A580@rtfm.net>
Nathan Dorfman <nathan@rtfm.net> said:
>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
Strange. It seems that the patch for Makefile (which adds -DORDER to
CFLAGS) failed as well (bad?) as hunk #8.
>/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'
Struct member ``order_names'' will be defined (in
contrib/top/machine.h) when -DORDER is specified.
Anyway, try following patch, which I created against the -current as
of 16:00 GMT, June 6.
Index: usr.bin/top/Makefile
===================================================================
RCS file: /sd0/FreeBSD/cvs/src/usr.bin/top/Makefile,v
retrieving revision 1.4
diff -c -r1.4 Makefile
*** Makefile 1997/07/21 16:06:00 1.4
--- Makefile 1998/06/06 19:54:01
***************
*** 3,9 ****
TOPDIR= ${.CURDIR}/../../contrib/top
.PATH: ${TOPDIR}
! CFLAGS+= -DHAVE_GETOPT -I${.CURDIR} -I${TOPDIR}
#
# The table size should be a prime number approximately twice as
--- 3,9 ----
TOPDIR= ${.CURDIR}/../../contrib/top
.PATH: ${TOPDIR}
! CFLAGS+= -DHAVE_GETOPT -DORDER -I${.CURDIR} -I${TOPDIR}
#
# The table size should be a prime number approximately twice as
Index: usr.bin/top/machine.c
===================================================================
RCS file: /sd0/FreeBSD/cvs/src/usr.bin/top/machine.c,v
retrieving revision 1.10
diff -c -r1.10 machine.c
*** machine.c 1998/05/28 09:29:48 1.10
--- machine.c 1998/05/28 17:27:52
***************
*** 13,18 ****
--- 13,20 ----
*
* LIBS: -lkvm
*
+ * CFLAGS: -DHAVE_GETOPT -DORDER
+ *
* AUTHOR: Christos Zoulas <christos@ee.cornell.edu>
* Steven Wallace <swallace@freebsd.org>
* Wolfram Schneider <wosch@FreeBSD.org>
***************
*** 167,173 ****
static long lastpid;
static unsigned long cnt_offset;
static unsigned long bufspace_offset;
- static long cnt;
/* these are for calculating cpu state percentages */
--- 169,174 ----
***************
*** 206,211 ****
--- 207,228 ----
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,316 ****
--- 328,334 ----
statics->cpustate_names = cpustatenames;
statics->memory_names = memorynames;
statics->swap_names = swapnames;
+ statics->order_names = ordernames;
/* all done! */
return(0);
***************
*** 321,333 ****
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;
}
--- 339,350 ----
register char *uname_field;
{
static char Header[128];
snprintf(Header, sizeof(Header), smpmode ? smp_header : up_header,
namelength, namelength, uname_field);
! cmdlength = 128 - strlen(Header) + 6; /* 128 should be the line of screen */
return Header;
}
***************
*** 691,710 ****
}
return(1);
}
!
! /* comparison routine 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.
*/
static unsigned char sorted_state[] =
{
0, /* not used */
--- 708,744 ----
}
return(1);
}
!
! /* comparison routines for qsort */
/*
! * 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,723 ****
4 /* stop */
};
int
! proc_compare(pp1, pp2)
struct proc **pp1;
struct proc **pp2;
--- 750,759 ----
4 /* stop */
};
+ /* compare_cpu - the comparison function for sorting by cpu percentage */
+
int
! compare_cpu(pp1, pp2)
struct proc **pp1;
struct proc **pp2;
***************
*** 726,764 ****
register struct kinfo_proc *p1;
register struct kinfo_proc *p2;
register int result;
! register pctcpu lresult;
/* 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;
! }
return(result);
}
--- 762,867 ----
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_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 Sat Jun 6 13:41:03 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA18508
for freebsd-current-outgoing; Sat, 6 Jun 1998 13:41:03 -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 NAA18503
for <current@freebsd.org>; Sat, 6 Jun 1998 13:41:00 -0700 (PDT)
(envelope-from tlambert@usr04.primenet.com)
Received: (from daemon@localhost)
by smtp02.primenet.com (8.8.8/8.8.8) id NAA11949
for <current@freebsd.org>; Sat, 6 Jun 1998 13:40:57 -0700 (MST)
Received: from usr04.primenet.com(206.165.6.204)
via SMTP by smtp02.primenet.com, id smtpd011939; Sat Jun 6 13:40:46 1998
Received: (from tlambert@localhost)
by usr04.primenet.com (8.8.5/8.8.5) id NAA27252
for current@freebsd.org; Sat, 6 Jun 1998 13:40:46 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199806062040.NAA27252@usr04.primenet.com>
Subject: Patches for 'id' command available:
To: current@FreeBSD.ORG
Date: Sat, 6 Jun 1998 20:40:46 +0000 (GMT)
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 have made some small patches to the 'id' command:
] This is a small patch that adds a "-P" option to the "id" program
] to allow it to print out the id as a password file line.
]
] This functionality is most useful in shell scripts on NIS using
] machines, since there is no simple way to get an entry from a
] shell script without caring whether it's coming from the local
] password file or from NIS.
They are available from:
http://www.freebsd.org/~terry/DIFF.ID.txt
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 Sat Jun 6 13:50:37 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA19228
for freebsd-current-outgoing; Sat, 6 Jun 1998 13:50:37 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA19220
for <current@freebsd.org>; Sat, 6 Jun 1998 13:50:33 -0700 (PDT)
(envelope-from brian@Awfulhak.org)
Received: from gate.lan.awfulhak.org (localhost [127.0.0.1])
by awfulhak.org (8.8.8/8.8.8) with ESMTP id VAA02013;
Sat, 6 Jun 1998 21:49:36 +0100 (BST)
(envelope-from brian@gate.lan.awfulhak.org)
Message-Id: <199806062049.VAA02013@awfulhak.org>
X-Mailer: exmh version 2.0.1 12/23/97
To: ben@stuyts.nl
cc: current@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: ppp -background sets wrong pid in /var/run/tun0.pid
In-reply-to: Your message of "Sat, 30 May 1998 22:26:59 +0200."
<199805302027.WAA09104@daneel.stuyts.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 06 Jun 1998 21:49:35 +0100
From: Brian Somers <brian@Awfulhak.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
> Hi,
This has just been fixed..... Thanks for the report.
> I have just done a make world of -current, and I noticed the following
> problem with the new ppp:
>
> [terminus.stuyts.nl var/run]16: ppp -background nlnet
> Working in background mode
> Using interface: tun0
> PPP enabled.
>
> [terminus.stuyts.nl var/run]17: ps -aguxww | grep ppp
> benst 1389 0.0 1.5 1276 956 ?? Ss 10:24PM 0:00.05 ppp -background nlnet
>
> [terminus.stuyts.nl var/run]18: cat /var/run/tun0.pid
> 1388
>
> It seems the value in tun0.pid is one off. This is quite a problem in scripts
> such as:
>
> /usr/sbin/ppp -background nlnet > /dev/console 2>&1
> ...
> /bin/kill -TERM `cat /var/run/tun0.pid` > /dev/console
>
> Any ideas?
>
> Best regards,
> Ben
>
--
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>
Don't _EVER_ lose your sense of humour....
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 13:57:01 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id NAA20128
for freebsd-current-outgoing; Sat, 6 Jun 1998 13:57:01 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from top.worldcontrol.com (surf52.cruzers.com [205.215.232.52])
by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA20123
for <freebsd-current@freebsd.org>; Sat, 6 Jun 1998 13:56:57 -0700 (PDT)
(envelope-from brian@worldcontrol.com)
From: brian@worldcontrol.com
Received: (qmail 7902 invoked by uid 100); 6 Jun 1998 19:57:33 -0000
Message-ID: <19980606125729.A7819@top.worldcontrol.com>
Date: Sat, 6 Jun 1998 12:57:29 -0700
To: freebsd-current@FreeBSD.ORG
Subject: Re: New SMP perf/quality snapshot
Mail-Followup-To: freebsd-current@freebsd.org
References: <199806060135.UAA00595@dyson.iquest.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91i
In-Reply-To: <199806060135.UAA00595@dyson.iquest.net>; from John S. Dyson on Fri, Jun 05, 1998 at 08:35:51PM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
On %M 0, "John S. Dyson" <toor@dyson.iquest.net> wrote:
> I have placed a new SMP quality/performance snapshot on:
>
> http://www.freebsd.org/~dyson/sysjun06.diff.gz
On my 2xPP150 system things work, 'cept I occasional get:
Jun 6 02:38:48 bls2 /kernel: pid 2159 (cpp), uid 0: exited on signal 11 (core dumped)
Jun 6 02:39:20 bls2 /kernel: pid 2772 (cpp), uid 0: exited on signal 11 (core dumped)
I rebuilt cc and it subcomponents. Still happens.
--
Brian Litzinger <brian@litzinger.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 14:32:42 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id OAA24225
for freebsd-current-outgoing; Sat, 6 Jun 1998 14:32:42 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from isf.kiev.ua (sunone.isf.kiev.ua [194.44.162.131])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA24210
for <freebsd-current@FreeBSD.ORG>; Sat, 6 Jun 1998 14:32:30 -0700 (PDT)
(envelope-from kushn@mail.kar.net)
Received: from olinet.isf.kiev.ua by isf.kiev.ua with ESMTP id AAA07869;
(8.8.7/2.b2) Sun, 7 Jun 1998 00:26:05 +0300 (EET DST)
Received: from kushnir.kiev.ua by olinet.isf.kiev.ua with SMTP id AAA14459;
(8.8.last/vAk3/1.9) Sun, 7 Jun 1998 00:20:53 +0300 (EET DST)
Date: Sun, 7 Jun 1998 00:29:01 +0300 (EEST)
From: Vladimir Kushnir <kushn@mail.kar.net>
X-Sender: volodya@kushnir.kiev.ua
Reply-To: Vladimir Kushnir <kushn@mail.kar.net>
To: freebsd-current@FreeBSD.ORG
Subject: XFree86 & elf
Message-ID: <Pine.BSF.3.96.980607001727.8141A-100000@kushnir.kiev.ua>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Hello,
Awhile ago somebody (sorry, I haven't saved that message) wrote about
patches for XFree to build it using elf. Would you please point to those
patches (or mail them to me if they're not available from 'Net)?
Thanx in advance,
Vladimir
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 14:55:24 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id OAA26225
for freebsd-current-outgoing; Sat, 6 Jun 1998 14:55:24 -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 OAA26219
for <freebsd-current@FreeBSD.ORG>; Sat, 6 Jun 1998 14:55:21 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id QAA19447;
Sat, 6 Jun 1998 16:55:17 -0500 (EST)
(envelope-from toor)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199806062155.QAA19447@dyson.iquest.net>
Subject: Re: New SMP perf/quality snapshot
In-Reply-To: <19980606125729.A7819@top.worldcontrol.com> from "brian@worldcontrol.com" at "Jun 6, 98 12:57:29 pm"
To: brian@worldcontrol.com
Date: Sat, 6 Jun 1998 16:55:17 -0500 (EST)
Cc: freebsd-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
> On %M 0, "John S. Dyson" <toor@dyson.iquest.net> wrote:
> > I have placed a new SMP quality/performance snapshot on:
> >
> > http://www.freebsd.org/~dyson/sysjun06.diff.gz
>
> On my 2xPP150 system things work, 'cept I occasional get:
> Jun 6 02:38:48 bls2 /kernel: pid 2159 (cpp), uid 0: exited on signal 11 (core dumped)
> Jun 6 02:39:20 bls2 /kernel: pid 2772 (cpp), uid 0: exited on signal 11 (core dumped)
>
> I rebuilt cc and it subcomponents. Still happens.
>
Yep, it probably seems to be broken bzero code. I am still trying to make sure
that there aren't other problems. I also noticed that the new tlb shootdown
code has some problems, and am testing some new stuff right now.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 15:26:26 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id PAA29871
for freebsd-current-outgoing; Sat, 6 Jun 1998 15:26:26 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from awfulhak.org (awfulhak.force9.co.uk [195.166.136.63])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29856
for <current@FreeBSD.ORG>; Sat, 6 Jun 1998 15:26:21 -0700 (PDT)
(envelope-from brian@Awfulhak.org)
Received: from gate.lan.awfulhak.org (localhost [127.0.0.1])
by awfulhak.org (8.8.8/8.8.8) with ESMTP id XAA04727;
Sat, 6 Jun 1998 23:10:59 +0100 (BST)
(envelope-from brian@gate.lan.awfulhak.org)
Message-Id: <199806062210.XAA04727@awfulhak.org>
X-Mailer: exmh version 2.0.1 12/23/97
To: Mike Smith <mike@smith.net.au>
cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, 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 12:04:30 PDT."
<199806011904.MAA00827@dingo.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 06 Jun 1998 23:10:58 +0100
From: Brian Somers <brian@Awfulhak.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
I've been away for a week.....
I'll look into getting the elf side of this working and commit the
changes. Does anyone have any objections to dlopen() searching for
the lib if it has no ``/''s in the name ?
> > > 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
[.....]
--
Brian <brian@Awfulhak.org>, <brian@FreeBSD.org>, <brian@OpenBSD.org>
<http://www.Awfulhak.org>
Don't _EVER_ lose your sense of humour....
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 21:20:00 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id VAA03997
for freebsd-current-outgoing; Sat, 6 Jun 1998 21:20:00 -0700 (PDT)
(envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from cockatoo.aus.org (lh@cockatoo.aus.org [199.166.246.189])
by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03992
for <current@freebsd.org>; Sat, 6 Jun 1998 21:19:55 -0700 (PDT)
(envelope-from lh@cockatoo.aus.org)
Received: (from lh@localhost)
by cockatoo.aus.org (8.8.8/8.8.8) id AAA23198
for current@freebsd.org; Sun, 7 Jun 1998 00:19:49 -0400 (EDT)
(envelope-from lh)
Message-ID: <XFMail.980607001948.lh@aus.org>
X-Mailer: XFMail 1.3-beta-042198 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Sun, 07 Jun 1998 00:19:48 -0400 (EDT)
From: Luke <lh@aus.org>
To: current@FreeBSD.ORG
Subject: mtree error
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
-----BEGIN PGP SIGNED MESSAGE-----
I know someone mentioned this earlier, but I encountered it yesterday and just
now after cvsuping
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr
mtree: line 58: unknown keyword nochange
its at about line @605 as well, removing the word nochange seems to work
Hanlon's Razor:
Never attribute to malice that which is adequately explained by
stupidity.
E-Mail: Luke <lh@aus.org>
Sent by XFMail
- ----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNXoU4+6GmDnHtZHpAQGJsQP/Q1DsdI7IcfayIkwNJ09SO4HE3AvW3Crb
XnTQ6HnbYBW8YhN60jaYpv+7IZb1XkTgdE7OeGOmUtZUyAN9ZgRv5WESx/Mz1VH/
SnbwuVynNNJaT0c9MLVdkVpm1xHbqm1S+cW7S+R8J9qqz7OlNt82E5NAm2+BF6qn
FzJTQTCD3Y0=
=sFYD
-----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 Sat Jun 6 22:50:32 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id WAA10085
for freebsd-current-outgoing; Sat, 6 Jun 1998 22:50:32 -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 WAA10077
for <current@freebsd.org>; Sat, 6 Jun 1998 22:50:29 -0700 (PDT)
(envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
by dyson.iquest.net (8.8.8/8.8.8) id AAA00614
for current@freebsd.org; Sun, 7 Jun 1998 00:50:28 -0500 (EST)
(envelope-from toor)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199806070550.AAA00614@dyson.iquest.net>
Subject: Another snap for -current improvements
To: current@FreeBSD.ORG
Date: Sun, 7 Jun 1998 00:50:28 -0500 (EST)
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
Another snap at:
http://www.freebsd.org/~dyson/sysjun07.diff.gz
Might work on P5 now. Also, some strange problems that
I could finally repeat have been fixed. New pte update
code that considers the modification of VA space as
a side effect, as opposed to depending upon the lack
of compiler optimization.
John
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
From owner-freebsd-current Sat Jun 6 23:52:34 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
by hub.freebsd.org (8.8.8/8.8.8) id XAA15215
for freebsd-current-outgoing; Sat, 6 Jun 1998 23:52:34 -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 XAA15203
for <current@freebsd.org>; Sat, 6 Jun 1998 23:52:29 -0700 (PDT)
(envelope-from mantar@netcom.com)
Received: from dual (DUAL [192.168.0.2])
by pozo.com (8.8.8/8.8.8) with SMTP id XAA09806;
Sat, 6 Jun 1998 23:52:17 -0700 (PDT)
(envelope-from mantar@netcom.com)
Message-Id: <199806070652.XAA09806@pozo.com>
X-Sender: null@192.168.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Date: Sat, 06 Jun 1998 23:52:17 -0700
To: "John S. Dyson" <toor@dyson.iquest.net>
From: Manfred Antar <mantar@netcom.com>
Subject: Re: Another snap for -current improvements
Cc: current@FreeBSD.ORG
In-Reply-To: <199806070550.AAA00614@dyson.iquest.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
At 12:50 AM 6/7/98 -0500, you wrote:
>Another snap at:
>
>http://www.freebsd.org/~dyson/sysjun07.diff.gz
>
>Might work on P5 now. Also, some strange problems that
>I could finally repeat have been fixed. New pte update
>code that considers the modification of VA space as
>a side effect, as opposed to depending upon the lack
>of compiler optimization.
>
>John
>
John
I just built a kernel and it locks up the same with xdm.
I commented out xdm and am makeing -j8 world
Also I get alot of:
Null pmap (cb) at va: 0x4b000
Null pmap (cb) at va: 0x8a000
Null pmap (cb) at va: 0x1d2000
Null pmap (cb) at va: 0x49000
Null pmap (cb) at va: 0x2e000
Null pmap (cb) at va: 0x33000
Null pmap (cb) at va: 0x34000
Null pmap (cb) at va: 0x8a000
Null pmap (cb) at va: 0x4c000
Null pmap (cb) at va: 0x63000
Null pmap (cb) at va: 0x41000
Null pmap (cb) at va: 0x5a000
Null pmap (cb) at va: 0x44000
Null pmap (cb) at va: 0x53000
Null pmap (cb) at va: 0x46000
Null pmap (cb) at va: 0x50000
Null pmap (cb) at va: 0x43000
Null pmap (cb) at va: 0x58000
Null pmap (cb) at va: 0x5a000
these happened over a period of time.
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