Re: Syscons flag to turn off random_harvest in scmouse?
> 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 can be worked around, but with some difficulty. > It may be a good source of randomness, but the random module > cannot and should not depend on it so heavily. That is temporary. Within a couple of weeks there will be harvesting from more sources. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
> 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 anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
>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 used). I tend to agree. Moused is an optional component in FreeBSD, thus, we cannot expect that it is always running. It may be a good source of randomness, but the random module cannot and should not depend on it so heavily. Kazu >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? > > David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
+---[ 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 under X that | > having random_harvest in scmouse.c is probably ill advised. | | That is a _great_ source of entropy. So are disk and network accesses, I don't see harvesting code being sprinkled inside them. Probably because more people would scream if their network or disk performance died. | Please explain "ill advised". Your system will suffer so badly that a) You will lose serial interrupts when using X b) You will not be able to use your sound card with acceptable performance c) If you use an ATAPI cdrom you will get device timeouts; acd0: READ_BIG command timeout - resetting ata0: resetting devices .. ata0: mask=01 ostat0=58 ostat2=00 interactive use of -current will be so poor as to be useless. | > Can we have a flag for syscons to turn this off, or do we just turn off | > moused and run X with direct access to the mouse? Since it seems you | > can do this, there wouldn't seem to be harm in having a flag. | | Why? The rest of the kernel has not had the Giant mutex properly | degraded/removed/unravelled, and this is the real problem. Well this would indicate that having the current random module is probably a little premature then. Perhaps we should back it out completely until the Giant mutices are gone. | If having the mouse randomness (very approcimately the best randomness | available) removed is really what you want, then doing a private | patch in your own sources is probably best. | | Later, when the Giant unravelling progresses, you can remove that. I'm asking for an non-default flag/option to turn off the harvesting inside syscons until then. A sysctl would be good. | > I still need the random module to use ssh (and I used to have it built | > into my kernel, so I couldn't simply unload it). | | See above. SSH needs good randomness. it is silly to try to break | that. But if I want that randomness I can't actually use the machine to use ssh. I don't think turning my machine into a single-purpose graphical entropy provider is really that acceptable. As to "good" ; /* NOTE NOTE NOTE - This is not finished! It will supply numbers, but * it is not yet cryptographically secure!! */ That's your comment isn't it? If you're only harvesting from the keyboard and mouse then you are in trouble for headless servers. Most things that require really strong random numbers are network connected in some way, so perhaps the harvesting should be focussed more on network interfaces where it makes more sense, rather than relying on localised human intervention. And as mentioned before it seems to be easily circumventable for people directly talking to their mouse device. | > It seems a bit of a shame that if you want to use your sound card that | > you give up X, or you give up ssh. | | If you are function oriented, rather than development oriented, | why are you useing CURRENT? Because I don't want to have a -current box for development and a -stable box as head for it. Running current actually means it gets tested. Where would you be if noone actually ran it in 'real world' situations. It just happens that at the moment in the real world it sucks if you want random numbers. Look I know you wrote it, and I know you took heat for it. Perhaps you should back off a bit and have a little objectivity here. I don't want to get rid of the random module, I want to reduce the impact it has on my machine when I'm using it interactively, and that's my choice. Given the number of unanswered emails about hwptr went backwards there's a lot of people who run current and might also like that choice. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mbuf.h in netstat
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 of this?) -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
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, 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 used). 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? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld broken ... CVS from today ...
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/include -c > >/usr/local/base/src/usr.bin/netstat/if.c > >In file included from > >/usr/obj/usr/local/base/src/i386/usr/include/net/if_var.h:78, > > from /usr/local/base/src/usr.bin/netstat/if.c:49: > >/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' > >undeclared here (not in a function) > > Already fixed. great, grabbing a new copy now, thanks ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld broken ... CVS from today ...
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 included from >/usr/obj/usr/local/base/src/i386/usr/include/net/if_var.h:78, > from /usr/local/base/src/usr.bin/netstat/if.c:49: >/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' >undeclared here (not in a function) Already fixed. -- Joanthan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make buildworld broken ... CVS from today ...
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/include/net/if_var.h:78,
from /usr/local/base/src/usr.bin/netstat/if.c:49:
/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:120: `MSIZE' undeclared here
(not in a function)
/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:120: size of array
`MH_databuf' has non-integer type
/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:123: `MSIZE' undeclared here
(not in a function)
/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:123: size of array `M_databuf'
has non-integer type
/usr/obj/usr/local/base/src/i386/usr/include/sys/mbuf.h:239: `MCLBYTES' undeclared
here (not in a function)
*** Error code 1
Stop in /usr/local/base/src/usr.bin/netstat.
*** Error code 1
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ISA Soundcards that work ?
-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 gumption to try -current yet myself (still working off -stable for the practice) - -stable does the same thing, at least with a SB Vibra16, though I haven't noticed any adverse reactions (other than filling the syslog and xconsole (and when I use VT1, that screen). I guess what I am trying to say here (and maybe I'm wrong about this) but it doesn't seem to me to be a huge problem; if it kept my system from working or something, I might be a lot more concerned. (Though knowing how to fix it is kinda nice, too) mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjohf94ACgkQZ7GovTQbIm5ttQCeP/Rv7K2RXhiMWNfCWx1wVr/x Ly8An06UADw0xvjU2ReKzn0DDvIIYszG =xW/t -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Syscons flag to turn off random_harvest in scmouse?
> 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 probably ill advised. That is a _great_ source of entropy. Please explain "ill advised". > Can we have a flag for syscons to turn this off, or do we just turn off > moused and run X with direct access to the mouse? Since it seems you > can do this, there wouldn't seem to be harm in having a flag. Why? The rest of the kernel has not had the Giant mutex properly degraded/removed/unravelled, and this is the real problem. If having the mouse randomness (very approcimately the best randomness available) removed is really what you want, then doing a private patch in your own sources is probably best. Later, when the Giant unravelling progresses, you can remove that. > I still need the random module to use ssh (and I used to have it built > into my kernel, so I could simply unload it). See above. SSH needs good randomness. it is silly to try to break that. > It seems a bit of a shame that if you want to use your sound card that > you give up X, or you give up ssh. If you are function oriented, rather than development oriented, why are you useing CURRENT? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
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 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. > > > > Yes; I"m testing a fix with: > > > > #ifdef _KERNEL > > #include > > #endif /* _KERNEL */ > > #include > > > > My machines are churning through a make world right now.. > > Ick, shouldn't it just be required that one include sys/mbuf.h before > this include file? Probably, but I want to unbreak -current quickly. :-( -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
* 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 sys/mutex.h. > > > > Except that the kernel won't build if sys/mbuf.h isn't included. Oh well. > > Yes; I"m testing a fix with: > > #ifdef _KERNEL > #include > #endif /* _KERNEL */ > #include > > My machines are churning through a make world right now.. Ick, shouldn't it just be required that one include sys/mbuf.h before this include file? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
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 included. Oh well. Yes; I"m testing a fix with: #ifdef _KERNEL #include #endif /* _KERNEL */ #include My machines are churning through a make world right now.. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
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, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "Times are bad. Children no longer obey their parents, and everyone is writing a book." -- Marcus Tullius Cicero To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken: mbuf.h:120: `MSIZE' undeclared here
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/mbuf.h and change machine/mutex.h to sys/mutex.h. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "Times are bad. Children no longer obey their parents, and everyone is writing a book." -- Marcus Tullius Cicero To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lpd panic
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 sure how to proceed. The active processes (for me) are irq7:lpt0, irq7:ppc0, and gs (ghostscript, being driven from my apsfilter installation). What's the right way to access the stacks of these processes, so that I can look at their stack frames, and get some idea if they're interfering with one another? Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: -current on ibm tp a20p?
> 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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Syscons flag to turn off random_harvest in scmouse?
+---[ 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 understand what the problem is. I think that for those people using /dev/sysmouse under X that having random_harvest in scmouse.c is probably ill advised. Those running X without using moused won't be being affected. Can we have a flag for syscons to turn this off, or do we just turn off moused and run X with direct access to the mouse? Since it seems you can do this, there wouldn't seem to be harm in having a flag. I still need the random module to use ssh (and I used to have it built into my kernel, so I could simply unload it). It seems a bit of a shame that if you want to use your sound card that you give up X, or you give up ssh. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New PnP code does not work for me(?)
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: > > > > 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 > unknown indicates that no driver seems to be responsible for this card. > I had a similar problem with an Aztech sound card, which should be MSS > compatible. > > > Logical Device ID: CTL0044 0x44008c0e #0 > > Device Description: Audio > [...] > > You should check your Device IDs with the ones in > /sys/dev/pcm/isa/sb.c > > You should add your IDs at the right place there (it should be easy to > find). > Only use the "Audio" ID (CTL0044) > > Daniel > > > 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
Re: COMMAND_SET ?
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 what it > means. Any takers? > > > Chuck Robey| Interests include C programming, Electronics, > 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. > Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and > (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) > > > > > 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
Re: Demand-loaded network ifs and bpf
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 any device loaded after boot. The specific case for me was, I compiled a kernel with bpf support, but no tun device. Then, after 'kldload'ing if_tun.ko, attempting to run 'tcpdump -i tun0' gave: tcpdump: tun0: Device not configured The tun0 commit that paralells the one you quoted, says: --- ... Remove NBPF conditionality of bpf calls in most of our network drivers. This means that we will not have to have a bpf and a non-bpf version of our driver modules. This does not open any security hole, because the bpf core isn't loadable ... - Maybe I'm just not reading enough into this, but this commit does not seem to address the problem I had. I never had a non-bpf version of the tun module. In any case, the issue is easily resolvable. I will just build a kernel with bpf and no tun0, and see if 'tun0 as kld' works with bpf :-) On Mon, Sep 27, 1999 at 04:53:21PM -0700, John-Mark Gurney wrote: > Donald J . Maddox scribbled this message on Sep 26: > > 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 the case? > > Will bpf work for demand-loaded network klds? > > you should do your own research such are reading the commit logs that > has to deal with it (remeber, you're suppose to be reading them if you > are running -current): > wpaul 1999/09/22 20:32:59 PDT > > Modified files: > sys/pci if_al.c if_ax.c if_dm.c if_mx.c if_pn.c > if_rl.c if_sf.c if_sis.c if_sk.c if_ste.c > if_ti.c if_tl.c if_vr.c if_wb.c if_xl.c > sys/i386/isa if_wi.c > Log: > As suggested by phk, unconditionalize BPF support in these drivers. Since > there are stubs compiled into the kernel if BPF support is not enabled, > there aren't any problems with unresolved symbols. The modules in /modules > are compiled with BPF support enabled anyway, so the most this will do is > bloat GENERIC a little. > > -- > John-Mark GurneyVoice: +1 408 975 9651 > Cu Networking > > "The soul contains in itself the event that shall presently befall it. > The event is only the actualizing of its thought." -- Ralph Waldo Emerson > > > 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
Re: New PnP code does not work for me(?)
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 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 understanding that, with the new PnP code, I should not have to > > specify the ports, IRQs, DMA, etc., right? Here is the config I used: > > It looks like an ID is missing for this card. Try this patch: > > Index: sb.c > === > RCS file: /home/ncvs/src/sys/dev/pcm/isa/sb.c,v > retrieving revision 1.23 > diff -u -r1.23 sb.c > --- sb.c 1999/09/07 08:42:44 1.23 > +++ sb.c 1999/09/27 09:34:04 > @@ -1258,6 +1258,7 @@ > case 0x31008c0e: /* CTL0031 */ > case 0x41008c0e: /* CTL0041 */ > case 0x42008c0e: /* CTL0042 */ > + case 0x44008c0e: /* CTL0044 */ > case 0x45008c0e: /* CTL0045 */ > s = "SB16 PnP"; > break; > > -- > Doug Rabson Mail: [EMAIL PROTECTED] > Nonlinear Systems Ltd.Phone: +44 181 442 9037 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New PnP code does not work for me(?)
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 lists/groups where other people have > been abrupt to the point of rudeness. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New PnP code does not work for me(?)
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 quite often when they are compatable with something > they use that as their logical ID.) Ah, OK... That makes a lot of sense. Thanks for the clear, concise explanation. > > For example, there are a zillion Soundblaster PnP compatables with their own > unique vendor ID but with a CTL ID on the logical device that implements > the sb parts of the card. > > We're not doing this because we enjoy pain and suffering, it's because > it'll be better and more robust in the long run. Unfortunately, there was > no canonical list of logical ID's on the cards we used to recognize. > > So I repeat for the list.. If you've got a card that used to work or does > work under BIOS backwards compat preconfig with 'controller pnp0' disabled, > please send us a dmesg and pnpinfo -v so we can add the ID's. 'controller > pnp0' is quite likely to become non-optional soon so we can use the > motherboard resource lists. 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 and unhelpful responses from Mike Smith specifically NOT solicited) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[dmaddox@conterra.com: Re: New PnP code does not work for me(?)]
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 and unhelpful responses from Mike Smith specifically NOT solicited) > > You get what you have coming to you. In the time it's taken you to > discover that I'm not interesting in holding your hand through the > entire process you could have worked it out for yourself. > > Consider which would have been the better investment. I didn't enter this conversation looking for hand-holding from anybody. I simply reported what seemed like broken functionality to me. Thanks to Peter, I now at least understand why the brokenness is unavoidable in this case. Thanks to you... Well, I don't actually have anything to thank you for, do I?
Re: [dmaddox@conterra.com: Re: New PnP code does not work for me(?)]
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: > > Considering you just redirected what seemed to be a private message > to a public mailing list, I have completely just written you off. > > To say this is bad etiquette would be a gross understatement. I hope > you feel like a complete ass, because you just presented yourself as > one. > > -- > - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - > - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - > > > > > > > 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
Re: Loss of Functionality with newpnp
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 obsoleted. You need > to take the functionality that you want from the old driver and > implement it in the newpcm code. I just reviewed this thread in it's entirety. No one has said, up to this point, that the AWE driver was obsoleted, but rather that it was broken with respect to PnP. It appears that my ability to read remains intact. > > It's amazing that one of the most popular sound cards of all time, one > > that works fine on practically every OS from DOS3.3 to Linux and BeOS, > > is of no concern to FBSD developers :-/ > > Since the AWE64 is already reported to work just fine with the current > generation sound code, this sounds just a little hysterical to me. You > seem to have a slightly more specialised requirement that's not yet > being catered to that does require some more attention. You got a false report, or at least one for a different card than the one I have. Peter just sent me a patch moments ago that should make the newPnP code recognize my card. I assume by 'slightly more specialized requirement', you mean expecting the AWE device to actually work? Well, since that device is, essentially, the raison d'etre for this particular card, that seems to be a reasonable thing to expect. On a more personal note - What *is* your problem, anyway? If you don't have anything useful to contribute to the conversation, why reply at all? Peter answered all my questions, and provided lots of useful information in a single missive. I have yet to get anything from you except surly and wholely unhelpful responses. Please - If you don't have any useful info, try to restrain yourself from the compulsion to reply. Thank you in advance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
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 has no use for user intervention > > ever? My experience indicates that it is not. > > > > It would be very nice if the architects of the new PnP code would add back > > this lost functionality. > My (Q&D) solution for this problem: > > Get rid of > controllerpnp0 > in your config-file. > > Write down the Port/IRQ/DMA of all your PnP cards, then configure them > the > hard way (they normally don't change between reboots). > > This was my solution to get my PnP ISDN card working again (i4b isn't > yet > converted to newPnP). As a side effect I also had to manually configure > my NE2000 compatible PnP card manually. > > Before > --- > controllerpnp0 > deviceed0 > deviceisic0 > -- > ed0: at port 0x220-0x23f irq 3 on isa0 > ed0: address 00:40:05:38:7b:a4, type NE2000 (16 bit) > unknown3: at port 0x108-0x10f irq 11 on isa0 > > After > --- > deviceed0 at isa? port 0x220 irq 3 > deviceisic0 at isa? port 0x108 irq 11 flags 9 > -- > ed0 at port 0x220-0x23f irq 3 on isa0 > ed0: address 00:40:05:38:7b:a4, type NE2000 (16 bit) > isic0 at port 0x108 irq 11 flags 0x9 on isa0 > isic0: Sedlbauer WinSpeed > isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) > (Addr=0x10a) > isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x10b, AddrB=0x10d) > > The ISDN card needed some additional tweaking, since it a PnP only card > and > isn't expected to run as a non-PnP card, but the sound driver should be > just > like the ed driver. > > > Daniel > > > 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
Re: New PnP code does not work for me(?)
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 following patch: > > Index: src/sys/dev/pcm/isa/sb.c > === > RCS file: /home/ncvs/src/sys/dev/pcm/isa/sb.c,v > retrieving revision 1.23 > diff -u -r1.23 sb.c > --- sb.c 1999/09/07 08:42:44 1.23 > +++ sb.c 1999/09/26 20:23:34 > @@ -1258,6 +1309,7 @@ > case 0x31008c0e: /* CTL0031 */ > case 0x41008c0e: /* CTL0041 */ > case 0x42008c0e: /* CTL0042 */ > + case 0x44008c0e: /* CTL0044 */ > case 0x45008c0e: /* CTL0045 */ > s = "SB16 PnP"; > break; > > Cheers, > -Peter > > > > 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
Re: Loss of Functionality with newpnp
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 indiscriminately configure any and all PnP hardware > > > regardless of whether a driver had requested it to. > > > > Why is this not desirable? > > I've already asked you to do your own research, and I meant it. The > simple answer is "if we don't have a [working] driver for it, we don't > want it". 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? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New PnP code does not work for me(?)
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 understanding that, with the new PnP code, I should not have to specify the ports, IRQs, DMA, etc., right? Here is the config I used: machine i386 ident RHIANNON maxusers128 options MAXDSIZ="(256*1024*1024)" options DFLDSIZ="(256*1024*1024)" options INCLUDE_CONFIG_FILE cpu I586_CPU options COMPAT_43 options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options MD5 options DDB options KTRACE options PERFMON options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options INET pseudo-device loop pseudo-device bpf 4 pseudo-device disc2 pseudo-device tun 2 pseudo-device ppp 2 pseudo-device streams options PPP_BSDCOMP options PPP_DEFLATE options PPP_FILTER options MROUTING options FFS #optionsCD9660 options MFS #optionsMSDOSFS #optionsPROCFS options SOFTUPDATES options NSWAPDEV=20 controller scbus0 device da0 device cd0 device pass0 options SCSI_REPORT_GEOMETRY pseudo-device pty 32 pseudo-device speaker pseudo-device gzip #pseudo-device vn pseudo-device snp 3 pseudo-device splash controller isa0 options AUTO_EOI_1 options AUTO_EOI_2 controller pnp0 controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device sc0 at isa? device vga0at isa? port ? conflicts options MAXCONS=32 #optionsSTD8X16FONT options SC_HISTORY_SIZE=1000 options SC_PIXEL_MODE device npx0at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13 controller wdc0at isa? port IO_WD1 irq 14 flags 0xb0ffb0ff diskwd0 at wdc0 drive 0 diskwd1 at wdc0 drive 1 controller fdc0at isa? port IO_FD1 irq 6 drq 2 diskfd0 at fdc0 drive 0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device sio2at isa? port IO_COM3 flags 0x2000 irq 12 #device sio2at isa? port IO_COM3 flags 0x2 irq 12 device sio3at isa? port IO_COM4 irq 9 #controller snd0 #device sb0 at isa? port 0x220 irq 5 drq 1 #device sbxvi0 at isa? drq 5 #device sbmidi0 at isa? port 0x330 #device awe0at isa? port 0x620 #device opl0at isa? port 0x388 device pcm0#at isa? port ? irq 5 drq 1 flags 0x15 #device pca0at isa? port IO_TIMER1 #device joy0at isa? port 0x200 options AHC_ALLOW_MEMIO controller pci0 controller ahc0 #optionsEXT2FS options SHOW_BUSYBUFS options SHMALL=1025 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMMAXPGS=1025 options SHMMIN=2 options SHMMNI=33 options SHMSEG=9 options MSGBUF_SIZE=40960 #optionsVESA options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L And here is the pnpinfo output: Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID CTL009e (0x9e008c0e), Serial Number 0x09f665ec PnP Version 1.0, Vendor Version 32 Device Description: Creative SB AWE64 Gold Logical Device ID: CTL0044 0x44008c0e #0 Device Description: Audio TAG Start DF Good Configuration IRQ: 5 - only one type (true/edge) DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x220, alignment 0x1, len 0x10 [16-bit addr] I/O Range 0x330 .. 0x330, alignment 0x1, len 0x2 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 5 7 9 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 6 7 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 5 7 9 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA
Re: Loss of Functionality with newpnp
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 have already explained to you that the AWE64 driver that you were > using (one actually of _three_ that we have) only worked with PnP cards > as an accidental side-effect of the old PnP code. Now that the PnP > code has been fixed, the brokenness of the old driver is exposed. Can you give me a few hints on what would be necessary to get the old driver to work with the new PnP? I confess ignorance of both PnP and soundcard programming, but I am willing to try to fix it if fixing it is within my means. It's amazing that one of the most popular sound cards of all time, one that works fine on practically every OS from DOS3.3 to Linux and BeOS, is of no concern to FBSD developers :-/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
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 driver had requested it to. > Why is this not desirable? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Demand-loaded network ifs and bpf
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 the case? Will bpf work for demand-loaded network klds? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
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, 1999 at 01:42:09PM -0400, Gary Palmer wrote: > "Donald J . Maddox" wrote in message ID > <[EMAIL PROTECTED]>: > > Ummm... I'm not screaming anything, Gary. The intent of my message is > > just to let the authors of this code know that it is *not* equal in > > functionality to what was removed. As I said in my original message, it > > would be nice to see that functionality restored. > > And how much time/resources are you willing to dedicate to restoration > of functionality *YOU* need? > > > It may very well be that the authors are aware of this, and just don't > > give a damn. I prefer to give them the benefit of the doubt. > > They probably give a damn, but it goes a long way if you HELP them > rather than go around demanding stuff be put back. > > > 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
Re: Loss of Functionality with newpnp
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 unconditionally and then > > provide no replacement at all... > > If people lose functionality, then it motivates them to help the > author replace the functionality that is important to them, and for > devices that the author probably has no access to > > We're a volunteer project Donald, and screaming blue murder 'cos your > card doesn't work as well as it used to gets us nowhere. Have > you contacted the newpcm author and asked if you can help to get AWE64 > support back? Thats probably the best way to proceed. Ummm... I'm not screaming anything, Gary. The intent of my message is just to let the authors of this code know that it is *not* equal in functionality to what was removed. As I said in my original message, it would be nice to see that functionality restored. It may very well be that the authors are aware of this, and just don't give a damn. I prefer to give them the benefit of the doubt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
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 > > that the authors in question _do_ want such feedback. > > Actually, in your case, no. The "functionality" you're claiming was > lost was actually an unintentional side-effect of the code which will > intentionally not be emulated. I'm not sure I follow you here. My card was recognized and configured properly by the old PnP code. It is not recognized and configured properly by the new PnP code. How can that be classified as simply 'an unintentional side-effect of the code'? It seems to me that PnP functionality should not be dependant on any particular driver... I mean, the PnP code and the audio code (and the network driver code, and any other possible PnP device driver code) are seperate things, no? Shouldn't it be the job of the PnP code to recognize and configure the device so that it probes and attaches, regardless of what driver finds it? At least, it appears to me that that is what the old PnP code did. My card worked just fine with it, regardless of whether I selected 'pcm' or 'snd' in my kernel config. > > You are encouraged to participate in the ongoing development of our new > sourd drivers in order to ensure they meet the functionality of the old > ones, since that _is_ lost functionality that we care about. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loss of Functionality with newpnp
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 particular audio driver. Obviously, the newpnp code is not as versatile as the oldpnp code was, because the oldpnp code worked with my card regardless of whether I used snd or pcm. 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 unconditionally and then provide no replacement at all... On Sun, Sep 26, 1999 at 12:58:58PM +0200, Ollivier Robert wrote: > > Can you try to new newpcm ? > > controller pnp0 > device pcm0 > > > The first 2 lines have always been unnecessary, but harmless; however, the > > 3rd line is _absolutely necessary_ to get the AWE to probe. > > The above works for my AWE64. > > pcm0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 > unknown0: at port 0x200-0x207 on isa0 > unknown1: at port 0x620-0x623 on isa0 > > FreeBSD Audio Driver (newpcm) Sep 9 1999 00:19:32 > Installed devices: > pcm0: at io 0x220 irq 5 drq 1:5 (1/1 channels duplex) > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] > FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 > > > > 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
Loss of Functionality with newpnp
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 my understanding, it simply fails like this: 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 If I configure it the old way: controller pnp0 controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device awe0at isa? port 0x620 device opl0at isa? port 0x388 device joy0at isa? port 0x200 I get the same failures as above from the PnP code, but the card still works (mostly) because it has already been configured by the PnP BIOS. The SB16-compatible portion of the card works OK even if I take PnP support out of the kernel completely, and always has. Unfortunately, the AWE device *needs* a little more initialization than it gets from the BIOS to probe correctly. With the old PnP code, I used a userconfig-script, like this: pnp 1 0 os enable port0 0x220 irq0 5 drq0 1 drq1 5 port1 0x330 port2 0x388 pnp 1 1 os enable port0 0x200 pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 The first 2 lines have always been unnecessary, but harmless; however, the 3rd line is _absolutely necessary_ to get the AWE to probe. As far as I can tell, there is no way to duplicate this functionality with the new PnP code. Is the new PnP code really so smart that it has no use for user intervention ever? My experience indicates that it is not. It would be very nice if the architects of the new PnP code would add back this lost functionality. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Interesting new warnings in boot msgs from -current kernel
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: Sun Jul 4 00:13:56 EDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/RHIANNON Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 166194077 Hz CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 67108864 (65536K bytes) config> pnp 1 0 os enable port0 0x220 irq0 5 drq0 1 drq1 5 port1 0x330 port2 0x388 config> pnp 1 1 os enable port0 0x201 config> pnp 1 2 os enable port0 0x620 port1 0xa20 port2 0xe20 avail memory = 61652992 (60208K bytes) Preloaded elf kernel "kernel" at 0xc02fb000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc02fb09c. Preloaded elf module "vesa.ko" at 0xc02fb0ec. Preloaded elf module "cd9660.ko" at 0xc02fb188. Preloaded elf module "msdos.ko" at 0xc02fb228. Preloaded elf module "procfs.ko" at 0xc02fb2c8. Preloaded elf module "linux.ko" at 0xc02fb368. Intel Pentium detected, installing workaround for F00F bug VESA: v3.0, 16320k memory, flags:0x1, mode table:0xc02c8102 (122) VESA: STB Systems, Inc WARNING: "streams" is usurping "streams"'s cdevsw[] ^^^ Probing for PnP devices: CSN 1 Vendor ID: CTL009e [0x9e008c0e] Serial 0x09f665ec Comp ID: PNPb02f [0x2fb0d041] npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 isab0: at device 7.0 on pci0 ide_pci0: at device 7.1 on pci0 ahc0: irq 10 at device 10.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: irq 11 at device 12.0 on pci0 isa0: on motherboard atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 sc0: on isa0 sc0: VGA <32 virtual consoles, flags=0x200> vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa0 wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-32 wd0: 1277MB (2616240 sectors), 648 cyls, 64 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , LBA, DMA, 32-bit, multi-block-16 wd1: 5009MB (10259160 sectors), 638 cyls, 255 heads, 63 S/T, 512 B/S fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2 at port 0x3e8-0x3ef irq 12 flags 0x2002 on isa0 sio2: type ST16650A sio3 at port 0x2e8-0x2ef irq 9 on isa0 sio3: type 16550A sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: sbxvi0 at port 0x drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ sbmidi0 at port 0x330 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ awe0 at port 0x620 on isa0 awe0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ opl0 at port 0x388 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ pca0 at port 0x40 on isa0 pca0: PC speaker audio driver joy0 at port 0x201 on isa0 joy0: joystick ds0 XXX: driver didn't set ifq_maxlen da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: 507MB (1039329 512 byte sectors: 64H 32S/T 507C) changing root device to wd1s1a cd0 at ahc0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present ?!?! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot -c not saving changes
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 /boot/loader.conf > > and edit it to match what you want to happen at boot. > > Copying is dangerous. If you do not remove the loader_conf_files > line, it will enter an infinite recursion. Interestingly enough, I copied /boot/defaults/loader.conf to /boot/loader.conf, edited it, and rebooted (not removing the loader_conf_files line) and it boots just fine, with no recursion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
AWE broken by recent commits to i386/isa/sound files?
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 exactly which files were changed... Is it possible that these changes broke AWE support? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: boot -c not saving changes
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 type at the config> prompt when you Boot: -c. 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 /boot/loader.conf and edit it to match what you want to happen at boot. On Sun, Mar 14, 1999 at 03:51:24PM +, Donn Miller wrote: > When I boot up my -current box, I hit 'c' to get to the boot prompt. Then > I do "boot -c", and then "vi" to configure my kernel. But any changes I > make via userconfig aren't saved for when the next time I boot. > > Is it a problem with the boot loader, or do I have to type some commands > to save my config in /boot.config? I have a zero-length /boot.config > right now. I would think this involves invoking load -t /boot.config at > the boot prompt to load /boot.config the next time I boot, but I don't > know the exact sequence. > > Thanks > . > > Donn > > > > 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
Have anyone run rtc.ko module on FreeBSD-current?
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 rtc-2000.09.22.tgz. rtc-2000.09.22.tgz runs well on my FreeBSD 4.1, but when I update my system to FreeBSD-current, it complains that! ¡Iì¹» ®&Þ±éݨ¥¶Ý¢jçH:+éì¹» ®&Þ~·nÇ\ººÞا¶¡Ü¨~Ø^ë,j
ISA Soundcards that work ?
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) ES968 (ok I was getting desperate) The PNP init for the Opti and the ES1869 seems to be picking up the wrong DMA channels. This never used to happen, it's only started happening in the last month or 6 weeks. I upgrade my -current box every week, and this is still happening with a current less than 24 hours old (with all cards). This is a UP build on a UP machine. Does anyone know how to get any of these functioning correctly? pcm0: at port 0x534-0x537,0x380-0x38b,0x220-0x22f,0xe0c-0xe0f irq 5 drq 0,1 on isa0 the DMA channels reported at boot are 3 and 6 pnpinfo gives this: Checking for Plug-n-Play devices... Card assigned CSN #1 Vendor ID OPT0931 (0x3109143e), Serial Number 0x PnP Version 1.0, Vendor Version 0 Device Description: OPTi Audio 16 Logical Device ID: OPT 0x143e #0 Vendor register funcs 00 Device Description: AUX0 Logical Device ID: OPT9310 0x1093143e #1 Vendor register funcs 00 Device Description: OPTi Audio 16 TAG Start DF I/O Range 0x534 .. 0x608, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 5 6 8/16-bit, not a bus master, count by byte, count by word, Type F TAG Start DF I/O Range 0x534 .. 0xff0, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 5 6 8/16-bit, not a bus master, count by byte, count by word, Type F DMA: channel(s) 0 1 3 5 6 8/16-bit, not a bus master, count by byte, count by word, Type F TAG Start DF I/O Range 0x534 .. 0x608, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG Start DF I/O Range 0x534 .. 0xff0, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG Start DF I/O Range 0x534 .. 0xff0, alignment 0x4, len 0x4 [16-bit addr] I/O Range 0x380 .. 0x3f0, alignment 0x10, len 0xc [16-bit addr] I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0xe0c .. 0xffc, alignment 0x4, len 0x4 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Type F TAG End DF Logical Device ID: OPT0001 0x0100143e #2 Vendor register funcs 00 Device Description: Game Port I/O Range 0x200 .. 0x20f, alignment 0x1, len 0x1 [16-bit addr] Logical Device ID: OPT0002 0x0200143e #3 Vendor register funcs 00 Device Description: MPU401 I/O Range 0x300 .. 0x360, alignment 0x10, len 0x2 [16-bit addr] IRQ: 5 7 9 10 11 - only one type (true/edge) End Tag Successfully got 53 resources, 4 logical fdevs -- card select # 0x0001 CSN OPT0931 (0x3109143e), Serial Number 0x Logical device #0 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #1 IO: 0x0380 0x0380 0x0380 0x0380 0x0380 0x0380 0x0380 0x0380 IRQ 5 0 DMA 0 1 IO range check 0x00 activate 0x01 Logical device #2 IO: 0x 0x 0x 0x 0x 0x 0x 0x IRQ 0 0 DMA 4 4 IO range check 0x00 activate
