Re: HEADS UP: Strange booting lockups
On Sun, Jan 21, 2001 at 03:29:22PM -0800, Kris Kennaway wrote: On Sun, Jan 21, 2001 at 06:05:20AM -0500, Donald J . Maddox wrote: It may have absolutely nothing to do with either of these cases, but I found out the hard way recently that booting with no device.hints in /boot will exhibit symptoms that appear identical to this. Is it possible that something is trashing the device list, or not initializing it properly at kernel load time? This is a different problem. If you don't have device hints available at boot (statically compiled into the kernel or loaded from /boot) then the console driver doesn't get its hints, and doesn't work in the manner you describe. Yeah, I know what my problem was... I was just suggesting that if something trashed the area of memory where these hints live at boot time, it could possibly cause the problem being described. That wasn't the problem, but hey, I was trying to help :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes This may be controversial, but it has always worked for me, and although it's not supposed to (in my understanding), the build (I think both world and kernel) does use installed headers. If you don't think so, mv /usr/include and then try to build either. 2) cd usr.sbin/config; make obj make depend make make install 3) config and build kernel 4) make buildworld 5) install kernel 6) make installworld 7) update /etc if necessary 8) reboot Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld 5) reboot cycle instead, since I have been assured that this is the canonical way of doing things now. It appears that these pronouncements were premature at best. On Sun, Jan 21, 2001 at 11:12:44PM -0800, John Baldwin wrote: Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 - 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I just do it the old fashioned way, and with the exception of the 2.9 - 2.10 binutils upgrade, it always works. buildkernel overloads the KERNEL variable and thus violates POLA, so it needs fixing regardless, but I don't see a reason to encourage its use unless it is actually needed. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lastest kernel from cvs ( sh exists with signal 8 )
On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote: On 22-Jan-01 Donald J . Maddox wrote: 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I used to do 'make -DCLOBBER includes' to make sure no old stuff survived, but somebody decided that was just too convenient, I guess. No CLOBBER in the Makefiles anymore... SNIP This should work, except that buildkernel has a few problems: 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting meanings. Simply using KERNCONF for the buildkernel case instead can fix this, however. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ I think this is a good policy :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. On Fri, Jan 19, 2001 at 11:42:32PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Sean Kelly writes: : I did not have this behavior in -STABLE, but now I do since I upgraded : to -CURRENT. -current's interrupt latency is horrible these days, which seems to manifest itself in problem with the sound driver. I have a -current laptop and get all kinds of artifacts on it. I have a laptop that is running -stable and has 1/3 the power of the -current laptop and plays w/o a hitch. Warner 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: pcm status
If it helps at all, it's marginal. I still get skips. On Sat, Jan 20, 2001 at 05:36:08PM +0200, Mark Murray wrote: This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. Please tell me if sysctl -w kern.random.yarrow.bins=2 makes a difference for you. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn 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
ACPI says: too many dependant configs(?)
Last night I installed a kernel with 'device acpica' for the 1st time, and all seems fine, except that I see this at boot: . . . npx0: math processor on motherboard npx0: INT 16 interface too many dependant configs too many dependant configs too many dependant configs too many dependant configs atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 . . . I traced this message to /usr/src/sys/dev/acpica/acpi_isa.c, function acpi_isa_set_start_dependant(). Now, I have not had any indication of errors during ISA bus enumeration before, so why should I get this from the ACPI isa bus enumeration? Doesn't seem to hurt anything, but I'm curious (and ACPI-ignorant) :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI says: too many dependant configs(?)
Ok, thanks for the info... But this begs the question: Why does the code limit maxdeps to 8? On Sun, Dec 24, 2000 at 11:50:13AM -0800, Mike Smith wrote: Last night I installed a kernel with 'device acpica' for the 1st time, and all seems fine, except that I see this at boot: ... too many dependant configs ... I traced this message to /usr/src/sys/dev/acpica/acpi_isa.c, function acpi_isa_set_start_dependant(). Now, I have not had any indication of errors during ISA bus enumeration before, so why should I get this from the ACPI isa bus enumeration? It just means that you have a device with more configuration options than our code can deal with; we just ignore the extra options. Doesn't seem to hurt anything, but I'm curious (and ACPI-ignorant) :) This part is just like BIOS PnP. The warning indicates that we're losing possibly-useful information, but if things are still working, all is well. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E 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: Is compatibility for old aout binaries broken?
Looks like you got a lot farther than I did with it... Are you sure you don't have an old aout ld.so on that machine? Here's what I get: dmaddox SimCity Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 dmaddox BTW - That 'commerce' directory has more old aout binaries in it I bet... Also, it looks to me like SimCity would probably run just fine for you if you started X on an 8-bit display... On Wed, Dec 20, 2000 at 12:51:06AM -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... Does anyone have any old a.out binaries other than SimCity that they have problems with? I've installed the SimCity package, compat20 and compat21 dists, but cannot get it to run: Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes Adding a player on dragon:0.0 ... Display Visual = truecolor Display Depth = 24 SimCity can't find an 8 bit color or 1 bit monochrome display on "dragon:0.0". SimCity: error in TCL code: bad window path name ".head0" -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Actually, the aout libs I am using when I get the ___error undefined are the ones from the XFree86-3.3.6 distribution, compiled for FreeBSD 3.x. Originally I was using the aout X libs I built myself when building the XFree86-3.3.6 port. Using those, I still got an undefined symbol, but it wasn't ___error, and I don't remember exactly what it was, just that it started with 3 underscores too. On Wed, Dec 20, 2000 at 01:42:59AM -0800, David O'Brien wrote: src/lib/libc/sys/__error.c suggests this was the case for 2.2.7+. What is out of sync is the X11 a.out libs. They are probably built on a 2.2.7 or 2.2.8 box, thus they refer to `___error' vs. `errno'. These libs are wrong for the SimCity binary. They are a.out yes, but not proper for compat20 use. Since SimCity needs `libgcc.so.261', I'll assume it was built that long ago. The problem isn't as much ld.so, as it should match the libc.so, et.al. you are using from the compat2[01] dist (needed to satisfy ``ldd lib/SimCity/res/sim''). And `ld.so' and the shared libs would be consistent on the system the a.out program was built on. What I would feel most comfortable with, is doing a MFC to RELENG_2_2 of the rtld-aout changes since then, building a new `ld.so' and putting that in the compat2? dists. Problem is I don't have access to a 2.2-STABLE box. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. Are you sure? src/lib/compat/compat2[012]/ld.so.gz.uu are all at rev 1.1. So there has been no change to them over the lifetime of their existence. All three are identical -- having the same MD5 checksum. Well, looking at the release tags compat22/ld.so was in 3.2. compat2[01]/ld.so was added for 3.3. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Not quite. I seem to remember that JKH was makeing a tarball of a.out libs from what ever was on his box at the time (thus probably the last a.out ld.so just before E-day on 3-CURRENT). When I committed the compat2? bits, I took ld.so from a 2.2.x release as this is the compat2? dist, not compat3.aout dist. Which is what you're suggesting should have been done. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX 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: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 01:52:23AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 03:57:07AM -0500, Donald J . Maddox wrote: Looks like you got a lot farther than I did with it... Are you sure you don't have an old aout ld.so on that machine? Nope. This is a box that was a virgin install of 5-CURRENT a month ago. I had to install the compat20 and compat21 dists, along with doing a ``pkg_add -r XFree86-aoutlibs''. The Tk is 8.0.5. Here's what I get: dmaddox SimCity Starting SimCity ... SimCity Classic - UNIX / Tcl Tk Toolkit version 3.6b - Mattes /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 Actually you're probably getting farther than I am. I believe I'm bombing so early in starting Tk, I'm not really getting to the point you are. What does `ldd /usr/local/lib/SimCity/res/sim'' report? res ldd sim sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) res Also, it looks to me like SimCity would probably run just fine for you if you started X on an 8-bit display... Maybe, but I'm not going to dink with my X server config. ;-) Mabye I'll try to find another box to try this on. Heh :) You don't have to dink around with your config... Just do 'startx -- -bpp 8'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 02:24:26AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 05:09:45AM -0500, Donald J . Maddox wrote: res ldd sim sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) res Looks good. Can you install the XFree896-aoutlib port? You may have seen were someone posted the a.out libs from 3.3.6 are known to not be the the best to use for compatibility use. Ok, I'll try that now... Heh :) You don't have to dink around with your config... Just do 'startx -- -bpp 8'. You assume I'm using an XFree86 server ;-) -- I am not. How can you be using the same X libs as me, and not be using XFree86? And if you're not, doesn't that put a crimp in your testing? ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Interesting. After I installed the XFree86-aoutlibs port, SimCity works fine for me (on an 8-bit display)... It didn't work with the X libs built by the port when aout libs are requested, and it didn't work with the X libs from 3.3.6, but it works with these. Looks good. Can you install the XFree896-aoutlib port? You may have seen were someone posted the a.out libs from 3.3.6 are known to not be the the best to use for compatibility use. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 10:14:09AM -0800, David O'Brien wrote: On Wed, Dec 20, 2000 at 11:15:55PM +1000, Stephen McKay wrote: Correcting slightly for your slightly off assumption: The X11 libs were probably built on a 3.x box. Their problem is that being newer than libc.so.2.2 (or was it libc.so.3.0) they use ___error but libc does not supply it. My patches to rtld-aout (that first appeared in FreeBSD 3.0) supply ___error in this case. This is the only full fix for this situation. Why is not changing the XFree86-aoutlibs port to offer libs built on 2.2.x not the right fix? I was under the impression that this was already the case... The libs in the XFree86-aoutlibs port ARE from 2.2.x. My problem was that I was using libs built on 3.x. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Wed, Dec 20, 2000 at 10:43:39AM -0800, David O'Brien wrote:
On Wed, Dec 20, 2000 at 05:28:45AM -0500, Donald J . Maddox wrote:
How can you be using the same X libs as me, and not be using
XFree86?
XFree86 has many components to it -- binaries (such as Xterm), libs (such
as libX11.{so,a}, and X servers. I use all the XFree86 bits except for
the X server. I use a mix of Metrolink's and Xi Graphics servers.
I see. I was thinking that the Xserver would need to use the installed
X libs, but I see that is not the case, even with XF86:
dmaddox ldd /usr/X11R6/bin/XF86_SVGA
/usr/X11R6/bin/XF86_SVGA:
libxpg4.so.3 = /usr/lib/libxpg4.so.3 (0x2830b000)
libz.so.2 = /usr/lib/libz.so.2 (0x2830d000)
libm.so.2 = /usr/lib/libm.so.2 (0x2831a000)
libc.so.5 = /usr/lib/libc.so.5 (0x28336000)
dmaddox
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Interesting new messages in logs
After my latest update, I am getting LOTS of the following in my logs: Dec 19 12:21:04 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1286 Dec 19 12:24:08 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1299 Dec 19 12:27:13 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1308 Dec 19 12:39:28 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1336 Obviously, this machine is using log_in_vain, and it appears obvious that these are local smtp transactions. It is _not_ obvious, at least to me, why they are now being logged as if port 25 was not open. Also, why the odd format in the addresses? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting new messages in logs
On Tue, Dec 19, 2000 at 07:33:49PM +0100, Szilveszter Adam wrote: On Tue, Dec 19, 2000 at 01:20:57PM -0500, Donald J . Maddox wrote: After my latest update, I am getting LOTS of the following in my logs: Dec 19 12:21:04 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1286 Dec 19 12:24:08 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1299 Dec 19 12:27:13 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1308 Dec 19 12:39:28 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1336 Obviously, this machine is using log_in_vain, and it appears obvious that these are local smtp transactions. It is _not_ obvious, at least to me, why they are now being logged as if port 25 was not open. Also, why the odd format in the addresses? Key might be: IPv6.:-) (At least for the addresses.) Check your configuration if you are listening on port 25 for IPv6 or not... That's off the top of my head though so yell at me if I am talking nonsense:-) Nope, no nonsense, you're right on the money :) In the previous kernel I didn't have IPV6 enabled, and in this one it is enabled. Thanks for helping clear this up for me :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting new messages in logs
You're right that the answer to my question was IPV6 (I didn't have it compiled into the previous kernel). You're wrong that a port need not be open to receive connections. You will note in the log excerpt below that these are connection *attempts*, not actual connections. On Tue, Dec 19, 2000 at 01:51:04PM -0500, Hasan Azam Diwan wrote: To answer your first question, a port need not be open in order to receive connections. To answer your second, these appear to be IPv4 addresses encapsulated as IPv6 addresses. Dec 19 12:21:04 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1286 Dec 19 12:24:08 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1299 Dec 19 12:27:13 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1308 Dec 19 12:39:28 cae88-102-101 /boot/kernel/kernel: Connection attempt to TCP ::0001:25 from ::0001:1336 Obviously, this machine is using log_in_vain, and it appears obvious that these are local smtp transactions. It is _not_ obvious, at least to me, why they are now being logged as if port 25 was not open. Also, why the odd format in the addresses? 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: Interesting new messages in logs
On Tue, Dec 19, 2000 at 09:56:36PM +0100, Ollivier Robert wrote: According to Donald J . Maddox: open. Also, why the odd format in the addresses? Looks like some kind of IPv6 address... You're right. I compiled the new kernel with IPV6 enabled. I didn't have IPV6 in my previous kernel... Thanks :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No cable modems??
Sorry to post this to -current, but (as should be obvious from the below) it's the only way I can get Ollivier to see it :( Why are you (or your ISP) refusing to accept mail from people with cable modems? Enquiring minds want to know... ;-) The original message was received at Tue, 19 Dec 2000 18:19:21 -0500 (EST) from dmaddox@localhost - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 no cable modems here) - Transcript of session follows - ... while talking to frmug.org.: MAIL From:[EMAIL PROTECTED] 550 no cable modems here 554 5.0.0 [EMAIL PROTECTED] Service unavailable Reporting-MTA: dns; cae88-102-101.sc.rr.com Arrival-Date: Tue, 19 Dec 2000 18:19:21 -0500 (EST) Final-Recipient: RFC822; [EMAIL PROTECTED] Action: failed Status: 5.0.0 Diagnostic-Code: SMTP; 550 no cable modems here Last-Attempt-Date: Tue, 19 Dec 2000 18:19:38 -0500 (EST) On Tue, Dec 19, 2000 at 09:56:36PM +0100, Ollivier Robert wrote: According to Donald J . Maddox: open. Also, why the odd format in the addresses? Looks like some kind of IPv6 address... You're right. I compiled the new kernel with IPV6 enabled. I didn't have IPV6 in my previous kernel... Thanks :)
Re: No cable modems??
I apologized in advance, and I do again, but I have no way of knowing if Ollivier is subscribed to -chat. Thanks for understanding. Further discssion has been moved to chat. On Wed, Dec 20, 2000 at 08:19:34AM +0200, Mark Murray wrote: This is offtopic! If you need to discuss it, please take it to -chat. OFFTOPIC Sorry to post this to -current, but (as should be obvious from the below) it's the only way I can get Ollivier to see it :( Why are you (or your ISP) refusing to accept mail from people with cable modems? Enquiring minds want to know... ;-) : - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 no cable modems here) Many ISP's consider cable modem pools and DSL pools as the same sort of "animal" as dialup users. Very many ISPs will refuse to receive mail from all three of those user-classes, because of the "direct-to-MX" spam issue. The solution is to use your ISP's SMTP "smarthost" for your mail. See http://mail-abuse.org/dul/ /OFFTOPIC M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
You don't need a CDROM... You can get it from: ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/commerce/games/SimCity/SimCity-3.6b.tgz On Mon, Dec 18, 2000 at 10:03:15AM -0800, David O'Brien wrote: On Tue, Dec 19, 2000 at 01:00:28AM +1000, Stephen McKay wrote: So we could in principle build ld.so for every release. I would say "no". The building of a.out bits is getting harder as more and more framework pieces are removed. I don't quite fully understand the problem yet. Do you have a binary that shows the problem other than SimCity from a 3.x release CDROM? I don't have any 3.x CDROMs any more, so I'd have to wait a while until I can find one at the office. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
Ok, thanks for a very enlightening explanation :) Under the circumstances, it seems silly to have aout conpat bits installed at all, seeing as how they cannot work. Like you, I normally upgrade from source -- This box has been -current ever since 2.0.5 or so was -current, but I had to reinstall from scratch a while back by installing 4.2-RELEASE and then cvsupping back to -current, so I guess I lost my working aout ld.so in the process. Bummer :( On Mon, Dec 18, 2000 at 02:58:16AM +1000, Stephen McKay wrote: On Saturday, 16th December 2000, "Donald J . Maddox" wrote: The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... You and I may be the only people in the world that run old binaries. This has been broken for new users for some time. :-( Those of us upgrading from source have been immune to this problem, because we retain the old a.out ld.so binary. /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib /aout/libX11.so.6.1 at 0x20160644 When errno became a function that returns a pointer (previously it was a simple integer variable), recompiled libraries became incompatable with old binaries. So, I hacked the a.out loader (ld.so). The fix was in 3.0. Well, Nate called it a horrible hack, so maybe I should say "the hack was in 3.0". Am I overlooking something obvious here, or is something actually broken with respect to running old aout binaries? I found that rtld-aout won't compile. That's kinda broken. (It's probably something simple. Looks like the a.out version of a pic library just isn't around any more). I'll try harder later. What's certain is that it isn't compiled by default. I poked about with my old FreeBSD CD collection and found that version 3.0 through 3.2 have a fully functioning (fully hack enabled) ld.so, but an older binary has been substituted in 3.3 and onward, including 4.0 and 4.1, and most likely 4.2 also. I can only guess that some anonymous release engineer (nobody we know :-) picked the wrong CD at some point to get the master copy of ld.so once it stopped compiling. (Or at least stopped being easily compiled.) Ideally, rtld-aout would be compiled fresh for every release. Until then, you can repair your system by retrieving ld.so from a 3.3 CD (in the compat22 section), or from a 3.2 live filesystem CD. Stephen. 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: Is compatibility for old aout binaries broken?
Well, if you do manage to uncover the lost magic, please let me know :) On Mon, Dec 18, 2000 at 04:41:17PM +1000, Stephen McKay wrote: I expected some build tool expert to say "Just compile with these options". But they haven't. So I'll see if the bits have rotted, or whether we can keep building ld.so instead of just including an age old binary. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Is compatibility for old aout binaries broken?
The other day, on a whim, I decided to try running an old binary of SimCity (the same one found in the 'commerce' directory on many FBSD cds), and it failed in a odd way... /usr/libexec/ld.so: Undefined symbol "___error" called from sim:/usr/X11R6/lib/aout/libX11.so.6.1 at 0x20160644 # ldd sim ./sim: -lXext.6 = /usr/X11R6/lib/aout/libXext.so.6.3 (0x200c5000) -lX11.6 = /usr/X11R6/lib/aout/libX11.so.6.1 (0x200cf000) -lc.2 = /usr/lib/compat/aout/libc.so.2.2 (0x20166000) -lm.2 = /usr/lib/compat/aout/libm.so.2.0 (0x201cb000) -lgcc.261 = /usr/lib/compat/aout/libgcc.so.261.0 (0x201e5000) So, all the necessary compatibility libraries are there, but it fails anyway. I tried 'nm | grep error' on the sim binary and libX11.so.6.1 and didn't find any symbol, undefined or otherwise, by that name... Am I overlooking something obvious here, or is something actually broken with respect to running old aout binaries? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem With Man Formatting
I don't think so... I am -current as of yesterday and my manpages are displaying just fine, headers and all. On Fri, Dec 08, 2000 at 06:05:01PM -0500, Brandon D. Valentine wrote: On Fri, 8 Dec 2000, Thomas D. Dean wrote: Since a 12/6 cvsup and 'make world', I notice a problem with the output of man. The output consists of one block of justified text. The headers, etc., are missing. Could this be a result of the recent groff upgrade? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [jhb@FreeBSD.org: RE: Panic in -current]
Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_saver module is obviously using a VESA mode, but I had no problem problem with it... On Mon, Dec 04, 2000 at 06:41:55PM -0800, John Baldwin wrote: On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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: [jhb@FreeBSD.org: RE: Panic in -current]
Sorry, I guess I should specify that this is a desktop with APM enabled in the BIOS, but not being used otherwise... VESA module loaded. #uname -a FreeBSD cae88-102-101.sc.rr.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Dec 2 16:07:54 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/RHIANNON i386 #kldstat Id Refs AddressSize Name 19 0xc010 234878 kernel 21 0xc0335000 5540 vesa.ko 31 0xc033b000 9eb4 cd9660.ko 41 0xc0345000 eb44 msdos.ko 51 0xc0354000 7a98 procfs.ko 61 0xc035c000 158eclinux.ko 71 0xc0372000 b2cc if_dc.ko 82 0xc037e000 10004miibus.ko 91 0xc038f000 76e0 linprocfs.ko On Mon, Dec 04, 2000 at 09:59:31PM -0500, Donald J . Maddox wrote: Just as a data point, I just tried this as well... The daemon saver was ok, the fire saver was ok, but as soon as I loaded logo_saver and it activated, I got a 'dc0 timeout'(?) and I was unable to access any of the vtys after that... I could switch vtys, but could not type anything. The fire_saver module is obviously using a VESA mode, but I had no problem problem with it... On Mon, Dec 04, 2000 at 06:41:55PM -0800, John Baldwin wrote: On 05-Dec-00 Andrea Campi wrote: More details: this is an IBM Thinkpad laptop with APM enabled and in the kernel. As usual, any hint is more than welcome. This used to work... Which screen saver? Does it do it with all of them? Just graphical ones, just text ones, just green_saver, etc.? Rrrright... I can assure you I would never have thought this could make a difference... That's ok, it didn't occur to me either at first. However, the green_saver calls into APM, and the graphical ones will call into VESA, so it might make a difference. Ok, I will try each one. At the moment, I'm using logo_saver. I will let you know. Bye, Andrea -- Weird enough for government work. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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
3dfx.ko
The standard way of loading a particular module at boot from /boot/loader.conf is 'modulename_load="YES"', right? This doesn't seem to be possible with the 3dfx module, however... Since it's name starts with a number, it causes a syntax error. Being FORTH-impaired, I have no idea how to work around this... Anybody know how to make this work? Also, it doesn't seem to be possible to compile 'device tdfx' statically into the kernel either, since it depends on symbols that only exist in the kernel when compat_linux is defined, and COMPAT_LINUX is no longer an option, is it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3dfx.ko
I actually thought that COMPAT_LINUX had been completely removed, just causing opt_dontuse.h to be generated. I see now that it doesn't even warn about this being a deprecated option. *Is* it still considered a deprecated option? I'm sure config used to warn about COMPAT_LINUX being deprecated a while back... On Tue, Nov 28, 2000 at 06:22:33PM -0500, Marcel Moolenaar wrote: "Donald J . Maddox" wrote: Also, it doesn't seem to be possible to compile 'device tdfx' statically into the kernel either, since it depends on symbols that only exist in the kernel when compat_linux is defined, and COMPAT_LINUX is no longer an option, is it? COMPAT_LINUX is still supported. It's broken on the Alpha though. If it's broken on i386 as well, let me know. I'm not aware of any brokeness at this time. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Other Linux stuff...
Huh... I was sure it did... Oh, well, guess my memory ain't what it used to be :-/ But... Since you are the Linux Guru, and it seems I momentarily have your attention, let me ask you about another Linux emulation matter. :) The Linux 'ldd' program is, as I'm sure you know, just a shell script that tries to directly execute 'ld-linux.so.2' on the filename passed in argv to the script. This doesn't work with our Linux emulation. Apparently, ld-linux.so.2 is simply (and not too surprisingly) not recognized as an executable file. While I'm surprised that this works on Linux, shouldn't our emulator emulate this behavior too? On Tue, Nov 28, 2000 at 07:03:38PM -0500, Marcel Moolenaar wrote: "Donald J . Maddox" wrote: I actually thought that COMPAT_LINUX had been completely removed, just causing opt_dontuse.h to be generated. I see now that it doesn't even warn about this being a deprecated option. *Is* it still considered a deprecated option? I'm sure config used to warn about COMPAT_LINUX being deprecated a while back... It's not a deprecated option. I'm not aware of config ever emitting a warning for it. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 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: 3dfx.ko
Thanks! This works great. I remember reading the stuff at the bottom of /boot/defaults/loader.conf about the 'module_name' variable, etc. and wondering what on Earth it might be useful for :) Guess I know now :) Thanks again... "Daniel C. Sobral" wrote: Use two variables to control this. For instance: threedfx_load="YES" threedfx_name="3dfx" The way loader is set up, you put the _name line in /boot/defaults/loader.conf, so that the user only needs to put the threedfx_load="YES" line in his config. 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
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
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
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=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 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: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82439HX PCI cache memory controller at device 0.0 on pci0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 ide_pci0: Intel PIIX3 Bus-master IDE controller at device 7.1 on pci0 ahc0: Adaptec 2940 Ultra SCSI adapter irq 10 at device 10.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: NVidia Riva TNT graphics accelerator irq 11 at device 12.0 on pci0 isa0: ISA bus on motherboard atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 sc0: System console on isa0 sc0: VGA 32 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa0 wdc0: unit 0 (wd0): Maxtor 71336 AP, 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): Maxtor 85250D6, LBA, DMA, 32-bit, multi-block-16 wd1: 5009MB (10259160 sectors), 638 cyls, 255 heads, 63 S/T, 512 B/S fdc0: NEC 72065B or clone 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: SoundBlaster 16 4.16 sbxvi0 at port 0x drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: SoundBlaster 16 4.16 WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ sbmidi0 at port 0x330 on isa0 snd0: SoundBlaster MPU-401 WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ awe0 at port 0x620 on isa0 awe0: SoundBlaster EMU8000 MIDI (RAM4096k) WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ opl0 at port 0x388 on isa0 snd0: Yamaha OPL3 FM 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: FUJITSU M2684S-512 2036 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: MATSHITA CD-ROM CR-508 XS03 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
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: 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 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
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: SB16 PnP at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 FreeBSD Audio Driver (newpcm) Sep 9 1999 00:19:32 Installed devices: pcm0: SoundBlaster 16 4.16 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
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
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 foo 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
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 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
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
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: 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 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, ,
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
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
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 (QD) 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: NE2000 Compatible at port 0x220-0x23f irq 3 on isa0 ed0: address 00:40:05:38:7b:a4, type NE2000 (16 bit) unknown3: speed win SEDLBAUER AG 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: 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: [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
[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: 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(?)
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: 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 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: 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: 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: 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: 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 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
Problems with stdbool.h...
As some of you may have noticed, apsfilter will no longer
compile on -current. The reason is that the configure
script checks for stdbool.h, and uses it if it exists;
but this file, as I understand it, is intended only for
use with C99, and unfortunately, if it is included by the
standard compiler, the results are bad. An example:
/* test.c */
#include stdbool.h
int main()
{
return(0);
}
$ cc -o test test.c
In file included from test.c:1:
/usr/include/stdbool.h:51: conflicting types for `_Bool'
/usr/include/stdbool.h:38: previous declaration of `_Bool'
Apparently, stdbool.h defines _Bool, then redefines it if
__STDC_VERSION__ 199901L.
Fixing the port to compile anyway would be simple enough,
but I think the real problem is in stdbool.h, no? It
shouldn't break the standard compiler like this, should
it?
Please forgive the cross-posting... Although this affects
ports, I have no way of knowing if the maintainer of this
file reads the ports mailing list...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
What happened to netstat?
After rebuilding World and kernel last night, I find that the behavior of 'netstat -a' has changed... Only UNIX domain sockets are shown in the output, no inet stuff at all, e.g.: # netstat -a Active UNIX domain sockets Address Type Recv-Q Send-QInode Conn Refs Nextref Addr cbf67c40 stream 0 00 cbf67c0000 /tmp/.X11-unix/X0 cbf67c00 stream 0 00 cbf67c4000 cbf67e00 stream 0 00 cbf67b4000 /tmp/.X11-unix/X0 cbf67b40 stream 0 00 cbf67e0000 cbf67d80 stream 0 00 cbf67a4000 /tmp/.X11-unix/X0 cbf67a40 stream 0 00 cbf67d8000 cbf67a80 stream 0 00 cbf67c8000 /tmp/.X11-unix/X0 cbf67c80 stream 0 00 cbf67a8000 cbf67cc0 stream 0 00 cbf67dc000 fs7100 cbf67dc0 stream 0 00 cbf67cc000 cbf67d40 stream 0 00 cbf67e8000 /tmp/.X11-unix/X0 cbf67e80 stream 0 00 cbf67d4000 cbf67e40 stream 0 0 cc22bd20000 /tmp/.X11-unix/X0 cbf67d00 stream 0 00000 fs7100 cbf67ec0 stream 0 0 cbf80660000 fs7100 cbf67f40 stream 0 0 cbf5ac60000 /var/run/printer cbf67ac0 dgram 0 00 cbf60fc00 cbf67f00 cbf67f00 dgram 0 00 cbf60fc00 cbf67f80 cbf67f80 dgram 0 00 cbf60fc00 cbf67fc0 cbf67fc0 dgram 0 00 cbf60fc000 cbf60fc0 dgram 0 0 cbf5ca600 cbf67ac00 /var/run/log Anybody have an idea what's going on here? 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: 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: 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
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: 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 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
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: SB16 PnP at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 unknown0: Game at port 0x200-0x207 on isa0 unknown1: WaveTable at port 0x620-0x623 on isa0 FreeBSD Audio Driver (newpcm) Sep 9 1999 00:19:32 Installed devices: pcm0: SoundBlaster 16 4.16 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
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
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: 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 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, ,
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
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 (QD) 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: NE2000 Compatible at port 0x220-0x23f irq 3 on isa0 ed0: address 00:40:05:38:7b:a4, type NE2000 (16 bit) unknown3: speed win SEDLBAUER AG 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(?)
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: 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 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: 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?
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=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 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: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82439HX PCI cache memory controller at device 0.0 on pci0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 ide_pci0: Intel PIIX3 Bus-master IDE controller at device 7.1 on pci0 ahc0: Adaptec 2940 Ultra SCSI adapter irq 10 at device 10.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: NVidia Riva TNT graphics accelerator irq 11 at device 12.0 on pci0 isa0: ISA bus on motherboard atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 sc0: System console on isa0 sc0: VGA 32 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa0 wdc0: unit 0 (wd0): Maxtor 71336 AP, 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): Maxtor 85250D6, LBA, DMA, 32-bit, multi-block-16 wd1: 5009MB (10259160 sectors), 638 cyls, 255 heads, 63 S/T, 512 B/S fdc0: NEC 72065B or clone 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: SoundBlaster 16 4.16 sbxvi0 at port 0x drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: SoundBlaster 16 4.16 WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ sbmidi0 at port 0x330 on isa0 snd0: SoundBlaster MPU-401 WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ awe0 at port 0x620 on isa0 awe0: SoundBlaster EMU8000 MIDI (RAM4096k) WARNING: "snd" is usurping "snd"'s cdevsw[] ^^^ opl0 at port 0x388 on isa0 snd0: Yamaha OPL3 FM 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: FUJITSU M2684S-512 2036 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: MATSHITA CD-ROM CR-508 XS03 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
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 majord...@freebsd.org 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 majord...@freebsd.org 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 majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: boot -c not saving changes
Yeah, you're right on all counts, of course... I've answered this question so many times in the last 10 days that I'm starting to go on autopilot :-/ Robert Nordier wrote: Donald J . Maddox wrote: 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. Rather load -t userconfig_script /kernel.config In particular, not /boot.config which is a file with a different purpose used by the bootblocks (boot stages 1 2). -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
link_elf: symbol lkmexists undefined
Since building a new kernel and a full 'make world' on Jan 24, I am seeing this at boot: avail memory = 62210048 (60752K bytes) Preloaded elf kernel kernel at 0xf02cc000. Preloaded elf module msdos.ko at 0xf02cc09c. Preloaded elf module procfs.ko at 0xf02cc13c. Preloaded elf module if_tun.ko at 0xf02cc1dc. Preloaded elf module if_disc.ko at 0xf02cc27c. Preloaded elf module linux.ko at 0xf02cc31c. Preloaded elf module vesa.ko at 0xf02cc3bc. Preloaded elf module joy.ko at 0xf02cc458. link_elf: symbol lkmexists undefined Anybody have any idea where this is coming from? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RELENG_3 boot failed
On Sun, Jan 24, 1999 at 10:35:23AM -0500, Tom Torrance at home wrote: After a cvsup this AM, the boot process failed when attempting to mount the root partition, with the message: specified device does no match mounted device. I had to change the device specification in /etc/fstab from /dev/da0s2a to /dev/da0a to boot properly. Whoops... I just noted that you're using RELENG_3, but I'm getting the same problem on: FreeBSD 4.0-CURRENT #0: Sun Jan 24 00:23:52 EST 1999 so I'm cc'ing -current on this reply... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with 4.0-current
On Sun, Jan 24, 1999 at 01:47:25PM -0600, Stingray wrote: I just CVSup'd 4.0-current and installed it, then made an elf kernel. The elf kernel seemed to boot up just fine, but when the file systems where being mounted, it couldn't mount /: Specified device does not match mounted device. I believe this was the error message. Does anyone know what it means? I am seeing the same problem... It works if you use the old-style names, e.g. wd0a instead of wd0s1a. Not sure yet what's causing this... (CC'ed to -current) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
