I've now tried 5 different Sound Cards in an effort to find one that doesn't
spew
pcm0: hwptr went backwards 2060 - 1872
all the time. (Seems to happen more when I move my mouse (PS/2)).
I've tried:
SB 16 + SCSI-2
Opti 931 (MED 3931 Ver2.0)
CMI8330
ES1869 (Playing sound locks the machine)
+---[ Andrew Kenneth Milton ]--
| I've now tried 5 different Sound Cards in an effort to find one that doesn't
| spew
|
| pcm0: hwptr went backwards 2060 - 1872
Ok so I've been told this is related to the random module.
Having had a look through the code I now
On Sat, 25 Nov 2000 18:01:33 -0500 (EST), Bosko Milekic [EMAIL PROTECTED]
said:
jlemon, I think you may want to remove the include for
sys/mbuf.h in if_var.h if it isn't needed (try) -- I think this
is what may be screwing up netstat.
OK, I think I have it now. Remove
On Sun, Nov 26, 2000 at 01:06:12PM -0600, Michael Harnois wrote:
On 26 Nov 2000 12:48:48 -0600, Michael Harnois [EMAIL PROTECTED] said:
OK, I think I have it now. Remove sys/mbuf.h and change
machine/mutex.h to sys/mutex.h.
Except that the kernel won't build if sys/mbuf.h isn't
* Jonathan Lemon [EMAIL PROTECTED] [001126 11:18] wrote:
On Sun, Nov 26, 2000 at 01:06:12PM -0600, Michael Harnois wrote:
On 26 Nov 2000 12:48:48 -0600, Michael Harnois [EMAIL PROTECTED] said:
OK, I think I have it now. Remove sys/mbuf.h and change
machine/mutex.h to
On Sun, Nov 26, 2000 at 11:23:45AM -0800, Alfred Perlstein wrote:
* Jonathan Lemon [EMAIL PROTECTED] [001126 11:18] wrote:
On Sun, Nov 26, 2000 at 01:06:12PM -0600, Michael Harnois wrote:
On 26 Nov 2000 12:48:48 -0600, Michael Harnois [EMAIL PROTECTED] said:
OK, I think I have
Ok so I've been told this is related to the random module.
Related, sure, but the real problem is elsewhere.
Having had a look through the code I now understand what the problem is.
I think that for those people using /dev/sysmouse under X that
having random_harvest in scmouse.c is
Just tried to do a buildworld, got as far as netstat before it barf'd
with:
=== usr.bin/netstat
cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC
-I/usr/obj/usr/local/base/src/i386/usr/include -c
/usr/local/base/src/usr.bin/netstat/if.c
In file included from
+---[ Mark Murray ]--
| Ok so I've been told this is related to the random module.
|
| Related, sure, but the real problem is elsewhere.
|
| Having had a look through the code I now understand what the problem is.
|
| I think that for those people using /dev/sysmouse
To be fair, if the random module depends that badly on getting
entropy from the mouse it isn't much good for many of our users
who may not even have a mouse, keyboard or console. (Even when
using X, personally I use the mouse as little as possible. On some
of our servers the console is rarely
I think the yarrow stuff is probably somewhat more roubust than
requiring the mouse - as long as there is some source of entropy.
What other sources does the random device currently use?
Currently - keyboard and mouse.
RSN, also interrupts and network activity.
M
--
Mark Murray
Join the
I meet a problem that: when I start my system is say:
rtc rtckldload: can't load /usr/local/modules/rtc.ko: Exec format error
link_elf: symbol lminor undefined
link_elf: symbol linux_ioctl_register_handler undefined
why?
System: FreeBSD-current src-cur.4613.gz with Linux_base 6.1
The answer depends on exactly how current you are...
With -current from a few days ago, I would have said:
Make sure you have a /boot/loader.rc file that contains at least
these lines:
load /kernel
load -t /boot.config
Then, make sure /boot.config contains all the stuff that you would
After a 'make world' last night, everytime I use any of the AWE
utilities (as ported by Randall Hopper) I get this:
AWE32: unsupported ioctl -1064546046
AWE32: unsupported ioctl -1064546046
I remember seeing a couple of commits to some of the files in
sys/i386/isa/sound, but I don't remember
On Mon, Mar 15, 1999 at 07:16:24PM +0900, Daniel C. Sobral wrote:
"Donald J . Maddox" wrote:
If you are *really* -current, /boot/loader.rc should probably
just contain something like:
include /boot/loader.4th
start
Then, you should copy /boot/defaults/loader.conf to
After last night's new kernel and 'make world', I find I am seeing
some interesting new warnings at boot time:
Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT
The new PnP code just plain does not work for my PnP AWE64.
If I configure like this:
controller pnp0
controller snd0
device sb0
device sbxvi0
device sbmidi0
device awe0
device opl0
device joy0
Which is the way it *should* work,
The whole point is that I want to be able to use the wavetable
synthesis features of the card. Newpcm (or oldpcm, for that matter)
provides NO support for the AWE device whatsoever, as you can see
from your dmesg below.
It makes little sense to me that PnP functionality should be tied
down to a
On Sun, Sep 26, 1999 at 10:51:59AM -0700, Mike Smith wrote:
Sigh. Again, I didn't demand anything.
I simply pointed out that functionality had been lost. If I
was the author of this code, I would *want* feedback on how
it was working out for people out here in userland. I assume
On Sun, Sep 26, 1999 at 01:11:55PM -0400, Gary Palmer wrote:
"Donald J . Maddox" wrote in message ID
[EMAIL PROTECTED]:
I'm just suggesting here that it would be nice if the authors of
this code would make it _equally functional_ to what was removed.
It's not nice to remove functionality
Sigh. Again, I didn't demand anything.
I simply pointed out that functionality had been lost. If I
was the author of this code, I would *want* feedback on how
it was working out for people out here in userland. I assume
that the authors in question _do_ want such feedback.
On Sun, Sep 26,
On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
PnP is an infrastructure facility used by drivers to detect and
configure hardware. The side-effect you were relying on was that the
old code would indiscriminately configure any and all PnP hardware
regardless of whether a
On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
But we do have a working driver for the AWE64. Or rather, it worked fine
before the new PnP code was comitted, now it doesn't. It seems to me that
this indicates a deficiency in the new PnP code. Isn't that correct?
No.
I couldn't get my PnP Creative AWE64G to work with the new PnP
code, so I tried compiling a kernel with pcm instead. All I get is:
unknown0: Audio at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
unknown1: Game at port 0x200-0x207 on isa0
unknown2: WaveTable at port 0x620-0x623
On Sun, Sep 26, 1999 at 11:59:33AM -0700, Mike Smith wrote:
On Sun, Sep 26, 1999 at 11:41:14AM -0700, Mike Smith wrote:
PnP is an infrastructure facility used by drivers to detect and
configure hardware. The side-effect you were relying on was that the
old code would
Ok, will do. Thanks.
This may be a silly question, but... The old PnP driver recognized
a lot of devices, including my AWE64. Isn't there a list of IDs it
was aware of that should be merged into newPnP ASAP?
On Mon, Sep 27, 1999 at 04:27:42AM +0800, Peter Wemm wrote:
Please try the
Thanks. That is exactly what I have done. The AWE device cannot
work this way, but everything else is functional if I remove the
PnP controller from my kernel...
On Sun, Sep 26, 1999 at 10:04:38PM +0200, D. Rock wrote:
"Donald J . Maddox" schrieb:
Is the new PnP code really so smart that it
On Sun, Sep 26, 1999 at 02:23:18PM -0700, Mike Smith wrote:
Can you give me a few hints on what would be necessary to get the old
driver to work with the new PnP?
As has already been explained to you (you _do_ read these messages in
their entirety, right?), the old driver has been
While your response seems a bit strong, to say the least, I confess
that the redirection was a real mistake... I thought Mike had replied
to me on the list and I had hit 'r' by accident, instead of 'g', in
mutt. My apologies to Mike.
On Sun, Sep 26, 1999 at 05:10:30PM -0400, Bill Fumerola
On Sun, Sep 26, 1999 at 02:29:43PM -0700, Mike Smith wrote:
Again, thanks for the very helpful and informative answers. I would still
appreciate it if someone could give me a little bit more of a clue as to
what is necessary to add newPnP-awareness to the AWE driver, though.
(Surly
God knows, I'll second that one... :-) Hear, hear!
On Sun, Sep 26, 1999 at 07:39:27PM -0700, Darryl Okahata wrote:
I want to publicly thank Peter Wemm for posting a reply that is
courteous, informative, and useful. Recently, there has been too much
noise in this and other FreeBSD
Thanks, Doug. Peter already provided an equivalent patch, and I am
happy to report that it works like a charm (of course :-)).
On Mon, Sep 27, 1999 at 10:35:46AM +0100, Doug Rabson wrote:
On Sun, 26 Sep 1999, Donald J . Maddox wrote:
I couldn't get my PnP Creative AWE64G to work with the
Thanks for the info. I do read the commit logs, and I was aware
of this commit; however, it's not entirely clear to me if this
commit resolves the issue I'm talking about.
The problem, as I recall, had to do with the bpf pseudo-device
attaching to devices _only_ at boot time, so it would not
It's defined in sys/boot/common/bootstrap.h. I think all you want to know
is in that file.
On Tue, Oct 12, 1999 at 09:46:12PM -0400, Chuck Robey wrote:
I'm looking at sys/boot/common/pnp.c so I can find out how pnp is handled,
and I found something called a COMMAND_SET, and I can't figure out
Thanks again, Daniel... I'll take a look. If the ID isn't in there,
I'll submit a PR to get it added. (should only take about 10-12
months to actually get it comitted, if experience is a reliable guide :-/)
On Sun, Sep 26, 1999 at 10:09:58PM +0200, D. Rock wrote:
"Donald J . Maddox" schrieb:
the sound card is a Crystal Semiconductor CS 4624 controller with CS 4297A
AC97 codec, pcic0 is a TI PCI-1450 PCI-CardBus Bridge.
sound output results in "pcm0: play interrupt timeout, channel dead".
try turning off apm and all power saving in the bios setup.
-cg
To Unsubscribe:
On Sun, 26 Nov 2000, Mark Murray wrote:
seems to be going ok, but I pick up a kernel panic whilst printing.
Ditto. Also on a dual-cpu machine, also a really recent CURRENT.
Well, I can catch the panic in gdb, but I'm not
In article
local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
Just tried to do a buildworld, got as far as netstat before it barf'd
with:
=== usr.bin/netstat
cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC
-I/usr/obj/usr/local/base/src/i386/usr/include -c
On Sun, 26 Nov 2000, Jonathan Lemon wrote:
In article
local.mail.freebsd-current/[EMAIL PROTECTED]
you write:
Just tried to do a buildworld, got as far as netstat before it barf'd
with:
=== usr.bin/netstat
cc -O -pipe -Wall -DIPSEC -DINET6 -DIPSEC
Immediate problem is fixed by including machine/param.h in netstat/if.c.
ifmcstat, rip6query, rtadvd/dump.c, i4b/isdnd/rc_config.c too...
Those appear to be all.
I don't know the "canonical" solution;
maybe including machine/param.h in if_var.h? (or was removing it
for "cleanliness" the
40 matches
Mail list logo
