On Sat, 4 May 2002, David O'Brien wrote:
> On Sat, May 04, 2002 at 11:16:22PM -0700, Doug Barton wrote:
> > Ok, I put the following in /usr/lib/compat, from my releng_4 box:
> >
> > libc.so.4
> > libc_r.a
> > libc_r.so.4
> > libpam.a
> > libpam.so.1
> > libpam_ssh.a
>
> There is no need for .a's
On Sat, May 04, 2002 at 11:16:22PM -0700, Doug Barton wrote:
> Ok, I put the following in /usr/lib/compat, from my releng_4 box:
>
> libc.so.4
> libc_r.a
> libc_r.so.4
> libpam.a
> libpam.so.1
> libpam_ssh.a
There is no need for .a's in /usr/lib/compat -- think about it.
To Unsubscribe: send ma
On Sun, May 05, 2002 at 04:36:41AM +0200, Dag-Erling Smorgrav wrote:
> modules and doesn't clobber your old 4.x modules. I asked David to
> put libpam and the PAM modules in COMPAT4X, but never heard back from
> him.
I guess I need clarification. Since PAM modules aren't versioned, is
there a p
On 5 May 2002, Dag-Erling Smorgrav wrote:
> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> > Doug Barton <[EMAIL PROTECTED]> writes:
> > > Then I'm back to my original point. I think that breaking binary
> > > compatibility for all 4.x pam applications is a very bad idea.
> > It was already
On Sat, May 04, 2002 at 21:54:08 +0200, Martin Blapp wrote:
> Hi all,
>
> I experiment very strange problems here at the moment with
> a new server.
>
> Buildworld survives about 30 secondy, the errors are SIG4 (90%)
> and SIG11 (10%). And I cannot compile any important programs :-/
>
> I've ex
I have released a new zero copy sockets snapshot; the patches are against
yesterday's (May 3rd) -current.
The astute reader may note that it has been quite a while (November 2000)
since my last zero copy code release, and all I can say is "time,
motivation, lack of local equipment".
Anyway, the
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> Doug Barton <[EMAIL PROTECTED]> writes:
> > Then I'm back to my original point. I think that breaking binary
> > compatibility for all 4.x pam applications is a very bad idea.
> It was already broken. There's nothing you can do about it.
Hmm,
On Sun, 5 May 2002, Bruce Evans wrote:
> On Sat, 4 May 2002, Jake Burkholder wrote:
>
> > Apparently, On Sun, May 05, 2002 at 10:44:44AM +1000,
> > Bruce Evans said words to the effect of;
> > >
> > > I have seen signs of a generic pipe bug in vi: vi's i/o buffer for
> > > pipes is sometimes
Doug Barton <[EMAIL PROTECTED]> writes:
> Then I'm back to my original point. I think that breaking binary
> compatibility for all 4.x pam applications is a very bad idea.
It was already broken. There's nothing you can do about it.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsub
On 5 May 2002, Dag-Erling Smorgrav wrote:
> That's right, I'd forgotten - the old PAM modules don't like
> libc.so.5. Not much I can do about that :( I'm afraid you'll have to
> rebuild X.
Then I'm back to my original point. I think that breaking binary
compatibility for all 4.x pam app
On Sat, 4 May 2002, Jake Burkholder wrote:
> Apparently, On Sun, May 05, 2002 at 10:44:44AM +1000,
> Bruce Evans said words to the effect of;
> >
> > I have seen signs of a generic pipe bug in vi: vi's i/o buffer for
> > pipes is sometimes invalid (kern/sys_pipe.c:pipe_build_write_buffer()
Apparently, On Sun, May 05, 2002 at 10:44:44AM +1000,
Bruce Evans said words to the effect of;
> On Sat, 4 May 2002, David O'Brien wrote:
>
> > On Sat, May 04, 2002 at 09:26:33PM +0100, Brian Somers wrote:
> > > Try disabling -pipe when building the compiler. This seems to make
> > > th
Doug Barton <[EMAIL PROTECTED]> writes:
> Ok, I updated to today's -current, including v. 1.4 of
> /etc/pam.d/xdm, and still no joy:
>
> PAM unable to dlopen(/usr/lib/pam_unix.so)
> PAM [dlerror: /usr/lib/pam_unix.so: Undefined symbol "setnetconfig"]
> PAM adding faulty module: /usr/lib/pam
On Sat, 4 May 2002, David O'Brien wrote:
> On Sat, May 04, 2002 at 06:51:08PM -0600, Kenneth D. Merry wrote:
> > How about this? Assuming exists() does the right thing (does it?), this
> > patch would restore the previous behavior if bsd.init.mk isn't there.
>
> That is what I have locally -- it
On Sat, 4 May 2002, Kenneth D. Merry wrote:
> On Sun, May 05, 2002 at 10:05:18 +1000, Bruce Evans wrote:
> > On Fri, 3 May 2002, Kenneth D. Merry wrote:
> > > > + .if exists()
> >
> > It will never exist when it has 2 layers of misspelling like this :-).
>
> I grabbed the __ part from bsd.ini
On 30 Apr 2002, Dag-Erling Smorgrav wrote:
> Doug Barton <[EMAIL PROTECTED]> writes:
> > I saw that actually... but (not coredumping) != (lets users log
> > in). :) Should I update and try again?
>
> Argh. Just replace pam_lastlog with pam_permit for now. I'll try to
> find out exactly what
On Sat, May 04, 2002 at 06:51:08PM -0600, Kenneth D. Merry wrote:
> How about this? Assuming exists() does the right thing (does it?), this
> patch would restore the previous behavior if bsd.init.mk isn't there.
That is what I have locally -- it just backs out rev 1.116. I was
waiting to get bs
On Sun, May 05, 2002 at 10:05:18 +1000, Bruce Evans wrote:
> On Fri, 3 May 2002, Kenneth D. Merry wrote:
>
> > On Fri, May 03, 2002 at 22:00:05 -0600, Kenneth D. Merry wrote:
> > > The attached patch "fixes" it for me.
> > >
> > > I'm sure someone can come up with a cleaner way of fixing the prob
On Sat, 4 May 2002, David O'Brien wrote:
> On Sat, May 04, 2002 at 09:26:33PM +0100, Brian Somers wrote:
> > Try disabling -pipe when building the compiler. This seems to make
> > things more stable here (CFLAGS=-O in /etc/make.conf) - as if
> > building the kernel with -pipe sometimes produces
On Sun, May 05, 2002 at 10:05:18AM +1000, Bruce Evans wrote:
> On Fri, 3 May 2002, Kenneth D. Merry wrote:
>
> > On Fri, May 03, 2002 at 22:00:05 -0600, Kenneth D. Merry wrote:
> > > The attached patch "fixes" it for me.
> > >
> > > I'm sure someone can come up with a cleaner way of fixing the pr
On Fri, 3 May 2002, Kenneth D. Merry wrote:
> On Fri, May 03, 2002 at 22:00:05 -0600, Kenneth D. Merry wrote:
> > The attached patch "fixes" it for me.
> >
> > I'm sure someone can come up with a cleaner way of fixing the problem.
It doesn't seem to be very easy to fix. Kernel makefiles should
On Sat, May 04, 2002 at 09:26:33PM +0100, Brian Somers wrote:
> Try disabling -pipe when building the compiler. This seems to make
> things more stable here (CFLAGS=-O in /etc/make.conf) - as if
> building the kernel with -pipe sometimes produces a kernel that
> subsequently murders the compil
On Sat, 2002-05-04 at 13:54, Martin Blapp wrote:
>
> Hi all,
>
> I experiment very strange problems here at the moment with
> a new server.
>
> Buildworld survives about 30 secondy, the errors are SIG4 (90%)
> and SIG11 (10%). And I cannot compile any important programs :-/
>
> I've exchanged
Hi,
Try disabling -pipe when building the compiler. This seems to make
things more stable here (CFLAGS=-O in /etc/make.conf) - as if
building the kernel with -pipe sometimes produces a kernel that
subsequently murders the compiler with sig11/sig4 all the time.
This is just marginally more th
I can tell now for sure that it happens on CURRENT only.
I replaced the disk with a STABLE one, same model, and have
completed a make buildworld -j 20 sucessfully.
The CURRENT disk (in this case SCSI, but it happens also on ATA
dumps core a buildworld after 10 - 30 seconds.
Martin
Martin Blap
In message <[EMAIL PROTECTED]>, Poul-Henning Kamp writes:
>
>I tried "make buildworld TARGET_ARCH=alpha" and it croaked. Is this
>expected breakage for a cross-build or genuine breakage ?
>/flat/src/usr.sbin/pstat/pstat.c:546: `NLOCKED' undeclared (first use in this
>fu
>nction)
It's genuine b
Poul-Henning Kamp <[EMAIL PROTECTED]> writes:
> I tried "make buildworld TARGET_ARCH=alpha" and it croaked. Is this
> expected breakage for a cross-build or genuine breakage ?
Are those sources up-to-date and consistent?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail
Hi all,
I experiment very strange problems here at the moment with
a new server.
Buildworld survives about 30 secondy, the errors are SIG4 (90%)
and SIG11 (10%). And I cannot compile any important programs :-/
I've exchanged all relevant parts:
- Power Supply: 300W, for PIV with additional CP
So I decided it might be nice to upgrade my Nov 21 CURRENT to today's and
started a make buildworld on a clean /usr/src and a /usr/obj with nothing it.
After a while I get:
===> gnu/usr.bin/binutils
===> gnu/usr.bin/binutils/libiberty
cc -O -g -pipe -march=pentium -Wall -D_GNU_SOURCE -I. -I/sto
I tried "make buildworld TARGET_ARCH=alpha" and it croaked. Is this
expected breakage for a cross-build or genuine breakage ?
Poul-Henning
===> usr.sbin/pstat
cc -O -pipe -mcpu=ev4-c /flat/src/usr.sbin/pstat/pstat.c
/flat/src/usr.sbin/pstat/pstat.c: In function `nfs_print':
/flat/src/usr.s
-On [20020504 11:45], David Malone ([EMAIL PROTECTED]) wrote:
>I did find some AMD errata docs which hinted at a problem involving
>4MB pages, MTRR and SMM. (Search for "MTRR SMM athlon ASEG" on
>google and you should get the PDF - there are two pages describing
>errata i
Hiten,
You're aborting on an assertion that no longer exists in vm_map.c. This
appears to be a case where your new kernel is based upon the new
vm_mmap.c but an old vm_map.c.
Please make sure that both vm_map.c and vm_mmap.c are updated and try a
"make clean" before building your kernel.
Regar
Hi there,
I've been attempting to get my Xircom Realport CBEM56G working under CURRENT
for some time without success. I grabbed the latest source on 03/05 12:00PM
GMT and compiled without a problem. I have a 3Com Etherlink III 3C589D card
which is a 16 bit card which I can insert and use withou
Hi all,
I just compiled the kernel now, the date is:
Sat May 4 14:18:08 BST 2002
I couldn't get a trace as I don't have a serial console or kernel dumps
because of some S_Clockinfo problem. Anyway, the panic message was like
this; just after trying to mount root:
%%
panic: mutex Giant not own
Daniel Rock schrieb:
>My kernel war relatively recent at the time of last boot - build
>around March 2nd from -CURRENT sources a few hours before.
>
>If someone runs -CURRENT with default HZ of 100 and moans 247 days
>later, his -CURRENT cannot be called -CURRENT any more...
>
>I am now running a
> Heh, finally someone that's actually trying to fix this. 8)
;-)
> The "right" thing is going to be to fix the MTRR code to preserve the
> extra MTRR bits; I've tried a few times to get some documentation on what
> these other bits mean without any luck.
The code I added to the MTRR stuff re
ken> It worked fine, up until the commit to kmod.mk.
That's by chance.
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Fri, 3 May 2002, Kenneth D. Merry wrote:
> On Sat, May 04, 2002 at 13:41:51 +0900, Makoto Matsushita wrote:
> >
> > ken> Sorry, it was this commit that broke building -current kernels on -stable:
> >
> > How do you build -current kernel on your -stable box?
> >
> > cd /usr
> > cvs
39 matches
Mail list logo
