Re: did SVN r227753 (locale changes) break something?
On Mon, Nov 21, 2011 at 07:21:17PM -0500, Michael Butler wrote: > #0 0x283eb243 in fprintf () from /lib/libc.so.7 > #1 0x283eb558 in uselocale () from /lib/libc.so.7 > #2 0x283eb6f9 in newlocale () from /lib/libc.so.7 > #3 0x281637f2 in msg_Subscribe () from /usr/local/lib/libvlccore.so.4 Could you contact new locale submitter directly on this issue, please? It seems I don't understand the new code path well. -- http://ache.vniz.net/ ___ 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: /usr/home vs /home
Am Mon, 21 Nov 2011 13:15:36 -1000 schrieb David Cornejo : > I've always liked the more succinct /home and was wondering if there > is any reason why not to delete the symlink and move home to / to > mimic the old many partition style? Hi David, I like the idea of having /usr/home better, because if you don't want to have a separate partition for homes, you would at least have a huge partition (/usr) and won't run out of space quickly. If you create /home, you'll assign the rootfs space to users without a home partitions and rootfs is typically small. FreeBSD is totally fine with /home mountpoint. It won't work differently. I consider the installer procedure as a quick way to install FreeBSD. It is for people who want to try something. And you don't want to have all these "help! my rootfs is full!" support questions and explain the same thing over and over again. I think, I'm not alone when I say that I prepare the disks myself instead of using the installer. I don't even know if the new installer will be capable of installing FreeBSD like I have it installed now. -- Martin signature.asc Description: PGP signature
Re: rc.conf changes IPV6
Your right Doug, didn't bother taking box down after changing to new format, it works as expected, ignoring duplicate aliases regardless of protocal. I've regrouped my configs into interfaces instead of protocals now for the change so ipv4/6 aliases can be seen together without making mistakes. Definately would be nice to see ipv6_addrs_ added. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Mon, 21 Nov 2011, Dan The Man wrote: Good point, I did switch to new config, let me find a box I can take down and I'll report back. I assume you'd be right considering how shell scripting works, that would not make much sense... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Mon, 21 Nov 2011, Doug Barton wrote: On 11/21/2011 17:39, Dan The Man wrote: On Mon, 21 Nov 2011, Stefan Bethke wrote: Am 21.11.2011 um 20:25 schrieb Dan The Man: I notice we have changed way IPV6 is done in rc.conf now. I assume someone will update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html My question now concerns aliases, and what the norm will end up being. Here is example below: Here we have the new layout with IPV6, the below works fine, however since the ifconfig lines for IPV4 and IPV6 are essentially the same other than the actual "inet" and "inet6", will it be ok to start with alias0 for both IPV4 and IPV6, or should I in this example be starting at alias4 for IPV6? I would like idea to keep it way it is each protocal starting at alias0. #GATEWAY defaultrouter="67.159.46.233" hostname="sunsaturn.com" #IPV4 ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" #IPV6 ipv6_activate_all_interfaces="YES" ipv6_network_interfaces="em1" ipv6_defaultrouter="2001:49f0:4004:::::0001" ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 prefixlen 48" ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 prefixlen 48" ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 prefixlen 48" Remember that rc.conf follows shell syntax and sematics, so the second _alias0 and _alias1 will overwrite the previous ones. In 9.0 you can use the ipv4_addrs_ variable to set both the IPv4 "main" address as well as "alias" addresses, see rc.conf(5). There doesn't seem to be an equivalent IPv6 option, as best as I can tell. You would assume so Stefan, that the duplicate alias0 would overwrite, but it seems since ifconfig separates the namespace for IPV4/IPV6 it actually works. I don't see how that could possibly be true, how have you tested it? Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: rc.conf changes IPV6
Good point, I did switch to new config, let me find a box I can take down and I'll report back. I assume you'd be right considering how shell scripting works, that would not make much sense... Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com On Mon, 21 Nov 2011, Doug Barton wrote: On 11/21/2011 17:39, Dan The Man wrote: On Mon, 21 Nov 2011, Stefan Bethke wrote: Am 21.11.2011 um 20:25 schrieb Dan The Man: I notice we have changed way IPV6 is done in rc.conf now. I assume someone will update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html My question now concerns aliases, and what the norm will end up being. Here is example below: Here we have the new layout with IPV6, the below works fine, however since the ifconfig lines for IPV4 and IPV6 are essentially the same other than the actual "inet" and "inet6", will it be ok to start with alias0 for both IPV4 and IPV6, or should I in this example be starting at alias4 for IPV6? I would like idea to keep it way it is each protocal starting at alias0. #GATEWAY defaultrouter="67.159.46.233" hostname="sunsaturn.com" #IPV4 ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" #IPV6 ipv6_activate_all_interfaces="YES" ipv6_network_interfaces="em1" ipv6_defaultrouter="2001:49f0:4004:::::0001" ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 prefixlen 48" ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 prefixlen 48" ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 prefixlen 48" Remember that rc.conf follows shell syntax and sematics, so the second _alias0 and _alias1 will overwrite the previous ones. In 9.0 you can use the ipv4_addrs_ variable to set both the IPv4 "main" address as well as "alias" addresses, see rc.conf(5). There doesn't seem to be an equivalent IPv6 option, as best as I can tell. You would assume so Stefan, that the duplicate alias0 would overwrite, but it seems since ifconfig separates the namespace for IPV4/IPV6 it actually works. I don't see how that could possibly be true, how have you tested it? Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: rc.conf changes IPV6
On 11/21/2011 17:39, Dan The Man wrote: > > On Mon, 21 Nov 2011, Stefan Bethke wrote: > >> Am 21.11.2011 um 20:25 schrieb Dan The Man: >> >>> I notice we have changed way IPV6 is done in rc.conf now. >>> I assume someone will update: >>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html >>> >>> >>> My question now concerns aliases, and what the norm will end up being. >>> Here is example below: >>> Here we have the new layout with IPV6, the below works fine, however >>> since >>> the ifconfig lines for IPV4 and IPV6 are essentially the same other >>> than the actual "inet" and "inet6", will it be ok to start with >>> alias0 for both IPV4 and IPV6, or should I in this example be >>> starting at alias4 for IPV6? >>> I would like idea to keep it way it is each protocal starting at alias0. >>> >>> >>> #GATEWAY >>> defaultrouter="67.159.46.233" >>> hostname="sunsaturn.com" >>> #IPV4 >>> ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" >>> ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" >>> ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" >>> ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" >>> ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" >>> >>> #IPV6 >>> ipv6_activate_all_interfaces="YES" >>> ipv6_network_interfaces="em1" >>> ipv6_defaultrouter="2001:49f0:4004:::::0001" >>> ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 >>> prefixlen 48" >>> ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 >>> prefixlen 48" >>> ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 >>> prefixlen 48" >> >> Remember that rc.conf follows shell syntax and sematics, so the second >> _alias0 and _alias1 will overwrite the previous ones. >> >> In 9.0 you can use the ipv4_addrs_ variable to set both the >> IPv4 "main" address as well as "alias" addresses, see rc.conf(5). >> There doesn't seem to be an equivalent IPv6 option, as best as I can >> tell. > > You would assume so Stefan, that the duplicate alias0 would overwrite, > but it seems since ifconfig separates the namespace for IPV4/IPV6 it > actually works. I don't see how that could possibly be true, how have you tested it? Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: rc.conf changes IPV6
On Mon, 21 Nov 2011, Stefan Bethke wrote: Am 21.11.2011 um 20:25 schrieb Dan The Man: I notice we have changed way IPV6 is done in rc.conf now. I assume someone will update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html My question now concerns aliases, and what the norm will end up being. Here is example below: Here we have the new layout with IPV6, the below works fine, however since the ifconfig lines for IPV4 and IPV6 are essentially the same other than the actual "inet" and "inet6", will it be ok to start with alias0 for both IPV4 and IPV6, or should I in this example be starting at alias4 for IPV6? I would like idea to keep it way it is each protocal starting at alias0. #GATEWAY defaultrouter="67.159.46.233" hostname="sunsaturn.com" #IPV4 ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" #IPV6 ipv6_activate_all_interfaces="YES" ipv6_network_interfaces="em1" ipv6_defaultrouter="2001:49f0:4004:::::0001" ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 prefixlen 48" ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 prefixlen 48" ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 prefixlen 48" Remember that rc.conf follows shell syntax and sematics, so the second _alias0 and _alias1 will overwrite the previous ones. In 9.0 you can use the ipv4_addrs_ variable to set both the IPv4 "main" address as well as "alias" addresses, see rc.conf(5). There doesn't seem to be an equivalent IPv6 option, as best as I can tell. Stefan -- Stefan BethkeFon +49 151 14070811 You would assume so Stefan, that the duplicate alias0 would overwrite, but it seems since ifconfig separates the namespace for IPV4/IPV6 it actually works. Which is good news I would assume, as I have time to time added a new IPV4 alias, and would have forgotten to update IPV6 alias numbers many times unless I revise my config to put ipv4 and ipv6 aliases together in rc.conf instead of separating the protocals in there. I looked at man page, thats a very nice config option ipv4_addrs_, I agree it would be nice to have an IPV6 equivalent considering how big the IPV6 range is. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.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: rc.conf changes IPV6
Looping Hiroki Sato in since he's the architect of the most recent changes here. Doug On 11/21/2011 12:11, Stefan Bethke wrote: > Am 21.11.2011 um 20:25 schrieb Dan The Man: > >> I notice we have changed way IPV6 is done in rc.conf now. >> I assume someone will update: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html >> >> My question now concerns aliases, and what the norm will end up being. >> Here is example below: >> Here we have the new layout with IPV6, the below works fine, however since >> the ifconfig lines for IPV4 and IPV6 are essentially the same other than the >> actual "inet" and "inet6", will it be ok to start with alias0 for both IPV4 >> and IPV6, or should I in this example be starting at alias4 for IPV6? >> I would like idea to keep it way it is each protocal starting at alias0. >> >> >> #GATEWAY >> defaultrouter="67.159.46.233" >> hostname="sunsaturn.com" >> #IPV4 >> ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" >> ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" >> ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" >> ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" >> ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" >> >> #IPV6 >> ipv6_activate_all_interfaces="YES" >> ipv6_network_interfaces="em1" >> ipv6_defaultrouter="2001:49f0:4004:::::0001" >> ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 prefixlen >> 48" >> ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 prefixlen >> 48" >> ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 prefixlen >> 48" > > Remember that rc.conf follows shell syntax and sematics, so the second > _alias0 and _alias1 will overwrite the previous ones. > > In 9.0 you can use the ipv4_addrs_ variable to set both the IPv4 > "main" address as well as "alias" addresses, see rc.conf(5). There doesn't > seem to be an equivalent IPv6 option, as best as I can tell. > > > Stefan ___ 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"
Heads Up: NFS server will now use LK_SHARED vnode locks
Hi, I have just committed r227809 to head/current which enables the new/default NFS server's use of shared vnode locks for Read, Readdir, Readlink, Getattr and Access. Although it is hoped that this will improve performance for these operations when multiple ones are performed concurrently on the same file/vnode, I thought I should give a heads up. Why? Well it is conceivable that this may have negative issues that I haven't seen in testing along the lines of overloading a server, due to the lack of serialization of the above RPCs for the same file/vnode. If anyone encounters problems with their NFS server after upgrading to post-r227809, please email and let me know. rick ___ 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"
did SVN r227753 (locale changes) break something?
VLC (multimedia/vlc) on my -current now crashes leaving a trace like this .. imb@toshi:/home/imb> gdb `which vlc` vlc.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `vlc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libvlc.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvlc.so.7 Reading symbols from /usr/local/lib/libvlccore.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libvlccore.so.4 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x283eb243 in fprintf () from /lib/libc.so.7 [New Thread 28804300 (LWP 100408/vlc)] (gdb) bt #0 0x283eb243 in fprintf () from /lib/libc.so.7 #1 0x283eb558 in uselocale () from /lib/libc.so.7 #2 0x283eb6f9 in newlocale () from /lib/libc.so.7 #3 0x281637f2 in msg_Subscribe () from /usr/local/lib/libvlccore.so.4 #4 0x in ?? () #5 0x28191f6f in .rodata () from /usr/local/lib/libvlccore.so.4 #6 0x28420120 in _CurrentRuneLocale () from /lib/libc.so.7 #7 0x in ?? () #8 0x281a3ee0 in .got () from /usr/local/lib/libvlccore.so.4 #9 0x288400fc in ?? () #10 0x288400fc in ?? () #11 0x280ca9b6 in libvlc_InternalCreate () from /usr/local/lib/libvlccore.so.4 #12 0x281a4df4 in .bss () from /usr/local/lib/libvlccore.so.4 #13 0x005c in ?? () #14 0xfd66 in ?? () #15 0x281861d4 in .rodata () from /usr/local/lib/libvlccore.so.4 #16 0x0440 in ?? () #17 0x0001 in ?? () #18 0x in ?? () #19 0x280b4ad0 in .got () from /usr/local/lib/libvlc.so.7 #20 0xbfbfe640 in ?? () #21 0x0002 in ?? () #22 0xbfbfe678 in ?? () #23 0x280a39b2 in libvlc_new () from /usr/local/lib/libvlc.so.7 Previous frame inner to this frame (corrupt stack?) (gdb) ___ 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"
/usr/home vs /home
Hi, In the old days home was typically a separate partition that was mounted on /home. If you didn't have a partition the installer would create /usr/home and symlink /home to it. The root was also typically an independent partition, so it made sense not to clutter it up with home directories. Now that the default behavior is to use one big partition, the installer defaults to /usr/home + symlink. I've always liked the more succinct /home and was wondering if there is any reason why not to delete the symlink and move home to / to mimic the old many partition style? thanks, dave c ___ 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: Buildworld broken with clang on current
this was broken by the xlocale import, David, can you fix this please? I guess that just removing the typedef from strcasecmp.c should do it On Mon, Nov 21, 2011 at 12:59:38PM -0800, Manfred Antar wrote: > make buildworld is broken iif using clang on current i386 > > (libc)5027}make > clang -O2 -pipe -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 > -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE > -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP > -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING > -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/string/strcasecmp.c > /usr/src/lib/libc/string/strcasecmp.c:45:23: error: redefinition of typedef > 'u_char' is invalid in C > [-Wtypedef-redefinition] > typedef unsigned char u_char; > ^ > /usr/include/sys/types.h:50:23: note: previous definition is here > typedef unsigned char u_char; > ^ > 1 error generated. > *** Error code 1 > > Stop in /usr/src/lib/libc. > > > > > || n...@pozo.com || > || Ph. (415) 681-6235 || > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > ___ > 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" ___ 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"
Buildworld broken with clang on current
make buildworld is broken iif using clang on current i386 (libc)5027}make clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/string/strcasecmp.c /usr/src/lib/libc/string/strcasecmp.c:45:23: error: redefinition of typedef 'u_char' is invalid in C [-Wtypedef-redefinition] typedef unsigned char u_char; ^ /usr/include/sys/types.h:50:23: note: previous definition is here typedef unsigned char u_char; ^ 1 error generated. *** Error code 1 Stop in /usr/src/lib/libc. || n...@pozo.com || || Ph. (415) 681-6235 || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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"
9.0-RC2 - bsdinstall overwrites /etc/fstab and spams /etc/rc.conf after edits in shell
Fresh install of 9.0RC2. Which comes first the, installer writing config files, or user using live shell to write custom config files? On the "Final Configuration' screen I have the option to change several options like hostname/root password/network/etc.etc and final option is: "Open a shell in the new system" I used that option to create /etc/fstab with /dev/gpt/label for my partitions. After I reboot, my 'fstab' changes were overwritten with the installer /dev/ada0p# devices. Another file I tested is '/etc/rc.conf' - it just gets appended and the 'hostname=' entry is added on the very first line, so my entries stayed in the middle. I understand "Open a shell in the new system" is with the config files already written and are 'editable' but that is not the case. What else is touched in that final 'Exit' that will overwrite changes made in 'shell' ? How about adding that option into the last 'Complete' dialog where the configs are all written and are safe to edit and have three options: ? ]Peter[ Just a complain...errr...tester. ___ 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: rc.conf changes IPV6
Am 21.11.2011 um 20:25 schrieb Dan The Man: > I notice we have changed way IPV6 is done in rc.conf now. > I assume someone will update: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html > > My question now concerns aliases, and what the norm will end up being. > Here is example below: > Here we have the new layout with IPV6, the below works fine, however since > the ifconfig lines for IPV4 and IPV6 are essentially the same other than the > actual "inet" and "inet6", will it be ok to start with alias0 for both IPV4 > and IPV6, or should I in this example be starting at alias4 for IPV6? > I would like idea to keep it way it is each protocal starting at alias0. > > > #GATEWAY > defaultrouter="67.159.46.233" > hostname="sunsaturn.com" > #IPV4 > ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" > ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" > ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" > ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" > ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" > > #IPV6 > ipv6_activate_all_interfaces="YES" > ipv6_network_interfaces="em1" > ipv6_defaultrouter="2001:49f0:4004:::::0001" > ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 prefixlen 48" > ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 prefixlen > 48" > ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 prefixlen > 48" Remember that rc.conf follows shell syntax and sematics, so the second _alias0 and _alias1 will overwrite the previous ones. In 9.0 you can use the ipv4_addrs_ variable to set both the IPv4 "main" address as well as "alias" addresses, see rc.conf(5). There doesn't seem to be an equivalent IPv6 option, as best as I can tell. Stefan -- Stefan BethkeFon +49 151 14070811 ___ 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"
9.0-RC2 - bsdinstall - new user group
Doing a fresh install of 9.0RC2 [amd64]. Add User Accounts -> Yes [stuff between '*' is my input/answers] Username: *peter* Full name: *P* UID: [default] Login group [peter]: *admin* Group admin does not exist! Login group [peter]: *ENTER* Login group is peter. Invite peter into other groups? []? . .. Why can the installer create a new login group 'peter' but not a new login group 'admin' ?. [when adding second user, I can input Login Group of 'peter' without any problems, or third user can create a group name of its name, but still no 'admin' group unless I add an 'admin' user]. ]Peter[ No biggie, just always have to remember to edit /etc/group. ___ 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"
rc.conf changes IPV6
I notice we have changed way IPV6 is done in rc.conf now. I assume someone will update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-ipv6.html My question now concerns aliases, and what the norm will end up being. Here is example below: Here we have the new layout with IPV6, the below works fine, however since the ifconfig lines for IPV4 and IPV6 are essentially the same other than the actual "inet" and "inet6", will it be ok to start with alias0 for both IPV4 and IPV6, or should I in this example be starting at alias4 for IPV6? I would like idea to keep it way it is each protocal starting at alias0. #GATEWAY defaultrouter="67.159.46.233" hostname="sunsaturn.com" #IPV4 ifconfig_em1="inet 67.159.46.238 netmask 255.255.255.248" ifconfig_em1_alias0="inet 67.159.46.234 netmask 255.255.255.248" ifconfig_em1_alias1="inet 67.159.46.235 netmask 255.255.255.248" ifconfig_em1_alias2="inet 67.159.46.236 netmask 255.255.255.248" ifconfig_em1_alias3="inet 67.159.46.237 netmask 255.255.255.248" #IPV6 ipv6_activate_all_interfaces="YES" ipv6_network_interfaces="em1" ipv6_defaultrouter="2001:49f0:4004:::::0001" ifconfig_em1_ipv6="inet6 2001:49f0:4004:::::0002 prefixlen 48" ifconfig_em1_alias0="inet6 2001:49f0:4004:::::0003 prefixlen 48" ifconfig_em1_alias1="inet6 2001:49f0:4004:::::0004 prefixlen 48" Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.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: 9RC2 amd64 "Can't work out which disk we are booting from"
> But I have not found what it was, and switched to build i386 images only > yet. Indeed, only amd64 has this problem. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5011412.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: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
> On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: >> On 11/18/11 17:09, nev...@tx.net wrote: >> > >> > If you are performating a manual partion in 9.0-RC2 bsdinstall and you >> > delete any created partition except the most recently created one, the >> > total remaining space will be miscalculated. Reproducable as shown >> > below. >> > >> > Workaround: if you delete a partition that is not the last partition >> > that was created, delete all partitions created after that partition >> > before continuing. Order does not seem to be important. >> > >> > The results are similar with other hard drive sizes, with the i386 or >> > amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go >> > back and check install discs prior to RC1) >> > >> > Reproducing the miscount: >> > >> > A 114 GB drive is used for this example: >> > >> > Select Manual Partitioning >> > >> > Perform the first Create on the drive and select GPT >> > >> > Creating the first partition: "Add Partition" "size" shows 114GB >> > >> > Change size to 4GB, set mountpoint to / and tab to OK >> > (agree to the boot partition creation) >> > >> > Create a second partition: "Add Partition" "size" shows 110GB >> > >> > Adjust size to 10GB, set mountpoint to /usr and tab to OK >> > >> > Create a third partition: "Add Partition" "size" shows 100GB >> > >> > Adjust size to 20GB, set mountpoint to /var, and tab to OK >> > >> > Create a 4th partition: "size" shows 80GB remaining >> > >> > Adjust size to 40GB, set mountpoint to /data, and tab to OK. >> > >> > There is 40 GB remaining on the drive. Now change the size of /var. >> > First, delete the currently configured /var partition. >> > >> > In the Partition Editor, adding up all the lines on the screen shows >> > 54GB (plus a 64K boot) as allocated, so there should now be 60GB >> > remaining. But the deleted /var space has not been added back into >> > the total. >> > >> > Select Create again: "Add Partition" "size" shows 40GB >> > >> >Adjust size to 30GB, set mountpoint as /var, tab to OK >> > >> > A subsequent "Create" will show that 20GB is remaining, rather than >> > the actual remaining 30GB. Selecting any size 20GB or larger for >> > /home will give you a 20GB partition, and then an additional create >> > will show the 10GB. >> >> This isn't a bug. The partitions are laid out on disk already, and, >> because you deleted one in the middle, the largest *contiguous* block of >> free space is 20GB, which is what is shown and the maximum it is >> possible to create. That's why you can make one 20 GB partition and one >> 10 GB partition, but not a single 30 GB one. > > Except that this is not intuitive. If I'm laying out a disk and haven't > committed the changes yet, it should be possible to do things like resize > an existing partition, or have the installer realize that if you delete > one partition the other partitions that are pending should just "move up" > to maximize free space automatically. I ran into this when first trying > the new installer last week where you could not modify a pending > partition's > size which I found non-intuitive. > > -- > John Baldwin > ___ Issue is not just because of deleting a partition in the middle, but also because the installer doesn't use up 100% of the remaining disk space... I'm doing an install onto a 232GB drive now. Deleted all partitions, and created the following: ada0p1 64KB freebsd-boot ada0p2 10GB freebsd-ufs / ada0p3 1GB freebsd-swap none When I go to create 'p4' it automatically fills the disk space to 221GB, so now I have: ada0p4 221GB freebsd-ufs /data ..BUT I can still create 'p5' with a size of 907MB! Workaround is to delete 'p4' and hit 'Create' but for size instead of accepting default of '221GB' I input '321GB' [well over the physical disk size] - It creates 'p5' with size 221GB and now when I go to create 'p5' I get the expected 'No free space left on device'. Both times the installer showed 221GB for /data, but one time it still had 907MB left to create a fifth partition - So it rounds down the 221.9GB to 221GB giving a false impression the disk is 100% full. and yes, when I delete 'p2' and my 221GB 'p4', I can create another partition of 221GB [which is now p2] and then create another 10GB partition which becomes p4. The installer should move swap to p2 and allow me to recreate p3 with size of 331GB instead of this result: ada0p1 64kB freebsd-boot ada0p3 1GB freebsd-swap ada0p2 221GB freebsd-ufs /data ada0p4 10GB freebsd-ufs / How did p2 become 221GB when originally it was only 10GB? Seems nothing is written to disk at this point and the installer should have dynamically "moved" p3 into p2, and allowed to use the remaining continous disk space for p3 of 331GB [after all, it moved 221GB from p4 to p2 without a problem]. ]Peter[ There are more "advanced user" installer issues which I'm documenting.
loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID
This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned it to a DVD. I have a computer that currently runs Windows 7 but I plan to install FreeBSD on it in the near future so I booted it up from the DVD to check the hardware/driver status. Much to my dismay, the boot loader crashed right away (register dump followed by "BTX halted") and the computer immediately rebooted. I took a video with my phone so I could capture the crash message, screenshot here: http://picpaste.com/pics/BTXcrash.1321899682.jpg I then tried tweaking a few BIOS settings and found that turning off the built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA type from "RAID" to "AHCI". Fortunately I plan to use the controller in AHCI mode for the FreeBSD installation so this won't end up being a problem for me, but I still thought it was worth reporting. The system in question has a Foxconn A7GM-S motherboard with AMD 780G (NB) and AMD SB700 chipsets. I have a two-disk mirror for the Windows installation which is why I had RAID mode enabled in the first place. In case jhb^H^H^Hsomeone is interested, below is the output from "dmesg" and "pciconf -lv" once I booted up in AHCI mode. Let me know if any additional information or tests would be helpful. Thanks! JN === dmesg === Copyright (c) 1992-2011 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 9.0-RC2 #0: Sat Nov 12 18:35:25 UTC 2011 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2767.66-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Family = f Model = 6b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f real memory = 8589934592 (8192 MB) avail memory = 7711911936 (7354 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <050410 APIC1120> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x/0x1 (20110527/tbfadt-586) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <050410 RSDT1120> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fec1, 20 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfe0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xc000-0xcfff,0xfe9f-0xfe9f,0xfe80-0xfe8f irq 18 at device 5.0 on pci1 hdac0: mem 0xfe9e8000-0xfe9ebfff irq 19 at device 5.1 on pci1 pcib2: irq 18 at device 2.0 on pci0 pci2: on pcib2 vgapci1: port 0xd000-0xd0ff mem 0xd000-0xdfff,0xfeaf-0xfeaf irq 18 at device 0.0 on pci2 hdac1: mem 0xfeaec000-0xfeae irq 19 at device 0.1 on pci2 pcib3: irq 17 at device 9.0 on pci0 pci3: on pcib3 re0: port 0xe800-0xe8ff mem 0xfebff000-0xfebf irq 17 at device 0.0 on pci3 re0: Using 1 MSI message re0: Chip rev. 0x3800 re0: MAC rev. 0x0040 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:1f:e2:55:1d:bc ahci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 17.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 18.0 on pci0 usbus0: on ohci0 ohci1: mem 0xfe7fd000-0xfe7fdfff irq 16 at device 18.1 on pci0 usbus1: on ohci1 ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 17 at device 18.2 on pci0 ehci0: AMD SB600/700 quirk applied usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.0 on pci0 usbus3: on ohci2 ohci3: mem 0xfe7f7000-0xfe7f7fff irq 18 at device 19.1 on pci0 usbus4: on ohci3 ehci1: mem 0xfe7f6800-0xfe7f68ff irq 19 at device 19.2 on pci0 ehci1: AMD SB600/700 quirk applied usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci0 ata1: on at
Re: Reprobing of devices after module load?
On 11/21/11, John Baldwin wrote: > On Friday, November 18, 2011 11:48:20 am Paul B. Mahol wrote: >> Hi, >> >> Is there nice way in FreeBSD to force reprobe of devices for specific >> driver like it is done when kernel module is loaded (via >> DRIVER_MODULE(...) stuff)? > > Note that those probes happen for specific buses rather than for specific > drivers. The routine that does this currently is static > (devclass_driver_added() in sys/kern/subr_bus.c). What specific problem are > you trying to solve? You might be able to use BUS_DRIVER_ADDED() or > device_probe_and_attach() to achieve what you are trying to do. I have changed NDISulator to load 3rd party *.SYS from userspace via ioctl on /dev/ndis. For now i can do reprobe by reloading if_ndis.ko module. Loading if_ndis.ko ideally should not cause reprobe but reprobe should be done after ioctl on /dev/ndis. Perhaps devclass_add_driver from sys/kern/subr_bus can do this? ___ 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: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On 11/21/11 11:52, John Baldwin wrote: On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: "Add Partition" "size" shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: "Add Partition" "size" shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: "Add Partition" "size" shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: "size" shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: "Add Partition" "size" shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent "Create" will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just "move up" to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. There doesn't seem to be an easy solution though. Not laying them out on disk is extremely fragile: the installer needs to know tons of tiny details about the partition schemes (alignment constraints, partition numbering/lettering, available space after the header, the list is very long) or it will break. One simple example is that whether a partition is ad0s1 or ad0s3 depends on its order on the disk (or in the partition table anyway). If I have an ad0s2 and s3, and delete the s2, should the new partition be s2 or s4? That depends on a lot of things the installer can't easily know about, and that even if it could, simulating which would be dangerous. -Nathan ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
(replying with Debian hat this time) 2011/11/21 Kostik Belousov : > There are some implementations that > use FreeBSD kernel, and which could potentially benefit from providing > its own value for __FreeBSD_kernel. Actually, we wouldn't be able to provide a different value for the macro (whatever its name). Our compiler simply doesn't know which version of the kernel it is building for. Only the headers do, but if we define it in the headers we'd just use the FreeBSD definitions. Our compiler defines __FreeBSD_kernel__ as an empty macro, I don't expect this will change because unlike with FreeBSD, on Debian there are strong technical limitations to making it a number. If __FreeBSD_kernel__ is to be defined in FreeBSD land, may I suggest that it is defined as an empty macro as well? This covers the vast majority of cases (e.g. like the ones in my initial patch which started this discussion), and it doesn't preclude the possibility that this macro becomes a number without breaking backward compatibility. OTOH once you define it as a number, it becomes relevant whether you did it with #ifndef or with #undef, and so you have to commit to it. Just to make it clear: It's no problem to me if it's defined as a number, but it doesn't help much either. At least from Debian POV it's not worth making a big argument about. It could be a good idea from FreeBSD POV, but please only do this if it's useful to FreeBSD. -- Robert Millan ___ 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: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: > On 11/18/11 17:09, nev...@tx.net wrote: > > > > If you are performating a manual partion in 9.0-RC2 bsdinstall and you > > delete any created partition except the most recently created one, the > > total remaining space will be miscalculated. Reproducable as shown > > below. > > > > Workaround: if you delete a partition that is not the last partition > > that was created, delete all partitions created after that partition > > before continuing. Order does not seem to be important. > > > > The results are similar with other hard drive sizes, with the i386 or > > amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go > > back and check install discs prior to RC1) > > > > Reproducing the miscount: > > > > A 114 GB drive is used for this example: > > > > Select Manual Partitioning > > > > Perform the first Create on the drive and select GPT > > > > Creating the first partition: "Add Partition" "size" shows 114GB > > > > Change size to 4GB, set mountpoint to / and tab to OK > > (agree to the boot partition creation) > > > > Create a second partition: "Add Partition" "size" shows 110GB > > > > Adjust size to 10GB, set mountpoint to /usr and tab to OK > > > > Create a third partition: "Add Partition" "size" shows 100GB > > > > Adjust size to 20GB, set mountpoint to /var, and tab to OK > > > > Create a 4th partition: "size" shows 80GB remaining > > > > Adjust size to 40GB, set mountpoint to /data, and tab to OK. > > > > There is 40 GB remaining on the drive. Now change the size of /var. > > First, delete the currently configured /var partition. > > > > In the Partition Editor, adding up all the lines on the screen shows > > 54GB (plus a 64K boot) as allocated, so there should now be 60GB > > remaining. But the deleted /var space has not been added back into > > the total. > > > > Select Create again: "Add Partition" "size" shows 40GB > > > >Adjust size to 30GB, set mountpoint as /var, tab to OK > > > > A subsequent "Create" will show that 20GB is remaining, rather than > > the actual remaining 30GB. Selecting any size 20GB or larger for > > /home will give you a 20GB partition, and then an additional create > > will show the 10GB. > > This isn't a bug. The partitions are laid out on disk already, and, > because you deleted one in the middle, the largest *contiguous* block of > free space is 20GB, which is what is shown and the maximum it is > possible to create. That's why you can make one 20 GB partition and one > 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just "move up" to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. -- 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: ixgbe and fast interrupts
On Mon, Nov 21, 2011 at 11:29:29AM -0500, John Baldwin wrote:
> On Friday, November 18, 2011 5:04:58 pm Luigi Rizzo wrote:
> > On Fri, Nov 18, 2011 at 11:16:00AM -0800, Doug Barton wrote:
> > > On 11/18/2011 09:54, Luigi Rizzo wrote:
> > > > One more thing (i am mentioning it here for archival purposes,
> > > > as i keep forgetting to test it). Is entropy harvesting expensive ?
> > >
> > > No. It was designed to be inexpensive on purpose. :)
> >
> > hmmm
> > unfortunately I don't have a chance to test it until monday
> > (probably one could see if the ping times change by modifying
> > the value of kern.random.sys.harvest.* ).
> >
> > But in the code i see the following:
> >
> > - the harvest routine is this:
> >
> > void
> > random_harvest(void *entropy, u_int count, u_int bits, u_int frac,
> > enum esource origin)
> > {
> > if (reap_func)
> > (*reap_func)(get_cyclecount(), entropy, count, bits, frac,
> > origin);
> > }
> >
> > - the reap_func seems to be bound to
> >
> > dev/random/randomdev_soft.c::random_harvest_internal()
> >
> > which internally uses a spinlock and then moves entries between
> > two lists.
> >
> > I am concerned that the get_cyclecount() might end up querying an
> > expensive device (is it using kern.timecounter.hardware ?)
>
> On modern x86 it just does rdtsc().
>
> > So between the indirect function call, spinlock, list manipulation
> > and the cyclecounter i wouldn't be surprised it the whole thing
> > takes a microsecond or so.
>
> I suspect it is not quite that expensive.
>
> > Anyways, on monday i'll know better. in the meantime, if someone
> > wants to give it a try... in our tests between two machines and
> > ixgbe (10G) interfaces, an unmodified 9.0 kernel has a median ping
> > time of 30us with "slow" pings (say -i 0.01 or larger) and 17us with
> > a ping -f .
>
> Did you time it with harvest.interrupt disabled?
yes, thanks for reminding me to post the results.
Using unmodified ping (which has 1us resolution on the reports),
there is no measurable difference irrespective
of the setting of kern.random.sys.harvest.ethernet,
kern.random.sys.harvest.interrupt and kern.timecounter.hardware.
Have tried to set hw mitigation to 0 on the NIC (ixgbe on both
sides) but there is no visible effect either.
However I don't trust my measurements because i cannot explain them.
Response times have a min of 20us (about 50 out of 5000 samples)
and a median of 27us, and i really don't understand if the low
readings are real or the result of some races.
Ping does a gettimeofday() for the initial timestamp, and relies
on in-kernel timestamp for the response.
cheers
luigi
___
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: Reprobing of devices after module load?
On Nov 21, 2011, at 9:26 AM, John Baldwin wrote: > On Friday, November 18, 2011 11:48:20 am Paul B. Mahol wrote: >> Hi, >> >> Is there nice way in FreeBSD to force reprobe of devices for specific >> driver like it is done when kernel module is loaded (via >> DRIVER_MODULE(...) stuff)? > > Note that those probes happen for specific buses rather than for specific > drivers. The routine that does this currently is static > (devclass_driver_added() in sys/kern/subr_bus.c). What specific problem are > you trying to solve? You might be able to use BUS_DRIVER_ADDED() or > device_probe_and_attach() to achieve what you are trying to do. You can load a dummy module that has an attach point to the bus that you're wanting to force a rescan on. Warner ___ 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: Stop scheduler on panic
2011/11/21 John Baldwin : > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: >> on 17/11/2011 23:38 John Baldwin said the following: >> > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: >> >> Hmmm, you could also make critical_exit() not perform deferred preemptions >> >> if SCHEDULER_STOPPED? That would fix the recursion and still let the >> >> preemption "work" when resuming from the debugger? >> >> Yes, that's a good solution, I think. I just didn't want to touch such a >> "low >> level" code, but I guess there is no rational reason for that. >> >> > Or you could let the debugger run in a permament critical section (though >> > perhaps that breaks too many other things like debugger routines that try >> > to use locks like the 'kill' command (which is useful!)). Effectively >> > what you >> > are trying to do is having the debugger run in a critical section until the >> > debugger is exited. It would be cleanest to let it run that way explicitly >> > if possible since then you don't have to catch as many edge cases. >> >> I like this idea, but likely it would take some effort to get done. > > Yes, it would take some effort, so checking SCHEDULER_STOPPED in > critical_exit() is probably good for the short term. Would be nice to fix > it properly some day. > >> Related to this is something that I attempted to discuss before. I think >> that >> because the debugger acts on a frozen system image (the debugger is a sole >> actor >> and observer), the debugger should try to minimize its interaction with the >> debugged system. In this vein I think that the debugger should also bypass >> any >> locks just like with SCHEDULER_STOPPED. The debugger should also be careful >> to >> note a state of any subsystems that it uses (e.g. the keyboard) and return >> them >> to the initial state if it had to be changed. But that's a bit different >> story. >> And I really get beyond my knowledge zone when I try to think about things >> like >> handling 'call func_' in the debugger where func_ may want to acquire >> some locks or noticeably change some state within a system. > > I think to some extent, I think if a user calls a function from the debugger > they better know what they are doing. However, I think it can also be useful > to have the debugger modify the system in some cases if it can safely do so > (e.g. the 'kill' command from DDB can be very useful, and IIRC, it is careful > to only use try locks and just fail if it can't acquire the needed locks). I would be very in favor about having a 'thread trampoline for KDB', thus that it can use locks. The only downside is that it assume an healthy state of the switching infrastructure, so maybe it would be fine to wrapper this under a proper compile-time option (KDB_LITE -> it will run in interrupt context and the users will better know what they do). 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: Stop scheduler on panic
On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: > on 17/11/2011 23:38 John Baldwin said the following: > > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: > >> Hmmm, you could also make critical_exit() not perform deferred preemptions > >> if SCHEDULER_STOPPED? That would fix the recursion and still let the > >> preemption "work" when resuming from the debugger? > > Yes, that's a good solution, I think. I just didn't want to touch such a "low > level" code, but I guess there is no rational reason for that. > > > Or you could let the debugger run in a permament critical section (though > > perhaps that breaks too many other things like debugger routines that try > > to use locks like the 'kill' command (which is useful!)). Effectively what > > you > > are trying to do is having the debugger run in a critical section until the > > debugger is exited. It would be cleanest to let it run that way explicitly > > if possible since then you don't have to catch as many edge cases. > > I like this idea, but likely it would take some effort to get done. Yes, it would take some effort, so checking SCHEDULER_STOPPED in critical_exit() is probably good for the short term. Would be nice to fix it properly some day. > Related to this is something that I attempted to discuss before. I think that > because the debugger acts on a frozen system image (the debugger is a sole > actor > and observer), the debugger should try to minimize its interaction with the > debugged system. In this vein I think that the debugger should also bypass > any > locks just like with SCHEDULER_STOPPED. The debugger should also be careful > to > note a state of any subsystems that it uses (e.g. the keyboard) and return > them > to the initial state if it had to be changed. But that's a bit different > story. > And I really get beyond my knowledge zone when I try to think about things > like > handling 'call func_' in the debugger where func_ may want to acquire > some locks or noticeably change some state within a system. I think to some extent, I think if a user calls a function from the debugger they better know what they are doing. However, I think it can also be useful to have the debugger modify the system in some cases if it can safely do so (e.g. the 'kill' command from DDB can be very useful, and IIRC, it is careful to only use try locks and just fail if it can't acquire the needed locks). > But to continue about the locks... I have this idea to re-implement > SCHEDULER_STOPPED as some more general check that could be abstractly denoted > as > LOCKING_POLICY_CHECK(context). Where the context could be defined by flags > like > normal, in-panic, in-debugger, etc. And the locking policies could be: > normal, > bypass, warn, panic, etc. > > However, I am not sure if this could be useful (and doable properly) in > practice. I am just concerned with the interaction between the debugger and > the > locks. It still seems to me inconsistent that we are going with > SCHEDULER_STOPPED for panic, but we are continuing to use "if (!kdb_active)" > around some locks that could be problematic under kdb (e.g. in USB). In my > opinion the amount of code shared between normal context and kdb context is > about the same as amount of code shared between normal context and panic > context. But I haven't really quantified those. I think you need to keep the 'kill' case in mind. In that case you don't want to ignore locks, but the code is carefully written to use try locks instead (or should be). -- 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: ixgbe and fast interrupts
On Friday, November 18, 2011 5:04:58 pm Luigi Rizzo wrote:
> On Fri, Nov 18, 2011 at 11:16:00AM -0800, Doug Barton wrote:
> > On 11/18/2011 09:54, Luigi Rizzo wrote:
> > > One more thing (i am mentioning it here for archival purposes,
> > > as i keep forgetting to test it). Is entropy harvesting expensive ?
> >
> > No. It was designed to be inexpensive on purpose. :)
>
> hmmm
> unfortunately I don't have a chance to test it until monday
> (probably one could see if the ping times change by modifying
> the value of kern.random.sys.harvest.* ).
>
> But in the code i see the following:
>
> - the harvest routine is this:
>
> void
> random_harvest(void *entropy, u_int count, u_int bits, u_int frac,
> enum esource origin)
> {
> if (reap_func)
> (*reap_func)(get_cyclecount(), entropy, count, bits, frac,
> origin);
> }
>
> - the reap_func seems to be bound to
>
> dev/random/randomdev_soft.c::random_harvest_internal()
>
> which internally uses a spinlock and then moves entries between
> two lists.
>
> I am concerned that the get_cyclecount() might end up querying an
> expensive device (is it using kern.timecounter.hardware ?)
On modern x86 it just does rdtsc().
> So between the indirect function call, spinlock, list manipulation
> and the cyclecounter i wouldn't be surprised it the whole thing
> takes a microsecond or so.
I suspect it is not quite that expensive.
> Anyways, on monday i'll know better. in the meantime, if someone
> wants to give it a try... in our tests between two machines and
> ixgbe (10G) interfaces, an unmodified 9.0 kernel has a median ping
> time of 30us with "slow" pings (say -i 0.01 or larger) and 17us with
> a ping -f .
Did you time it with harvest.interrupt disabled?
--
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: Reprobing of devices after module load?
On Friday, November 18, 2011 11:48:20 am Paul B. Mahol wrote: > Hi, > > Is there nice way in FreeBSD to force reprobe of devices for specific > driver like it is done when kernel module is loaded (via > DRIVER_MODULE(...) stuff)? Note that those probes happen for specific buses rather than for specific drivers. The routine that does this currently is static (devclass_driver_added() in sys/kern/subr_bus.c). What specific problem are you trying to solve? You might be able to use BUS_DRIVER_ADDED() or device_probe_and_attach() to achieve what you are trying to do. -- 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: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
On Mon, Nov 21, 2011 at 01:45:29PM +1100, Bruce Evans wrote: > On Sun, 20 Nov 2011, Kostik Belousov wrote: > > >On Sun, Nov 20, 2011 at 12:40:42PM +0100, Robert Millan wrote: > >>On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote: > >>>I fully agree with an idea that compiler is not an authorative source > >>>of the knowledge of the FreeBSD version. Even more, I argue that we shall > >>>not rely on compiler for this at all. Ideally, we should be able to > >>>build FreeBSD using the stock compilers without local modifications. > >>>Thus relying on the symbols defined by compiler, and not the source > >>>is the thing to avoid and consistently remove. > >>> > >>>We must do this to be able to use third-party tooldchain for FreeBSD > >>>builds. > >>> > >>>That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version > >>>? > >>>And then make more strong wording about other systems that use the macro, > >>>e.g. remove 'may' from the kFreeBSD example. > >>>Also, please remove the smile from comment. > >> > >>Ok. New patch attached. > > > >And the last, question, why not do > >#ifndef __FreeBSD_kernel__ > >#define __FreeBSD_kernel__ __FreeBSD_version > >#endif > >? > > > >#undef is too big tools tool apply there, IMO. > > #ifndef is too big to apply here, IMO :-). __FreeBSD_kernel__ is in the > implementation namespace, so any previous definition of it is a bug. The > #ifndef breaks the warning for this bug. FreeBSD does not need it at all. There are some implementations that use FreeBSD kernel, and which could potentially benefit from providing its own value for __FreeBSD_kernel. I was only tried to be nice for the out-of-tree implementations, it boils down to kFreeBSD project preferences. > > And why not use FreeBSD style? In KNF, the fields are separated by > tabs, not spaces. In FreeBSD style, trailing underscores are not used > for names in the implementation namespace, since they have no effect > on namespaces. The name __FreeBSD_version is an example of this. Does > existing practice require using the name with the trailing underscores? pgpM8lL9ZnvAT.pgp Description: PGP signature
