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
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:
> > >
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
subscribe freebsd-current
subscribe cvs-all
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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 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 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
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
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
> >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:)
>
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)
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
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
: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
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?
>
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
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
> > 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
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
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
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
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
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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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
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](
28 matches
Mail list logo
