Re: some usb troubles
On Sun, Feb 10, 2013 at 12:03:36PM +0100, Hans Petter Selasky wrote: On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: Hi all, trying to run macbookpro10,1 on HEAD: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) Between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can find here: http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt I found the commit that broke usb support: r239340 - merge acpica. pciconf: http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt any help would be greatly apprecated. -- Have fun! chd pgp3h69DSpjWx.pgp Description: PGP signature
Re: ports include /etc/src.conf? i.e. graphics/libfpx
On 2013/02/15 05:57, O. Hartmann wrote: Am 02/14/13 14:19, schrieb Yamaya Takashi: On 2013/02/13 22:33, Tom Evans wrote: On Wed, Feb 13, 2013 at 12:30 PM, Yamaya Takashi yama...@kbh.biglobe.ne.jp wrote: On 2013/02/13 19:08, O. Hartmann wrote: Setting only base system source compiler optins in /etc/src.conf, for instance # CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 which do NOT appear in /etc/make.conf, make building port grahpics/libfpx complaining about unrecognized compiler options. As far a sI know, /etc/src.conf is ONLY for building the source tree of the operating system and make.conf is supposed to contain all stuff necessary for compiling both world and ports, but /etc/src.conf is world only. Am I wrong? Oliver Yes. Because files/Makefile.bsd includes bsd.lib.mk, /etc/src.conf is included. src.conf(5) says: The only purpose of src.conf is to control the compilation of the FreeBSD source code, which is usually located in /usr/src. Cheers Tom src.conf(5) says: The values of variables are ignored regardless of their setting; even if they would be set to ``FALSE'' or ``NO''. Just the existence of an option will cause it to be honoured by make(1). The following list provides a name and short description for variables that can be used for source builds. Does it mean ONLY WITH_* and WITHOUT_* variables are allowed in /etc/src.conf? Shortly, there was a discussion about a fully installed LLVM/CLANG and the portion of LLVM/CLANG, that is only needed to compile the system's source. In this case, a strict separartion was intended. Not about llvm/clang. Including /etc/src.conf has problem of conflicting world knob and port knob. Skipping to include /etc/src.conf by bsd.own.mk is needed. It's difficult for base system. Then bsd.port.mk define _WITHOUT_SRCCONF and skip including /etc/src.conf. But some ports include bsd.*.mk (exclude bsd.port*.mk) has bug, because they don't define _WITHOUT_SRCCONF. If the manpage of /etc/src.conf says that only bool knobs are allowed like WITH_XXX or WITHOUT_XXX, then: where to put the options? NOT bool, the variable is defined or not. The options are written in /etc/make.conf ___ 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: CLANG and -fstack-protector
On Wed, Feb 13, 2013 at 4:22 AM, Dmitry Marakasov amd...@amdmi3.ru wrote: * Kimmo Paasiala (kpaas...@gmail.com) wrote: Does the -fstack-protector option work on CLANG 3.1 and 3.2? There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 You might be interested in this patch: https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector afaik, in prior discussion some years ago an issue was mentioned that some ports don't build with stack-protector, so I suggested to introduce STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by enabling stack protector are not transient, so we can have an exp-run to just mark all uncompatible ports and consider all others compatible). If there's interest in this, I can refresh the patch and submit it. Yes, this is very much what I had in mind. Please submit it :) -Kimmo ___ 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: Possible bug in NFSv4 with krb5p security?
On 17 February 2013 02:17, Doug Rabson d...@rabson.org wrote: I think it was Rick that mentioned the patch. I would apply the patch and rebuild your kernel in the interests of changing as little as possible while debugging the original issue. Fair enough. I did this. Thanks. Now, I'm sorry for asking something that should be obvious, but how can I rebuild crypto/heimdal? There is no Makefile in this directory, but when I did make world it did build it. So how does this actually work? Is there a special Makefile somewhere else that I should use? I need to be able to rebuild these things withou thaving to do a full make world, which is the only way I figured out so far. (of course, I could do a automake/configure/make sequence, but it seems as though the official FreeBSD build doesn't do this (I couldn't find any config.log file dropped from the configure script)). Regards, Elias ___ 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: Possible bug in NFSv4 with krb5p security?
Elias Martenson wrote: On 17 February 2013 02:17, Doug Rabson d...@rabson.org wrote: I think it was Rick that mentioned the patch. I would apply the patch and rebuild your kernel in the interests of changing as little as possible while debugging the original issue. Fair enough. I did this. Thanks. Now, I'm sorry for asking something that should be obvious, but how can I rebuild crypto/heimdal? I think the Makefiles are in the kerberos5 directory. Since the only function you care about is the one in kerberos5/lib/libgssapi_krb5/pname_to_uid.c, I'd just put a copy of that file in usr.sbin/gssd and modify the Makefile there to compile it and link its .o into gssd, avoiding rebuilding any libraries. I'd put a couple of fprintf(stderr, ...) in it and then run gssd -d and see what it says. Just how I'd attack it, rick There is no Makefile in this directory, but when I did make world it did build it. So how does this actually work? Is there a special Makefile somewhere else that I should use? I need to be able to rebuild these things withou thaving to do a full make world, which is the only way I figured out so far. (of course, I could do a automake/configure/make sequence, but it seems as though the official FreeBSD build doesn't do this (I couldn't find any config.log file dropped from the configure script)). Regards, Elias ___ 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
Re: gpart, slice starts at 0
On Sun, 17 Feb 2013, Erich Dollansky wrote: gpart destroy -F da0 diskinfo da0 dd if=/dev/zero of=/dev/da0 bs=512 count=34 dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 Someone here on the lists (I unfortunately forget who) showed a sneaky easier way to do this: gpart destroy -F da0 gpart create -s gpt da0 gpart destroy -F da0 This did not make a difference. It's an easier way to destroy the backup table at the end of the disk, whether one was there before or not, without having to calculate the location. gpart show -p da0 gpart create -s MBR da0 gpart add -t freebsd da0 gpart show -p da0 gpart show -p da0s1 gpart set -a active -i 1 da0 # # The following line always gives an error: # # gpart create -s BSD da0s1 'destroy' is not recursive. It destroys the geom found on the device given, but does not write to any geoms inside those geoms. This is obvious. What surprises me is that create does not write a new and empty description to the disk. It does, but not being recursive, it does not destroy the geoms inside the one given to the command (da0). You had: da0 (MBR) da0s1 (bsdlabel) After the destroy, it became da0 (null) da0s1 (bsdlabel) This can happen with any of the setups where there are geoms inside other geoms. The second part of your question, about da0 starting a block zero: [X220]...Appl/Some Tools (root) gpart show da0 = 63 312581745 da0 MBR (149G) 63 3125817451 freebsd [active] (149G) [X220]...Appl/Some Tools (root) gpart show da0s1 =0 312581745 da0s1 BSD (149G) 0 312581745 - free - (149G) That shows slice one starts at block 63, standard for MBR. The space inside the slice (da0s1) starts at block 0 *of the slice*. This is a bit confusing for me but it does not really matter as long as the programs get it straight. This is again because of the geom inside a geom setup. The actual start block is the start of the slice (block 63) plus the start of the FreeBSD partition inside the slice (currently 0). When you create FreeBSD partitions inside da0s1, they will have nonzero offsets from the start of the slice. There are examples shown here: http://forums.freebsd.org/showpost.php?p=206204postcount=11 ___ 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: [head tinderbox] failure on powerpc64/powerpc
On Feb 16, 2013, at 2:05 PM, Dag-Erling Smørgrav d...@des.no wrote: FreeBSD Tinderbox tinder...@freebsd.org writes: cc -O2 -pipe -I/src/lib/libldns/../../contrib/ldns -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libldns/../../contrib/ldns/dnssec_verify.c -o dnssec_verify.o cc1: warnings being treated as errors /src/lib/libldns/../../contrib/ldns/dnssec_verify.c:638: warning: ldns_dnssec_trust_tree_print_sm' defined but not used *** [dnssec_verify.o] Error code 1 Stop in /src/lib/libldns. Why is this happening? The Makefile sets WARNS to 3, which adds -Wno-unused-function to CFLAGS, which should suppress this warning. I don't see -Wno-unused-function above. I only see -Wno-unused-parameter. I also don't see -Wno-parentheses-equality nor -Wno-conversion, so I guess that means that the set of flags applicable for WARNS=3 isn't being taken. It looks like WARNS is in fact 3: eris% make -V WARNS 3 Since bsd.sys.mk has grown unreadable, try unraveling the conditionals to see if WARNS for GCC does the equivalent for CLANG. Is the problem specific to architectures that don't use CLANG? -- Marcel Moolenaar mar...@xcllnt.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: gpart, slice starts at 0
Hi, On Sun, 17 Feb 2013 09:11:48 -0700 (MST) Warren Block wbl...@wonkity.com wrote: On Sun, 17 Feb 2013, Erich Dollansky wrote: gpart destroy -F da0 diskinfo da0 dd if=/dev/zero of=/dev/da0 bs=512 count=34 dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 Someone here on the lists (I unfortunately forget who) showed a sneaky easier way to do this: gpart destroy -F da0 gpart create -s gpt da0 gpart destroy -F da0 This did not make a difference. It's an easier way to destroy the backup table at the end of the disk, whether one was there before or not, without having to calculate the location. ok, so, I should keep this then. gpart show -p da0 gpart create -s MBR da0 gpart add -t freebsd da0 gpart show -p da0 gpart show -p da0s1 gpart set -a active -i 1 da0 # # The following line always gives an error: # # gpart create -s BSD da0s1 'destroy' is not recursive. It destroys the geom found on the device given, but does not write to any geoms inside those geoms. This is obvious. What surprises me is that create does not write a new and empty description to the disk. It does, but not being recursive, it does not destroy the geoms inside the one given to the command (da0). You had: da0 (MBR) da0s1 (bsdlabel) After the destroy, it became da0 (null) da0s1 (bsdlabel) It seems that we talk here about the same with very different words. The effect comes from the fact that the entries are always on the same location on a disk. The advantage is that repartitioning a disk stills leaves some room for recovery. This can happen with any of the setups where there are geoms inside other geoms. The second part of your question, about da0 starting a block zero: [X220]...Appl/Some Tools (root) gpart show da0 = 63 312581745 da0 MBR (149G) 63 3125817451 freebsd [active] (149G) [X220]...Appl/Some Tools (root) gpart show da0s1 =0 312581745 da0s1 BSD (149G) 0 312581745 - free - (149G) That shows slice one starts at block 63, standard for MBR. The space inside the slice (da0s1) starts at block 0 *of the slice*. This is a bit confusing for me but it does not really matter as long as the programs get it straight. This is again because of the geom inside a geom setup. The actual start block is the start of the slice (block 63) plus the start of the FreeBSD partition inside the slice (currently 0). When you create FreeBSD partitions inside da0s1, they will have nonzero offsets from the start of the slice. There are examples shown here: http://forums.freebsd.org/showpost.php?p=206204postcount=11 And I saw there how to overcome the alignment problems. It is so simple. Just understanding it was not so simple for me. Thanks! Erich ___ 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
Re: the latest version of Clang/LLVM for the world and kernel
On 02/16/2013 17:17, Dimitry Andric wrote: On 2013-02-16 00:04, deeptech71 wrote: First of all, you should understand that these are compilation errors No, they are only errors because we have turned on -Werror. You meant to say: Yes, but they are only errors because we have turned on -Werror. Regarding this particular warning, it could be fixed by casting status to int, or adding -Wno-tautological-constant-out-of-range-compare to the flags for its WARNS= level (which is 2, if I looked it up correctly). I'd change the variable to an int. Second of all, you should understand that these are real errors; in this case, the compiler may omit generating code to check for a boolean condition, if the value of that condition is known at compile time, and thus generating a program with an undesired mode of operation. No, this is not the case with enums, unless you use the -fstrict-enums flag, which we don't use at the moment. And even with that flag, I did not see any change in the resulting assembly. This is probably because it would break too much software, if such an optimization was implemented, even if that optimization is strictly speaking completely legal to do. What makes you think that no semantic changes will occur in the future? What about other compilers? As the makefile comments say, some warnings are kept enabled to create an incentive to fix the code. But the real incentive should be that fixing the code makes the difference between WRONG and non-WRONG. * /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression 0 is always false [-Werror,-Wtautological-compare] * if (len 0 || len left) * ~~~ ^ ~ Normally, they are not errors, but just warnings, unless you changed something in the bsd.*.mk logic to not detect clang. WRONG. Clang detection measures are intact here: /etc/make.conf contains: CC=/dir1/clang CPP=/dir1/clang-cpp CXX=/dir1/clang++ TBLGEN=/dir1/clang-tblgen ___ 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
conflicting types for 'EC_KEY_insert_key_method_data'
/llvm_installation/bin/clang -O2 -pipe -march=native -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM -DRMD160_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -DNO_IDEA -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parame ter -Wno - parentheses -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ec/ec_key.c -o ec_key.o /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ec/ec_key.c:532:7: error: conflicting types for 'EC_KEY_insert_key_method_data' void *EC_KEY_insert_key_method_data(EC_KEY *key, void *data, ^ /usr/include/openssl/ec.h:809:6: note: previous declaration is here void EC_KEY_insert_key_method_data(EC_KEY *, void *data, ^ Fix include paths (-I) in the makefiles? ___ 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
