Minor issue with portmap=NO vs 'ypwhich'
This will probably seem like a dumb thing to report, but I'll mention it in case someone who knows about yp/NIS would want to comment on it. My .bashrc file is (pretty much) the same on the many different platforms that I work on, and as a matter of trouble-shooting on SOME of those platforms I do a 'ypwhich' in it. Most of those platforms do NOT run yp, but I still run it on all platforms and just catch the error for those hosts which are not running yp. I am NOT running yp on freebsd. With this week's -stable, /etc/defaults/rc.conf changes portmap_enable to be NO. With portmap_enable off, ypwhich still errors out as it does with portmap_enable on, but it takes it much longer to figure out that yp is not running (30 seconds? 60 seconds?). So, I realize it's probably dumb to care about how quickly ypwhich completes on a machine which is NOT running yp, but it is a noticeable change, so I thought I'd mention it. It is easy for me to just fix my .bashrc so I wouldn't hit that long delay, or to just turn on portmap, for that matter (which is what I've done for the moment). So, this isn't a big issue for me. I'm just wondering if there are any other effects which might be more significant for other users. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: New kernel option CPU_ENABLE_SSE
--R+My9LyyhiUvIEro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 16, 2001 at 04:20:35PM -0400, Kenneth W Cochran wrote: Assuming CPU_ENABLE_SSE is a Good Thing, why not make it default with the cpu I686_CPU kernel config directive (similar to F00F_HACK auto-include with I586_CPU)? Because not all i686'es support SSE. So detect it automatically based on the CPU feature bits. Needing a kernel compile option for this is unforgivably lame. If you want to be able to disable it, use a tunable. -- ... 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-stable in the body of the message
Re: New kernel option CPU_ENABLE_SSE
To: Kris Kennaway [EMAIL PROTECTED] cc: Kenneth W Cochran [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: New kernel option CPU_ENABLE_SSE --R+My9LyyhiUvIEro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 16, 2001 at 04:20:35PM -0400, Kenneth W Cochran wrote: Assuming CPU_ENABLE_SSE is a Good Thing, why not make it default with the cpu I686_CPU kernel config directive (similar to F00F_HACK auto-include with I586_CPU)? Because not all i686'es support SSE. So detect it automatically based on the CPU feature bits. Needing a kernel compile option for this is unforgivably lame. If you want to be able to disable it, use a tunable. Perhaps; the gist I get is that the compile option is for some field-testing. Maybe similarly appropriate would be something similar to NO_F00F_HACK; for example, CPU_DISABLE_SSE or CPU_NO_ENABLE_SSE (?). Just thinking out loud; the current method is ok with me. :) -kc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: boot crash after hardware change.
On Sat, 18 Aug 2001 12:54:29 -0700, Mike Smith wrote: BIOS crash. I bet you configured your disk dangerously dedicated when you installed. Hmm... I hung the disk on the sister system, and here's what fdisk reports: *** Working on device /dev/da3 *** parameters extracted from in-core disklabel are: cylinders=1496 heads=142 sectors/track=42 (5964 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1496 heads=142 sectors/track=42 (5964 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 8925000 (4357 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 0; end: cyl 555/ sector 42/ head 141 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED I thought if it was DD, it wouldn't have the 4 partition entries... Is this right? I'm dumping the disks partitions to files on the system it's hung off of now, and can re-fdisk, re-label, newfs everything, and restore, but I'd hate to do that if its not the problem... Thanks, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Out of buffer space
In message [EMAIL PROTECTED] Stephen Montgomery-Smith writes: : Someone suggested that I try : ifconfig ep0 down : ifconfig ep0 up : This cleared up the frozen connection to hub. This might also be due to the card not getting interrupts, which is a problem I'm trying to solve... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Security check output line I don't understand
It looks like I finally have my email set up half-way decent and can send messages to the list without getting bounced. Thank you to the people that responded to my last question - I eventually gave up on installing oracle on my FreeBSD box, but will try again fairly soon... Currently, I'm seeing the following line in my security check output: adsl-63-198-218-205.dsl.snfc21.pacbell.net kernel log messages: 8-205 sendmail[1492]: f6VA5T701492: SYSERR(root): savemail: cannot save rejected email anywhere Any idea of what it means and how to fix this? thanks, rob To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: New kernel option CPU_ENABLE_SSE
On Sat, Aug 18, 2001 at 02:51:00PM -0700, Mike Smith wrote: --R+My9LyyhiUvIEro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Aug 16, 2001 at 04:20:35PM -0400, Kenneth W Cochran wrote: Assuming CPU_ENABLE_SSE is a Good Thing, why not make it default with the cpu I686_CPU kernel config directive (similar to F00F_HACK auto-include with I586_CPU)? Because not all i686'es support SSE. So detect it automatically based on the CPU feature bits. Needing a kernel compile option for this is unforgivably lame. If you want to be able to disable it, use a tunable. No arguments there.. Kris PGP signature
Re: 4.4-RC kernel can't boot on vmware
More Information. I found booting enable on some case. mac I'm using vmware for W2K(2.0.4 build 1142), Guest OS FreeBSD. mac I made 4.4-RC kernel and tried boot, but it can't. mac The kernel freeze at exec moused. I try to disable to exec moused, but mac init(1) panics before login prompt. mac 4.4-PRERELEASE kernel(cvsuped at 8/13) can boot, so, I merge change step mac by step, I found, mac merging SSE kernel support(2001/08/14 18:23:54 PDT) - can't boot mac Kernel option CPU_ENABLE_SSE is not effective. I tried to both kernel mac CPU_ENABLE_SSE option enable/disable, but, it can't boot. 4.4-RC kernel (include SSE support) can boot on vmware, the root partionis Virtual Disk. can't boot on vmware, the root partionis Existing Disk Partions. 4.4-RC kernel (not include SSE support) can boot on vmware, the root partionis Virtual Disk. can boot on vmware, the root partionis Existing Disk Partions. 5-current kernel (cvsuped at 8/12) can boot on vmware, the root partionis Existing Disk Partions. and, 4.4-RC kernel (not include SSE support) with Native FreeBSD(Native means not vmware), my PCCARD NIC works fine, but, 4.4-RC kernel include SSE support with Native FreeBSD, put bellow messages and many packet lossing. ed1: remote transmit DMA failed to complete. Above two kernel has same configuration files, and same pccard.conf. pcic recognize message is, pcic0: TI PCI-1410 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 pcic0: PCI Memory allocated: 0x4400 pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][pci only] pccard0: PC Card bus (classic) on pcic0 and pccard nic recognize message is, from pccardd Card corega K.K.(corega EtherII PCC-T) [(null)] [(null)] matched corega K.K. (/corega Ether(II)? PCC-T/) [(null)] [(null)] Using I/O addr 0x320, size 32 Setting config reg at offs 0x3f8 to 0x61, Reset time = 50 ms Assigning I/O window 0, start 0x320, size 0x20 flags 0x7 Assign ed0, io 0x320-0x33f, mem 0x0, 0 bytes, irq 9, flags 0 and from kernel, ed1 at port 0x320-0x33f irq 9 slot 0 on pccard0 ed1: address 00:90:99:0d:b5:cf, type NE2000 (16 bit) ed1: corega K.K. (/corega Ether(II)? PCC-T/) messages is same, but, 4.4-RC including SSE support kernel has ed1: remote transmit DMA failed to complete. message and packet lossing. -- [EMAIL PROTECTED][EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: Silly crackers... NT is for kids...
On Sat, 18 Aug 2001, Matt Piechota wrote: On Fri, 17 Aug 2001, Nate Williams wrote: [...telnetd exploit allows anyone root access...] I must have misspoke. There's only 4 of us that have the root password on our machines, but we 4 telnet everywhere as root. And just horrify everyone, my lead actaully runs X as root, as did I for awhile. Having the users enable it by default makes them more aware of what's going on. (Although, one could argue that all the folks who are still infected with CodeRed initially enabled it, and have done nothing since...) I completely agree. I like the way RedHat 7.1 disables almost everything on install. One could argue that they shouldn't even install sshd, since they may well have a bug in it as well. Makes it awfully tough to manage a rack of boxen remotely... -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] I was raised by a pack of wild corn dogs. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
