newpcm and RealPlayer woes
I've been using the newpcm drivers for some time, and they seem to work with most things, but I've noticed some problems, specifically with the RealPlayer 7 Beta for linux. The sound seems to jump at the beginning of a stream, leaving it at least 3-4 seconds behind the counter and any video content. This makes video streams hard to watch, and also cuts off local streams early. Also, on remote streams, the sound clicks and squeals loudly about 1-2 seconds into the stream, and the stream stays out of sync with the RealPlayer counter the whole time. I have a PR open on this, misc/18728. All of this seems to have started happening around the time of the May 12 MFC, it looks like. I don't know enough about how newpcm works to be able to offer any advice on fixing the code, but I'd be willing to take a look at it in my spare time, and I can try any patches someone can come up with. I have my dmesg pasted below; this is from -STABLE CVSupped Sunday night. -lee ---cut here-- Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.0-STABLE #0: Tue Jul 11 04:10:20 EDT 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LEE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 400910252 Hz CPU: AMD-K6(tm) 3D+ Processor (400.91-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bf AMD Features=0x8800 real memory = 134217728 (131072K bytes) avail memory = 127434752 (124448K bytes) Preloaded elf kernel "LEE" at 0xc02e7000. VESA: v2.0, 8192k memory, flags:0x1, mode table:0xc0293e82 (122) VESA: Matrox Graphics Inc. K6-family MTRR support enabled (2 registers) npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at 0.0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 11 fxp0: port 0xd800-0xd81f mem 0xe880-0xe88f,0xe8901000-0xe8901fff irq 9 at device 8.0 on pci0 fxp0: Ethernet address 00:a0:c9:76:92:a7, 10Mbps sym0: <875> port 0xdc00-0xdcff mem 0xe890-0xe8900fff,0xe8904000-0xe89040ff irq 10 at device 9.0 on pci0 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym1: <875> port 0xe000-0xe0ff mem 0xe8903000-0xe8903fff,0xe8902000-0xe89020ff irq 9 at device 9.1 on pci0 sym1: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. pcib1: on motherboard pci2: on pcib1 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> 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 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/15 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: sb0: driver is using old-style compatability shims sbxvi0 at port 0x drq 5 on isa0 isa_compat: didn't get ports for sbxvi snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] sbxvi0: driver is using old-style compatability shims sbmidi0 at port 0x330 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] sbmidi0: driver is using old-style compatability shims awe0 at port 0x620 on isa0 awe0: WARNING: "snd" is usurping "snd"'s cdevsw[] awe0: driver is using old-style compatability shims ad0: 8693MB [17662/16/63] at ata0-master using UDMA33 acd0: CDROM at ata1-master using WDMA2 afd0: 120MB [963/8/32] at ata1-slave using PIO2 Waiting 10 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. sa0 at sym1 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers pass1 at sym1 bus 0 target 5 lun 0 pass1: Fixed Scanner SCSI-2 device pass1: 3.300MB/s transfers Mounting root from ufs:/dev/ad0s1a cd0 at sym1 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [1 x 2048 byte records] -- ++ | Lee Cremeans -- Manassas, VA, USA (WakkyMouse on WTnet) | | [EMAIL PROTECTED] | http://wakky.dyndns.org/~lee | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target tomake your kernels
At 1:29 PM +0200 2000/7/11, Peter van Heusden wrote: > My only (minor) concern, from a useability point of view, is that there is > no default BUILDKERNEL value - shouldn't it default to GENERIC if nothing > else is specified? That way you won't actually be able to do a > 'buildkernel' without building a kernel. Hmm. Good idea. Until then, this needs to be mentioned in the documentation. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: why new buildkernel (was HEADS UP! Always use the 'make buildkernel'..."
- Original Message - From: "Jeff Wyman" <[EMAIL PROTECTED]> To: "Francisco Reyes" <[EMAIL PROTECTED]> Cc: "Vivek Khera" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Kris Kennaway" <[EMAIL PROTECTED]> Sent: Tuesday, July 11, 2000 3:36 AM Subject: Re: why new buildkernel (was HEADS UP! Always use the 'make buildkernel'..." > > Why is this new procedure necessary. > > I recall reading is because of some new additions, but what were > > these additions (I have seen the name, but have no clue what > > they are.. binutils?) and why the new, more cumbersome, > > procedure? > > francisco > > Moderator of the Corporate BSD list > > http://www.egroups.com/group/BSD_Corporate > > If you missed one of Kris Kennaway's previous messages about this, this is > how he described it: > > --SNIP-- > Buildkernel internally handles tool dependency problems, where the kernel > build depends on tools which were built by make installworld, but not yet > installed on the system. The alternative is to post a detailed list of > which bits must be installed before you can build your new kernel, each > time it happens, which is error-prone and subject to people not reading > their mail (oops, which is exactly what happened this time around). > --SNIP-- > Can someone (who is knowledgable enough to explain it properly, otherwise I would make a go at it) put this in handbook/makeworld.html? I just read it and it still says to do your kernel upgrade after doing make world (or make installworld). There is a -CURRENT section in there detailing -j4, so why not a 4.0-STABLE (and higher) section detailing this change to the kernel building procedure and why it is now preferred over make world/installworld and then kernel config/make depend/make/make install kernel building procedure? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target to make yerkernels
On Mon, 10 Jul 2000, Kris Kennaway wrote: >Well, I didn't see you very active with the 20-odd people who posted the >same build error this time around. And I think it makes much more sense to >teach people to use a tool which won't have dependency problems in the >first place than to catch them all individually once they've tried what >they knew and failed, and resorted to asking for help. But if you're going >to make a commitment to answer each and every one of them every time this >problem recurs, on every support forum, then I suppose it amounts to more >or less the same thing in the end. Kris, You have some very valid concerns from a support perspective, and I respect that. What I believe you are failing to take into account is the fact that the buildkernel target requires a full source repository and object tree. It is not that people object to a /usr/src level target for kernel builds, they object to the idea that The FreeBSD Project would require all users to have an entire source tree and object tree for something as common as a kernel build. Often users chose to stay with -RELEASE and those users need to be able to install only src-sys from their RELEASE CDROMs and build and install custom kernels. It would be a bit obtuse to do a full buildworld in order to obtain an object tree if one was planning on staying with -RELEASE code. The only way I can see making it feasible to for the buildworld target to be universally supported is to implement some sort of a check to see whether or not the version of the kernel code is different from that of the currently running kernel. If that is the case, then an object tree should be required. Otherwise buildkernel should use the build tools from the running system. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target to make yer kernels
> "WL" == Warner Losh <[EMAIL PROTECTED]> writes: WL> In message <[EMAIL PROTECTED]> Vivek Khera writes: WL> : So if I don't have a "buildworld" /usr/obj tree sitting around, I am WL> : not supported to build a new kernel for my existing system, say, to WL> : add a new SCSI controller to a server? WL> No. You misunderstand. The buildkernel is only needed when you are I don't think I misunderstood what was said. What was said was that the only supported way of building a kernel was "make buildkernel" and I was pointing out why that could be an issue. WL> updating your kernel. If you do not update the sources via cvs, cvsup WL> or other means, then you can just cd to the src/compile/FOO directory So the final result of the discussion seems to be: 1) after upgrading sources (ie, make buildworld of any sort) use "make buildkernel" to build your kernel 2) any other times, you can use the traditional build process Correct? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target to make yer kernels
Greg Lehey wrote: > > 3. It gives the kernel a different name. > Suppose you happen to have a kernel name like dev or etc. You would have problems then. :-) -- Stephen Montgomery-Smith Department of Mathematics, University of Missouri, Columbia, MO 65211 Phone 573-882-4540, fax 573-882-1869 http://www.math.missouri.edu/~stephen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target tomake yer kernels
At 10:39 AM -0400 2000/7/11, Vivek Khera wrote: > So the final result of the discussion seems to be: > > 1) after upgrading sources (ie, make buildworld of any sort) use "make > buildkernel" to build your kernel > > 2) any other times, you can use the traditional build process > > Correct? Right. I'm trying to get the exact set of steps (and related comments, such as "don't report errors if you fed '-j4' to make", etc...) consolidated and fed to [EMAIL PROTECTED], for use in updating the Handbook. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: newpcm and RealPlayer woes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 11 Jul 2000, Lee Cremeans wrote: : : I've been using the newpcm drivers for some time, and they seem to work with : most things, but I've noticed some problems, specifically with the : RealPlayer 7 Beta for linux. The sound seems to jump at the beginning of a : stream, leaving it at least 3-4 seconds behind the counter and any video : content. This makes video streams hard to watch, and also cuts off local : streams early. Also, on remote streams, the sound clicks and squeals loudly : about 1-2 seconds into the stream, and the stream stays out of sync with the : RealPlayer counter the whole time. I have a PR open on this, misc/18728. Hmm.. I never noticed it before, but it would appear that I have the same problem. Though it MAY just be the stream, I only tried with two *remote* streams as I have no local ones to test. I found that video content was about 4 seconds behind the audio content.. I do not have any of the 'weird sound' problem though. I did through XMMS but their new version fixed that out. Similar problems occured with things that used certain mixers. I believe this was an issue of the *program* not the OS. Either way, xmms 1.2.x fixed it. : All of this seems to have started happening around the time of the May 12 : MFC, it looks like. I don't know enough about how newpcm works to be able to : offer any advice on fixing the code, but I'd be willing to take a look at it : in my spare time, and I can try any patches someone can come up with. I have : my dmesg pasted below; this is from -STABLE CVSupped Sunday night. My CVSup last was May 30 2000. : -lee I've attached my dmesg incase there are some similarities. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-STABLE #0: Mon Jul 3 00:26:07 EDT 2000 [EMAIL PROTECTED]:/opt/FreeBSD-src/sys/compile/EPSILON Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 400910368 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ff real memory = 268369920 (262080K bytes) avail memory = 258084864 (252036K bytes) Preloaded elf kernel "kernel" at 0xc02ba000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 irq 10 chip1: port 0x5000-0x500f at device 7.3 on pci0 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe400-0xe47f mem 0xea00-0xea7f irq 10 at device 11.0 on pci0 xl0: Ethernet address: 00:10:4b:0f:e6:b6 miibus0: on xl0 xlphy0: <3Com internal media interface> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> 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 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppi0: on ppbus0 sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 sbc0: setting card to irq 5, drq 1, 5 pcm0: on sbc0 unknown0: at port 0x200-0x207 on isa0 IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to accept, logging disabled ad0: 8063MB [16383/16/63] at ata0-master using UDMA33 ad1: 8063MB [16383/16/63] at ata0-slave using UDMA33 acd0: CDROM at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s1a * Matt Heckaman - mailto:[EMAIL PROTECTED] http://www.lucida.qc.ca/ * * GPG fingerprint - A9BC F3A8 278E 22F2 9BDA BFCF 74C3 2D31 C035 5390 * -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (FreeBSD) Comment: http://www.lucida.qc.ca/pgp iD8DBQE5azNwdMMtMcA1U5ARApeSAJ9QzfibRk07/txywVRL2xfqAwr0qQCeLYJT YpreSBErCLIxuzbWRe+pJyk= =OBUt -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target to make yerkernels
> "KK" == Kris Kennaway <[EMAIL PROTECTED]> writes: KK> support after the fact, and so people should be using the buildkernel KK> target if they want their kernel builds to work across upgrades. Which is a very different claim than saying you should *always* use buildkernel, and no other method is "supported". You're now qualifying your statement with "across upgrades". -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG & MIME spoken herehttp://www.khera.org/~vivek/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: newpcm and RealPlayer woes
Matt Heckaman <[EMAIL PROTECTED]> probably said: > I do not have any of the 'weird sound' problem though. I did through XMMS > but their new version fixed that out. Similar problems occured with things > that used certain mixers. I believe this was an issue of the *program* not > the OS. Either way, xmms 1.2.x fixed it. I'm using xmms 1.2.1. I get the static on open as I described with xmms, x11amp and mpg123. With the same software on a machine using an SBLive, I don't get any static problems. I also haven't seen the mose movement or console change noise, just static on open, sometimes ... P. -- pir [EMAIL PROTECTED][EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: buildkernel
I think the purpose is to cause the kernel builds and installs to work right. I would HOPE everyone could agree on that as a "purpose." Some people have made suggestions such as, "if you're using the same system, (ie. the -RELEASE people), don't require a whole buildowrld..." Why not accept this as Voodoo Black Magic, and simply line up the features you'd like? A) Check for this, B) Check for that . and ask them to implement them? If they really don't like the idea, then _maybe_ they will try to solve the problem in a different way? Just an obscure idea -- Close your eyes. Now forget what you see. What do you feel? -- My heart. -- Come here. -- Your heart. -- See? We're exactly the same. Jon Smith -- Senior Math Major @ Purdue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
NIS/YP compatibility
[A -questions matter. BCC'd to -stable to gain the input of the many on that list who run FreeBSD in an enterprise situation. Please, if you reply on -questions CC me as I have trouble sifting through all of my -questions mailbox] I'm running into some NIS/YP issues which I would like the community's input on. To make a long story short we need our users to be machine independent. We run such a motley collection of OSes on the hardware we have around here that NIS/YP is the lowest common denominator solution for user account management. It's the only scheme every platform we run has support for. Security issues aside, I must run NIS. At the moment we are successfully running NIS + NFS(w/ automounted shares) off of an IRIX box. This was installed and running when I arrived. That IRIX box is somebody's workstation and understandably I'd like to move that service onto one of our servers around here. Downtime is a Bad Thing and workstations have downtime. When I got here there were already servers running RedHat Linux doing various things. My first thought was to try moving NIS onto the Linux servers, they were already running and NIS doesn't impact server performance significantly. Well, no such luck, Linux's yp and NFS implementations are for shame! The only things that would talk to the Linux boxen were other Linux boxen. Soon after that failed attempt I inherited a couple of old sparcstation's for server use that I figured would make decent NIS servers since they're 10BaseT only and I wouldn't want to use them to serve anything bandwidth intensive anyway. I opted to install NetBSD/sparc on them after inspecting the OpenBSD and NetBSD manpages on yp and concluding that NetBSD had a more recent, complete implementation. That endeavor failed too. The Linux boxen and other sparc's running NetBSD could talk to it just fine, but the IRIX clients were no go. Now I'm understandably a bit frustrated. All this time I've also been struggling with the fact that I'm a BSD admin, those things are natural to me, and the various SYSV OSes we have running around are giving me nightmares the night after I dig around in /etc. I would love to be able to put my favorite OS, FreeBSD, on these servers and be done with it. Give linux the axe, so to speak. In fact, I've even convinced my boss to let me do it if it'll get these NIS issues resolved. He too, doesn't desire to leave NIS running off of an IRIX workstation any longer than he has to. Here's the dilemma, with all of the issues we've had surrounding various NIS implementations, before I set about the task of converting our servers to FreeBSD, he would like to see some detailed success reports from people using FreeBSD to serve IRIX NIS/YP clients. Details like what version of FreeBSD, what version of IRIX, and what is used as master, slave, and client. I've searched the mailing list archives to no avail. I am asking those of you listening to help me out and jot down a quick message about your use of NIS in a mixed IRIX/FreeBSD environment. Thank you for your time. -- Brandon D. Valentine, Systems Administrator Vanderbilt University, Center for Structural Biology bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Bad sound output, AudioPCI ES1371, 4.0-STABLE
I have an AudioPCI ES1371 sound card. From dmesg & sndstat : --- > dmesg|grep pcm pcm0: port 0xb400-0xb43f irq 5 at device 13.0 on pci0 --- > cat /dev/sndstat FreeBSD Audio Driver (newpcm) Jul 10 2000 17:31:19 Installed devices: pcm0: at io 0xb400 irq 5 (1p/1r channels duplex) --- The only thing in my kernel config for this is : --- device pcm --- I've had this machine for awhile, with sound working fine under 3.4. I believe it was also working under 4.0-RELEASE also. It's now running 4-STABLE (from 10 Jul 2000) and putting out really crummy sound ouput. You can make out the song that it's playing, but not easily because it's generating so much static and garbage around it. I've seen several posts about bad sound output, but I haven't seen any solutions yet. If there are some patches that are floating around looking for someone to test them I'd be happy to. -- Joseph Scott [EMAIL PROTECTED] Office Of Water Programs - CSU Sacramento To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
problems building kernels
is anyone else more than a little concerned that the people who ostensibly understand all the details can't agree as to how to do what and when?? and this is supposed to be STABLE??? give us a break, guys. you don't go changing how a kernel gets built in a release called STABLE. and if you didn't do that, please explain that we can just ignore all the mail the last few days and go back to trying to figure out why cvsup-ing the latest STABLE release doesn't compile/run-on-SMP/etc,etc,etc i'll restate my minority view that the FreeBSD project *really* needs to rethink their release names and the whole release process, rather than explaining that we don't understand the effort's peculiar definitions of words like "stable" but i'll shut up now. the last time i said this i generated a few free kilowatts with the recovered heat from the flaming... -mo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
