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](bp)
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
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 Driver
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
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 known
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 though, can
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?
No it doesn't.
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, and things
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: depends on
ng_ether - not
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)
DES
--
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 is that??
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
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.c
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
subscribe freebsd-current
subscribe cvs-all
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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:
If
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 keep
21 matches
Mail list logo
