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 understa
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 sys/
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 included. Oh well.
--
Michael D. Harnois, Redeemer Lutheran Church
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
* 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.
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,
> 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 pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 26 Nov 2000, Andrew Kenneth Milton wrote:
> I've now tried 5 different Sound Cards in an effort to find one that
> doesn't spew
>
> pcm0: hwptr went backwards 2060 -> 1872
>
FWIW (and I know it can't be worth much, since I haven't gathered the
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 /usr/obj/usr/local/base/src/i386/usr/inc
On Mon, Nov 27, 2000 at 01:20:39AM +0200, Mark Murray wrote:
> See above. SSH needs good randomness. it is silly to try to break
> that.
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, k
+---[ 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/sysmo
>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 rarel
> 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 a
> I tend to agree. Moused is an optional component in FreeBSD,
> thus, we cannot expect that it is always running.
I'm not expecting it, but it is a folly to ignore that good a source
of randomness. If you don't have a mouse (or you don't use it),
there is a bit of a struggle for randomness. It
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
with
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
normally
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 exa
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.co
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 #0:
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, in
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 a
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 funct
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, 199
I see that support has been added for demand-loading network
if drivers. I seem to recall that the last time I tried using
network drivers as klds, nothing that required bpf to work
was functional anymore, because bpf required that the device
existed at the time it was initialized. Is this still
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?
>
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: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
unknown1: at port 0x200-0x207 on isa0
unknown2: at port 0x620-0x623 on isa0
It is my
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 woul
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 followin
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
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 wrote
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.
> > (S
On Mon, Sep 27, 1999 at 05:05:37AM +0800, Peter Wemm wrote:
>
> The old PnP code was matching on the card vendor ID. The new pnp code
> treats each logical device on it's own and matches by logical ID..
> (It's actually far more useful that way as most cards have their own
> manufacturer ID but
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 lis
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 th
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 see
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 ou
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 Unsubscri
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 no
In article
[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
>/usr/local/base/src/usr.bin/netstat/if.c
>In file incl
On Sun, 26 Nov 2000, Jonathan Lemon wrote:
> In article
>[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/incl
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 cause
46 matches
Mail list logo
