Can somebody please try if this fixes MFS ?
Poul-Henning
Index: ufs/mfs/mfs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/mfs/mfs_vfsops.c,v
retrieving revision 1.63
diff -u -r1.63 mfs_vfsops.c
--- mfs_vfsops.c1999/05/14 20:
> Anyone know why libf2c* was renamed to libg2c* in egcs?
Cygnus has hacked (possibly considerably) Bell-Labs' libf2c. To the
point a program written to the EGCS's FORTRAN lib wouldn't be linkable
with libf2c. Thus they felt the need for a unique name.
> Does egcs have a replacement for f2c?
> Index: Makefile
> ===
> RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v
> +beforeinstall:
> + ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
> + ${DESTDIR}/usr/include
> +
$ brucify Makefi
--- Begin Message ---
I recently made a 15GB filesystem and ended up with almost 500
cylinder groups. That is unlikely to be optimal. I talked to Kirk
about the right parameters for UFS on modern disks some years back,
and he said that no more than maybe a hundred cylinder groups made
any sense.
On Sun, 23 May 1999 11:32:27 +0200, Poul-Henning Kamp wrote:
> Can somebody please try if this fixes MFS ?
Do you want your patch applied alongside Luoqi Chen's patch to
kern_conf.c from last week? I've been able to mount_mfs without problems
since then.
Ciao,
Sheldon/
To Unsubscribe: send m
Peter Wemm wrote:
> Bruce Evans wrote:
> > >calcru() access p_stats, which is in upages. Therefore, as I understand,
> > >it should not be called on a swapped out process. Neither calcru() nor
> >
> > Does anyone object to moving everything except the stack from the upages
> > to the proc table?
In message <4478.927463...@axl.noc.iafrica.com>, Sheldon Hearn writes:
>
>
>On Sun, 23 May 1999 11:32:27 +0200, Poul-Henning Kamp wrote:
>
>> Can somebody please try if this fixes MFS ?
>
>Do you want your patch applied alongside Luoqi Chen's patch to
>kern_conf.c from last week? I've been able to
The -current MAKEDEV has a problem.
The recent addition of the i4btel?? stuff has broken "sh MAKEDEV all"
The section of the sh case for "i4teld*)" should be BEFORE the case for
"i4tel*)". (match the longest prefix first!)
This problem is causing the generation of i4teld? to FAIL! and thus the
'
I am confused!
The /boot/loader is "announcing" that it wants the root device to be
"da0s1a".
It appears that the "normal" fstab entries want "sliced" versions as well,
eg.
# DeviceMountpoint FStype Options Dump
Pass#
/dev/da0s1b noneswaps
On Sun, 23 May 1999, David O'Brien wrote:
# > Index: Makefile
# > ===
# > RCS file: /home/ncvs/src/gnu/lib/libg2c/Makefile,v
#
# > +beforeinstall:
# > + ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 ${.CURDIR}/g2c.h \
# > +
># $ brucify Makefile
># Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
># character.
>
>I pilfered the format from src/lib/libalias/Makefile, so it fails
>brucify(1) there as well. :)
I don't know where all the bad examples in src/lib/*/Makefile came from.
In Lite
> ># $ brucify Makefile
> ># Line 123: Continuation of rule should be indented 4 spaces, not 1 tab
> ># character.
> >
> >I pilfered the format from src/lib/libalias/Makefile, so it fails
> >brucify(1) there as well. :)
>
> I don't know where all the bad examples in src/lib/*/Makefile ca
Hi !
I am new to to list and to BSD-current. I cvsup'ed whole thing and
installed it over weekend, but I encountered problem. I have one machine at
home with two ethernet cards of same type (NE2000 compatible). One is used
for connection to cable modem and other to my private network. Problem is
t
Poul-Henning Kamp wrote:
> In message <199905230245.maa13...@godzilla.zeta.org.au>, Bruce Evans writes:
> >>calcru() access p_stats, which is in upages. Therefore, as I understand,
> >>it should not be called on a swapped out process. Neither calcru() nor
> >
> >Does anyone object to moving every
Following my latest rebuild (make world on Friday, make of kernel
on Friday) -- I can no longer find my ed0 (WD 8216) network card.
dmesg.yesterday:ed0 at port 0x280-0x29f iomem 0xd8000-0xdbfff irq 10 on isa0
dmesg.yesterday:ed0: address 00:00:c0:bb:a8:b2, type SMC8216/SMC8216C (16 bit)
dmesg.yes
I recently tried building a new kernel after quite a bit, and I get a
panic while the system's booting in devfs_makelink, apparently being
called from fd_attach().
Is DEVFS and the new-bus code hopelessly incompatable, and should I just
unconfigure DEVFS? Or is this something that I can dig into
In message <199905240133.vaa01...@i4got.pechter.dyndns.org> Bill
Pechter writes:
: dmesg.yesterday:ed0 at port 0x280-0x29f iomem 0xd8000-0xdbfff irq 10 on isa0
: The ed0 line is the same as it was before:
: device ed0 at isa? port 0x260 irq 9 iomem 0xd8000
I find that extremely hard to believe...
Quoting Louis A. Mamakos (lo...@transsys.com):
>
> I recently tried building a new kernel after quite a bit, and I get a
> panic while the system's booting in devfs_makelink, apparently being
> called from fd_attach().
>
> Is DEVFS and the new-bus code hopelessly incompatable, and should I just
>
I got this with recent -current. Something need to be fixed since ed0 line
is the same as in LINT (iomem 0xd8000) excepting irq is different.
...
ed0 at port 0x300-0x31f iomem 0 irq 10 on isa0
isa_compat: didn't get memory for ed
ed0: address 00:c0:6c:62:47:20, type NE2000 (16 bit)
...
--
Andre
In message <199905240222.waa00...@whizzo.transsys.com>, "Louis A. Mamakos" writ
es:
>
>I recently tried building a new kernel after quite a bit, and I get a
>panic while the system's booting in devfs_makelink, apparently being
>called from fd_attach().
>
>Is DEVFS and the new-bus code hopelessly in
20 matches
Mail list logo
