Re: Anybody willing to test out kload?
on 14/11/2012 23:56 Russell Cattelan said the following: This has been sitting on my plate for a while and I would like to get some more feedback / testing on this feature. A few words about what kload is and how to use/test it might increase chances of that actually happening. What is really would like to find out is which drivers do not shutdown their chips correctly and thus cause stray interrupts on the kload boot. -- 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: Anybody willing to test out kload?
On 15/11/2012 11:16, Andriy Gapon wrote: on 14/11/2012 23:56 Russell Cattelan said the following: This has been sitting on my plate for a while and I would like to get some more feedback / testing on this feature. A few words about what kload is and how to use/test it might increase chances of that actually happening. Google finds this: http://www.bsdcan.org/2012/schedule/events/325.en.html I would have thought the major problem here is not the kernel itself but the drivers, leaving hardware in undetermined state (especially server hardware, which is numerous and surprisingly sensitive to there being One True Way to initialize it). signature.asc Description: OpenPGP digital signature
Recent CURRENT - Mounting from zfs:zroot failed with error 22.
Hello list, I wanted to update CURRENT installation on my home server because kernel dated: # uname -a FreeBSD server.obsysa.net 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r240357: Tue Sep 11 19:14:47 CEST 2012 r...@server.obsysa.net:/usr/obj/usr/src/sys/ATHLON10 i386 is unstable for me. Unfortunately, I can't succesfully boot any recent CURRENT, it always ends with: Trying to mount root from zfs:zroot []... Mounting from zfs:zroot failed with error 22. at last stage. I've updated world and bootcodes on all disks to latest code, I've tried building with clang and gcc, still the same - old kernel boots, but recent current doesn't. dmesg from old kernel: http://pastebin.com/ppbvTRW8 kernel config: http://pastebin.com/K96T3hrV # gpart show = 34 78165293 ada0 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) = 34 78165293 ada1 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) = 34 78242909 ada2 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 77616- free - (37M) = 34 78242909 ada3 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 77616- free - (37M) # gpart show -l = 34 78165293 ada0 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap0 (1.0G) 2097314 76068013 3 disk0 (36G) = 34 78165293 ada1 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap1 (1.0G) 2097314 76068013 3 disk1 (36G) = 34 78242909 ada2 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap2 (1.0G) 2097314 76068013 3 disk2 (36G) 78165327 77616- free - (37M) = 34 78242909 ada3 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap3 (1.0G) 2097314 76068013 3 disk3 (36G) 78165327 77616- free - (37M) # zdb zroot: version: 28 name: 'zroot' state: 0 txg: 4 pool_guid: 4467765745870166865 hostid: 2539839140 hostname: 'mfsbsd' vdev_children: 2 vdev_tree: type: 'root' id: 0 guid: 4467765745870166865 create_txg: 4 children[0]: type: 'mirror' id: 0 guid: 697384422102507547 metaslab_array: 33 metaslab_shift: 28 ashift: 9 asize: 38942015488 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 8710134285551915560 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 13312030606858472664 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 1 create_txg: 4 children[1]: type: 'mirror' id: 1 guid: 4490522279017872594 metaslab_array: 30 metaslab_shift: 28 ashift: 9 asize: 38942015488 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 15041339321584576645 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 18403473023508789449 path: '/dev/gpt/disk3' phys_path: '/dev/gpt/disk3' whole_disk: 1 create_txg: 4 # zpool status -v pool: zroot state: ONLINE scan: scrub repaired 0 in 0h57m with 0 errors on Sun Nov 11 17:55:44 2012 config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0
Re: Recent CURRENT - Mounting from zfs:zroot failed with error 22.
on 15/11/2012 13:56 Bartosz Stec said the following: Hello list, I wanted to update CURRENT installation on my home server because kernel dated: # uname -a FreeBSD server.obsysa.net 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r240357: Tue Sep 11 19:14:47 CEST 2012 r...@server.obsysa.net:/usr/obj/usr/src/sys/ATHLON10 i386 is unstable for me. Unfortunately, I can't succesfully boot any recent CURRENT, it always ends with: Trying to mount root from zfs:zroot []... Mounting from zfs:zroot failed with error 22. I am looking into this. That's probably a bug in one of my commits. at last stage. I've updated world and bootcodes on all disks to latest code, I've tried building with clang and gcc, still the same - old kernel boots, but recent current doesn't. dmesg from old kernel: http://pastebin.com/ppbvTRW8 kernel config: http://pastebin.com/K96T3hrV # gpart show = 34 78165293 ada0 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) = 34 78165293 ada1 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) = 34 78242909 ada2 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 77616- free - (37M) = 34 78242909 ada3 GPT (37G) 34 128 1 freebsd-boot (64k) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) 78165327 77616- free - (37M) # gpart show -l = 34 78165293 ada0 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap0 (1.0G) 2097314 76068013 3 disk0 (36G) = 34 78165293 ada1 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap1 (1.0G) 2097314 76068013 3 disk1 (36G) = 34 78242909 ada2 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap2 (1.0G) 2097314 76068013 3 disk2 (36G) 78165327 77616- free - (37M) = 34 78242909 ada3 GPT (37G) 34 128 1 (null) (64k) 162 2097152 2 swap3 (1.0G) 2097314 76068013 3 disk3 (36G) 78165327 77616- free - (37M) # zdb zroot: version: 28 name: 'zroot' state: 0 txg: 4 pool_guid: 4467765745870166865 hostid: 2539839140 hostname: 'mfsbsd' vdev_children: 2 vdev_tree: type: 'root' id: 0 guid: 4467765745870166865 create_txg: 4 children[0]: type: 'mirror' id: 0 guid: 697384422102507547 metaslab_array: 33 metaslab_shift: 28 ashift: 9 asize: 38942015488 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 8710134285551915560 path: '/dev/gpt/disk0' phys_path: '/dev/gpt/disk0' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 13312030606858472664 path: '/dev/gpt/disk2' phys_path: '/dev/gpt/disk2' whole_disk: 1 create_txg: 4 children[1]: type: 'mirror' id: 1 guid: 4490522279017872594 metaslab_array: 30 metaslab_shift: 28 ashift: 9 asize: 38942015488 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 15041339321584576645 path: '/dev/gpt/disk1' phys_path: '/dev/gpt/disk1' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 18403473023508789449 path: '/dev/gpt/disk3' phys_path: '/dev/gpt/disk3' whole_disk: 1 create_txg: 4 # zpool status -v pool: zroot state: ONLINE scan: scrub repaired 0 in 0h57m with 0 errors on Sun Nov 11
LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page
To people knowing the code, do the following documentation changes look correct? --- a/share/man/man9/lock.9 +++ b/share/man/man9/lock.9 @@ -148,7 +148,9 @@ Flags indicating what action is to be taken. .Bl -tag -width .Dv LK_CANRECURSE .It Dv LK_SHARED Acquire a shared lock. -If an exclusive lock is currently held, it will be downgraded. +If an exclusive lock is currently held, +.Dv EDEADLK +will be returned. .It Dv LK_EXCLUSIVE Acquire an exclusive lock. If an exclusive lock is already held, and @@ -158,7 +160,8 @@ is not set, the system will .It Dv LK_DOWNGRADE Downgrade exclusive lock to a shared lock. Downgrading a shared lock is not permitted. -If an exclusive lock has been recursed, all references will be downgraded. +If an exclusive lock has been recursed, the system will +.Xr panic 9 . .It Dv LK_UPGRADE Upgrade a shared lock to an exclusive lock. If this call fails, the shared lock is lost. -- 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: compiler info in kernel identification string
On Tue, Nov 13, 2012 at 03:57:55PM -0800, David Wolfskill wrote: I like the idea, but I have long found the idea of putting this type of logic (including VCS-awareness) in newvers.sh itself something that is prone to turn what should be a rather simple script into a ... mess. I don't think newvers.sh is a mess (yet) and I find current features highly desirable. What I have been using for several months has been a modified newvers.sh that uses an externally-defined function (from a file that is sourced) to handle whatever VCS-specific things I think are appropriate. (Thus, folks who want to use one VCS don't need to have newvers.sh test for VCSen they don't use; they could also provide a sample file that provides the function. An installation could use a symlink to point to the function definition of choice We could even have a kitchen sink default, that goes through all the hoops gyrations the current code does, if folks want that.) newvers.sh definitely should continue to work without hints on cvs/svn/git. Moving checks to different files seems completely unnecessary for me as I don't find current checks expensive. But if you do the work I see nothing wrong with it. :) (but please note I'm in no position to accept your changes) Given that, low-cost support for custom version strings could look like this: after all standard values are filled, prepare complete version string, then source custom script if it exists. This way your script has access to everything that newvers.sh was able to determine and to complete version string, and you are free to change it however you want using detected revision/compiler/whatever or completely new data. -- Mateusz Guzik mjguzik gmail.com ___ 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
genmodes dumping core during buildworld
Hi, anyone see something similar before: === usr.sbin/zic/zdump (depend) rm -f .depend mkdep -f .depend -a-DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\/usr/share/zoneinfo\ -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/stdtime -std=gnu99 /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/zdump.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/ialloc.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/scheck.c echo zdump: /usr/obj/usr/src/tmp/usr/lib/libc.a .depend === usr.sbin/zzz (depend) 1 error *** [_depend] Error code 2 1 error *** [buildworld] Error code 2 1 error This is in the log: Nov 15 15:56:49 server kernel: pid 83891 (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83893 (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83897 (genmodes), uid 0: exited on signal 10 (core dumped) genmodes seems to be a component of gcc? Lars
Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page
On 11/15/12, Andriy Gapon a...@freebsd.org wrote: To people knowing the code, do the following documentation changes look correct? The latter chunk is not correct. It will panic only if assertions are on. I was thinking that however it would be good idea to patch lockmgr to panic also in non-debugging kernel situation. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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
cvsup/csup servers stale?
Hi Has the svn-cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? Ian -- Ian Freislich ___ 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: cvsup/csup servers stale?
On 15 November 2012 13:47, Ian FREISLICH i...@clue.co.za wrote: Hi Has the svn-cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? The FreeBSD cluster is undergoing maintenance. In particular the main machines were recently physically moved, upgraded, and discombobulated. A number of services are down but we are working on fixing this as fast as possible! -- Eitan Adler ___ 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: cvsup/csup servers stale?
On 11/15/2012 12:58 PM, Eitan Adler wrote: On 15 November 2012 13:47, Ian FREISLICH i...@clue.co.za wrote: Hi Has the svn-cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? The FreeBSD cluster is undergoing maintenance. In particular the main machines were recently physically moved, upgraded, and discombobulated. A number of services are down but we are working on fixing this as fast as possible! I want my money back! :) Upgrades are always fun. *throws his hands up and shouts whee!! as the rollercoaster goes up and down* No worries. :) -- Chuck Burns brea...@gmail.com ___ 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: USB keyboard problem
On Mon, Nov 12, 2012 at 2:22 PM, Sam Fourman Jr. sfour...@gmail.com wrote: hello, I believe my keyboard is being detected as a mouse by mistake using amd64 HEAD svn r242748 I can not use this keyboard, I have to plug in another one. this is also broken in FreeBSD 9.1RC3 is this simple to patch? any help is appreciated uhid0: Razer Razer BlackWidow, class 0/0, rev 2.00/2.00, addr 1 on usbus0 uhid1: vendor 0x04d9 product 0x1203, class 0/0, rev 2.00/2.80, addr 2 on usbus3 ums0: Razer Razer BlackWidow, class 0/0, rev 2.00/2.00, addr 1 on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ums1: Razer Razer Naga, class 0/0, rev 2.00/2.00, addr 2 on usbus0 ums1: 7 buttons and [XYZ] coordinates ID=0 verbose dmesg follows http://www.samjess.com/keyboard.txt -- Sam Fourman Jr. What does usbconfig -d X.Y dump_device_desc dump_curr_config_desc say about your device? --HPS http://www.samjess.com/usbconfig.txt Does anyone know where I would start hacking around to fix this? Sam ___ 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: Anybody willing to test out kload?
On 11/15/12 5:40 AM, Ivan Voras wrote: On 15/11/2012 11:16, Andriy Gapon wrote: on 14/11/2012 23:56 Russell Cattelan said the following: This has been sitting on my plate for a while and I would like to get some more feedback / testing on this feature. A few words about what kload is and how to use/test it might increase chances of that actually happening. Google finds this: http://www.bsdcan.org/2012/schedule/events/325.en.html yes thank you. This is probably the best place for info on kload currently. I need to create a wiki page soon. I would have thought the major problem here is not the kernel itself but the drivers, leaving hardware in undetermined state (especially server hardware, which is numerous and surprisingly sensitive to there being One True Way to initialize it). Yup... this is what I would like to hear about. Which drivers / cards are not behaving well and may need some attention. -Russell signature.asc Description: OpenPGP digital signature
Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page
on 15/11/2012 20:46 Attilio Rao said the following: On 11/15/12, Andriy Gapon a...@freebsd.org wrote: To people knowing the code, do the following documentation changes look correct? The latter chunk is not correct. It will panic only if assertions are on. But the current content is not correct too? I was thinking that however it would be good idea to patch lockmgr to panic also in non-debugging kernel situation. It would make sense indeed, IMO. -- 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: compiler info in kernel identification string
on 14/11/2012 01:43 Mateusz Guzik said the following: Hello, avg@ suggested to include compiler version in the kernel so that it's present in uname (and one can easly tell what was used to compile it). Here is my attempt: http://people.freebsd.org/~mjg/patches/newvers-compiler.diff When are you committing this? Basically adds compiler name and version/revision after revision of system sources. Sample output from dirty git sources: gcc: FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed Nov 14 00:11:51 CET 2012 clang: FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14 00:12:26 CET 2012 Sample output from svn with gcc: FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14 00:41:23 CET 2012 I have no strong opinions on format, I just want this information easly accessible. -- 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: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page
On Thu, Nov 15, 2012 at 8:38 PM, Andriy Gapon a...@freebsd.org wrote: on 15/11/2012 20:46 Attilio Rao said the following: On 11/15/12, Andriy Gapon a...@freebsd.org wrote: To people knowing the code, do the following documentation changes look correct? The latter chunk is not correct. It will panic only if assertions are on. But the current content is not correct too? Indeed, current content is crappy. I was thinking that however it would be good idea to patch lockmgr to panic also in non-debugging kernel situation. It would make sense indeed, IMO. Do you think you can test this patch?: http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I think the LK_NOSHARE case is still fine with just asserts. Once this patch goes in, you are free to commit your documentation one. Thanks for fixing doc. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: compiler info in kernel identification string
On 2012-11-15 21:43, Andriy Gapon wrote: on 14/11/2012 01:43 Mateusz Guzik
said the following:
Hello,
avg@ suggested to include compiler version in the kernel so that it's
present in uname (and one can easly tell what was used to compile it).
Here is my attempt:
http://people.freebsd.org/~mjg/patches/newvers-compiler.diff
When are you committing this?
Please don't commit it yet, we're not done reviewing. :)
For starters, this hardcodes the compiler names gcc and clang, and
this will include incorrect information into the kernel version string,
if you use another setting for ${CC}.
Then, if you fix the script use ${CC}, and set it to gcc versions from
ports (for example), the parsing breaks down, as I expected:
$ echo $CC
/usr/local/bin/gcc47
$ compiler=gcc-`$CC --version | head -n1 | awk '{ print $3 - $4}'`
$ echo $compiler
gcc-Ports-Collection)
So please fix this first. Either handle all possible variants of
version output, or just put the version string verbatim into the
identification. I would opt for the latter.
Last but not least, I am not sure this information belongs in uname at
all. Maybe it would be better to put it somewhere else, in a sysctl, or
show it in dmesg.
___
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: compiler info in kernel identification string
On 2012-11-14 16:38, Ian Lepore wrote: On Wed, 2012-11-14 at 10:25 +0100, Dimitry Andric wrote: ... That way, you are sure never to lose information. This also works for gcc from ports (which is the reason for the space after 'version' in the grep command): $ gcc47 -v 21 | grep 'version ' gcc version 4.7.3 20120929 (prerelease) (FreeBSD Ports Collection) I realize this is a bit long, but it is better to have complete than stripped information. Rather than just taking whatever the compiler emits, the proposed patch seems to be carefully crafted to avoid breaking existing 3rd party tools which parse uname output based on the location of whitespace. I'm not sure how important that is given that the uname manpage doesn't document the output format as if it were somehow rigidly specified. I can see where you're coming from, but I also think it is very fragile to depend on parsing such information from uname. If you do so, you must be prepared to accept wonky input, otherwise, just don't do it. :) And as I remarked in another reply, now that I have thought about it a bit, I would much rather see this information moved to a sysctl or dmesg line, than in uname. With the happy side effect that no existing uname parsers would be confused! ___ 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: compiler info in kernel identification string
On Fri, Nov 16, 2012 at 12:05:33AM +0100, Dimitry Andric wrote:
For starters, this hardcodes the compiler names gcc and clang, and
this will include incorrect information into the kernel version string,
if you use another setting for ${CC}.
Yes, I blindly assumed that both gcc and clang will keep format of --version.
For everything else you would get 'unknown-compiler'.
Last but not least, I am not sure this information belongs in uname at
all. Maybe it would be better to put it somewhere else, in a sysctl, or
show it in dmesg.
As stated in original mail, I don't have strong opinions on this. I only
care about accessibility of this information.
So, here is my patch that adds information at boot time and sysctl
kern.compiler:
http://people.freebsd.org/~mjg/patches/compiler-info.diff
Sample output:
Copyright (c) 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #281 r243095=c24a389-dirty: Fri Nov 16 00:24:46 CET 2012
f@lap:/usr/obj/i386.i386/srv/repos/freebsd/sys/DEVEL i386
Compiled with cc (GCC) 4.2.1 20070831 patched [FreeBSD] -- HERE
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
CPU: Intel(R) Core(TM)2 Duo CPU P9600 @ 2.66GHz (2635.19-MHz 686-class CPU)
[..]
As you can see only first line is captured and I go with assumption that
--version works, I hope this is ok.
--
Mateusz Guzik mjguzik gmail.com
___
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: cvsup/csup servers stale?
Good luck with employing full discombobulation! I think this is the main requirement for _cloud computing_. -- View this message in context: http://freebsd.1045724.n5.nabble.com/cvsup-csup-servers-stale-tp5761290p5761389.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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
UTF-8 console
Hello :-) I was wondering if its possible to have UTF-8 console? ISO seems to be a bit outdated these days and less comfortable for multinational applications :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: UTF-8 console
http://wiki.freebsd.org/SysconsUnicodeProject -- View this message in context: http://freebsd.1045724.n5.nabble.com/UTF-8-console-tp5761405p5761407.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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: genmodes dumping core during buildworld
On Thu, 15 Nov 2012 15:02:36 + Eggert, Lars l...@netapp.com wrote: Hi, anyone see something similar before: === usr.sbin/zic/zdump (depend) rm -f .depend mkdep -f .depend -a-DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\/usr/share/zoneinfo\ -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/stdtime -std=gnu99 /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/zdump.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/ialloc.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/scheck.c echo zdump: /usr/obj/usr/src/tmp/usr/lib/libc.a .depend === usr.sbin/zzz (depend) 1 error *** [_depend] Error code 2 1 error *** [buildworld] Error code 2 1 error This is in the log: Nov 15 15:56:49 server kernel: pid 83891 (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83893 (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83897 (genmodes), uid 0: exited on signal 10 (core dumped) genmodes seems to be a component of gcc? Lars It also happens to be the 10 years old piece of software that has not changed in recent history. Which means that (likely) you run out of memory, your CPU overheats or something else is wrong with your computer, or (less likely) it is being mis-compiled by clang. -- Alexander Kabaev signature.asc Description: PGP signature
Re: compiler info in kernel identification string
on 16/11/2012 01:05 Dimitry Andric said the following:
For starters, this hardcodes the compiler names gcc and clang, and
this will include incorrect information into the kernel version string,
if you use another setting for ${CC}.
Oops, I agree. The script should definitely make use of $CC.
Thank you for pointing this out.
--
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: compiler info in kernel identification string
on 16/11/2012 01:09 Dimitry Andric said the following: And as I remarked in another reply, now that I have thought about it a bit, I would much rather see this information moved to a sysctl or dmesg line, than in uname. With the happy side effect that no existing uname parsers would be confused! I would still like to have at least compiler's base name or type or something in uname. -- 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
