Re: 6.3-RC2 Available
Hello, On Mon, 31 Dec 2007 07:59:24 -0500 Ken Smith [EMAIL PROTECTED] wrote: If you would like to test doing a fresh install ISOs for each arch are available at: I just finsihed installing 6.3-RC2 on my new amd64 machine[1] (I installed from disc1).There was one small issue with sysinstall: when I got to configure networking, I had to do 'ifconfig re0 up' from the rescue shell on vty4 before the network interface would work (I use dhcp). First I did 'ifconfig re0' - it showed status as no carrier. after 'ifconfig re0 up' it showed status as active. I had the same problem when installing FreeBSD 7.0-beta4. I believe this problem is related specifically to some re0 nics, mine is a: [EMAIL PROTECTED] pciconf -lv | grep -B4 ethernet [EMAIL PROTECTED]:0:0: class=0x02 card=0x81aa1043 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet Perhaps this workaround should be mentioned in the errata if it isn't fixed before release? References: 1) http://tingox.googlepages.com/asus_m2a-vm_hdmi_freebsd -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Nagios + 6.3-RELEASE == Hung Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G'day ... Yesterday, I setup nagios to do some system monitoring ... installed the latest version from ports into a jail, so that I could easily move it around between machines as I upgrade, without losing data ... after about 30 minutes running, I get a second nagios process running (fork?) that takes up ch CPU time as is available, and just hangs there until I kill -9 it ... Figuring that it might be a problem with the jail (trying to access somethign that isn't available to the process in a jail), I moved it to the physical server level ... but, again, after ~30 minutes, its doing the same thing: # ps aux | grep nagios nagios 32065 73.2 0.1 10948 3516 ?? R11:15AM 7:40.77 /usr/local/bin/nagios -d /usr/local/etc/nagios/nagios.cfg nagios 82120 0.0 0.1 10948 3580 ?? Ss 10:47AM 0:01.18 /usr/local/bin/nagios -d /usr/local/etc/nagios/nagios.cfg So, definitely not jail related ... I've tried to do a 'truss -p 32065', it just hangs. And: ktrace -f /tmp/output -p 32065 ... produces nothing: # kdump -f /tmp/output 32065 nagios PSIG SIGKILL SIG_DFL Once I kill -9 the process, a bunch of 'check_ping' processes start up and then things go back to normal ... My last kernel / world build on that box is: Mon Nov 12 06:43:30 AST 2007 After searching the 'Net a bit, came across this thread: http://www.nagiosexchange.org/nagios-users.34.0.html?tx_maillisttofaq_pi1%5Bmode%5D=1tx_maillisttofaq_pi1%5BshowUid%5D=7694 That recommends modifying libmap.conf with: [/usr/local/bin/nagios] libpthread.so.2 libthr.so.2 libpthread.so libthr.so This seems to fix the problem on the physical server, and am currently testing it in the jail itself to make sure it fixes it there too ... Should this be something that is more prominently documented somewhere? Maybe in the port itself? azureus has similar problems that are fixed with entries in libmap.conf, so its not just a nagios issue ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHemsH4QvfyHIvDvMRApUOAKCLRDnmRba6ho4St8qZ6U19V8yJ+wCghMBp Xph3ac9d7QsMjeKBMtmgkuw= =mXxF -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios + 6.3-RELEASE == Hung Process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc G. Fournier wrote: G'day ... Yesterday, I setup nagios to do some system monitoring ... installed the latest version from ports into a jail, so that I could easily move it around between machines as I upgrade, without losing data ... after about 30 minutes running, I get a second nagios process running (fork?) that takes up ch CPU time as is available, and just hangs there until I kill -9 it ... [ .. ] After searching the 'Net a bit, came across this thread: http://www.nagiosexchange.org/nagios-users.34.0.html?tx_maillisttofaq_pi1%5Bmode%5D=1tx_maillisttofaq_pi1%5BshowUid%5D=7694 That recommends modifying libmap.conf with: [/usr/local/bin/nagios] libpthread.so.2 libthr.so.2 libpthread.so libthr.so Thanks for pointing this out. I've had similar problems with nagios but hadn't found a solution until I saw your pointer. Sadly, my expertise with both thread libraries is sufficiently lacking that I have no clue where to start looking for the cause :-( Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHenK4Qv9rrgRC1JIRAqifAKChinXb0dEPTMMlnXNYsuECLJL+vgCgvLF5 G5UYcIuvPe+UEk+qJSplrnY= =xXMF -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Installworld fails on 7.0-RC1
Hello, Hope the new year finds everybody well and not too hung over :) ... posted a bit earlier with BETA4 but just wanted to state that installworld still fails for me on 7.0-RC1 - uname -a = FreeBSD ssfbsd.securestate.org 7.0-RC1 FreeBSD 7.0RC1 #1: Tue Jan 1 10:28:19 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 The entire build output (alo script) can be found at: https://www.nan-elmoth.net/fbsd/7.0-rc1.installworld.txt Repost of current issues with 7.0: --- Issue 1: I originally built my source with WITHOUT_TCSH=YES defined but then discovered later that OpenOffice.org needs it to build. I can manually go into /usr/src/contrib/tcsh and make and make install but when I attempt to rebuild world (after removed WITHOUT_TSCH=YES from src.conf) it dies. See: https://www.nan-elmoth.net/fbsd/buildworld.tar.gz --- Issue 2: To resolve Issue 2 I simply stick WITHOUT_TCSH=YES back in my src.conf and make buildworld. Once this completes I continue to follow UPDATING and make kernel (just fine) and reboot into single user mode. Once here though make installworld FAILS. As you can see my kern.securelevel is correct and I know for a fact zfs supports symlinks so got me. To get around this I do it the old fashion way and make installkernel and then make install continuing to follow UPDATING after this (make delete-old and mergemaster -i). See: https://www.nan-elmoth.net/fbsd/buildworld_no_tsch.tar.gz https://www.nan-elmoth.net/fbsd/makeinstallworld.tar.gz Help on the above issues would be appreciated. I can provide more info as needed or troubleshoot further if you provide me exactly what you want me to do. Thanks, -Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failure of gvinum after panic
Hi all, A fix is found. This is not pretty but worked for me. I did this since the attach command of the old vinum tool is not implemented in gvinum. Which would be nice. What I did: 1) snap the vinum config to a file. 2) delete the objects. 3) saveconfig 4) create the same objects again. 5) saveconfig 6) gvinum start here is some examples: #!/bin/sh gvinum rm var gvinum rm home gvinum rm usr gvinum rm var.p0 gvinum rm home.p0 gvinum rm usr.p0 gvinum rm var.p1 gvinum rm home.p1 gvinum rm usr.p1 gvinum rm var.p0.s0 gvinum rm home.p0.s0 gvinum rm usr.p0.s0 gvinum rm var.p1.s0 gvinum rm home.p1.s0 gvinum rm usr.p1.s0 # Vinum configuration of sauron.barnabas.dk, saved at Tue Sep 18 01:11:49 2007 # Current configuration: volume usr volume home volume var plex name usr.p1 org concat vol usr plex name home.p1 org concat vol home plex name var.p1 org concat vol var plex name usr.p0 org concat vol usr plex name home.p0 org concat vol home plex name var.p0 org concat vol var sd name usr.p1.s0 drive elben len 11521427s driveoffset 4505865s plex usr.p1 plexoffset 0s sd name home.p1.s0 drive elben len 2048000s driveoffset 2457865s plex home.p1 plexoffset 0s sd name var.p1.s0 drive elben len 1228800s driveoffset 265s plex var.p1 plexoffset 0s sd name usr.p0.s0 drive donau len 11521427s driveoffset 4505865s plex usr.p0 plexoffset 0s sd name home.p0.s0 drive donau len 2048000s driveoffset 2457865s plex home.p0 plexoffset 0s sd name var.p0.s0 drive donau len 1228800s driveoffset 265s plex var.p0 plexoffset 0s regards Nikolaj Hansen On Dec 28, 2007 2:06 AM, Nikolaj Hansen [EMAIL PROTECTED] wrote: Hi all, I have some problems with my gvinum setup after the system panic'ed. Afterwards the system fails finding the plexes to the subdisks (or at least that is what I can understand after having searched the gvinum source code for the error string in the DMESG log..) The machine is an IBM Netfinity 5000 and the internal HW self tests does not find any errors in the hw. Luckily my root is not on a gvinum drive, so I am able to boot the server in single user. Does anyone have any hints as to what I can do to get gvinum to recognize the disks correctly? The system is 6.3 stable Dont worry about the media disks or anything right now - I am trying to revive the system disks for now. Thanks Nikolaj Hansen 7 drives: D elben State: up /dev/da1s1h A: 0/7825 MB (0%) D donau State: up /dev/da0s1h A: 0/7825 MB (0%) D raid5_4_ad11 State: up /dev/ad11 A: 6/194480 MB (0%) D raid5_3_ad10 State: up /dev/ad10 A: 6/194480 MB (0%) D raid5_2_ad9 State: up /dev/ad9A: 6/194480 MB (0%) D raid5_1_ad8 State: up /dev/ad8A: 6/194480 MB (0%) D spree State: up /dev/ad4a A: 3/114473 MB (0%) 6 volumes: V data01State: up Plexes: 1 Size:111 GB V usr State: up Plexes: 0 Size: 0 B V home State: up Plexes: 0 Size: 0 B V tmp State: up Plexes: 0 Size: 0 B V var State: up Plexes: 0 Size: 0 B V media State: up Plexes: 1 Size:379 GB 10 plexes: P data01.p0 C State: up Subdisks: 1 Size:111 GB P usr.p1 C State: up Subdisks: 0 Size: 0 B P home.p1 C State: up Subdisks: 0 Size: 0 B P tmp.p1 C State: up Subdisks: 0 Size: 0 B P var.p1 C State: up Subdisks: 0 Size: 0 B P usr.p0 C State: up Subdisks: 0 Size: 0 B P home.p0 C State: up Subdisks: 0 Size: 0 B P tmp.p0 C State: up Subdisks: 0 Size: 0 B P var.p0 C State: up Subdisks: 0 Size: 0 B P media.p0 R5 State: degraded Subdisks: 3 Size:379 GB 13 subdisks: S data01.p0.s0 State: up D: spreeSize:111 GB S usr.p1.s0 State: up D: elbenSize: 5625 MB S home.p1.s0State: up D: elbenSize: 1000 MB S tmp.p1.s0 State: up D: elbenSize:600 MB S var.p1.s0 State: up D: elbenSize:600 MB S usr.p0.s0 State: up D: donauSize: 5625 MB S home.p0.s0State: up D: donauSize: 1000 MB S tmp.p0.s0 State: up D: donauSize:600 MB S var.p0.s0 State: up D: donauSize:600 MB S media.p0.s0 State: up D: raid5_1_ad8 Size:189 GB S media.p0.s1 State: up D: raid5_2_ad9
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
David E. Thiel wrote: On Sun, Dec 30, 2007 at 11:12:26PM +0100, Kris Kennaway wrote: FWIW, the problem remains for me. Still terrible performance during compiles. OK. Instead of going over all of the usual questions again, can you point me to a previous mail in which you explain your observations and test results in detail? The most recent is http://marc.info/?l=freebsd-stablem=119428719505129w=2, but it started way back at http://marc.info/?l=freebsd-currentm=118998090512027w=2. I've tried a lot of stuff in between, and all I've been able to narrow it down to is that it's not a display driver issue, and that none of my swap partition is getting used, so that's not the problem. During compiles, my UP system with ULE still gets very unresponsive when compiling, sometimes taking up to 10 seconds just to draw a new terminal window. Even changing focus with the window manager can take several seconds. I'd like to provide more info, but I'm not sure what stats are useful for this particular issue. Please let me know. dmesg is at http://redundancy.redundancy.org/dmesg.txt, and kernel config is at http://redundancy.redundancy.org/DEEPTHOUGHT. Even though I'm still getting reported 80-95% memory utilization and no paging, I'm going to get an extra gig of RAM on order to see if that improves things. 2G of ram for a desktop, what's the world coming to? ;) OK, can you obtain a schedgraph trace when the problem is manifesting? See /usr/src/tools/sched/ and previous discussion in this or related threads. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP on FreeBSD 6.x and 7.0: Worth doing?
On Wed, 26 Dec 2007, Adrian Chadd wrote: On 26/12/2007, Scott Long [EMAIL PROTECTED] wrote: Yes, Squid is the ideal application for IFS. Do you still have any of your work on this, and would you be able to share it? It'd be easy to rewrite it from scratch if IFS were recovered. In fact, the whole point behind IFS, way back when, is I could layer a user-space directory hierarchy on top of a kernel provided space and then do stuff (I had a POP3 Maildir-like server written using IFS back then.) The squid code wasn't difficult at all. The biggest problem back then was rebuilding the disk index - didn't I have some code to export the inode allocation bitmap via a special file in the filesystem so I didn't have to stat() each individual inode, or didn't I end up comitting that? I'm happy to work on that later on next year. I've got enough non-disk Squid code to rewrite and optimise over the next few months; the storage side is going to have to wait a while. Do you think the IFS model offers significant benefits from an application perspective to, say, the fh*() model used by Arla? This approach originated, as far as I am aware, with the AFS implementation from CMU, in which new ioctls added by CMU allowed an give-me-a-free-inode, open-by-inode-number, and flagged inodes as in use by AFS even though they weren't hooked up to the namespace. fsck then knew to skip them, but the UFS implementation was otherwise largely unmodified. In the slightly less intrusive Arla view of the world, cache files do appear in the UFS name space, but an independent namespace is maintained by the cache manager, each with two file system names: a normal path (used to delete the cache file if required), and its NFS file handle, which can be used to open, stat, etc, the file without a normal file system namespace operation. The user application can allocate a set of inodes in some arbitrary directory tree using normal operations (ideally in advance), but when it does so also query the NFS file handles for the files using getfh(2). Then it later performs all accesses using the file handles (fhopen(2) fhstat(2), etc), unless they are invalidated due to, say, moving the cache to a new file system, in which case the handle database can be rebuilt by re-getfh(2)'ing the files using the actual file system namespace. It also passes the file handles to the kernel for use by the nnpfs synthetic file system for file access... Last time I looked closely, it seemed like the main downside to this vs. IFS was that you did in fact need real file system names to files with the fh*() approach, even though you never used them except for create/destroy. As long as the application effectively cached the inodes for reuse, rather than unlinking/creating frequently, this wasn't a problem. This did, however, mean that a whole new metadata layer didn't have to be created for an IFS, and fsck requires no modifications as compared to the AFS approach. So Squid (or whatever) would need to populate a tree and build a DB with file handles as well as real names in case the DB has to be rebuilt. You'd also have to be careful about crash-recovery state to make sure the squid DB agreed with the contents of the files when coming up after a crash, if reusing inodes rather than unlinking/reallocating them. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
7B4: kernel messages garbled
Hello, and happy New Year to all! I'm hoping to update all our servers to 7 in the near future. As such, I'm experimenting with it on one of our less prominent production servers. My procedure for it's installation and usage: download 7-CURRENT disk1 iso (B4) from nearest freebsd mirror install choice - minimum + src make config options, reboot download cvsup-no-gui pkg cvsup ports + src (above procedures performed 2007-12-30) (above procedures again performed on 2007-12-31) In every case, I wiped the hard drive, performing a fresh install. After initial install. Sending a halt, in order to reboot the system results in garbled messages to the console. Specifically, the Syncing disks... message is unintelligible. As does is line preceding it. Also. After syncing the source, I altered/renamed GENERIC and performed build/world/kernel, and install/kernel/world. During the buildworld process I recieved more warnings than I can recall seeing in previous versions = 6. ee (aee) resulted in Illegal instruction... core dumped after the build/install process. FWIW this is on an i386 2 proc MB. Given the many changes in 7, I spent more time reading the doc's and errata than I have spent in previous versions. Thank you for all your time and attention to this matter. -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7B4: kernel messages garbled
On Tue, Jan 01, 2008 at 10:09:02PM -0800, Chris H. wrote: After initial install. Sending a halt, in order to reboot the system results in garbled messages to the console. Specifically, the Syncing disks... message is unintelligible. As does is line preceding it. Does garbled mean it looks like there's two separate printf()s occuring at the same time, with characters interleaved? If so: http://jdc.parodius.com/freebsd/common_issues.txt Also, your Email address has a hash symbol in it, so I hope this mail makes it through to you... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7B4: kernel messages garbled
Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Tue, Jan 01, 2008 at 10:09:02PM -0800, Chris H. wrote: After initial install. Sending a halt, in order to reboot the system results in garbled messages to the console. Specifically, the Syncing disks... message is unintelligible. As does is line preceding it. Does garbled mean it looks like there's two separate printf()s occuring at the same time, with characters interleaved? If so: Yes. http://jdc.parodius.com/freebsd/common_issues.txt Thanks. I'll have a look. Also, your Email address has a hash symbol in it, so I hope this mail makes it through to you... Indeed. It does. It's an anti-spam device. While not perfect, it has helped. :) OH. It got through. ;) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7B4: kernel messages garbled
On Tue, Jan 01, 2008 at 10:39:16PM -0800, Jeremy Chadwick wrote: Also, your Email address has a hash symbol in it, so I hope this mail makes it through to you... Whatever dnsbl this is is incorrectly labelling our netblock as part of a DUL, which it is not. Whatever logic it's using to determine that is quite flawed. BAYAREA.NET is a co-lo provider, and we have co-lo service from them. I own the boxes in our cage. We run our own mail services. [EMAIL PROTECTED]: host mail.1command.com[75.160.109.226] said: 550 5.7.1 Mail from 72.20.106.3 REFUSED! See http://moensted.dk/spam/no-more-funn/?addr=72.20.106.3 (in reply to MAIL FROM command) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7 jerky mouse and skipping sound (still a problem -BETA3)
On Sunday 30 December 2007, Kris Kennaway wrote: Kip Macy wrote: On Nov 19, 2007 9:53 AM, Anish Mistry [EMAIL PROTECTED] wrote: On Wednesday 07 November 2007, Anish Mistry wrote: On Monday 05 November 2007, [LoN]Kamikaze wrote: Marc Fonvieille wrote: On Thu, Oct 18, 2007 at 05:53:47PM +0200, [LoN]Kamikaze wrote: Anish Mistry wrote: On Thursday 18 October 2007, Marc Fonvieille wrote: On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: I just updated to RELENG_7 from 6.2 and I'm running into some really annoying issues with jerky mouse movement and skipping sound. This seems to be similar to: Re: SCHED_4BSD in RELENG_7 disturbs workflow This happens both with 4BSD and ULE. I seems to happen when I'm compiling ports and a new cc/bzip2/sh process fires off (I'm just watching top), I'll get the skip/freezeup. [...] Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the things but it's still very annoying to use firefox during ports build. I see this lag/freeze on all boxes I use with 7.0, but it's true that with a fast machine people can ignore the problem, it's less obvious than with a 1GHz box for example. Yeah, I'm still seeing this behavior. Does anyone have suggestions on debugging? Thanks, I did post the solution in this thread. It has nothing to do with the mouse. Does the problem persist for you? It's gone for me, even with moused. Yes, the problem seems to have been fixed. I'm back to kern.hz=1000 and removed FULL_PREEMPTION. No skipping. It looks like I spoke too soon. I've just tried to compile miro and as it was compiling the boost-python dependency I noticed the problem again. Switching kern.hz=100 seems to fix the problem. Can any of the developers in this area reproduce the issue? It's pretty easy to reproduce on my 1.33Ghz Athlon. There is an ithread priority inversion bug that might be causing this. The fix for that should be going in shortly. -Kip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Anish, Can you confirm that this fix helped for you? i.e. do you still see the problem? FreeBSD 7.0-RC1 #14: Sun Dec 30 21:50:59 EST 2007 I'm still seeing this problem, but it isn't nearly as bad. I still get some jerky mouse movement, but music doesn't skip now when I'm compiling. -- Anish Mistry signature.asc Description: This is a digitally signed message part.
Re: 7B4: kernel messages garbled
Quoting Chris H. [EMAIL PROTECTED]: Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Tue, Jan 01, 2008 at 10:09:02PM -0800, Chris H. wrote: After initial install. Sending a halt, in order to reboot the system results in garbled messages to the console. Specifically, the Syncing disks... message is unintelligible. As does is line preceding it. Does garbled mean it looks like there's two separate printf()s occuring at the same time, with characters interleaved? If so: Yes. http://jdc.parodius.com/freebsd/common_issues.txt Thanks. I'll have a look. If I interpreted the thread(s) correctly, adding: option PRINTF_BUFR_SIZE 128 to my kernel source file fixes this. Correct? Also, were these threads in regard to 7? I don't see this in any of our recent 6 kernel messages. Lastly, just for the record, the only place I ever experience the garbled (overlapping) messages is to the console. dmesg seems to be clear. Thanks. Chris Also, your Email address has a hash symbol in it, so I hope this mail makes it through to you... Indeed. It does. It's an anti-spam device. While not perfect, it has helped. :) OH. It got through. ;) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
