Re: sysutils/fusefs-kmod problem in CURRENT
On Wed, Mar 27, 2013 at 2:03 AM, Attilio Rao atti...@freebsd.org wrote: On Wed, Mar 27, 2013 at 4:00 AM, Marcelo/Porks marceloro...@gmail.com wrote: On Mar 22, 2013 1:02 AM, Attilio Rao atti...@freebsd.org wrote: On Fri, Mar 22, 2013 at 2:02 AM, Marcelo/Porks marceloro...@gmail.com wrote: Hi, I'm facing an error compiling the sysutils/fusefs-kmod. I'm using the CURRENT from today (2013-03-21). Can someone using the CURRENT confirm if this also happens in your system? CURRENT should not allow you to build fusefs-kmod at all. Use option FUSEFS from your kernel config. Sorry, maybe I didnt understand what you said. I tried to use in my kernel conf: options FUSEFS option FUSEFS options fusefs option fusefs Sorry, my fault, I mis-pelled it. it is: options FUSE Oh Thanks it worked (compiling the option in the kernel) And it also worked using the module like Andrey V. Elsukov said. # kldload fuse.ko Thanks again. -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: sysutils/fusefs-kmod problem in CURRENT
On Mar 22, 2013 1:02 AM, Attilio Rao atti...@freebsd.org wrote: On Fri, Mar 22, 2013 at 2:02 AM, Marcelo/Porks marceloro...@gmail.com wrote: Hi, I'm facing an error compiling the sysutils/fusefs-kmod. I'm using the CURRENT from today (2013-03-21). Can someone using the CURRENT confirm if this also happens in your system? CURRENT should not allow you to build fusefs-kmod at all. Use option FUSEFS from your kernel config. Sorry, maybe I didnt understand what you said. I tried to use in my kernel conf: options FUSEFS option FUSEFS options fusefs option fusefs But they didnt work. The kernel does not compile. The result is above: -- Kernel build for GENERIC started on Tue Mar 26 23:21:09 BRT 2013 -- === GENERIC -- stage 1: configuring the kernel -- /usr/src/sys/amd64/conf/GENERIC: unknown option FUSEFS *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error -- Kernel build for GENERIC started on Tue Mar 26 23:33:24 BRT 2013 -- === GENERIC -- stage 1: configuring the kernel -- /usr/src/sys/amd64/conf/GENERIC: unknown option fusefs *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error -- Kernel build for GENERIC started on Tue Mar 26 23:44:14 BRT 2013 -- === GENERIC -- stage 1: configuring the kernel -- /usr/src/sys/amd64/conf/GENERIC: unknown option FUSEFS *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error -- Kernel build for GENERIC started on Tue Mar 26 23:51:52 BRT 2013 -- === GENERIC -- stage 1: configuring the kernel -- /usr/src/sys/amd64/conf/GENERIC: unknown option fusefs *** [buildkernel] Error code 1 1 error *** [buildkernel] Error code 2 1 error 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
sysutils/fusefs-kmod problem in CURRENT
Hi, I'm facing an error compiling the sysutils/fusefs-kmod. I'm using the CURRENT from today (2013-03-21). Can someone using the CURRENT confirm if this also happens in your system? How should I proceed? Thanks in advance. BARAD-DUR# portsnap fetch update Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. Fetching snapshot tag from ec2-sa-east-1.portsnap.freebsd.org... done. Latest snapshot on server matches what we already have. No updates needed. Ports tree is already up to date. BARAD-DUR# uname -a FreeBSD BARAD-DUR 10.0-CURRENT FreeBSD 10.0-CURRENT #11 r248594M: Thu Mar 21 19:47:16 BRT 2013 root@BARAD-DUR:/mnt/data/system/obj/usr/src/sys/GENERIC amd64 BARAD-DUR# cat /etc/make.conf # added by use.perl 2012-02-18 15:32:40 PERL_VERSION=5.12.4 WITH_PKGNG=yes BARAD-DUR# cat /etc/src.conf BARAD-DUR# cd /usr/ports/sysutils/fusefs-kmod BARAD-DUR# make === Building for fusefs-kmod-0.3.9.p1.20080208_11 === fuse_module (all) Warning: Object directory not changed from original /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_main.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_msg.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_dev.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vfsops.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno -red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wne sted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c fuse_vnops.c In file included from fuse_vnops.c:36: @/vm/vm_pager.h:127:2: error: implicit declaration of function 'rw_assert' is invalid in C99 [-Werror,-Wimplicit-function-declaration] VM_OBJECT_ASSERT_WLOCKED(object); ^ @/vm/vm_object.h:214:2: note: expanded from macro 'VM_OBJECT_ASSERT_WLOCKED' rw_assert((object)-lock, RA_WLOCKED) ^ In file included from fuse_vnops.c:36: @/vm/vm_pager.h:127:2:
Re: libfftw3.so.5: compile error on port of awesome
On Wed, Jan 18, 2012 at 03:04, Kevin Oberman kob6...@gmail.com wrote: On Tue, Jan 17, 2012 at 5:09 PM, Marcelo/Porks marceloro...@gmail.com wrote: Hi guys, I do not know if this is the correct mail list to report this. I'm trying to compile the port x11-wm/awesome but failed with the error: [ 37%] Building C object CMakeFiles/awesome.dir/common/tokenize.c.o Linking C executable awesome [ 37%] Built target awesome Scanning dependencies of target generated_icons [ 38%] Generating themes/zenburn/titlebar/maximized_normal_active.png Shared object libfftw3.so.5 not found, required by convert*** Error code 1 Stop in /usr/ports/x11-wm/awesome/work/awesome-3.4.11. *** Error code 1 I'm using the head and the workaround of UNAME_r=9.9-CURRENT BARAD-DUR# uname -a FreeBSD BARAD-DUR 9.9-CURRENT FreeBSD 10.0-CURRENT #6 r230290M: Tue Jan 17 22:22:46 BRST 2012 root@BARAD-DUR:/usr/clang/obj/usr/src/sys/GENERIC amd64 BARAD-DUR# echo $UNAME_r u9.9-CURRENT (GMT-2) I have on my system /usr/local/lib/libfftw3.so.6 I can compile making: ln -s /usr/local/lib/libfftw3.so /usr/local/lib/libfftw3.so.5 (I know, this is a bad thing to do) Could someone check if on your system the same happen? Yes, it's risky to do that. The problem is that some port on your system needs to re-link against /usr/local/lib/libfftw3.so.6. You can find the ports that link to non-existent libs by installing sysutils/bsdadminscripts and running pkg_libchk. It will list all executables that are linked against non-existent libs. Note that it does generate a few false positives. See the man page for details, but none of the false positives is likely to show up for libfftw3. Re-install any port with files linked against libfftw3.so.5. While you are at it, fix any other errors found, though you may skip openoffice and Java (false positives). I didn't know about the sysutils/bsdadminscripts:pkg_libchk. It was really helpful. The problem was an old version of ImageMagick installed on my system. Once the ImageMagick's port also failed to compile. I tried to install the last version of the package at ftp.freebsd.org and so the issue about libfftw3.so.5 was gone. Thanks -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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
libfftw3.so.5: compile error on port of awesome
Hi guys, I do not know if this is the correct mail list to report this. I'm trying to compile the port x11-wm/awesome but failed with the error: [ 37%] Building C object CMakeFiles/awesome.dir/common/tokenize.c.o Linking C executable awesome [ 37%] Built target awesome Scanning dependencies of target generated_icons [ 38%] Generating themes/zenburn/titlebar/maximized_normal_active.png Shared object libfftw3.so.5 not found, required by convert*** Error code 1 Stop in /usr/ports/x11-wm/awesome/work/awesome-3.4.11. *** Error code 1 I'm using the head and the workaround of UNAME_r=9.9-CURRENT BARAD-DUR# uname -a FreeBSD BARAD-DUR 9.9-CURRENT FreeBSD 10.0-CURRENT #6 r230290M: Tue Jan 17 22:22:46 BRST 2012 root@BARAD-DUR:/usr/clang/obj/usr/src/sys/GENERIC amd64 BARAD-DUR# echo $UNAME_r u9.9-CURRENT (GMT-2) I have on my system /usr/local/lib/libfftw3.so.6 I can compile making: ln -s /usr/local/lib/libfftw3.so /usr/local/lib/libfftw3.so.5 (I know, this is a bad thing to do) Could someone check if on your system the same happen? ___ 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: FreeBSD 9.0-BETA1/amd64 r224808: buildworld failure: === lib/clang/include (all), 1 error, *** Error code 2, 1 error, *** Error code 2, 1 error
On Sat, Aug 13, 2011 at 05:39, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I run several boxes based on FreebSD 9.0-BETA1/amd64, compiled with clang. Since yesterday, I run on all of these machines into strange situations: buildworld won't build anymore, it fails always on all boxes at the very same position as showed by the error message below. I can build and install a kernel, that's working all right. Is there any known issue? Hi. I had problems about 2 weeks ago when I tried to compile world/kernel/ports (with or without clang). I thought that the problems were related to the file system. So I disabled the SUJ, ran the fsck and tried to compile again. And everything worked fine. So I reinstalled the new world/kernel, I re-enabled the SUJ and the problems didn't come back. I already deleted /usr/obj and did a fsck on the filesystem(s). The filesystem in question is UFS2. Maybe it is worth to know, that I also have on all of these boxes the strange behaviour, that a portsnap update/extract now fails permanently with: /usr/ports/devel/ccdoc/ /usr/ports/devel/ccrtp/ /usr/ports/devel/cdash/ files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt. This is the same on every box compiled FreeBSD 9.0-BETA1/amd64. The portsnap issue does not occur on our two FreeBSD 8.2-STABLE servers. Well, this might be a simple coincidence, but due to the fact these errors occur simultanously on every FreeBSD 9.0/amd box we run it might could be realted to a real issue in FreeBSD 9.0-BETA1/amd64 (even compiled with clang). A VFS issue perhaps? I updated the kernel sources minutes ago and installed a most recent kernel, rebooted and hoped to get rid of the problem, but it still remains. Regards, Oliver gzip -cn /usr/src/lib/bind/lwres/../../../contrib/bind9/lib/lwres/man/lwres_resutil.3 lwres_resutil.3.gz building profiled lwres library ranlib liblwres_p.a === lib/clang (all) === lib/clang/libclanganalysis (all) === lib/clang/libclangarcmigrate (all) === lib/clang/libclangast (all) === lib/clang/libclangbasic (all) === lib/clang/libclangcodegen (all) === lib/clang/libclangdriver (all) === lib/clang/libclangfrontend (all) === lib/clang/libclangfrontendtool (all) === lib/clang/libclangindex (all) === lib/clang/libclanglex (all) === lib/clang/libclangparse (all) === lib/clang/libclangrewrite (all) === lib/clang/libclangsema (all) === lib/clang/libclangserialization (all) === lib/clang/libclangstaticanalyzercheckers (all) === lib/clang/libclangstaticanalyzercore (all) === lib/clang/libclangstaticanalyzerfrontend (all) === lib/clang/libllvmanalysis (all) === lib/clang/libllvmasmparser (all) === lib/clang/libllvmasmprinter (all) === lib/clang/libllvmbitreader (all) === lib/clang/libllvmbitwriter (all) === lib/clang/libllvmcodegen (all) === lib/clang/libllvmcore (all) === lib/clang/libllvminstcombine (all) === lib/clang/libllvminstrumentation (all) === lib/clang/libllvmipa (all) === lib/clang/libllvmipo (all) === lib/clang/libllvmmc (all) === lib/clang/libllvmmcparser (all) === lib/clang/libllvmscalaropts (all) === lib/clang/libllvmselectiondag (all) === lib/clang/libllvmsupport (all) === lib/clang/libllvmtarget (all) === lib/clang/libllvmtransformutils (all) === lib/clang/libllvmarmasmparser (all) === lib/clang/libllvmarmcodegen (all) === lib/clang/libllvmarmdesc (all) === lib/clang/libllvmarmdisassembler (all) === lib/clang/libllvmarminfo (all) === lib/clang/libllvmarminstprinter (all) === lib/clang/libllvmmipscodegen (all) === lib/clang/libllvmmipsdesc (all) === lib/clang/libllvmmipsinfo (all) === lib/clang/libllvmmipsinstprinter (all) === lib/clang/libllvmpowerpccodegen (all) === lib/clang/libllvmpowerpcdesc (all) === lib/clang/libllvmpowerpcinfo (all) === lib/clang/libllvmpowerpcinstprinter (all) === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/include (all) 1 error *** Error code 2 1 error *** Error code 2 1 error ___ 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 -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: please (re) test if_ath in -HEAD
On Thu, Mar 3, 2011 at 19:31, Adrian Chadd adrian.ch...@gmail.com wrote: Hi all, For those of you who are testing out my if_ath changes, I'd really appreciate it if you'd update to -HEAD and re-test. I've done a variety of changes to the radio setup and found/fixed a few bugs in the TX path. It's quite possible these have introduced regressions. I'd like to make sure that I haven't broken legacy (11abg) support in weird/wonderful ways. I'd also like to make sure that I haven't broken/changed the behaviour or performance of the NICs in any way. Please give things a good thrashing and let me know the results. I'm still working towards debugging and enabling basic 11n support, but I need to first make sure that I haven't broken legacy operation in any way. Hi Adrian. I compiled your changes and everything worked. I'm using hostapd with WEP key. My kernel/world is compiled with clang. Is there any kind of test that I can do for you? There is still a annoying message, but it existed before your update: ath0: stuck beacon; resetting (bmiss count 4) - BARAD-DUR# uname -a FreeBSD BARAD-DUR 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r219303: Sat Mar 5 09:16:19 BRT 2011 root@BARAD-DUR:/usr/clang/obj/mnt/data/system/src/sys/GENERIC amd64 BARAD-DUR# dmesg| grep -i ath ath0: Atheros 5212 mem 0xfd8f-0xfd8f irq 16 at device 7.0 on pci1 ath0: AR2413 mac 7.9 RF2413 phy 4.5 ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) ath0: stuck beacon; resetting (bmiss count 4) BARAD-DUR# ifconfig ath0 ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290 ether 00:19:e0:8a:0a:d6 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running Thanks, Adrian ___ 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 -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: Can't update CLang-based system
On Mon, Feb 28, 2011 at 09:06, Dimitry Andric d...@freebsd.org wrote:
On 2011-02-28 04:30, Tim Kientzle wrote:
I have a FreeBSD-CURRENT AMD64 system here that was last updated at
r215029.
I'm trying to update it to r219079, but the build fails in lib/libz when
it tries to compile gvmat64.S. It looks like the Makefile here has a
workaround for clang on AMD64, but it doesn't seem to actually be working in
this case.
For this to work, you must put the following fragment in /etc/make.conf,
*not* in /etc/src.conf.
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
# Don't die on warnings
NO_WERROR=
WERROR=
The problem with src.conf is that is only read when make encounters a
.include bsd.lib.mk or bsd.prog.mk statement, which usually is at
the end of a Makefile. Thus, any checks done on ${CC} or ${CXX} in the
beginning of a Makefile pick up only the default value.
Hi. This worked for me.
Thanks for your help
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
I have nothing against God, I just hate His fan club
___
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: Can't update CLang-based system
On Mon, Feb 28, 2011 at 00:30, Tim Kientzle t...@kientzle.com wrote: I have a FreeBSD-CURRENT AMD64 system here that was last updated at r215029. I'm trying to update it to r219079, but the build fails in lib/libz when it tries to compile gvmat64.S. It looks like the Makefile here has a workaround for clang on AMD64, but it doesn't seem to actually be working in this case. Hi all I'm using AMD64 with clang and I having the same problem. I guess since 23th february. I tried to 'svn up' yesterday but the problem remains /tmp/cc-5pKuc1.s:336:3: error: unknown use of instruction mnemonic without a size suffix ret 0 ^ *** Error code 1 Stop in /mnt/data/system/src/lib/libz. -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: [TESTING]: updated clang/LLVM needs testing in ClangBSD
On Wed, Jul 14, 2010 at 3:38 PM, Roman Divacky rdiva...@freebsd.org wrote: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld Hi. Until here worked fine. I'm on an AMD64-Quadcore (Phenom x4). I did 'make buildworld'. Should I use something like 'make -j 8' for testing? The 'installworld' and kernel I will test thursday. snip -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: [TESTING]: updated clang/LLVM needs testing in ClangBSD
On Tue, Jul 20, 2010 at 8:25 AM, Marcelo/Porks marceloro...@gmail.com wrote: On Wed, Jul 14, 2010 at 3:38 PM, Roman Divacky rdiva...@freebsd.org wrote: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld Hi. Until here worked fine. I'm on an AMD64-Quadcore (Phenom x4). I did 'make buildworld'. Should I use something like 'make -j 8' for testing? The 'installworld' and kernel I will test thursday. Hi again. I did a 'svn up' on http://svn.freebsd.org/base/projects/clangbsd at 2010-07-20 21:30:00 UTC make -j 8 buildworld make installworld DESTDIR=/usr/clang cd sys/amd64/conf config GENERIC export CC=clang cd ../compile/GENERIC make make install KODIR=/boot/clang nextboot -k clang shutdown -r now and... BARAD-DUR% grep clang -A 3 -B 3 /var/log/messages Jul 20 20:52:51 BARAD-DUR su: porks to root on /dev/pts/5 Jul 20 20:52:58 BARAD-DUR shutdown: reboot by porks: Jul 20 20:53:02 BARAD-DUR syslogd: exiting on signal 15 Jul 20 20:54:21 BARAD-DUR syslogd: kernel boot file is /boot/clang/kernel Jul 20 20:54:21 BARAD-DUR kernel: Copyright (c) 1992-2010 The FreeBSD Project. Jul 20 20:54:21 BARAD-DUR kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 20 20:54:21 BARAD-DUR kernel: The Regents of the University of California. All rights reserved. BARAD-DUR% uname -a FreeBSD BARAD-DUR 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r210317: Tue Jul 20 20:40:06 BRT 2010 po...@barad-dur:/usr/src/sys/amd64/compile/GENERIC amd64 (I'm using GMT-3) Everything is running ok : ) -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: Fwd: umodem (4) recognize a CDC-ACM device
On Fri, Jun 4, 2010 at 12:32 PM, Marcelo/Porks marceloro...@gmail.com wrote:
On Fri, Jun 4, 2010 at 4:28 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Thu, Jun 3, 2010 at 12:57 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
Should be like this: Note the structure is called bulk_min:
static const uint16_t bulk_min[USB_SPEED_MAX] = {
[USB_SPEED_LOW] = 8,
[USB_SPEED_FULL] = 8,
[USB_SPEED_HIGH] = 512,
[USB_SPEED_VARIABLE] = 512,
[USB_SPEED_SUPER] = 1024,
};
--HPS
I think you also need to remove the check for LOW speed in the EHCI/OHCI/UHCI
controller drivers too. See usb/controller/{ehci.c,uhci.c,ohci.c}
case UE_BULK:
if (udev-speed != USB_SPEED_LOW) {
ep-methods = uhci_device_bulk_methods;
}
break;
--HPS
Hia Hans! It seems to work now or at least it was recognized.
I'll make more tests on Monday and post the results.
Hi all! Just to confirm, The patch works fine and I can use the device.
Bellow is the full patch that Hans sent to me in private. Thanks again, Hans.
==
Differences ...
//depot/projects/usb/src/sys/dev/usb/controller/ehci.c#53 (text+ko)
@@ -3792,9 +3792,7 @@
}
break;
case UE_BULK:
- if (udev-speed != USB_SPEED_LOW) {
- ep-methods = ehci_device_bulk_methods;
- }
+ ep-methods = ehci_device_bulk_methods;
break;
default:
/* do nothing */
//depot/projects/usb/src/sys/dev/usb/controller/ohci.c#35 (text+ko)
@@ -2614,9 +2614,7 @@
}
break;
case UE_BULK:
- if (udev-speed != USB_SPEED_LOW) {
- ep-methods = ohci_device_bulk_methods;
- }
+ ep-methods = ohci_device_bulk_methods;
break;
default:
/* do nothing */
//depot/projects/usb/src/sys/dev/usb/controller/uhci.c#32 (text+ko)
@@ -3068,9 +3068,7 @@
}
break;
case UE_BULK:
- if (udev-speed != USB_SPEED_LOW) {
- ep-methods = uhci_device_bulk_methods;
- }
+ ep-methods = uhci_device_bulk_methods;
break;
default:
/* do nothing */
//depot/projects/usb/src/sys/dev/usb/usb_transfer.c#177 (text+ko)
@@ -3057,7 +3057,7 @@
};
static const uint16_t bulk_min[USB_SPEED_MAX] = {
- [USB_SPEED_LOW] = 0,/* not supported */
+ [USB_SPEED_LOW] = 8,
[USB_SPEED_FULL] = 8,
[USB_SPEED_HIGH] = 512,
[USB_SPEED_VARIABLE] = 512,
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
___
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: Fwd: umodem (4) recognize a CDC-ACM device
On Fri, Jun 4, 2010 at 4:28 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 04 June 2010 03:02:52 Marcelo/Porks wrote:
On Thu, Jun 3, 2010 at 12:57 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Thursday 03 June 2010 17:54:17 Hans Petter Selasky wrote:
On Thursday 03 June 2010 17:50:08 Hans Petter Selasky wrote:
On Thursday 03 June 2010 16:22:33 Marcelo/Porks wrote:
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky
hsela...@c2i.net
wrote:
Hi,
The problem is that LOW speed does not support BULK transfers
according to the USB specification. I guess we could switch that
support on, though I'd rather stick with the spec.
Try changing this line in:
src/sys/dev/usb/usb_transfer.c
Hi,
Should be like this: Note the structure is called bulk_min:
static const uint16_t bulk_min[USB_SPEED_MAX] = {
[USB_SPEED_LOW] = 8,
[USB_SPEED_FULL] = 8,
[USB_SPEED_HIGH] = 512,
[USB_SPEED_VARIABLE] = 512,
[USB_SPEED_SUPER] = 1024,
};
--HPS
Hi, This was what I changed at first. I tried in a FreeBSD current
(Jun 3) and at 8.0-p3.
At FreeBSD current I changed the line 3062.
From:
[USB_SPEED_LOW] = 0, /* not supported */
To:
[USB_SPEED_LOW] = 8,
Like you suggested I'll try to talk with you in #bsdusb at efnet
Thank you!
Ok,
I think you also need to remove the check for LOW speed in the EHCI/OHCI/UHCI
controller drivers too. See usb/controller/{ehci.c,uhci.c,ohci.c}
case UE_BULK:
if (udev-speed != USB_SPEED_LOW) {
ep-methods = uhci_device_bulk_methods;
}
break;
--HPS
Hia Hans! It seems to work now or at least it was recognized.
I'll make more tests on Monday and post the results.
Thank you so much. again!
BARAD-DUR# uname -a
FreeBSD BARAD-DUR.BUTECO 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r208760M:
Fri Jun 4 12:16:35 BRT 2010
po...@barad-dur.buteco:/usr/obj/mnt/ad2s1d/data/src/sys/BARAD-DUR
i386
BARAD-DUR# kldload umodem
BARAD-DUR# kldstat
Id Refs AddressSize Name
1 29 0xc040 757368 kernel
21 0xc0b58000 5ad4 snd_cmi.ko
33 0xc0b5e000 574a4sound.ko
41 0xc0bb6000 4dfa90 nvidia.ko
53 0xc1096000 2eacclinux.ko
61 0xc4407000 8000 linprocfs.ko
71 0xc474f000 3000 logo_saver.ko
81 0xc4d54000 4000 umodem.ko
DEVICE PLUGGED ON USB PORT
BARAD-DUR# tail -f /var/log/messages
Jun 4 12:27:14 BARAD-DUR kernel: uhub_reattach_port: port 1 reset
failed, error=USB_ERR_TIMEOUT
Jun 4 12:27:14 BARAD-DUR kernel: uhub_reattach_port: device problem
(USB_ERR_TIMEOUT), disabling port 1
Jun 4 12:27:15 BARAD-DUR kernel: ugen0.3: www.recursion.jp at usbus0
Jun 4 12:27:15 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232,
class 2/0, rev 1.10/1.00, addr 3 on usbus0
Jun 4 12:27:15 BARAD-DUR kernel: umodem0: data interface 1, has CM
over data, has no break
BARAD-DUR# ls -lah /dev/cuaU*
crw-rw 1 uucp dialer0, 114 Jun 4 12:27 /dev/cuaU0
crw-rw 1 uucp dialer0, 115 Jun 4 12:27 /dev/cuaU0.init
crw-rw 1 uucp dialer0, 116 Jun 4 12:27 /dev/cuaU0.lock
DEVICE PLUGED OFF USB PORT
BARAD-DUR# tail -f /var/log/messages
Jun 4 12:30:15 BARAD-DUR kernel: ugen0.3: www.recursion.jp at
usbus0 (disconnected)
Jun 4 12:30:15 BARAD-DUR kernel: umodem0: at uhub0, port 1, addr 3
(disconnected)
BARAD-DUR# ls -lah /dev/cuaU*
zsh: no matches found: /dev/cuaU*
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
___
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: Fwd: umodem (4) recognize a CDC-ACM device
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net wrote: Hi, The problem is that LOW speed does not support BULK transfers according to the USB specification. I guess we could switch that support on, though I'd rather stick with the spec. Try changing this line in: src/sys/dev/usb/usb_transfer.c [USB_SPEED_LOW] = 0, /* not supported */ Into: [USB_SPEED_LOW] = 8, /* not supported according to USB spec. */ Hi, Thanks again for the reply. I changed this line [1], but the result was the same: BARAD-DUR% uname -a FreeBSD BARAD-DUR.BUTECO 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r208760M: Thu Jun 3 10:13:44 BRT 2010 po...@barad-dur.buteco:/usr/obj/mnt/ad2s1d/data/src/sys/BARAD-DUR i386 BARAD-DUR# kldstat Id Refs AddressSize Name 1 29 0xc040 757368 kernel 21 0xc0b58000 5ad4 snd_cmi.ko 33 0xc0b5e000 574a4sound.ko 41 0xc0bb6000 4dfa90 nvidia.ko 53 0xc1096000 2eacclinux.ko 61 0xc4405000 8000 linprocfs.ko 71 0xc4753000 3000 logo_saver.ko 81 0xc4a9b000 4000 umodem.ko BARAD-DUR# tail -f /var/log/messages Jun 3 11:10:21 BARAD-DUR kernel: uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT Jun 3 11:10:21 BARAD-DUR kernel: uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 Jun 3 11:10:21 BARAD-DUR kernel: ugen0.3: www.recursion.jp at usbus0 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232, class 2/0, rev 1.10/1.00, addr 3 on usbus0 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: data interface 1, has CM over data, has no break Jun 3 11:10:21 BARAD-DUR kernel: device_attach: umodem0 attach returned 6 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232, class 2/0, rev 1.10/1.00, addr 3 on usbus0 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: data interface 1, has CM over data, has no break Jun 3 11:10:21 BARAD-DUR kernel: device_attach: umodem0 attach returned 6 BARAD-DUR# usbconfig -u 0 -a 3 dump_device_desc dump_curr_config_desc ugen0.3: USB-232 www.recursion.jp at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0002 bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x16c0 idProduct = 0x05e1 bcdDevice = 0x0100 iManufacturer = 0x0001 www.recursion.jp iProduct = 0x0002 USB-232 iSerialNumber = 0x no string bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x0080 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x03, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0008 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0008 bInterval = 0x bRefresh = 0x bSynchAddress = 0x [1] Actually the line is 3062 on current of 2010 Jun 2: http://fxr.watson.org/fxr/source/dev/usb/usb_transfer.c#L3060 -- Marcelo Rossi This
Re: Fwd: umodem (4) recognize a CDC-ACM device
On Thu, Jun 3, 2010 at 12:57 PM, Hans Petter Selasky hsela...@c2i.net wrote:
On Thursday 03 June 2010 17:54:17 Hans Petter Selasky wrote:
On Thursday 03 June 2010 17:50:08 Hans Petter Selasky wrote:
On Thursday 03 June 2010 16:22:33 Marcelo/Porks wrote:
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
Hi,
The problem is that LOW speed does not support BULK transfers
according to the USB specification. I guess we could switch that
support on, though I'd rather stick with the spec.
Try changing this line in:
src/sys/dev/usb/usb_transfer.c
Hi,
Should be like this: Note the structure is called bulk_min:
static const uint16_t bulk_min[USB_SPEED_MAX] = {
[USB_SPEED_LOW] = 8,
[USB_SPEED_FULL] = 8,
[USB_SPEED_HIGH] = 512,
[USB_SPEED_VARIABLE] = 512,
[USB_SPEED_SUPER] = 1024,
};
--HPS
Hi, This was what I changed at first. I tried in a FreeBSD current
(Jun 3) and at 8.0-p3.
At FreeBSD current I changed the line 3062.
From:
[USB_SPEED_LOW] = 0,/* not supported */
To:
[USB_SPEED_LOW] = 8,
Like you suggested I'll try to talk with you in #bsdusb at efnet
Thank you!
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
___
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: Fwd: umodem (4) recognize a CDC-ACM device
On Wed, Jun 2, 2010 at 12:50 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Wednesday 02 June 2010 03:23:47 Garrett Cooper wrote: Looks like this device might be a bit quirky... Just forwarding to you to see if you had any details for the OP. Thanks! -Garrett Hi, Can you dump the USB descriptors of your device? Hi, right now I can do this at FreeBSD 8.0-RELEASE-p2 #8 r206060M, but If you prefer tonight I can dump from 'freebsd-current' box. Thank you # usbconfig -u 2 -a 2 dump_device_desc dump_curr_config_desc ugen2.2: USB-232 www.recursion.jp at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0002 bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x16c0 idProduct = 0x05e1 bcdDevice = 0x0100 iManufacturer = 0x0001 www.recursion.jp iProduct = 0x0002 USB-232 iSerialNumber = 0x no string bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x0080 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x03, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0003 wMaxPacketSize = 0x0008 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 bmAttributes = 0x0002 wMaxPacketSize = 0x0008 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0008 bInterval = 0x bRefresh = 0x bSynchAddress = 0x -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. ___ 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
umodem (4) recognize a CDC-ACM device
Hi guys. I have a device[1] that is recognized on Linux by the generic CDC-ACM driver and I'm trying to do the same on FreeBSD current with umodem (4). But, as you can see, I had no success: Jun 1 20:00:54 BARAD-DUR kernel: uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT Jun 1 20:00:54 BARAD-DUR kernel: uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 Jun 1 20:00:55 BARAD-DUR kernel: ugen0.3: www.recursion.jp at usbus0 Jun 1 20:00:55 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232, class 2/0, rev 1.10/1.00, addr 3 on usbus0 Jun 1 20:00:55 BARAD-DUR kernel: umodem0: data interface 1, has CM over data, has no break Jun 1 20:00:55 BARAD-DUR kernel: device_attach: umodem0 attach returned 6 Jun 1 20:00:55 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232, class 2/0, rev 1.10/1.00, addr 3 on usbus0 Jun 1 20:00:55 BARAD-DUR kernel: umodem0: data interface 1, has CM over data, has no break Jun 1 20:00:55 BARAD-DUR kernel: device_attach: umodem0 attach returned 6 Have you some tip for me to make this work on FreeBSD? I had put some 'printf' at the source code and noticed that umodem_attach() failed at line 378 [2]. The main reason is basically that the usbd_transfer_setup() got an endpoint [3] with 'ep-methods == NULL' [4] and this leads to USB_ERR_NO_PIPE on [5]. Thanks. [1] http://www.recursion.jp/avrcdc/driver.html#linux [2] http://fxr.watson.org/fxr/source/dev/usb/serial/umodem.c#L378 [3] http://fxr.watson.org/fxr/source/dev/usb/usb_transfer.c#L877 [4] http://fxr.watson.org/fxr/source/dev/usb/usb_transfer.c#L880 [5] http://fxr.watson.org/fxr/source/dev/usb/usb_transfer.c#L886 -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. ___ 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: SUJ Changes
On Thu, May 27, 2010 at 10:33 AM, John Baldwin j...@freebsd.org wrote:
On Wednesday 26 May 2010 7:56:24 pm Garrett Cooper wrote:
On Wed, May 26, 2010 at 3:52 PM, Marcelo/Porks marceloro...@gmail.com
wrote:
Hi guys. I'm not sure if I could call this a problem but I can disable
SU when SUJ is enabled, so SUJ will remain enabled and SU will be
disabled.
#tunefs -j enable /dev/device
#tunefs -n disable /dev/device
I did a patch for sbin/tunefs/tunefs.c that disable SUJ when the user
disable SU. Maybe this will be useful for some of you.
Thanks.
Index: sbin/tunefs/tunefs.c
===
--- sbin/tunefs/tunefs.c (revision 208580)
+++ sbin/tunefs/tunefs.c (working copy)
@@ -460,6 +460,14 @@
if ((~sblock.fs_flags FS_DOSOFTDEP) ==
FS_DOSOFTDEP)
warnx(%s remains unchanged as disabled,
name);
else {
+ /* also disable SUJ */
+ if ((sblock.fs_flags FS_SUJ) == FS_SUJ)
{
+ warnx(soft updates journaling
will be disabled too);
+ journal_clear();
+ sblock.fs_flags = ~FS_SUJ;
+ sblock.fs_sujfree = 0;
+ warnx(remove .sujournal to
reclaim space);
+ }
sblock.fs_flags = ~FS_DOSOFTDEP;
warnx(%s cleared, name);
}
I think that attempting to disable SU if SUJ
is enabled should just fail with an error message. The sysadmin can then
choose to disable both SUJ and SU if desired.
If SU is disabled and One tries to enable SUJ then SU will be
automatically enabled.
So Why not automatically disable SUJ when One tries to disable SU?
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
___
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: SUJ Changes
On 5/27/10, John Baldwin j...@freebsd.org wrote:
On Thursday 27 May 2010 10:13:38 am Marcelo/Porks wrote:
On Thu, May 27, 2010 at 10:33 AM, John Baldwin j...@freebsd.org wrote:
On Wednesday 26 May 2010 7:56:24 pm Garrett Cooper wrote:
On Wed, May 26, 2010 at 3:52 PM, Marcelo/Porks marceloro...@gmail.com
wrote:
Hi guys. I'm not sure if I could call this a problem but I can
disable
SU when SUJ is enabled, so SUJ will remain enabled and SU will be
disabled.
#tunefs -j enable /dev/device
#tunefs -n disable /dev/device
I did a patch for sbin/tunefs/tunefs.c that disable SUJ when the user
disable SU. Maybe this will be useful for some of you.
Thanks.
Index: sbin/tunefs/tunefs.c
===
--- sbin/tunefs/tunefs.c(revision 208580)
+++ sbin/tunefs/tunefs.c(working copy)
@@ -460,6 +460,14 @@
if ((~sblock.fs_flags FS_DOSOFTDEP) ==
FS_DOSOFTDEP)
warnx(%s remains unchanged as
disabled,
name);
else {
+ /* also disable SUJ */
+ if ((sblock.fs_flags FS_SUJ) ==
FS_SUJ)
{
+ warnx(soft updates
journaling
will be disabled too);
+ journal_clear();
+ sblock.fs_flags = ~FS_SUJ;
+ sblock.fs_sujfree = 0;
+ warnx(remove .sujournal to
reclaim space);
+ }
sblock.fs_flags = ~FS_DOSOFTDEP;
warnx(%s cleared, name);
}
I think that attempting to disable SU if SUJ
is enabled should just fail with an error message. The sysadmin can
then
choose to disable both SUJ and SU if desired.
If SU is disabled and One tries to enable SUJ then SU will be
automatically enabled.
So Why not automatically disable SUJ when One tries to disable SU?
I'm probably not a big fan of either really. :) For something as rarely
done
as tunefs I would prefer to err on the side of caution and require the admin
to explicitly specify everything.
Hi John. I agree with you, I do prefer a fail of tunefs in this
situation. Before of I have posted the first patch I have done another
one that fails to enable SUJ when SU is disabled and fails to disable
SU when SUJ is enabled. Now this patch is bellow and attached.
*All the stuff that I will say bellow is based on the attached patch*
The attached patch fails to disable SU when SUJ is enabled.
And it fails to enable SUJ when SU is disabled.
Earlier I decided to not post the patch because it will cause
confusion when SU and SUJ is disabled and you try to do something such
as:
# tunefs -j enable -n enable /dev/ad2s1d
The flags's processing order is alphabetically, so It will try to
enable SUJ first (and it will fail) and after it will enable SU. We
could resolve this by processing '-n' (SU) first and after '-j' (SUJ)
but this schema will make to fail the following command:
# tunefs -j disable -n disable /dev/ad2s1d
So I think we could create a function for each flag to be processed
and the main() calls this functions as necessary (and main() disabled
the relative flag so the function will not be called again).
But I'm just a curious doing trivial patches, You can talk about this
with more experience and knowlege.
=patch==
Index: sbin/tunefs/tunefs.c
===
--- sbin/tunefs/tunefs.c(revision 208584)
+++ sbin/tunefs/tunefs.c(working copy)
@@ -341,16 +341,19 @@
if (jflag) {
name = soft updates journaling;
if (strcmp(jvalue, enable) == 0) {
- if ((sblock.fs_flags (FS_DOSOFTDEP | FS_SUJ)) ==
- (FS_DOSOFTDEP | FS_SUJ)) {
+ if ((sblock.fs_flags FS_SUJ) == FS_SUJ) {
warnx(%s remains unchanged as enabled, name);
+ } else if ((sblock.fs_flags FS_DOSOFTDEP) !=
+ FS_DOSOFTDEP) {
+ warnx(%s cannot be enabled until soft updates is enabled,
+ name);
} else if (sblock.fs_clean == 0) {
warnx(%s cannot be enabled until fsck is run,
name);
} else if (journal_alloc(Svalue) != 0) {
warnx(%s can not be enabled, name);
} else {
- sblock.fs_flags |= FS_DOSOFTDEP | FS_SUJ;
+ sblock.fs_flags |= FS_SUJ;
warnx(%s set, name);
}
} else if (strcmp(jvalue, disable) == 0) {
@@ -459,6 +462,9 @@
} else if (strcmp(nvalue, disable) == 0) {
if ((~sblock.fs_flags FS_DOSOFTDEP) == FS_DOSOFTDEP)
warnx(%s remains
Re: SUJ Changes
On 5/27/10, Garrett Cooper yanef...@gmail.com wrote:
On Thu, May 27, 2010 at 3:44 PM, Marcelo/Porks marceloro...@gmail.com
wrote:
On 5/27/10, John Baldwin j...@freebsd.org wrote:
On Thursday 27 May 2010 10:13:38 am Marcelo/Porks wrote:
On Thu, May 27, 2010 at 10:33 AM, John Baldwin j...@freebsd.org wrote:
On Wednesday 26 May 2010 7:56:24 pm Garrett Cooper wrote:
On Wed, May 26, 2010 at 3:52 PM, Marcelo/Porks
marceloro...@gmail.com
wrote:
Hi guys. I'm not sure if I could call this a problem but I can
disable
SU when SUJ is enabled, so SUJ will remain enabled and SU will be
disabled.
#tunefs -j enable /dev/device
#tunefs -n disable /dev/device
I did a patch for sbin/tunefs/tunefs.c that disable SUJ when the
user
disable SU. Maybe this will be useful for some of you.
Thanks.
Index: sbin/tunefs/tunefs.c
===
--- sbin/tunefs/tunefs.c(revision 208580)
+++ sbin/tunefs/tunefs.c(working copy)
@@ -460,6 +460,14 @@
if ((~sblock.fs_flags FS_DOSOFTDEP) ==
FS_DOSOFTDEP)
warnx(%s remains unchanged as
disabled,
name);
else {
+ /* also disable SUJ */
+ if ((sblock.fs_flags FS_SUJ) ==
FS_SUJ)
{
+ warnx(soft updates
journaling
will be disabled too);
+ journal_clear();
+ sblock.fs_flags = ~FS_SUJ;
+ sblock.fs_sujfree = 0;
+ warnx(remove .sujournal to
reclaim space);
+ }
sblock.fs_flags = ~FS_DOSOFTDEP;
warnx(%s cleared, name);
}
I think that attempting to disable SU if SUJ
is enabled should just fail with an error message. The sysadmin can
then
choose to disable both SUJ and SU if desired.
If SU is disabled and One tries to enable SUJ then SU will be
automatically enabled.
So Why not automatically disable SUJ when One tries to disable SU?
I'm probably not a big fan of either really. :) For something as rarely
done
as tunefs I would prefer to err on the side of caution and require the
admin
to explicitly specify everything.
Hi John. I agree with you, I do prefer a fail of tunefs in this
situation. Before of I have posted the first patch I have done another
one that fails to enable SUJ when SU is disabled and fails to disable
SU when SUJ is enabled. Now this patch is bellow and attached.
*All the stuff that I will say bellow is based on the attached patch*
The attached patch fails to disable SU when SUJ is enabled.
And it fails to enable SUJ when SU is disabled.
Earlier I decided to not post the patch because it will cause
confusion when SU and SUJ is disabled and you try to do something such
as:
# tunefs -j enable -n enable /dev/ad2s1d
The flags's processing order is alphabetically, so It will try to
enable SUJ first (and it will fail) and after it will enable SU. We
could resolve this by processing '-n' (SU) first and after '-j' (SUJ)
but this schema will make to fail the following command:
# tunefs -j disable -n disable /dev/ad2s1d
So I think we could create a function for each flag to be processed
and the main() calls this functions as necessary (and main() disabled
the relative flag so the function will not be called again).
But I'm just a curious doing trivial patches, You can talk about this
with more experience and knowlege.
=patch==
Index: sbin/tunefs/tunefs.c
===
--- sbin/tunefs/tunefs.c(revision 208584)
+++ sbin/tunefs/tunefs.c(working copy)
@@ -341,16 +341,19 @@
if (jflag) {
name = soft updates journaling;
if (strcmp(jvalue, enable) == 0) {
- if ((sblock.fs_flags (FS_DOSOFTDEP | FS_SUJ)) ==
- (FS_DOSOFTDEP | FS_SUJ)) {
+ if ((sblock.fs_flags FS_SUJ) == FS_SUJ) {
warnx(%s remains unchanged as enabled, name);
+ } else if ((sblock.fs_flags FS_DOSOFTDEP) !=
+ FS_DOSOFTDEP) {
+ warnx(%s cannot be enabled until soft updates is
enabled,
+ name);
} else if (sblock.fs_clean == 0) {
warnx(%s cannot be enabled until fsck is run,
name);
} else if (journal_alloc(Svalue) != 0) {
warnx(%s can not be enabled, name);
} else {
- sblock.fs_flags |= FS_DOSOFTDEP | FS_SUJ;
+ sblock.fs_flags |= FS_SUJ;
I assume FS_DOSOFTDEP is being set elsewhere in the code?
warnx(%s set, name
Re: SUJ Changes
On 5/25/10, Marcelo/Porks marceloro...@gmail.com wrote:
Hi! I tested the r208241 and it's seems to be ok but this calls my
atention to other thing: Could I disable de SU when the SUJ is
enabled?
I did some tests and seems that I can do this (logs bellow).
But will SUJ work properly with SU disabled?
Hi guys. I'm not sure if I could call this a problem but I can disable
SU when SUJ is enabled, so SUJ will remain enabled and SU will be
disabled.
#tunefs -j enable /dev/device
#tunefs -n disable /dev/device
I did a patch for sbin/tunefs/tunefs.c that disable SUJ when the user
disable SU. Maybe this will be useful for some of you.
Thanks.
Index: sbin/tunefs/tunefs.c
===
--- sbin/tunefs/tunefs.c(revision 208580)
+++ sbin/tunefs/tunefs.c(working copy)
@@ -460,6 +460,14 @@
if ((~sblock.fs_flags FS_DOSOFTDEP) == FS_DOSOFTDEP)
warnx(%s remains unchanged as disabled, name);
else {
+ /* also disable SUJ */
+ if ((sblock.fs_flags FS_SUJ) == FS_SUJ) {
+ warnx(soft updates journaling
will be disabled too);
+ journal_clear();
+ sblock.fs_flags = ~FS_SUJ;
+ sblock.fs_sujfree = 0;
+ warnx(remove .sujournal to
reclaim space);
+ }
sblock.fs_flags = ~FS_DOSOFTDEP;
warnx(%s cleared, name);
}
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
___
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: SUJ Changes
On 5/17/10, Jeff Roberson jrober...@jroberson.net wrote: I fixed the sparse inode tunefs bug and changed the tunefs behavior based on discussions here on curr...@. Hopefully this works for everyone. Hi! I tested the r208241 and it's seems to be ok but this calls my atention to other thing: Could I disable de SU when the SUJ is enabled? I did some tests and seems that I can do this (logs bellow). But will SUJ work properly with SU disabled? Thanks. == logs BARAD-DUR# uname -a FreeBSD BARAD-DUR.BUTECO 9.0-CURRENT FreeBSD 9.0-CURRENT #11 r208366: Thu May 20 21:52:36 BRT 2010 po...@barad-dur.buteco:/usr/obj/usr/src/sys/BARAD-DUR i386 BARAD-DUR# df -h /dev/ad2s1d Filesystem SizeUsed Avail Capacity Mounted on /dev/ad2s1d 72G 54G 12G82% BARAD-DUR# df -h | grep /dev/ad2s1d BARAD-DUR# tunefs -p /dev/ad2s1d tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) BARAD-DUR# tunefs -j enable /dev/ad2s1d Using inode 13 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set BARAD-DUR# tunefs -p /dev/ad2s1d tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) BARAD-DUR# tunefs -n disable /dev/ad2s1d tunefs: soft updates cleared BARAD-DUR# tunefs -p /dev/ad2s1d tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) BARAD-DUR# mount /dev/ad2s1d BARAD-DUR# df -h | grep /dev/ad2s1d /dev/ad2s1d 72G 54G 12G82%/mnt/ad2s1d BARAD-DUR# ls -lah /mnt/ad2s1d/test.log ls: /mnt/ad2s1d/test.log: No such file or directory BARAD-DUR# echo test data /mnt/ad2s1d/test.log BARAD-DUR# ls -lah /mnt/ad2s1d/test.log -rw-r--r-- 1 root wheel10B May 25 19:36 /mnt/ad2s1d/test.log BARAD-DUR# cat /mnt/ad2s1d/test.log test data BARAD-DUR# I have one bad perf bug and one journal overflow bug left to resolve. Please keeps the reports coming and thank you for your help. Thanks, Jeff -- Forwarded message -- Date: Tue, 18 May 2010 01:45:28 + (UTC) From: Jeff Roberson j...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r208241 - head/sbin/tunefs Author: jeff Date: Tue May 18 01:45:28 2010 New Revision: 208241 URL: http://svn.freebsd.org/changeset/base/208241 Log: - Round up the journal size to the block size so we don't confuse fsck. Reported by: Mikolaj Golub to.my.troc...@gmail.com - Only require 256k of blocks per-cg when trying to allocate contiguous journal blocks. The storage may not actually be contiguous but is at least within one cg. - When disabling SUJ leave SU enabled and report this to the user. It is expected that users will upgrade SU filesystems to SUJ and want a similar downgrade path. Modified: head/sbin/tunefs/tunefs.c Modified: head/sbin/tunefs/tunefs.c
