In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>MFS is very inefficient. I didn't fix that... it isn't possible to
>fix it without a lot of work.
The real fix is to make "struct buf" more object oriented, so that
instead of
bwrite(bp)
one does
bp->b_op[BOP_BWRITE](
On Sun, Jan 14, 2001 at 04:41:30PM +1030, Matthew Thyer wrote:
> At the time the message occurred I had less than 6 MB usage in
> /tmp if that.
I believe that for `df' output. But what was the memory usage of the mfs
processes (using `ps')?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Hi all,
I just got round to popping the lid on my machine and installing a
Soundblaster 64 PCI card. I already had pcm in my kernel. It's working,
but there are some Strange Things Happening.
Firstly, here's /dev/sndstat:
FreeBSD Audio Driver (newpcm) Jan 5 2001 12:50:04
Installed devices:
pcm
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sun, 14 Jan 2001 16:41:30 +1030, Matthew Thyer wrote:
> Sheldon, I'm not stupid.
Sorry to have come across like that.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Dear Sears!
We are glad to propose You the unique opportunity of
fundamental life changing with the consultation of Universe
Informational Center.
We suggest momentary readout information from any animate
and inanimate object independently from time and distance.
Diagnostics
I'm slightly hoping that enabling an AUTO HALT mode will turn the fan down.
I don't think it will, I think I will have to do some subset of what
"acpiconf -s 1" does in cpu_idle but will still respond to the next clock
interrupt...
So my two questions are:
1. Is there an obvious subset of S1 tha
On Sun, 14 Jan 2001, Michael Wells wrote:
> Hi all,
>
> I just got round to popping the lid on my machine and installing a
> Soundblaster 64 PCI card. I already had pcm in my kernel. It's working,
> but there are some Strange Things Happening.
>
> Firstly, here's /dev/sndstat:
>
> FreeBSD Audio D
Hi John
There seems to be same breakage in the atomic stuff:
link_elf: symbol atomic_load_acq_int undefined
KLD file random.ko - could not finalize loading
I back out the latest commit to sys/i386/include/atomic.h, and things
work a bit better (on my laptop).
M
--
Mark Murray
Warning: this .s
> > If this is a known problem, I'll stop for now and watch out for fixes.
> > If it's not the expected behaviour from the PCM driver though, can
> > anyone advise?
>
> Okay, just checked and it appears tha htis is the same error that I'm
> seeing on mine, as reported yesterday ... not sure if its
On Sun, 14 Jan 2001, Cameron Grant wrote:
> > > If this is a known problem, I'll stop for now and watch out for fixes.
> > > If it's not the expected behaviour from the PCM driver though, can
> > > anyone advise?
> >
> > Okay, just checked and it appears tha htis is the same error that I'm
> > se
yup, just confirmed ... it does it with splay as well ...
On Sun, 14 Jan 2001, The Hermit Hacker wrote:
> On Sun, 14 Jan 2001, Cameron Grant wrote:
>
> > > > If this is a known problem, I'll stop for now and watch out for fixes.
> > > > If it's not the expected behaviour from the PCM driver th
In message <[EMAIL PROTECTED]>, Andrea Campi writes:
>> >> I think it's the time to throw i386 over the railing and lower the
>> >> waterline a fair bit on -current.
>> >
>> >Does it make any sense at all to make 80386 a separate platform
>> >a'la pc98/alpha/ia64? Do enough people care about it?
>
:If nobody has the hardware to test it on, *and* the inclination
:to do so, it will not get tested, and the code will erode as a
:result.
:
:I have a 386SX/20 CPU, but I'll be damned if I can be bothered
:to boot FreeBSD-current on it, in fact it didn't even boot
:a 4.x last I tried.
:
:Any featur
On 2001-Jan-14 23:02:28 +0200, Mark Murray <[EMAIL PROTECTED]> wrote:
>Hi John
>
>There seems to be same breakage in the atomic stuff:
>
>link_elf: symbol atomic_load_acq_int undefined
>KLD file random.ko - could not finalize loading
>
>I back out the latest commit to sys/i386/include/atomic.h, an
Dag-Erling Smorgrav wrote:
>
> Julian Elischer <[EMAIL PROTECTED]> writes:
> > Jun Kuriyama wrote:
> > > # kldload ng_bridge
> > > kldload: can't load ng_bridge: Exec format error
> > > And /var/log/messages says:
> > >
> > > Jan 12 16:27:07 waterblue /boot/kernel/kernel: KLD ng_bridge.ko: depend
Julian Elischer <[EMAIL PROTECTED]> writes:
> Dag-Erling Smorgrav wrote:
> > Something is terribly broken with ng_ether at the moment. It lacks a
> > MODULE_VERSION line.
> is this required for something to be a depency?
Yes.
> Where is it documented?
It's not, AFAIK. UTSL (like the rest of us)
> >Sorry Poul, I think the question here is: "if we decide to remove i386 support
> >BUT a few people still want to use it and can maintain it as a separate
> >platform port, is it an option to do so, from a technical point of view?"
> >
> (This is a general answer, not just about i386 support:)
>
I'm tempted to suggest that the freebsd-small and / or PicoBSD gang
would be the right people to ask to maintain i386 support in FreeBSD.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Jan 15, 2001 at 09:25:45AM +1100, Peter Jeremy wrote:
> Due to incompatibilities between __asm in different versions of gcc,
> several different versions of various macros (and expansions) are
> necessary.
Why is that?? The base, and *only* supported compiler for building
kernels is GCC
On 2001-Jan-14 17:05:20 -0800, David O'Brien <[EMAIL PROTECTED]> wrote:
>On Mon, Jan 15, 2001 at 09:25:45AM +1100, Peter Jeremy wrote:
>> Due to incompatibilities between __asm in different versions of gcc,
>> several different versions of various macros (and expansions) are
>> necessary.
>
>Why i
I just updated my source tree and ran make buildkernel, and it runs until
it gets to removing the old GENERIC directory in the /usr/obj/ tree. Just
after it removes that directory, I get this error:
../../conf/files coda/coda_fbsd.c must be optional, mandatory or standard
** error code 1
stop i
On Sun, Jan 14, 2001 at 08:28:14PM -0500, Dibble wrote:
> I just updated my source tree and ran make buildkernel, and it runs until
> it gets to removing the old GENERIC directory in the /usr/obj/ tree. Just
> after it removes that directory, I get this error:
>
> ../../conf/files coda/coda_fbsd
I wonder if a better approach might be to make /dev/random return 0
bytes when unseeded, instead of blocking. Then srandomdev() would
automatically back down to seeding internally, for example, and no
other code changes in mount_mfs would be needed.
A warning could be emitted in this case for dia
subscribe freebsd-current
subscribe cvs-all
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On 15 Jan 2001 01:38:00 +0100, Dag-Erling Smorgrav wrote:
> I'm tempted to suggest that the freebsd-small and / or PicoBSD gang
> would be the right people to ask to maintain i386 support in FreeBSD.
Guys, was Matt Dillon's suggestion infeasible? Can't we keep CPU_I386
support and just make i
Hi Cameron, all,
I'm not really tied to any single application. Streaming an .au file
from the command line into /dev/dsp does it, mpg123, XMMS...really, the
same symptoms everywhere.
Any ideas?
Michael
On Sun, Jan 14, 2001 at 09:08:47PM -, Cameron Grant ([EMAIL PROTECTED])
wrote:
> > >
Sheldon Hearn wrote:
>
>
> On 15 Jan 2001 01:38:00 +0100, Dag-Erling Smorgrav wrote:
>
> > I'm tempted to suggest that the freebsd-small and / or PicoBSD gang
> > would be the right people to ask to maintain i386 support in FreeBSD.
>
> Guys, was Matt Dillon's suggestion infeasible? Can't we
28 matches
Mail list logo
