Re: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED]
On Fri, Nov 12, 2010 at 5:24 AM, Wilkinson, Alex wrote: > > 0n Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: > > >I just committed libcompiler_rt.a to HEAD. Even though I don't expect > >serious issues -- especially not on the tier 1 architectures -- be sure > >to contact me in case something goes wrong. I hooked it up to the build > >in a separate commit, so if your system starts to act weird, just revert > >r2151 > Can you please explain to us what this actually brings to the table for > freebsd ? > I know it replaces libgcc ... but why is that such a good thing ? > > -Alex The main thing is that it's BSD-licensed instead of GPL, I believe. -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
taskqueue_create() name parameter lieftime
taskqueue_create() documentation never explicitly says this, but current taskqueue_create() implementation just stores a 'name' pointer parameter internally. Thus it depends on the 'name' having a life time encompassing that of the taskqueue. I think that alternatively we could have copied the name (or a portion of it) into an internal buffer. I don't any argument for either approach, just curious which one looks more preferable from general (FreeBSD, kernel) programming practices point of view. Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
On 08.11.2010 15:31, Adrian Chadd wrote: >> I've broken out the crunchgen logic from src/rescue/rescue into a >> share/mk file - that way it can be reused in other areas. >> >> The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff< >> http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff> >> >> This bsd.crunchgen.mk file is generic enough to use in my >> busybox-style thing as well as for src/rescue/rescue/. >> >> Comments, feedback, etc welcome! It seems this broke usage of livefs from sysinstall. sysinstall does check for /rescue/ldconfig and can not find it there. I think attached patch can fix this issue (not tested). -- WBR, Andrey V. Elsukov Index: head/usr.sbin/sysinstall/install.c === --- head/usr.sbin/sysinstall/install.c (revision 215396) +++ head/usr.sbin/sysinstall/install.c (working copy) @@ -342,7 +342,7 @@ installFixitUSB(dialogMenuItem *self) !DEVICE_INIT(mediaDevice)) { msgConfirm("No USB devices found!"); return (DITEM_FAILURE); - } else if (!file_readable("/dist/rescue/ldconfig")) { + } else if (!file_readable("/dist/rescue/rescue")) { msgConfirm("Unable to find a FreeBSD live filesystem."); return (DITEM_FAILURE); } @@ -375,7 +375,7 @@ installFixitCDROM(dialogMenuItem *self) mediaClose(); if (need_eject && msgYesNo("Unable to mount the disc. Do you want to try again?") != 0) return DITEM_FAILURE; - } else if (!file_readable("/dist/rescue/ldconfig")) { + } else if (!file_readable("/dist/rescue/rescue")) { mediaClose(); if (need_eject && msgYesNo("Unable to find a FreeBSD live filesystem. Do you want to try again?") != 0) @@ -565,7 +565,7 @@ fixit_livefs_common(dialogMenuItem *self) /* Generate a new ld.so.hints */ if (!file_readable("/var/run/ld.so.hints")) { Mkdir("/var/run"); - if (vsystem("/mnt2/rescue/ldconfig -s /mnt2/lib " + if (vsystem("/mnt2/rescue/rescue ldconfig -s /mnt2/lib " "/mnt2/usr/lib")) { msgConfirm("Warning: ldconfig could not create the " "ld.so hints file.\nDynamic executables from the " ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: taskqueue_create() name parameter lieftime
On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: > > taskqueue_create() documentation never explicitly says this, but current > taskqueue_create() implementation just stores a 'name' pointer parameter > internally. Thus it depends on the 'name' having a life time encompassing > that of > the taskqueue. > I think that alternatively we could have copied the name (or a portion of it) > into > an internal buffer. > I don't any argument for either approach, just curious which one looks more > preferable from general (FreeBSD, kernel) programming practices point of view. Hmm, in many other places we store a separate copy (e.g. all the interrupt code uses separate MAXCOMLEN char arrays to hold names). If that is easy to do, that is probably the best approach. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
On Tuesday, November 16, 2010 8:01:43 am Andrey V. Elsukov wrote: > On 08.11.2010 15:31, Adrian Chadd wrote: > >> I've broken out the crunchgen logic from src/rescue/rescue into a > >> share/mk file - that way it can be reused in other areas. > >> > >> The diff is here: http://people.freebsd.org/~adrian/crunchgen-mk.diff< > >> http://people.freebsd.org/%7Eadrian/crunchgen-mk.diff> > >> > >> This bsd.crunchgen.mk file is generic enough to use in my > >> busybox-style thing as well as for src/rescue/rescue/. > >> > >> Comments, feedback, etc welcome! > > It seems this broke usage of livefs from sysinstall. > sysinstall does check for /rescue/ldconfig and can not find it there. > I think attached patch can fix this issue (not tested). Err, are there no longer hard links to all of the frontends for a given crunch? If so, that is a problem as it will make rescue much harder to use. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: taskqueue_create() name parameter lieftime
On Tue, Nov 16, 2010 at 08:27:11AM -0500, John Baldwin wrote: > On Tuesday, November 16, 2010 7:20:47 am Andriy Gapon wrote: > > > > taskqueue_create() documentation never explicitly says this, but current > > taskqueue_create() implementation just stores a 'name' pointer parameter > > internally. Thus it depends on the 'name' having a life time encompassing > > that of > > the taskqueue. > > I think that alternatively we could have copied the name (or a portion of > > it) into > > an internal buffer. > > I don't any argument for either approach, just curious which one looks more > > preferable from general (FreeBSD, kernel) programming practices point of > > view. > > Hmm, in many other places we store a separate copy (e.g. all the interrupt > code uses separate MAXCOMLEN char arrays to hold names). If that is easy to > do, that is probably the best approach. The most friendly API would keep the name internally, but would also allow me to provide name in printf-like format, so I don't have to use sprint()/snprintf() before calling it. This unfortunatelly will change taskqueue API as name is the first argument, which makes it not worth the pain. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp3yVgaHDkwq.pgp Description: PGP signature
BSD at FOSDEM 2011 - Call for speakers
Hello all, FOSDEM 2011 will take place February 5-6, 2011 in Brussels, Belgium. We want to continue the great success of the last years and again we have a booth and a devroom. Please submit your proposal to me asap. We have a devroom on saturday this time. Talks will be 45 minutes including discussion (feel free to ask if you want to have a longer/shorter slot). Every talk is welcome, from internal hacker discussion to real-world examples and presentations about new and shiny features. The talk committee consists of Daniel Seuffert and me. Please submit your proposals to: mar...@nuenneri.ch and include the following information: * Your name * The title of your talk (please be descriptive, as titles will be listed with ~250 from other projects) * A short abstract of one to two paragraphs * A short biography introducing yourself * Links to related websites/blogs etc. The deadline for submissions is 20th December 2010. The proposals will be considered by committee. If your proposal has been accepted, you will be informed by email within one week of the submission deadline. Best regards, Marius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
On 16.11.2010 16:29, John Baldwin wrote: > Err, are there no longer hard links to all of the frontends for a given > crunch? If so, that is a problem as it will make rescue much harder to use. Yes, probably this patch is not needed and it should be fixed somewhere in makefiles. But currently rescue does not have any hardlinks: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ And what is was before: http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
aperf/mperf
Many modern processors provide APERF and MPERF MSRs which allow to easily and reliable calculate average CPU performance level over some interval of time. This also allows to notice things like performance boost, which is generally hidden from software. What would be a proper place to add code that would measure APERF/MPERF ratio? When should trigger such a measurement and over what interval? Ideas? Thanks a lot! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Does FreeBSD with TEKEN_UTF8 support displaying CKJ characters?
I wonder whether CKJ characters would be displayed out of box if TEKEN_UTF8 was set in the kernel. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: > On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >> On 16.11.2010 16:29, John Baldwin wrote: >> > Err, are there no longer hard links to all of the frontends for a given >> > crunch? If so, that is a problem as it will make rescue much harder to >> > use. >> >> Yes, probably this patch is not needed and it should be fixed somewhere in >> makefiles. But currently rescue does not have any hardlinks: >> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ >> >> And what is was before: >> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ > > That definitely needs to be fixed. The .mk file wasn't being installed. Could someone please test this patch for validity and commit it? More importantly, why didn't the above build process, or tinderbox fail properly with this change? Thanks, -Garrett Index: share/mk/Makefile === --- share/mk/Makefile (revision 215333) +++ share/mk/Makefile (working copy) @@ -3,7 +3,8 @@ FILES= bsd.README FILES+= bsd.arch.inc.mk -FILES+= bsd.compat.mk bsd.cpu.mk bsd.dep.mk bsd.doc.mk bsd.dtrace.mk +FILES+= bsd.compat.mk bsd.crunchgen.mk bsd.cpu.mk +FILES+= bsd.dep.mk bsd.doc.mk bsd.dtrace.mk FILES+= bsd.endian.mk FILES+= bsd.files.mk bsd.incs.mk bsd.info.mk bsd.init.mk FILES+= bsd.kmod.mk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wrote: > On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>> On 16.11.2010 16:29, John Baldwin wrote: >>> > Err, are there no longer hard links to all of the frontends for a given >>> > crunch? If so, that is a problem as it will make rescue much harder to >>> > use. >>> >>> Yes, probably this patch is not needed and it should be fixed somewhere in >>> makefiles. But currently rescue does not have any hardlinks: >>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ >>> >>> And what is was before: >>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ >> >> That definitely needs to be fixed. > > The .mk file wasn't being installed. Could someone please test > this patch for validity and commit it? > More importantly, why didn't the above build process, or tinderbox > fail properly with this change? Ouch. I can definitely still see the other problem: # make install install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script The second attached patch (not a superset of the first) what unbreaks it: # make -C rescue/rescue/ install install -s -o root -g wheel -m 555 rescue /rescue install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script /rescue/cat -> /rescue/rescue /rescue/chflags -> /rescue/rescue /rescue/chio -> /rescue/rescue /rescue/chmod -> /rescue/rescue /rescue/cp -> /rescue/rescue /rescue/date -> /rescue/rescue /rescue/dd -> /rescue/rescue /rescue/df -> /rescue/rescue /rescue/echo -> /rescue/rescue /rescue/ed -> /rescue/rescue /rescue/red -> /rescue/rescue /rescue/expr -> /rescue/rescue /rescue/getfacl -> /rescue/rescue /rescue/hostname -> /rescue/rescue /rescue/kenv -> /rescue/rescue /rescue/kill -> /rescue/rescue /rescue/ln -> /rescue/rescue /rescue/link -> /rescue/rescue /rescue/ls -> /rescue/rescue /rescue/mkdir -> /rescue/rescue /rescue/mv -> /rescue/rescue /rescue/pkill -> /rescue/rescue /rescue/pgrep -> /rescue/rescue /rescue/ps -> /rescue/rescue /rescue/pwd -> /rescue/rescue /rescue/realpath -> /rescue/rescue /rescue/rm -> /rescue/rescue /rescue/unlink -> /rescue/rescue /rescue/rmdir -> /rescue/rescue /rescue/setfacl -> /rescue/rescue /rescue/sh -> /rescue/rescue /rescue/stty -> /rescue/rescue /rescue/sync -> /rescue/rescue /rescue/test -> /rescue/rescue /rescue/[ -> /rescue/rescue /rescue/csh -> /rescue/rescue /rescue/tcsh -> /rescue/rescue /rescue/atacontrol -> /rescue/rescue /rescue/badsect -> /rescue/rescue /rescue/camcontrol -> /rescue/rescue /rescue/ccdconfig -> /rescue/rescue /rescue/clri -> /rescue/rescue /rescue/devfs -> /rescue/rescue /rescue/dmesg -> /rescue/rescue /rescue/dump -> /rescue/rescue /rescue/rdump -> /rescue/rescue /rescue/dumpfs -> /rescue/rescue /rescue/dumpon -> /rescue/rescue /rescue/fsck -> /rescue/rescue /rescue/fsck_ffs -> /rescue/rescue /rescue/fsck_4.2bsd -> /rescue/rescue /rescue/fsck_ufs -> /rescue/rescue /rescue/fsck_msdosfs -> /rescue/rescue /rescue/fsdb -> /rescue/rescue /rescue/fsirand -> /rescue/rescue /rescue/gbde -> /rescue/rescue /rescue/geom -> /rescue/rescue /rescue/glabel -> /rescue/rescue /rescue/gpart -> /rescue/rescue /rescue/ifconfig -> /rescue/rescue /rescue/init -> /rescue/rescue /rescue/kldconfig -> /rescue/rescue /rescue/kldload -> /rescue/rescue /rescue/kldstat -> /rescue/rescue /rescue/kldunload -> /rescue/rescue /rescue/ldconfig -> /rescue/rescue /rescue/md5 -> /rescue/rescue /rescue/mdconfig -> /rescue/rescue /rescue/mdmfs -> /rescue/rescue /rescue/mknod -> /rescue/rescue /rescue/mount -> /rescue/rescue /rescue/mount_cd9660 -> /rescue/rescue /rescue/mount_msdosfs -> /rescue/rescue /rescue/mount_nfs -> /rescue/rescue /rescue/mount_ntfs -> /rescue/rescue /rescue/mount_nullfs -> /rescue/rescue /rescue/mount_udf -> /rescue/rescue /rescue/mount_unionfs -> /rescue/rescue /rescue/newfs -> /rescue/rescue /rescue/newfs_msdos -> /rescue/rescue /rescue/nos-tun -> /rescue/rescue /rescue/ping -> /rescue/rescue /rescue/reboot -> /rescue/rescue /rescue/fastboot -> /rescue/rescue /rescue/halt -> /rescue/rescue /rescue/fasthalt -> /rescue/rescue /rescue/restore -> /rescue/rescue /rescue/rrestore -> /rescue/rescue /rescue/rcorder -> /rescue/rescue /rescue/route -> /rescue/rescue /rescue/routed -&
make installworld fails
Trying to installworld on 9-current AMD64, and it fails with: install -o root -g wheel -m 444 /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- r usage:tzsetup [-ns] ***Error code 1 Stop in /usr/src/share/zoneinfo. (above was transcribed from console) Anyone else seeing this? Is there a fix Csup from last night. Tia ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On Tue, 16 Nov 2010, AN wrote: Trying to installworld on 9-current AMD64, and it fails with: install -o root -g wheel -m 444 /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- r usage:tzsetup [-ns] ***Error code 1 Stop in /usr/src/share/zoneinfo. (above was transcribed from console) Anyone else seeing this? Is there a fix Csup from last night. We have seen similar tzsetup errors in installworld in the past. Is your build environment unusual in any way (cross-building, DESTDIR set, etc.)? -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On Tue, 16 Nov 2010, Benjamin Kaduk wrote: On Tue, 16 Nov 2010, AN wrote: Trying to installworld on 9-current AMD64, and it fails with: install -o root -g wheel -m 444 /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- r usage:tzsetup [-ns] ***Error code 1 Stop in /usr/src/share/zoneinfo. (above was transcribed from console) Anyone else seeing this? Is there a fix Csup from last night. We have seen similar tzsetup errors in installworld in the past. Is your build environment unusual in any way (cross-building, DESTDIR set, etc.)? -Ben Kaduk Nothing unusual, standard plain install. I used an image from http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. Used standard procedure: csup make buildworld make buildkernel make install kernel make installworld (single user mode) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On Tue, 16 Nov 2010, AN wrote: On Tue, 16 Nov 2010, Benjamin Kaduk wrote: On Tue, 16 Nov 2010, AN wrote: Trying to installworld on 9-current AMD64, and it fails with: install -o root -g wheel -m 444 /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- r usage:tzsetup [-ns] ***Error code 1 Stop in /usr/src/share/zoneinfo. (above was transcribed from console) Anyone else seeing this? Is there a fix Csup from last night. We have seen similar tzsetup errors in installworld in the past. Is your build environment unusual in any way (cross-building, DESTDIR set, etc.)? -Ben Kaduk Nothing unusual, standard plain install. I used an image from http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. Used standard procedure: csup Hmm, what server do you csup from? My tzsetup has this usage: usage: tzsetup [-nrs] [zoneinfo file] The one quoted above looks to be rather old. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On Tue, Nov 16, 2010 at 10:39 AM, AN wrote: > > > On Tue, 16 Nov 2010, Benjamin Kaduk wrote: > >> On Tue, 16 Nov 2010, AN wrote: >> >>> >>> Trying to installworld on 9-current AMD64, and it fails with: >>> >>> install -o root -g wheel -m 444 >>> /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ >>> Updating /etc/localtime >>> tzsetup: illegal option -- r >>> usage:tzsetup [-ns] >>> ***Error code 1 >>> >>> Stop in /usr/src/share/zoneinfo. >>> >>> (above was transcribed from console) >>> >>> Anyone else seeing this? Is there a fix >>> >>> Csup from last night. >> >> We have seen similar tzsetup errors in installworld in the past. Is your >> build environment unusual in any way (cross-building, DESTDIR set, etc.)? >> >> -Ben Kaduk >> > > > Nothing unusual, standard plain install. I used an image from > http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. > > Used standard procedure: > > csup > make buildworld > make buildkernel > make install kernel > make installworld (single user mode) (CCing edwin@) There might be a handful of other apps that don't work when upgrading from major version to major version (config; the way to work around this particular issue is to execute: cd /usr/src make -C usr.sbin/tzsetup all install This should be fixed in the share/zoneinfo Makefile (but might be tricky with cross-builds); producing an UPDATING entry to document the breakage might be good enough. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Call for Tests] PAT issue on Apple hardware
Le Mon, 15 Nov 2010 20:36:42 -0500, Jung-uk Kim a écrit : > Often times I hear complaints like "my Mac hangs after upgrading to > 8.1" or "snapshot CD hangs on my brand new Mac". I know some of > these complaints started happening when we switched to new PAT > layout. It is so puzzling because it never happened on non-Apple > hardware, AFAIK. I really like to fix this problem but I cannot > afford a Mac. :-P Thanks. > If you are one of those lucky people, please test the attached patch > and report your hardware model and any improvement or regression. Shall we test if the model is not listed in the patch and already works fine? (I'm using a MacBookPro3,1 on FreeBSD 8.1) if (strncmp(sysenv, "MacBook5,1", 10) strncmp(sysenv, "MacBookPro5,5", strncmp(sysenv, "Macmini3,1", 10) strncmp(sysenv, "iMac9,1", 7) == 0) Regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On Tue, 16 Nov 2010, Garrett Cooper wrote: On Tue, Nov 16, 2010 at 10:39 AM, AN wrote: On Tue, 16 Nov 2010, Benjamin Kaduk wrote: On Tue, 16 Nov 2010, AN wrote: Trying to installworld on 9-current AMD64, and it fails with: install -o root -g wheel -m 444 /usr/src/share/info/../../contrib/tzdata//zone.tab /usr/share/zoneinfo/ Updating /etc/localtime tzsetup: illegal option -- r usage:tzsetup [-ns] ***Error code 1 Stop in /usr/src/share/zoneinfo. (above was transcribed from console) Anyone else seeing this? Is there a fix Csup from last night. We have seen similar tzsetup errors in installworld in the past. Is your build environment unusual in any way (cross-building, DESTDIR set, etc.)? -Ben Kaduk Nothing unusual, standard plain install. I used an image from http://pub.allbsd.org/FreeBSD-snapshots/ downloaded about 2 or 3 days ago. Used standard procedure: csup make buildworld make buildkernel make install kernel make installworld (single user mode) (CCing edwin@) There might be a handful of other apps that don't work when upgrading from major version to major version (config; the way to work around this particular issue is to execute: cd /usr/src make -C usr.sbin/tzsetup all install This should be fixed in the share/zoneinfo Makefile (but might be tricky with cross-builds); producing an UPDATING entry to document the breakage might be good enough. Thanks, -Garrett Hi Garrett: After executing: cd /usr/src make -C usr.sbin/tzsetup all install make installworld completed sucessfully Machine is back, and seems to be fine. Thanks for your fast and helpful reply. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make installworld fails
On Tue, 16 Nov 2010, Garrett Cooper wrote: There might be a handful of other apps that don't work when upgrading from major version to major version (config; the way to work around this I thought we only supported major version upgrades by first upgrading from RELENG_X_Y to RELENG_X and then to RELENG_{X+1}_Z, but I didn't find documentation for that in a quick check. This should be fixed in the share/zoneinfo Makefile (but might be tricky with cross-builds); producing an UPDATING entry to document the breakage might be good enough. I had actually thought we fixed it a year ago when I ran into issues with r198351, but my memory is a bit hazy on what actually happened. -Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Call for Tests] PAT issue on Apple hardware
On Tuesday 16 November 2010 02:33 pm, Patrick Lamaiziere wrote: > Le Mon, 15 Nov 2010 20:36:42 -0500, > > Jung-uk Kim a �crit : > > Often times I hear complaints like "my Mac hangs after upgrading > > to 8.1" or "snapshot CD hangs on my brand new Mac". I know some > > of these complaints started happening when we switched to new PAT > > layout. It is so puzzling because it never happened on non-Apple > > hardware, AFAIK. I really like to fix this problem but I cannot > > afford a Mac. :-P > > Thanks. > > > If you are one of those lucky people, please test the attached > > patch and report your hardware model and any improvement or > > regression. > > Shall we test if the model is not listed in the patch and already > works fine? (I'm using a MacBookPro3,1 on FreeBSD 8.1) > > if (strncmp(sysenv, "MacBook5,1", 10) > strncmp(sysenv, "MacBookPro5,5", > strncmp(sysenv, "Macmini3,1", 10) > strncmp(sysenv, "iMac9,1", 7) == 0) There's no need if it already works fine. It seems the new PAT layout only broke recent models with NVidia chipset. Also, this patch won't apply to stable pmap.c. Actually, I am working on more complex version now. When I am done, I'll make patches for both branches. Thanks, Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Call for Tests] PAT issue on Apple hardware
On Monday 15 November 2010 08:36 pm, Jung-uk Kim wrote: > Often times I hear complaints like "my Mac hangs after upgrading to > 8.1" or "snapshot CD hangs on my brand new Mac". I know some of > these complaints started happening when we switched to new PAT > layout. It is so puzzling because it never happened on non-Apple > hardware, AFAIK. I really like to fix this problem but I cannot > afford a Mac. :-P > > If you are one of those lucky people, please test the attached > patch and report your hardware model and any improvement or > regression. > > Also, I added a new tunable "vm.pmap.pat_works" so that you can > turn it off from loader (i.e., "set vm.pmap.pat_works=0") and > restore old behaviour without recompiling a new kernel. I revised this patch to make it more robust. http://people.freebsd.org/~jkim/pat-current.diff Also, I prepared a patch for stable/8. If you have recent Apple hardware and it hangs with 8.1 or stable/8, please test this patch. http://people.freebsd.org/~jkim/pat-stable.diff Thanks! Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: breaking the crunchgen logic into a share/mk file
Oops, I can't believe I committed the wrong version of this damned thing. I'll go and commit that particular un-braindamage. in a sec. Sorry everyone. Adrian On 17 November 2010 02:04, Garrett Cooper wrote: > On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wrote: >> On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >>> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>>> On 16.11.2010 16:29, John Baldwin wrote: >>>> > Err, are there no longer hard links to all of the frontends for a given >>>> > crunch? If so, that is a problem as it will make rescue much harder to >>>> > use. >>>> >>>> Yes, probably this patch is not needed and it should be fixed somewhere in >>>> makefiles. But currently rescue does not have any hardlinks: >>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ >>>> >>>> And what is was before: >>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ >>> >>> That definitely needs to be fixed. >> >> The .mk file wasn't being installed. Could someone please test >> this patch for validity and commit it? >> More importantly, why didn't the above build process, or tinderbox >> fail properly with this change? > > Ouch. I can definitely still see the other problem: > > # make install > install -s -o root -g wheel -m 555 rescue /rescue > install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot > install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script > > The second attached patch (not a superset of the first) what unbreaks it: > > # make -C rescue/rescue/ install > install -s -o root -g wheel -m 555 rescue /rescue > install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot > install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script > /rescue/cat -> /rescue/rescue > /rescue/chflags -> /rescue/rescue > /rescue/chio -> /rescue/rescue > /rescue/chmod -> /rescue/rescue > /rescue/cp -> /rescue/rescue > /rescue/date -> /rescue/rescue > /rescue/dd -> /rescue/rescue > /rescue/df -> /rescue/rescue > /rescue/echo -> /rescue/rescue > /rescue/ed -> /rescue/rescue > /rescue/red -> /rescue/rescue > /rescue/expr -> /rescue/rescue > /rescue/getfacl -> /rescue/rescue > /rescue/hostname -> /rescue/rescue > /rescue/kenv -> /rescue/rescue > /rescue/kill -> /rescue/rescue > /rescue/ln -> /rescue/rescue > /rescue/link -> /rescue/rescue > /rescue/ls -> /rescue/rescue > /rescue/mkdir -> /rescue/rescue > /rescue/mv -> /rescue/rescue > /rescue/pkill -> /rescue/rescue > /rescue/pgrep -> /rescue/rescue > /rescue/ps -> /rescue/rescue > /rescue/pwd -> /rescue/rescue > /rescue/realpath -> /rescue/rescue > /rescue/rm -> /rescue/rescue > /rescue/unlink -> /rescue/rescue > /rescue/rmdir -> /rescue/rescue > /rescue/setfacl -> /rescue/rescue > /rescue/sh -> /rescue/rescue > /rescue/stty -> /rescue/rescue > /rescue/sync -> /rescue/rescue > /rescue/test -> /rescue/rescue > /rescue/[ -> /rescue/rescue > /rescue/csh -> /rescue/rescue > /rescue/tcsh -> /rescue/rescue > /rescue/atacontrol -> /rescue/rescue > /rescue/badsect -> /rescue/rescue > /rescue/camcontrol -> /rescue/rescue > /rescue/ccdconfig -> /rescue/rescue > /rescue/clri -> /rescue/rescue > /rescue/devfs -> /rescue/rescue > /rescue/dmesg -> /rescue/rescue > /rescue/dump -> /rescue/rescue > /rescue/rdump -> /rescue/rescue > /rescue/dumpfs -> /rescue/rescue > /rescue/dumpon -> /rescue/rescue > /rescue/fsck -> /rescue/rescue > /rescue/fsck_ffs -> /rescue/rescue > /rescue/fsck_4.2bsd -> /rescue/rescue > /rescue/fsck_ufs -> /rescue/rescue > /rescue/fsck_msdosfs -> /rescue/rescue > /rescue/fsdb -> /rescue/rescue > /rescue/fsirand -> /rescue/rescue > /rescue/gbde -> /rescue/rescue > /rescue/geom -> /rescue/rescue > /rescue/glabel -> /rescue/rescue > /rescue/gpart -> /rescue/rescue > /rescue/ifconfig -> /rescue/rescue > /rescue/init -> /rescue/rescue > /rescue/kldconfig -> /rescue/rescue > /rescue/kldload -> /rescue/rescue > /rescue/kldstat -> /rescue/rescue > /rescue/kldunload -> /rescue/rescue > /rescue/ldconfig -> /rescue/rescue > /rescue/md5 -> /rescue/rescue > /rescue/mdconfig -> /rescue/rescue > /rescue/mdmfs -> /rescue/rescue > /rescue/mknod -> /rescue/rescue > /rescue/mount -> /rescue/rescue > /rescue/
Re: breaking the crunchgen logic into a share/mk file
I've just committed: * stuff to re-enable the link production * installing bsd.crunchgen.mk Thanks, Adrian On 17 November 2010 06:19, Adrian Chadd wrote: > Oops, I can't believe I committed the wrong version of this damned thing. > > I'll go and commit that particular un-braindamage. in a sec. > > Sorry everyone. > > > > Adrian > > On 17 November 2010 02:04, Garrett Cooper wrote: >> On Tue, Nov 16, 2010 at 9:52 AM, Garrett Cooper wrote: >>> On Tue, Nov 16, 2010 at 6:12 AM, John Baldwin wrote: >>>> On Tuesday, November 16, 2010 8:45:08 am Andrey V. Elsukov wrote: >>>>> On 16.11.2010 16:29, John Baldwin wrote: >>>>> > Err, are there no longer hard links to all of the frontends for a given >>>>> > crunch? If so, that is a problem as it will make rescue much harder to >>>>> > use. >>>>> >>>>> Yes, probably this patch is not needed and it should be fixed somewhere in >>>>> makefiles. But currently rescue does not have any hardlinks: >>>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101116-JPSNAP/cdrom/livefs/rescue/ >>>>> >>>>> And what is was before: >>>>> http://pub.allbsd.org/FreeBSD-snapshots/i386-i386/9.0-HEAD-20101112-JPSNAP/cdrom/livefs/rescue/ >>>> >>>> That definitely needs to be fixed. >>> >>> The .mk file wasn't being installed. Could someone please test >>> this patch for validity and commit it? >>> More importantly, why didn't the above build process, or tinderbox >>> fail properly with this change? >> >> Ouch. I can definitely still see the other problem: >> >> # make install >> install -s -o root -g wheel -m 555 rescue /rescue >> install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot >> install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script >> >> The second attached patch (not a superset of the first) what unbreaks it: >> >> # make -C rescue/rescue/ install >> install -s -o root -g wheel -m 555 rescue /rescue >> install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot >> install -o root -g wheel -m 555 dhclient_FIXED /rescue/dhclient-script >> /rescue/cat -> /rescue/rescue >> /rescue/chflags -> /rescue/rescue >> /rescue/chio -> /rescue/rescue >> /rescue/chmod -> /rescue/rescue >> /rescue/cp -> /rescue/rescue >> /rescue/date -> /rescue/rescue >> /rescue/dd -> /rescue/rescue >> /rescue/df -> /rescue/rescue >> /rescue/echo -> /rescue/rescue >> /rescue/ed -> /rescue/rescue >> /rescue/red -> /rescue/rescue >> /rescue/expr -> /rescue/rescue >> /rescue/getfacl -> /rescue/rescue >> /rescue/hostname -> /rescue/rescue >> /rescue/kenv -> /rescue/rescue >> /rescue/kill -> /rescue/rescue >> /rescue/ln -> /rescue/rescue >> /rescue/link -> /rescue/rescue >> /rescue/ls -> /rescue/rescue >> /rescue/mkdir -> /rescue/rescue >> /rescue/mv -> /rescue/rescue >> /rescue/pkill -> /rescue/rescue >> /rescue/pgrep -> /rescue/rescue >> /rescue/ps -> /rescue/rescue >> /rescue/pwd -> /rescue/rescue >> /rescue/realpath -> /rescue/rescue >> /rescue/rm -> /rescue/rescue >> /rescue/unlink -> /rescue/rescue >> /rescue/rmdir -> /rescue/rescue >> /rescue/setfacl -> /rescue/rescue >> /rescue/sh -> /rescue/rescue >> /rescue/stty -> /rescue/rescue >> /rescue/sync -> /rescue/rescue >> /rescue/test -> /rescue/rescue >> /rescue/[ -> /rescue/rescue >> /rescue/csh -> /rescue/rescue >> /rescue/tcsh -> /rescue/rescue >> /rescue/atacontrol -> /rescue/rescue >> /rescue/badsect -> /rescue/rescue >> /rescue/camcontrol -> /rescue/rescue >> /rescue/ccdconfig -> /rescue/rescue >> /rescue/clri -> /rescue/rescue >> /rescue/devfs -> /rescue/rescue >> /rescue/dmesg -> /rescue/rescue >> /rescue/dump -> /rescue/rescue >> /rescue/rdump -> /rescue/rescue >> /rescue/dumpfs -> /rescue/rescue >> /rescue/dumpon -> /rescue/rescue >> /rescue/fsck -> /rescue/rescue >> /rescue/fsck_ffs -> /rescue/rescue >> /rescue/fsck_4.2bsd -> /rescue/rescue >> /rescue/fsck_ufs -> /rescue/rescue >> /rescue/fsck_msdosfs -> /rescue/rescue >> /rescue/fsdb -> /rescue/rescue >> /rescue/fsirand -> /rescue/rescue >> /rescue/gbde -> /rescue/rescue >> /rescue/geom -> /rescue/rescue >> /rescue/g
Re: www/chromium crashing whole system
On Tue Nov 16 10, Marcin Wisnicki wrote: > On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > > > On 11/13/10 2:08 PM, Robert Watson wrote: > >> > >> If regular crashdumps appear unreliable, try setting up a textdump with > >> an automatic reboot, that might provde more reliable (small chance, but > >> it could). > > > > we did have some people working on an ethernet version of the > > dcons/remote debugging stuff > > I guess it only supports a small subset of ethernet chips though.. > > Anyone know the status of that work? > > > > I don't know about ethernet dump but how about simply dumping memory after > reset ? > > See: > - http://en.wikipedia.org/wiki/Cold_boot_attack > - http://citp.princeton.edu/memory/ > - http://www.mcgrewsecurity.com/tools/msramdmp/ > > Last link contains a tool to dump memory to usb disk after reset. If kgdb > works with raw memory dumps, it may already work. > > This has the potential to solve all tricky debugging cases without needing > firewire. WOW! this is the first time i hear of such a concept. it seems great for people like me who are desktop users without any serial/firewire consoles or any additional debugging hardware. is there a way of trying this out somehow? personally i wouldn't need the memory dump to work in partitions. i'd simply blug in a blank usb stick and have the memory dump dd'ed onto it. i think adding partition awareness is not really needed. cheers. alex > > A boot time kernel option to avoid certain memory areas which are > overwritten during boot by bios and ram dumping tool could be useful or > maybe necessary. > > It can even be completely automated, eg. if kernel would maintain some > kind of "RAM dirty" flag, then during boot something (loader or kernel) > would check for it and perform dump if needed. > > Another idea worth implementing or at least adding to project ideas list > is to implement everything that is currently possible with serial (boot0, > loader, kernel console, ddb) over EHCI debug port: > - http://www.coreboot.org/EHCI_Debug_Port > -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: The path is now set for "busybox", FreeBSD style
Nope. it's easy. That's why I've done it. Adrian On 15 November 2010 01:43, John Hein wrote: > Adrian Chadd wrote at 11:40 +0800 on Nov 14, 2010: > > I've committed the below changes to -HEAD. You can now create and build > your > > own busybox style binary system, completely cross-compiled within the > > existing Make framework. It isn't as impressive as it sounds though - a > lot > > of the framework is already there from just building crunchgen'ed > > rescue/sysinstall binaries. > > > > There's a few things which should be done. Specifically, being able to > build > > an alternative set of libraries before building the crunchgen target. > The > > base crosscompile system may include support for PAM, Kerberos, ATM/IPX, > etc > > but you may not want your crunch'ed image to have them. To do this right > > now, you have to disable these features in the main build. That may be > OK > > for some. > > > > But just to stress it - I've got a couple of access point images at home > > running a crunchgen'ed environment under MIPS and besides the obvious > binary > > bloat, it works perfectly well. Besides a cut-down startup framework, > the > > image cross-builds entirely from the base FreeBSD source tree. > > > > Let me know if you'd like to give it a shot and I'll put my "bsdbox" > > Makefile scripts online to try. > > That's great. > I assume it be not be hard for someone to take your scripts as a > starting point and create a sysutils/bsdbox akin to sysutils/busybox? > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: kldunload(8) returns 0, although it fail
On Wed Nov 10 10, John Baldwin wrote: > On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > > On Wed Nov 10 10, Alexander Best wrote: > > > On Tue Nov 9 10, John Baldwin wrote: > > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > > hi there, > > > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could > > > > > > > help me with it. > > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the > > > > > > > second attempt > > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because > > > > > > > both modules > > > > > > > have dependencies. however it should fail with the first attempt. > > > > > > > right now > > > > > > > kldunloadf() returns zero, whereas it should actually return > > > > > > > EBUSY (just like > > > > > > > the second attempt). > > > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' > > > > > > > attempt and one > > > > > > > for the second. as you can see the problem is that for some > > > > > > > reason kldunloadf() > > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit > > > > > > kldload) > > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) > > > > > > then this > > > > > > is expected behavior. What your kldunload has done is to remove > > > > > > the manual > > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this > > > > > > changes is what > > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko > > > > > > now, then > > > > > > netgraph.ko will also be unloaded when its last reference drops (in > > > > > > this case > > > > > > it looks like you actually have two ng_*.ko objects loaded, so you > > > > > > would have > > > > > > to unload both of them, but I will assume a single ng_foo.ko to > > > > > > make the > > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' > > > > > > but had > > > > > > done 'kldunload ng_foo.ko', then the manual reference would have > > > > > > kept netgraph.ko > > > > > > loaded. > > > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it > > > > > > auto-loads bar.ko > > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both > > > > > > foo.ko and bar.ko. > > > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > > > Id Refs AddressSize Name > > > > > 1 37 0x8010 a2ddb8 kernel > > > > > 21 0x80b2e000 295e8snd_hda.ko > > > > > 31 0x80b58000 85110sound.ko > > > > > 41 0x80bde000 cf79e0 nvidia.ko > > > > > 55 0x818d6000 418c0linux.ko > > > > > 61 0x81918000 80e8 ng_ubt.ko > > > > > 72 0x81921000 fa78 ng_hci.ko > > > > > 82 0x81931000 2bd0 ng_bluetooth.ko > > > > > 93 0x81934000 15e68netgraph.ko > > > > > 101 0x81a12000 3efb linprocfs.ko > > > > > 113 0x81a16000 4698 pseudofs.ko > > > > > 121 0x81a1b000 31b3 procfs.ko > > > > > 131 0x81a1f000 a37 linsysfs.ko > > > > > 141 0x81a2 6f4 rtc.ko > > > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i > > > > > think > > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > > > i think i understand the logic, however the current behavior does not > > > > > confirm > > > > > to the description in kldunload(2). > > > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload > > > > ng_ubt.ko > > > > after boot? > > > > just tested and the behavior is *not* the same. when i do kldload ng_ubt > > after > > boot everything seems fine. netgraph gets loaded and has a REF count of 2. > > if i > > try doing `kldunload netgraph` i get EBUSY the first time i run that > > command. > > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count > > of > > 3 for netgraph.ko and i get the behavior i described beforehand. > > Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with > manually > loading any other netgraph modules so that nothing is loaded magically as a > dependency) and see what behavior that gives you. sorry it took me a while to check this out. i did some more research and it seem
Re: www/chromium crashing whole system
On Tue Nov 16 10, Alexander Best wrote: > On Tue Nov 16 10, Marcin Wisnicki wrote: > > On Sat, 13 Nov 2010 14:17:35 -0800, Julian Elischer wrote: > > > > > On 11/13/10 2:08 PM, Robert Watson wrote: > > >> > > >> If regular crashdumps appear unreliable, try setting up a textdump with > > >> an automatic reboot, that might provde more reliable (small chance, but > > >> it could). > > > > > > we did have some people working on an ethernet version of the > > > dcons/remote debugging stuff > > > I guess it only supports a small subset of ethernet chips though.. > > > Anyone know the status of that work? > > > > > > > I don't know about ethernet dump but how about simply dumping memory after > > reset ? > > > > See: > > - http://en.wikipedia.org/wiki/Cold_boot_attack > > - http://citp.princeton.edu/memory/ > > - http://www.mcgrewsecurity.com/tools/msramdmp/ > > > > Last link contains a tool to dump memory to usb disk after reset. If kgdb > > works with raw memory dumps, it may already work. > > > > This has the potential to solve all tricky debugging cases without needing > > firewire. > > WOW! this is the first time i hear of such a concept. it seems great for > people like me who are desktop users without any serial/firewire consoles or > any additional debugging hardware. > > is there a way of trying this out somehow? personally i wouldn't need the > memory dump to work in partitions. i'd simply blug in a blank usb stick and > have the memory dump dd'ed onto it. i think adding partition awareness is not > really needed. ok i read some more details and i think i figured out how to dump the memory to a usb stick. question still remains however: will i be able to use that memory snapshot in kgdb or gdb? cheers. alex > > cheers. > alex > > > > > A boot time kernel option to avoid certain memory areas which are > > overwritten during boot by bios and ram dumping tool could be useful or > > maybe necessary. > > > > It can even be completely automated, eg. if kernel would maintain some > > kind of "RAM dirty" flag, then during boot something (loader or kernel) > > would check for it and perform dump if needed. > > > > Another idea worth implementing or at least adding to project ideas list > > is to implement everything that is currently possible with serial (boot0, > > loader, kernel console, ddb) over EHCI debug port: > > - http://www.coreboot.org/EHCI_Debug_Port > > > > -- > a13x -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
VIMAGE: Freed UMA keg was not empty
Hello, We are using FreeBSD + VIMAGE at work, and we have seen an annoying problem : there seems to be a memory leak in the kernel, which eventually causes a panic. (yes, we have seen the following message : "WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.") Configuring a network interface in a jail with vnet enabled, then removing that jail causes these messages. In dmesg: [...] Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled (with attached VIMAGE kernel config file). The following commands reproduce the bug: jail -l -u root -c path=/ name=foo persist vnet && jexec foo ifconfig lo0 127.0.0.1/8 && jail -r foo Running it too many times exhausts kernel memory and crashes the machine. The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN -head. Attachments: dmesg log and kernel config. cheers Thierry Herbelot # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.519.2.10.2.1 2010/06/14 02:09:06 kensmith Exp $ cpu I486_CPU cpu I586_CPU cpu I686_CPU ident VIMAGE options VIMAGE # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # N
Re: VIMAGE: Freed UMA keg was not empty
On Wed, 17 Nov 2010, Thierry Herbelot wrote: Hi, first of all freebsd-virtualization@ is the better list for this; Cc:ed. We are using FreeBSD + VIMAGE at work, and we have seen an annoying problem : there seems to be a memory leak in the kernel, which eventually causes a panic. (yes, we have seen the following message : "WARNING: VIMAGE (virtualized network stack) is a highly experimental feature.") Configuring a network interface in a jail with vnet enabled, then removing that jail causes these messages. In dmesg: [...] Freed UMA keg was not empty (203 items). Lost 1 pages of memory. Freed UMA keg was not empty (36 items). Lost 2 pages of memory. The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled (with attached VIMAGE kernel config file). The following commands reproduce the bug: jail -l -u root -c path=/ name=foo persist vnet && jexec foo ifconfig lo0 127.0.0.1/8 && jail -r foo Running it too many times exhausts kernel memory and crashes the machine. The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN -head. The problem has been present since day 1 and is still present up to HEAD. This is about type stability and teardown. So far we are no able to actually free TCP (and UDP in SVN) states as they might still be accesses after "free". It's a general problem in the network stack and has been implemented as a measure to circumvent panics in those cases. I am not sure if that's actually what's biting you wrt to memory or if it's something else. Unfortunately boot logs and kernel configs don't help much; enable ddb and get show uma and show malloc reports after the crash (or watch vmstat -z and vmstat -m) after every 50 jail restarts. I might have some patches for a couple of things but cannot (yet) help with the additional (duplicate) UMA zones showing up at each iteration (for the -z case). /bz -- Bjoern A. Zeeb Welcome a new stage of life. Going to jail sucks -- All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADS UP] Significant TCP work committed to head - VIMAGE users
On 11/12/10 20:35, Lawrence Stewart wrote: > Hi All, > > A quick note that this evening, I made the first in a series of upcoming > commits to head that modify the TCP stack fairly significantly. I have > no reason to believe you'll notice any issues, but TCP is a complex > beast and it's possible things might crop up. The changes are mostly > related to congestion control, so the sorts of issues that are likely to > crop up if any will most probably be subtle and difficult to even > detect. The first svn revision in question is r215166. The next few > commits I plan to make will be basically zero impact and then another > significant patch will follow in a few weeks. > > If you bump into an issue that you think might be related to this work, > please roll back r215166 from your tree and attempt to reporoduce before > reporting the problem. Please CC me directly with your problem report > and post to freebsd-current@ or freebsd-net@ as well. > > Lots more information about what all this does and how to use it will be > following in the coming weeks, but in the meantime, just keep this note > in the back of your mind. For the curious, some information about the > project is available at [1,2]. > > Cheers, > Lawrence > > [1] http://caia.swin.edu.au/freebsd/5cc/ > [2] > http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD For any VIMAGE users running head, please note that r215166 overlooked some important VIMAGE related issues and actually triggers a kernel panic when the first vnet is brought up (see [3] for details). Please ensure you update to r215395 or later to ensure you have all the patches I committed to address the VIMAGE deficiencies in the original r215166 commit. Cheers, Lawrence [3] http://lists.freebsd.org/pipermail/svn-src-head/2010-November/022381.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VIMAGE: Freed UMA keg was not empty
"Bjoern A. Zeeb" a écrit > On Wed, 17 Nov 2010, Thierry Herbelot wrote: > > Hi, > > first of all freebsd-virtualization@ is the better list for this; Cc:ed. (in fact, I did not know where else to send this message : -net, ... ? thanks for the CC) > > > We are using FreeBSD + VIMAGE at work, and we have seen an annoying > > problem : there seems to be a memory leak in the kernel, which > > eventually causes a panic. > > > > (yes, we have seen the following message : "WARNING: VIMAGE (virtualized > > network stack) is a highly experimental feature.") > > > > Configuring a network interface in a jail with vnet enabled, then > > removing that jail causes these messages. In dmesg: > > > > [...] > > Freed UMA keg was not empty (203 items). Lost 1 pages of memory. > > Freed UMA keg was not empty (36 items). Lost 2 pages of memory. > > > > The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled > > (with attached VIMAGE kernel config file). > > > > The following commands reproduce the bug: > > > > jail -l -u root -c path=/ name=foo persist vnet && > > jexec foo ifconfig lo0 127.0.0.1/8 && > > jail -r foo > > > > Running it too many times exhausts kernel memory and crashes the machine. > > > > The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN > > -head. > > The problem has been present since day 1 and is still present up to > HEAD. This is about type stability and teardown. So far we are no > able to actually free TCP (and UDP in SVN) states as they might still > be accesses after "free". It's a general problem in the network stack > and has been implemented as a measure to circumvent panics in those > cases. > > I am not sure if that's actually what's biting you wrt to memory or > if it's something else. Unfortunately boot logs and kernel configs > don't help much; enable ddb and get show uma and show malloc reports > after the crash (or watch vmstat -z and vmstat -m) after every 50 jail > restarts. I might have some patches for a couple of things but cannot > (yet) help with the additional (duplicate) UMA zones showing up at > each iteration (for the -z case). The context for our problem is that VIMAGE jails are mant to be used "in production" for automated tests, thus are likely to be multiple on one physical host, and are likely to be started and stopped according to our needs. We have tried more "classical" virtualization solutions (qemu, kvm, ... , normal jails with individual FIBs, ...) but only FreeBSD with VIMAGE seems to be the correct answer. (for other reasons, an i386 version of the kernel must be used) The point of my original email was to simplify the configuration for a test setup : any machine with the attached configuration file and the above sequence of commands creating and deleting jails, running in a loop, will eventually panic. Anyway, I will follow up with the logs you mentioned. Cheers (and thanks for the quick feedback) Thierry Herbelot > > /bz ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] top(1) inverse display of table header
Xin LI writes: > Hi, > > Here is a patch that makes top(1) to inverse its table header (PID > USERNAME THR, etc). > That MAX_COLS change in it makes `top -b' produce too much extra whitespace that's not trimmed and spans several lines, e.g. $ stty -a | sed 1q speed 38400 baud; 57 rows; 79 columns; $ top -b last pid: 54799; load averages: 1.90, 2.16, 2.16 up 0+04:28:34 10:18:15 91 processes: 4 running, 85 sleeping, 2 stopped Mem: 540M Active, 243M Inact, 2934M Wired, 79M Cache, 417M Buf, 136M Free Swap: 4097M Total, 8856K Used, 4088M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1730 holo 14 460 358M 197M ucond 1 1:24 0.00% firefox-bin FYI, using inverse color for header line can also be achieved on top-3.8b1 without touching source at all $ export TOPCOLORS='header=,#7' edwin@ planned to update top(1) but stalled, not sure why. http://docs.freebsd.org/cgi/mid.cgi?20080928054620.GA80250 And I for one still use his branch with below diff. against svn://svn.freebsd.org/base/user/edwin/top/top-3.8b1 - cherry-pick changes from /head (r189626, r200979, r211419) - report realtime priority like /head - lower min_screenwidth for FLG field, for 80 col tty sake - use int type for counter - fix amd64/i386 cross-compilation - remove `-g', prefer DEBUG_FLAGS - abbreviate Kern/Kernel row like Mem/Memory - adjust whitespace --- Index: contrib/top/display.c === --- contrib/top/display.c (revision 215416) +++ contrib/top/display.c (working copy) @@ -993,7 +993,6 @@ if (*bt != -1) { uptime = *tod - *bt; - uptime += 30; uptime_days = uptime / 86400; tm = gmtime(&uptime); @@ -1312,7 +1311,7 @@ } /* - * *_kernel(stats) - print "Kernel: " followed by the kernel summary string + * *_kernel(stats) - print "Kern: " followed by the kernel summary string * * Assumptions: cursor is on "lastline", the previous line */ @@ -1323,7 +1322,7 @@ { if (num_kernel > 0) { - display_write(0, y_kernel, 0, 0, "Kernel: "); + display_write(0, y_kernel, 0, 0, "Kern: "); /* format and print the kernel summary */ summary_format(x_kernel, y_kernel, stats, kernel_names, kernel_cidx); Index: contrib/top/username.c === --- contrib/top/username.c (revision 215416) +++ contrib/top/username.c (working copy) @@ -53,7 +53,6 @@ #include #include -#include #include "top.h" #include "utils.h" @@ -72,7 +71,7 @@ struct hash_data { intuid; -char name[UT_NAMESIZE + 1]; /* big enough? */ +char name[MAXLOGNAME]; /* big enough? */ time_t expire; }; @@ -120,7 +119,7 @@ { if ((pw = getpwuid(uid)) != NULL) { - strncpy(data->name, pw->pw_name, UT_NAMESIZE); + strncpy(data->name, pw->pw_name, MAXLOGNAME - 1); data->expire = now + EXPIRETIME; dprintf("username: updating %d with %s, expires %d\n", data->uid, data->name, data->expire); Index: contrib/top/hash.c === --- contrib/top/hash.c (revision 215416) +++ contrib/top/hash.c (working copy) @@ -99,7 +99,7 @@ next_prime(int x) { -double i, j; +int i, j; int f; i = x; @@ -108,7 +108,7 @@ f=1; for (j=2; j ${.TARGET} CLEANFILES+= config.h -CPU!= uname -m config.h: config.h.in @${ECHO} Making ${.TARGET} from ${.ALLSRC:T} sed \ @@ -55,7 +55,7 @@ -e 's/@DEFAULT_DELAY@/2/' \ -e 's/@HAVE_GETOPT_LONG@/1/' \ -e 's/@ENABLE_KILL@/1/' \ - -e "s/@CPU@/${CPU}/" \ + -e "s/@CPU@/${MACHINE}/" \ < ${.ALLSRC} > ${.TARGET} CLEANFILES+= top.1.local ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"