Re: libcompiler_rt now part of FreeBSD's base system [SEC=UNCLASSIFIED]

[Daniel Nebdal]

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

[Andriy Gapon]

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

[Andrey V. Elsukov]

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

[John Baldwin]

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

[John Baldwin]

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

[Pawel Jakub Dawidek]

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

[Marius Nünnerich]

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

[Andrey V. Elsukov]

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

[Andriy Gapon]

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?

[crocket]

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

[Garrett Cooper]

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

[Garrett Cooper]

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

[AN]

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

[Benjamin Kaduk]

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

[AN]

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

[Benjamin Kaduk]

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

[Garrett Cooper]

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

[Patrick Lamaiziere]

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

[AN]

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

[Benjamin Kaduk]

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

[Jung-uk Kim]

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

[Jung-uk Kim]

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

[Adrian Chadd]

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

[Adrian Chadd]

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

[Alexander Best]

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

[Adrian Chadd]

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

[Alexander Best]

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

[Alexander Best]

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

[Thierry Herbelot]

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

[Bjoern A. Zeeb]

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

[Lawrence Stewart]

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

[Thierry Herbelot]

"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

[Anonymous]

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"