Another fix was made on feeding and sucking pcm data. Now chn_wrfeed()
and the other functions do not attempt excessive feeding during DMA
transfer to eat up the whole processor. The patch is at:
http://people.FreeBSD.org/~tanimura/patches/newmidi/2ndbuf-19991227.diff.gz
--
Seigo Tanimura <[EMA
Something funny's going on with mpg123 and the pcm sound driver with the
ESS 1868. Whenever a clip is playing with mpg123, the load average shoots
up to around 2 (when running X). When the clip is "finished", my machine
then feels sluggish as if the sound driver is somehow tying up the
cpu. The
The kernel dated Dec 6 works fine. The kernel compiled from yesterday's
sources detects and attaches the card, but there is no sound. mpg123
(and other programs) hang in "pcmwr" (tsleep in pcm/channel.c).
Both the new and old kernels report the card as:
pcm0: at port 0x530-0x53f,0x310-0x311
Peter Wemm wrote:
> > > b) could not open /usr/local/lib/vmware/lib/vmm (no such file or directory)
>
> That is because /proc/curproc/exe is missing. Under Linux it's a pointer to
> the executable file (like our "file" used to be before it was killed). A
> trivial patch to reactivate it in a fo
On Sunday, 26 December 1999 at 21:24:15 -0500, Gary Palmer wrote:
> Greg Lehey wrote in message ID
> <[EMAIL PROTECTED]>:
>> It occurs to me that it is, in fact, correct to read from a volume
>> being revived. The data is consistent up to the point where the
>> revive has progressed, so the syste
Greg Lehey wrote in message ID
<[EMAIL PROTECTED]>:
> It occurs to me that it is, in fact, correct to read from a volume
> being revived. The data is consistent up to the point where the
> revive has progressed, so the system can read from this area.
Why would it be reading from the reviving ple
On Sunday, 26 December 1999 at 20:54:17 -0500, Gary Palmer wrote:
> Greg Lehey wrote in message ID
> <[EMAIL PROTECTED]>:
>> Did you forget the 'setupstate' keyword?
>
> How would that apply? The 2nd disk was not consistant as it was added
> after the data was copied onto the first and the old di
Greg Lehey wrote in message ID
<[EMAIL PROTECTED]>:
> Did you forget the 'setupstate' keyword?
How would that apply? The 2nd disk was not consistant as it was added
after the data was copied onto the first and the old disks removed.
Or should I have dd'd the contents of the first disk onto the s
On Sunday, 26 December 1999 at 19:03:27 -0500, Gary Palmer wrote:
>
> Hi Greg,
>
> I've got a question or two about vinum, and how to work it.
>
> I'm trying to upgrade the storage on my home computer, and while I was
> transitioning my old disks out, I only managed to get one of the new
> ones on
so i commented kerberos out of /etc/make.conf so i could keep chugging. an
hour later (smp off and only a 300mhz chip), perl cores the build.
cc -o /usr/obj/usr/src/gnu/usr.bin/perl/perl/build/POSIX/auto/POSIX/POSIX.so -shared
POSIX.o-lperl
chmod 755 /usr/obj/usr/src/gnu/usr.bin/perl/per
"Vladimir N. Silyaev" wrote:
> > I created a new configuration and the only problem seems
> > to be the following error messages:
> > a) about missing /dev/rtc and
> Exactly, /dev/rtc doesn't supported.
.. and I'm not entirely sure that we can support it easily. Linux appears
to allow user proc
Hi Greg,
I've got a question or two about vinum, and how to work it.
I'm trying to upgrade the storage on my home computer, and while I was
transitioning my old disks out, I only managed to get one of the new
ones online to copy data onto it. Now I want to mirror that volume
onto a 2nd plex.
As of today -current ppp is still incorrectly parsing dial string (yes,
I know that Brian several days ago already submitted some patches to
address similar problems, but it seems that it was not enough).
Following is transcript of my session, using configuration which worked
flawlessly on the pre
> ===> lib/libform
> cd: can't cd to /usr/src/lib/libform
> *** Error code 2
>
> so i removed libform from the /usr/src/lib/Makefile, and am now blessed with
>
> ===> usr.bin/strip
> rm -f maybe_stripped strip strip.o strip.1aout.gz strip.1aout.cat.gz
> rm -f .depend /usr/src/usr.bin/strip/GPATH
>Actually, that's one of the newest versions of gcc.
Perhaps a later snapshot of gcc will work .
>attached make.log. There's something about not allowing access
>to the cx register.
I am not into hacking gcc's register allocator 8)
--
Amancio Hasty
[EMAIL PROTECTED]
To Unsubscribe: s
> I'm trying to get the latest version of OSS (3.9.3a) working under
> -current and having very little success.
>
> When I try running soundconf, I get the following messages:
>
> kldload: can't load /usr/opt/oss/oss_mod: Exec format error
> Cannot load OSS driver module.
>
> Dec 25 21:02:46 he
Randy,
There are a few things you have to do when supping from 3.* to -CURRENT
The Best Source of information I have found is at
http://www.external.org/freebsd/current.html
I hope this document helps you, I have tried it, it worked fine (however
I didn't like -CURRENT so I reformatted and
FreeBSD-hackers list is added.
KATO Takenori <[EMAIL PROTECTED]> wrote:
> I didn't realize the difference in type of bus_space_handle_t. So,
> bus.h needs to be separated into bus_at386.h and bus_pc98.h.
I revised bus space patch. This patch does:
1. copy bus.h to bus_at386.h. The bus_at
===> lib/libform
cd: can't cd to /usr/src/lib/libform
*** Error code 2
so i removed libform from the /usr/src/lib/Makefile, and am now blessed with
===> usr.bin/strip
rm -f maybe_stripped strip strip.o strip.1aout.gz strip.1aout.cat.gz
rm -f .depend /usr/src/usr.bin/strip/GPATH /usr/src/usr.bin/
trying an upgrade from 3.4-stable to -current.9912261321
did a full rm -rf of /usr/src and /usr/obj, then a full cvsup. buildworld
dies:
rm -f libfetch.a # llib-lfetch.ln
rm -f fetch.po common.po ftp.po http.po file.po fetch_err.po fetch.po.tmp
common.po.tmp ftp.po.tmp http.po.tmp file.po.tmp
Amancio Hasty wrote:
>
> While trying to compile the latest version of XFree86 I found the following
> compiler bug.
>
> {root} gcc -v
> Using builtin specs.
> gcc version 2.95.2 19991024 (release)
>
> I assume that this an old version of gcc...
Actually, that's one of the newest versions of g
On Sat, Dec 25, 1999 at 11:13:19PM +0100, Andreas Klemm wrote:
>
> Well, I think I had an outdated vmware port.
> I grabbed it new from the mindspring webserver.
> Then I had to manually load the vmmon.ko module
> from /usr/local/lib/vmware/lib/modules
Don't required, this modules are loaded at
Cc:ed to -chat where this seems to belong now.
Yes, everyone should be familiar with fsdb (you should have seen the fear
on a coworker's face the other day when I said something about fixing a
filesystem with fsdb in jest. It was straight unadulterated terror.) The
mere mention of this tool makes
On Tue, 14 Dec 1999, Ben Rosengart wrote:
> > vi -- which is in /usr.
>
> Good example of something else that would be great to have in /bin.
>
> *ducking*
>
> --
> Ben Rosengart
and as a coworker, I'd have to tell you how to use cat ;)
ROTFL.
-Pat
__
Pat Lynch
Mike Smith wrote:
> > b) could not open /usr/local/lib/vmware/lib/vmm (no such file or directory)
.
>
> No idea about that one.
That is because /proc/curproc/exe is missing. Under Linux it's a pointer to
the executable file (like our "file" used to be before it was killed). A
trivial patc
25 matches
Mail list logo
