SSH patch for X SECURITY bug (CVE-2015-5352)?
A while back someone discovered a bug prior to OpenSSH v6.9 relating to use of the "-X" option (X11 forwarding) option for the SSH client. The CVE entry contains links to a couple other sites: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5352 The OpenSSH v6.9 release notes (http://www.openssh.com/txt/release-6.9) mention this as a security bugfix, but don't indicate if the problem existed in versions earlier than v6.8; FreeBSD 9.3-RELEASE, 10.1-RELEASE, and 10.2-RELEASE appear to have v6.6.1 (although linked against different versions of OpenSSL). I've searched FreeBSD's security advisories, but see no mention of this bug at all (certainly not in the most recent OpenSSH advisories). Top search hits in Google for this CVE show a couple Linux distros (RedHat and Ubuntu) mention it. For what it's worth, RedHat's declining to fix it in RHEL 5, deferring the fix in RHEL 6, and says RHEL 7 is not affected. Ubuntu's support mentions it but describes no plans to fix it. Are any of you aware of a patch for this that's been committed unannounced? It strikes me as a somewhat esoteric bug, but I promised someone I'd ask around about it. If no patch is committed, is the plan to just defer this one until later? -- Alan Amesbury University Information Security http://umn.edu/lookup/amesbury ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1?
Alfred Perlstein said: > It's possible they may work, but that is not guaranteed. > > Packages built on 9.1 should work on 9.3. > > Packages built on 9.3 may work on 9.1, but that would only be by chance. OK, it sounds like testing is in order to make sure, but the probability is greater than zero. It also sounds like I may be at least partially sane. Thanks! -- Alan Amesbury University Information Security http://umn.edu/lookup/amesbury ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Sanity check: FreeBSD 9.3 binaries on FreeBSD 9.1?
First off Yes, I know 9.1-RELEASE is deprecated. I want to run something newer, but circumstances require I can't for now. Traditionally in FreeBSD -STABLE (as in 9-STABLE) referred to the APIs as being stable, i.e., stuff compiled within the same major release would generally run on versions within that release... or so I recall. I have an instance where I have a need to run 9.1-RELEASE, but my package building infrastructure is all centered around 9.3-RELEASE or later. Based on my (possibly incorrect) understanding of How Things Are[tm], I think packages built for 9.3-RELEASE will generally run on 9.1-RELEASE. Does this sound generally correct, or am I totally off base here? Any major pitfalls I should know of? -- Alan Amesbury University Information Security http://umn.edu/lookup/amesbury ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Inmutable bit in some binaries
Jeremy Chadwick said: It's possible installworld will break (fail/exit) when trying to overwrite some of these binaries. However... It will totally break installworld where installworld tries to replace the file. Been there, done that, and have the collector's edition soundtrack. [snip] What you're attempting to solve, ultimately, is security through obscurity and gets you a very large headache. :-) Your schg idea would only work if you planned on using kern.securelevel=1 or higher. This sounds great in concept, but many a time on this list have people posted problems with system administrative tasks (re: upgrading) when this sysctl is set to non-default (-1). I run at kern.securelevel=2 on most hosts at work and home. The only problems I've encountered are a) you can't do an installworld reliably (but see below!) b) buildworld sometimes fails c) X and other devices that use /dev/io break Workstation-class hosts don't use securelevel specifically because of "c". I don't need X on my servers so it doesn't get installed; no problems there. If you plan on using this, I would advocate *all* installation/work be done in single-user mode. I know quite a few people who completely ignore the "boot into single user" step of src/Makefile and instead do it in multi-user mode -- only to be found later screaming/crying when [snip] 100% agreement! I admit to occasionally taking shortcuts on this, but the majority of the time installworld and mergemaster are done in single-user. Every time I've had a problem with installworld while *not* doing this could be attributed to trying to do it in multi-user. The fact that buildworld will only *sometimes* fail in multi-user with kern.securelevel=2 is something that I consider to be a bug in the buildworld process, but not one serious enough that I've dug into it to find the root cause. The failure is almost always when attempting to touch the SSH binaries that show up under /usr/obj during the build; schg gets set on those at some point... but, again, I haven't bothered to figure out when or how. In those instances, I'm willing to reboot with securelevel disabled, do my work, then enable it again when I'm finished. This seems to work well. The only problems I see with applying schg and friends to other files is that it will complicate your upgrades. I suspect it's doable, though, provided you keep track of which files you're modifying. Then you can remove the flags prior to an upgrade, let buildworld/installworld do its thing, and reapply them when the work's complete. It's possible that mtree(8) might be very useful for documenting this sort of thing. Otherwise, I'm pretty sure others here have made use of read-only environments, such as read-only NFS root filesystems (sometimes accomplished via PXE) and/or /usr, or CD-based OS (good luck changing any files there). I can't help in that regard. Actually, sysutils/ezjail puts together a pretty nice framework that makes use of what's effectively a read-only OS with other things overlaid on top of it. That might work as an example, if one's needed. -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Garbled output from kgdb?
Jung-uk Kim wrote: > The attached patch is for -STABLE. Note that it is only compile > tested on amd64. The platform in question is 7.1-RELEASE-p5/amd64, and the patch you supplied looks like it applies cleanly to it. While I am unable to pin down the specific trigger of this flaw (the host simply panicked a couple times while under moderate-to-heavy use), I'm willing to apply the patch to the host's current source tree, provided you and John Baldwin are in agreement that it's safe to do so. Note that's not meant to imply I don't trust your coding skills; I'm just not ready to modify production assets without a second look. ;-) Thanks again for your help on this. I appreciate it! -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Garbled output from kgdb?
John Baldwin wrote: > This is odd. [snip] > The trace actually ends here. There is nothing super bad here but there is a > big problem actually in that the idle threads cannot block on a lock, so it > is a problem for the ACPI code to be acquiring a mutex here. Perhaps the > locks protecting the idle registers need to use spin locks instead. The > problem with blocking in the idle thread is that the scheduler assumes (even > requires) that the idle thread is _always_ runnable. I'm a bit out of my depth when it comes to kernel debugging. That said, if you can think of anything I can do or provide which might help narrow down the scope and nature of the bug (ACPI code in the host's firmware, an error in FreeBSD's ACPI support, etc.), let me know what needs to be done. I'll provide it to the list. It's a production host, so I'd like to keep disruptions to a minimum. That said, it's panicked more than once, so I think I can justify using it towards elimination of the cause of that panic if necessary. I appreciate you taking the time to look at it this far! Thanks! -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Garbled output from kgdb?
John Baldwin wrote: > Drop the '0x8:' from this and it will work better. Also, 'bt' output would > be > good. Thanks for the pointer (no pun intended). (kgdb) list *0x80424561 0x80424561 is in turnstile_wait (/usr/src/sys/kern/subr_turnstile.c:727). 722 else 723 TAILQ_INSERT_TAIL(&ts->ts_blocked[queue], td, td_lockq); 724 MPASS(owner == ts->ts_owner); 725 mtx_unlock_spin(&td_contested_lock); 726 MPASS(td->td_turnstile != NULL); 727 LIST_INSERT_HEAD(&ts->ts_free, td->td_turnstile, ts_hash); 728 } 729 thread_lock(td); 730 thread_lock_set(td, &ts->ts_lock); 731 td->td_turnstile = NULL; The backtrace looked odd (lots of stuff apparently missing), which is why I didn't include it before. Here it is with repeated lines collapsed for brevity: (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0x in ?? () #2 0x803ee713 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x803ee9c5 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x8062478e in trap_fatal (frame=0xac057a40, eva=96) at /usr/src/sys/amd64/amd64/trap.c:764 #5 0x806251c6 in trap (frame=0xac057a40) at /usr/src/sys/amd64/amd64/trap.c:290 #6 0x8060aafe in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #7 0x80424561 in turnstile_wait (ts=0xff000105dd20, owner=Variable "owner" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:727 #8 0x803e0915 in _mtx_lock_sleep (m=0xff00011ff600, tid=18446742974215718624, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:420 #9 0x801ee1e9 in AcpiOsAcquireLock (Handle=0xff000105dd20) at /usr/src/sys/dev/acpica/Osd/OsdSynch.c:377 #10 0x801aaf9c in AcpiSetRegister (RegisterId=1, Value=1) at /usr/src/sys/contrib/dev/acpica/hwregs.c:444 #11 0x801f5f6e in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:928 #12 0x806119a9 in cpu_idle () at /usr/src/sys/amd64/amd64/machdep.c:581 #13 0x8040f0e4 in sched_idletd (dummy=Variable "dummy" is not available. ) at /usr/src/sys/kern/sched_ule.c:2676 #14 0x803caa30 in fork_exit (callout=0x8040ee00 , arg=0x0, frame=0xac057c80) at /usr/src/sys/kern/kern_fork.c:804 #15 0x8060aece in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:455 #16 0x in ?? () [identical lines 17-38 removed] #39 0x in ?? () #40 0x00afe000 in ?? () #41 0x808b08c0 in tdq_cpu () #42 0x in ?? () #43 0x808bacc0 in tdq_groups () #44 0xff00010f86e0 in ?? () #45 0xff00010f8a10 in ?? () #46 0xac057a18 in ?? () #47 0x0006 in ?? () #48 0x8040e963 in sched_switch (td=0x8040ee00, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1938 #49 0x in ?? () [identical lines 50-114 removed] #115 0x0000 in ?? () #116 0x in ?? () Cannot access memory at address 0xac058000 -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Garbled output from kgdb?
One of my systems (FreeBSD 7.1-RELEASE-p3/amd64) has panicked a couple
times recently without an identified cause. This most recent time I was
able to obtain a crash dump from the system, but output from kgdb is
garbled.
Output #1
% pwd
/usr/obj/usr/src/sys/[REDACTED]
% sudo kgdb kernel.debug ~/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 07
fault virtual addresske rn= el0 xt60r
afapul t 1co2de w= isutpehrv isiorn twerritreu pdtasta
d,i spaagbe lnoet dpres
ent
instruction pointer = 0x8:0x80424561
s
tack
pFoianttera l= 0x10t:0xfffrffaffpfac057af0
frame pointer = 0x10:0xff00010f86e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu3)
trap number = 12
panic: page fault
cpuid = 3
Uptime: 40d10h35m18s
Physical memory: 8176 MB
Dumping 691 MB: 676 660 644 628 612 596 580 564 548 532 516 500 484 468
452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180
164 148 132 116 100 84 68 52 36 20 4
Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from
/boot/kernel/daemon_saver.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/daemon_saver.ko
#0 doadump () at pcpu.h:195
195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) list *0x8:0x80424561
A syntax error in expression, near `:0x80424561'.
-- End output #1 --
I've seen a thread on garbled serial console output and have seen
symptoms of this on several of my systems (including this one), but
that's been more of an annoyance than anything about which I'm actually
worried... until now. (I've actually suspected hardware/BIOS issues
relating to serial port access, which is why I've stayed out of that
thread.) That the crash dump includes similar corruption suggests to me
that it's not the serial device, but something a bit closer to FreeBSD
itself.
Any ideas what's causing the garbled output in kgdb?
--
Alan Amesbury
OIT Security and Assurance
University of Minnesota
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zdump on amd64
Andriy Gapon <[EMAIL PROTECTED]> said: > Strange problem: > $ uname -srm > FreeBSD 6.2-RELEASE-p2 amd64 > > $ zdump -v EST > EST Sun Jan 26 08:29:52 -219 UTC = Sun Jan 26 03:29:52 -219 EST isdst=0 > gmtoff=-18000 > EST Mon Jan 27 08:29:52 -219 UTC = Mon Jan 27 03:29:52 -219 EST isdst=0 > gmtoff=-18000 > EST Fri Jan 1 04:59:59 -219 UTC = Thu Dec 30 23:59:59 -219 EST isdst=0 > gmtoff=-18000 > EST Fri Jan 1 05:00:00 -219 UTC = Fri Jan 1 00:00:00 -219 EST isdst=0 > gmtoff=-18000 > ^C [snip] Known bug. See http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/109584 -- Alan Amesbury OIT Security and Assurance University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: getting garbage faster using FreeBSD?
Ivan Voras wrote: > The obvious question - why don't you burn the tapes and hammer the disks? :) Ah, low-tech. I know it well. Still, the last time I did any data destruction, I found a 4 Tesla magnet does wonders. Downsides: 1) Oxford's 90cm bore, helium-cooled magnets aren't that common, perhaps because a 2000V/500A power source is a bit expensive (solution doesn't scale). 2) The hard drive has a tendency to fly out of one's hands while moving it through the lines of force (solution requires some physical coordination). It's primarily for item #1 that I hadn't mentioned this earlier, as most readers of -STABLE users are probably looking for a more scalable solution. -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.2 SHOWSTOPPER - em completely unusable on 6.2
7 on pci0 em3: port 0xccc0-0xccff mem 0xfdee-0xfdef irq 21 at device 2.0 on pci3 amr0: mem 0xfbcf-0xfbcf irq 22 at device 3.0 on pci3 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 atkbd0: irq 1 on atkbdc0 sio1: configured irq 3 not in bitmap of probed irqs 0 Note that em1 and em2 are NOT in use on this host, are not configured, and are not physically connected to anything. This host is a UP host; while its CPU has HTT capabilities, they are disabled in the BIOS. Both hosts are running somewhat customized kernels. Notable options not in GENERIC but in these kernels are DEVICE_POLLING (but kern.polling.enable=0!), HZ=1000, and ZERO_COPY_SOCKETS. Several devices were removed, and missing devices (io, mem, isa, and npx) were added in to counter the breakage caused by the silent inclusion of the DEFAULTS stuff. UP and SMP are *identical* except for SMP having ALTQ_NOPCC and SMP added in. Also, I've noticed that STP goes nuts for the bge(4) host, but doesn't seem to notice when the em(4) host watchdog timer goes off. However, I don't have direct access to the network equipment, so I can't check for differences there. -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD boots too fast on Dell PE850
Thanks for the feedback and discussion! Alas, in terms of network configuration, I'm just a tenant; I have no direct control over the networking gear, nor direct visibility into how the switch is configured. A couple people wrote to me directly and suggested I 'send-pr' this, so I'll do so (hopefully later today). Thanks again! -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD boots too fast on Dell PE850
OK, booting *too* quickly is a somewhat unusual problem. I have FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some reason, in the PowerEdge 850 Dell chose to replace the perfectly adequate em(4) adapters found on the PE750 with bge(4) hardware. FreeBSD identifies these adapters as BCM5750A1, but Dell says they're actually Broadcom 5721J adapters instead. See http://www.dell.com/downloads/global/products/pedge/en/850_specs.pdf for details. The switch to which the host is connected is a Cisco Catalyst 3750. How this relates to FreeBSD, however. During the boot process and before /etc/rc.d/netif runs, the networking hardware is *cold*, i.e., no link lights or anything. During boot, when FreeBSD brings the interface up, there is a period where the interface appears to do autonegotiation with the switch to which it's connected, regardless of whether the 'ifconfig_bge0=...' line in rc.conf includes "media" and "mediaopt" options. The console also displays various bge0: link state changed to DOWN bge0: link state changed to UP messages, while the link lights flash on and off in various patterns. Eventually the link stabilizes... but by this point FreeBSD has completed booting and is in multiuser. The result is that any services that rely on network being present during boot (NTP, for example, as well as numerous stuff installed from ports) fail in various ways. As hinted at above, locking the NIC and the associated switch ports to a fixed speed and duplex (thus avoiding the whole autonegotiation mess) does NOT help; FreeBSD still notes link state changes as described above and things break in unpleasant ways. My fix for this has been to apply this patch to /etc/rc.d/netif (also attached in pristine form): -- Patch for netif -- --- netif.orig Thu Jun 29 17:21:10 2006 +++ netif Thu Aug 17 20:30:10 2006 @@ -71,6 +71,12 @@ # Resync ipfilter /etc/rc.d/ipfilter resync fi + + if [ ! -z "$sleep_postnetif" ]; then + echo -n "Sleeping for $sleep_postnetif seconds . . . " + sleep $sleep_postnetif + echo "Done." + fi } network_stop() End patch for netif Setting $sleep_postnetif to a value of about 7 then causes the boot process to delay long enough that the network connection's stabilized enough to be usable. I chose that RC variable name as I suspected it would have a low incidence of collision in rc.conf in the future, i.e., I'm hoping this patch is safe to include in -STABLE in the event this sort of problem is widespread (and nobody comes up with a more elegant fix). Anyway, since I suspect that I might not be the only one running FreeBSD with Dell and/or Broadcom hardware, I figured it might be worth mentioning this and providing what has been (for me, anyway) a workable patch thus far. I hesitated to open a bug report on this because--well, it doesn't seem like the OS is really at fault here. :-\ Recommendations for improvement are welcome, as well as any suggestions for a less kludgy fix. I *really* dislike the idea of slowing down the boot process. :-( -- Alan Amesbury University of Minnesota --- netif.orig Thu Jun 29 17:21:10 2006 +++ netif Thu Aug 17 20:30:10 2006 @@ -71,6 +71,12 @@ # Resync ipfilter /etc/rc.d/ipfilter resync fi + + if [ ! -z "$sleep_postnetif" ]; then + echo -n "Sleeping for $sleep_postnetif seconds . . . " + sleep $sleep_postnetif + echo "Done." + fi } network_stop() ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UID/GID ranges (was Re: Required audit group is missing...)
Looks like the Handbook needs to be updated to reflect this, as audit isn't currently listed. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-uid-and-gids.html -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel INCLUDE_CONFIG_FILE workaround?
Jorge Aldana wrote: I'm on 6.1PreRelease and this works: strings -n 3 /boot/kernel/kernel | grep -v | sed -n 's/^___//p' There was a minor tweek in this line back in 5.X transition form 4.X but my script works fine for 6.X since then. Note that the problem isn't in the line you provided above that extracts the built-in configuration file. It's in the build procedure that's supposed to put the config file into the kernel in the first place. In other words, "options INCLUDE_CONFIG_FILE" doesn't include *all* the configuration data, because it doesn't include included configuration files. It's only including the very first level of nested configuration files, which is not an accurate representation of what's in the kernel. In my example, the configuration file for GENERIC should've been in there somewhere, as well as anything included by GENERIC (such as the stuff in DEFAULTS). Again, this used to work great, but appears to have been broken in favor of... usability? -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel INCLUDE_CONFIG_FILE workaround?
In the past "options INCLUDE_CONFIG_FILE" worked great. Unfortunately,
following recent changes in how kernel configuration files are parsed
(namely the changes that use the "DEFAULTS" to include the 'isa' and
'npx' devices), this feature appears to be broken. For example, here's
what appears in an almost-stock SMP kernel (on a 6.0-RELEASE-px box):
# echo "options INCLUDE_CONFIG_FILE" >>! /sys/i386/conf/SMP
# cd /usr/src
# make KERNCONF=SMP buildkernel
.
[build magic happens]
.
# strings /usr/obj/usr/src/sys/SMP/kernel | egrep "^___"
___#
___# SMP -- Generic kernel configuration file for FreeBSD/i386 SMP
___# Use this for multi-processor machines
___#
___# $FreeBSD: src/sys/i386/conf/SMP,v 1.5.6.1 2005/09/18 03:37:58
scottl Exp $
___include GENERIC
___identSMP-GENERIC
___# To make an SMP kernel, the next line is needed
___options SMP # Symmetric MultiProcessor Kernel
___options INCLUDE_CONFIG_FILE
Obviously that's not complete. There should be, at minimum, an 'npx'
and 'isa' device. ;-)
I'm not interested in rehashing earlier threads on the merits of dumbing
down or improving (depending on which side of the issue you were on)
kernel configuration through silent inclusion of devices via mechanisms
like DEFAULTS. I *am* interested seeing restored to functionality a
feature that used to work great, but is now broken.
Does anyone know if this is due to be fixed, or if there's a workaround?
(I've searched for PR's relating to "INCLUDE_CONFIG_FILE" but see
none.) One possible workaround (the one that seems to make the most
sense) is to delete DEFAULTS from /sys/`uname -m`/conf and use kernel
configs that don't use "include {otherconfig}". However, besides the
fact that DEFAULTS would come back every time /usr/src is sync'ed, I'm
unsure what the long-term ramifications are.
--
Alan Amesbury
University of Minnesota
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Getting a patch integrated into -STABLE?
Last week I sent a patch in to fix a problem with 'du' (bug report #89090). Unfortunately, I failed to indicate in the synopsis line that I'd included a patch (albeit one that should probably be looked at by someone with more clue than me). Is there a) an easy way for me to update the bug report to indicate this, and b) is there a typical time-to-fix for this sort of thing? Thanks in advance! -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange crashing/rebooting problem
Taken from the digest form, so hopefully I won't whack the formatting too badly. Dan Charrois <[EMAIL PROTECTED]> wrote: [snip] >No, I haven't been able to run diagnostics and rule out the hardware >for two reasons.. First, the server is located about an hour's drive >away, and I haven't had the chance to get to it yet. Of course, this >can be fixed. But secondly, I have no idea *how* to run Dell >Diagnostics. The "Dell PowerEdge Service and Diagnostic Utilities, >Version 4.4" CD that I have insists on being run from Windows, right >down to a setup.exe in the root directory and a ReadMe that starts >describing how to use the CD as: > > [snip] This is pretty much classic Dell. We've purchased a number of systems without operating systems on which we run FreeBSD. However, they continually operate under the assumption that we are running Windoze or Linux, and expect those to do things like BIOS updates. I'm trying to work it out with them, but it's been pretty painful so far (enough that I'm starting to look at other hardware vendors). However, in the case of the diagnostics utilities, Dell's a bit more enlightened. These links ftp://ftp.dell.com/diags/ED5061A0.tar.gz ftp://ftp.dell.com/diags/EI5061A0.ZIP ftp://ftp.dell.com/diags/MP1038A0.tar.gz ftp://ftp.us.dell.com/diags/MP1038A0.zip point at the Dell 32-bit diagnostics (first pair) and the memory diagnostics utilities (second pair). The .tar.gz files containg raw floppy images suitable for writing to floppy with a command like cat file.img | dd of=/dev/fd0 obs=18k or something like that. The .ZIP files contain what appear to be ISO images suitable for burning to a CD. Figuring that command out is left as an exercise for the reader. :-) -- Alan Amesbury University of Minnesota ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
