Re: ulpt can't attach Lexmark E120
On 08/23/13 02:29, George Mitchell wrote: On 08/22/13 07:34, Hans Petter Selasky wrote: Here's the result: root@pi:/ # usbdump -i usbus0 -f 4 -s 65536 00:26:01.592494 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 00:26:01.593117 usbus0.4 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 00:26:01.593209 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0 00:26:01.594146 usbus0.4 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 00:26:01.611621 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.614223 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 00:26:01.614730 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.617595 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 00:26:01.617758 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.620216 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.620313 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.622219 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.622326 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.624208 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.624305 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.631722 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 00:26:01.631925 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.634217 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.634315 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.637220 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=44,IVAL=0,ERR=0 00:26:01.637334 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.639214 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.639312 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.641585 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=28,IVAL=0,ERR=0 00:26:01.641769 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.644209 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=12,IVAL=0,ERR=0 00:26:01.644316 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.651213 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=32,IVAL=0,ERR=0 00:26:01.651316 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.653219 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.653321 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 00:26:01.654584 usbus0.4 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 (at which point if I type control-c to stop usbdump, the system gets a fatal kernel mode translation fault, but that's another story.) Hope this helps. -- George I would expect to see some messages ERR != 0 when you plug the device. Can you show both usbdump output and dmesg output which belongs together? --HPS ___ 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: ulpt can't attach Lexmark E120
On 08/22/13 07:34, Hans Petter Selasky wrote: On 08/22/13 13:24, George Mitchell wrote: As I was saying a few minutes ago ... On 01/27/13 17:32, George Mitchell wrote: On 01/27/13 14:07, Hans Petter Selasky wrote: [...] I need output when hw.usb.ulpt.debug=15 to say exactly. Could you ask the provider of the binaries to compile having USB_DEBUG set, also for the modules. --HPS I'm working on getting a debug build ... Thanks for your help so far. I notice that there seem to be only trivial differences between the 9.1 release ulpt and the 10.0 current ulpt driver. -- George (This is on a Raspberry Pi.) It took me a bit longer than anticipated, but here is the output, from an image built over last weekend: Hi, Could you run: usbdump -i usbusX -f Y -s 65536 To get a dump of the USB activity when you plug the device? The message in question is not important, and might be changed to not cancel the ulpt attach routine. --HPS ___ 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" Here's the result: root@pi:/ # usbdump -i usbus0 -f 4 -s 65536 00:26:01.592494 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 00:26:01.593117 usbus0.4 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 00:26:01.593209 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0 00:26:01.594146 usbus0.4 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 00:26:01.611621 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.614223 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0 00:26:01.614730 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.617595 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0 00:26:01.617758 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.620216 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.620313 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.622219 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.622326 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.624208 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.624305 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.631722 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=16,IVAL=0,ERR=0 00:26:01.631925 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.634217 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.634315 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.637220 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=44,IVAL=0,ERR=0 00:26:01.637334 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.639214 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.639312 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.641585 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=28,IVAL=0,ERR=0 00:26:01.641769 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.644209 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=12,IVAL=0,ERR=0 00:26:01.644316 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.651213 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=32,IVAL=0,ERR=0 00:26:01.651316 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0 00:26:01.653219 usbus0.4 DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0 00:26:01.653321 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 00:26:01.654584 usbus0.4 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 (at which point if I type control-c to stop usbdump, the system gets a fatal kernel mode translation fault, but that's another story.) Hope this helps. -- George ___ 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: why does buildkernel set COMPILER_TYPE?
Den 22/08/2013 kl. 18.23 skrev John-Mark Gurney : >> I don't think we should support building different parts of the tree >> with incompatible settings. E.g. compiling part of the tree using >> WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to >> work properly. > > Do we have a file that is source in /usr/src (or where your source tree > is located) that we can put these options in? make buildworld SRCCONF=/foo/bar/custom.conf But if you doing all sorts of weird build configurations regularly, you might want to just build within a jail that you can wipe afterwards, so you don't pollute the host machine by accident. Erik ___ 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"
patch to improve AES-NI performance
I have developed a patch to improve AES-NI performance. If you took the AES-XTS algorithm into userland (no cryptodev or geli usage), these changes improve the performance over 10x in my tests (from ~150MB/sec to over 2GB/sec). In tests of geli on gnop, the performance improvement is more moderate, around 4x due to overhead in other parts of the system. This is patch will be committed after the gcc intrinsics patch so that kernels will continue to compile w/ both clang and gcc w/o change. I have tested both AES-XTS and AES-CBC mode of geli and verified no difference between this and software mode. I plan to commit the test scripts for this in the future too. I have validated the AES-XTS via cryptodev against the standard test vectors and all the block sized vectors pass. The non-block sized test vectors cannot pass since our cryptodev implementation only allows block sized requests. Thanks to Mike Hamburg for help and advice in making the AES-XTS algorithm go really fast. The patch removes some assembly, and also replaces some hard coded instructions (as .byte values) to their proper instructions now that gcc can assemble them properly. The patch: https://people.freebsd.org/~jmg/aesni.new1.patch -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
patch to add AES intrinsics to gcc
In my work to get AES-NI performance in a better state and the fact that we haven't deprecated gcc yet, I have developed another patch to add the appropriate AES intrinstic headers to gcc. The patch is available at: https://people.freebsd.org/~jmg/gcc.aes.intrin.patch I did have to change the opth-gen.awk script, since it wouldn't let me use bit 31, and recent changes to gcc used up all the remaining bits. I also was unable to add the -mpclmul option because of running out of these bits. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: why does buildkernel set COMPILER_TYPE?
On Thu, 2013-08-22 at 09:23 -0700, John-Mark Gurney wrote:
> Dimitry Andric wrote this message on Thu, Aug 22, 2013 at 08:59 +0200:
> > On Aug 22, 2013, at 06:04, John-Mark Gurney wrote:
> > > I've noticed that if you do a:
> > > make buildworld WITHOUT_CLANG_IS_CC=YES
> > >
> > > and then do a:
> > > make buildkernel
> > >
> > > (w/o the WITHOUT_CLANG_IS_CC=YES option)
> > > that it fails...
> >
> > Why don't you just put the WITHOUT_CLANG_IS_CC setting in /etc/src.conf,
> > where it belongs? That would save you this trouble.
>
> Except that I'm testing code that needs to work both with clang and
> gcc... Putting an option like that in /etc/src.conf is bad as I'm
> likely to forget it, plus it'll effect other trees which isn't good...
>
> > I don't think we should support building different parts of the tree
> > with incompatible settings. E.g. compiling part of the tree using
> > WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to
> > work properly.
>
> Do we have a file that is source in /usr/src (or where your source tree
> is located) that we can put these options in?
>
You can put them in any file you want, and point to it with SRCCONF= on
the command line. It doesn't make sense to define a standard location
within the source tree, because it has to be possible to build from a
read-only tree, and also that still doesn't address the problem of
"today I want to build this source with gcc, tomorrow I want to build
the same source with clang without modifying anything in the source
tree."
It might be kind of nice if by default the build system looked first
in ../etc/ rather than /etc for {make,src}.conf, then you could have an
etc directory "associated with the source" but maintain the readonly
nature of src/ itself. Likewise look first for ../obj instead
of /usr/obj. This is basically what I do, but it requires me to have a
wrapper script that sets up the make command line with all the right
overrides to use the build config based on where I usually keep it "in
association with the source" which for me is a directory named config/
at the same level as src/ that's being built.
-- Ian
> When we finally are able to build and install all as a normal user
> (which we are getting close now), /etc/src.conf is a really bad place
> to put these things
>
> > > Apparently instead of letting buildkernel figure out
> > > which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE
> > > to be what the options specified instead of using what bsd.compiler.mk
> > > figures out...
> >
> > This was added by brooks in r240468 (and further developed in r250659
> > where he added external compiler support), with what I assume is the
> > explanation in the commit message:
> >
> > "To avoid negative performance impacts in the default case and correct
> > value for COMPILER_TYPE type is determined and passed in the environment
> > of submake instances while building world."
> >
> > So I suspect this is really on purpose. Brooks, any comments? :)
>
> Except that KMAKEENV just blindly takes all of WMAKEENV... I
> understand why WMAKEENV would have COMPILER_TYPE, I'm just puzzled why
> we don't let KMAKEENV figure out the correct one...
>
___
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: why does buildkernel set COMPILER_TYPE?
Dimitry Andric wrote this message on Thu, Aug 22, 2013 at 08:59 +0200: > On Aug 22, 2013, at 06:04, John-Mark Gurney wrote: > > I've noticed that if you do a: > > make buildworld WITHOUT_CLANG_IS_CC=YES > > > > and then do a: > > make buildkernel > > > > (w/o the WITHOUT_CLANG_IS_CC=YES option) > > that it fails... > > Why don't you just put the WITHOUT_CLANG_IS_CC setting in /etc/src.conf, > where it belongs? That would save you this trouble. Except that I'm testing code that needs to work both with clang and gcc... Putting an option like that in /etc/src.conf is bad as I'm likely to forget it, plus it'll effect other trees which isn't good... > I don't think we should support building different parts of the tree > with incompatible settings. E.g. compiling part of the tree using > WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to > work properly. Do we have a file that is source in /usr/src (or where your source tree is located) that we can put these options in? When we finally are able to build and install all as a normal user (which we are getting close now), /etc/src.conf is a really bad place to put these things > > Apparently instead of letting buildkernel figure out > > which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE > > to be what the options specified instead of using what bsd.compiler.mk > > figures out... > > This was added by brooks in r240468 (and further developed in r250659 > where he added external compiler support), with what I assume is the > explanation in the commit message: > > "To avoid negative performance impacts in the default case and correct > value for COMPILER_TYPE type is determined and passed in the environment > of submake instances while building world." > > So I suspect this is really on purpose. Brooks, any comments? :) Except that KMAKEENV just blindly takes all of WMAKEENV... I understand why WMAKEENV would have COMPILER_TYPE, I'm just puzzled why we don't let KMAKEENV figure out the correct one... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
[head tinderbox] failure on i386/pc98
TB --- 2013-08-22 11:21:29 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-08-22 11:21:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-08-22 11:21:29 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-08-22 11:21:29 - cleaning the object tree TB --- 2013-08-22 11:21:29 - /usr/local/bin/svn stat /src TB --- 2013-08-22 11:21:43 - At svn revision 254647 TB --- 2013-08-22 11:21:44 - building world TB --- 2013-08-22 11:21:44 - CROSS_BUILD_TESTING=YES TB --- 2013-08-22 11:21:44 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-22 11:21:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-22 11:21:44 - SRCCONF=/dev/null TB --- 2013-08-22 11:21:44 - TARGET=pc98 TB --- 2013-08-22 11:21:44 - TARGET_ARCH=i386 TB --- 2013-08-22 11:21:44 - TZ=UTC TB --- 2013-08-22 11:21:44 - __MAKE_CONF=/dev/null TB --- 2013-08-22 11:21:44 - cd /src TB --- 2013-08-22 11:21:44 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Aug 22 11:21:53 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Aug 22 14:37:01 UTC 2013 TB --- 2013-08-22 14:37:01 - generating LINT kernel config TB --- 2013-08-22 14:37:01 - cd /src/sys/pc98/conf TB --- 2013-08-22 14:37:01 - /usr/bin/make -B LINT TB --- 2013-08-22 14:37:01 - cd /src/sys/pc98/conf TB --- 2013-08-22 14:37:01 - /usr/sbin/config -m LINT TB --- 2013-08-22 14:37:01 - building LINT kernel TB --- 2013-08-22 14:37:01 - CROSS_BUILD_TESTING=YES TB --- 2013-08-22 14:37:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-08-22 14:37:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-08-22 14:37:01 - SRCCONF=/dev/null TB --- 2013-08-22 14:37:01 - TARGET=pc98 TB --- 2013-08-22 14:37:01 - TARGET_ARCH=i386 TB --- 2013-08-22 14:37:01 - TZ=UTC TB --- 2013-08-22 14:37:01 - __MAKE_CONF=/dev/null TB --- 2013-08-22 14:37:01 - cd /src TB --- 2013-08-22 14:37:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Aug 22 14:37:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^ /src/sys/pc98/pc98/machdep.c:1372:22: error: non-object type 'uint64_t (volatile uint64_t *)' is not assignable atomic_load_acq_64 = atomic_load_acq_64_i586; ~~ ^ /src/sys/pc98/pc98/machdep.c:1373:23: error: non-object type 'void (volatile uint64_t *, uint64_t)' is not assignable atomic_store_rel_64 = atomic_store_rel_64_i586; ~~~ ^ 4 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/pc98.i386/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-08-22 14:52:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-08-22 14:52:08 - ERROR: failed to build LINT kernel TB --- 2013-08-22 14:52:08 - 10357.18 user 1367.91 system 12638.50 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full ___ 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"
Diskless setup with NFS_V4
Its posible use currentle FreeBSD on NFS_V4 root? Explain: pxeboot do NFS_v3 (not NFS_v4) mount and pass fd to kernel. In this setup kernel can use only configured (established) nfs fh. This is not allowed to switch version or some options. When pxeboot use TFTP (not NFS) kernel (in nfs/bootp_subr.c) do DHCP discover and don't allow (in nfs/nfs_diskless.c:nfs_parse_options) 'nfsv4' option. nfs/nfs_diskless.c:nfs_setup_diskless also initialy set nd3->root_args.flags = (NFSMNT_NFSV3 | NFSMNT_WSIZE | NFSMNT_RSIZE | NFSMNT_RESVPORT); and don't allow 'nfsv4' option. Where I be wrong? How I can use diskless setup with R/O root on NFS_V4 share? ___ 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: Problems with iconv in base and static linking
On 8/21/2013 2:49 PM, Dimitry Andric wrote: > Hi, > > While packaging my just-rebuilt ports today, I noticed a strange message > occurring during the package creation stage: > > $ sudo make -C /usr/ports/ports-mgmt/pkg repackage > ===> Building package for pkg-1.1.4_1 > Creating package for pkg-1.1.4_1 > Service unavailable$ > > In fact, *every* make package/repackage produces the "Service > unavailable" message. The message is actually produced by the pkg(8) > command, which is run as follows: > > /usr/local/sbin/pkg-static create -o /usr/ports/packages pkg-1.1.4_1 > > Now comes the interesting part: if you use /usr/local/sbin/pkg instead, > the "Service unavailable" message does *not* appear. > > It turns out this is because pkg(8) uses libarchive, which is now > compiled with iconv support from base by default. But the iconv in base > does *not* work properly in statically linked executables. For example, > take this small program: ... > Of course, there may be other consumers of libc's iconv that might want > to link statically, so it should really be fixed there instead. For > example, by not doing the dlopen, and failing gracefully. Or maybe by > actually linking in (a subset of) the /usr/lib/i18n libraries. > > -Dimitry > I agree this is an iconv issue and that should be fixed instead of bandaging consumers as they are found. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: ulpt can't attach Lexmark E120
On 08/22/13 13:24, George Mitchell wrote: As I was saying a few minutes ago ... On 01/27/13 17:32, George Mitchell wrote: On 01/27/13 14:07, Hans Petter Selasky wrote: [...] I need output when hw.usb.ulpt.debug=15 to say exactly. Could you ask the provider of the binaries to compile having USB_DEBUG set, also for the modules. --HPS I'm working on getting a debug build ... Thanks for your help so far. I notice that there seem to be only trivial differences between the 9.1 release ulpt and the 10.0 current ulpt driver. -- George (This is on a Raspberry Pi.) It took me a bit longer than anticipated, but here is the output, from an image built over last weekend: Hi, Could you run: usbdump -i usbusX -f Y -s 65536 To get a dump of the USB activity when you plug the device? The message in question is not important, and might be changed to not cancel the ulpt attach routine. --HPS ___ 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: Re: ulpt can't attach Lexmark E120
As I was saying a few minutes ago ... On 01/27/13 17:32, George Mitchell wrote: On 01/27/13 14:07, Hans Petter Selasky wrote: [...] I need output when hw.usb.ulpt.debug=15 to say exactly. Could you ask the provider of the binaries to compile having USB_DEBUG set, also for the modules. --HPS I'm working on getting a debug build ... Thanks for your help so far. I notice that there seem to be only trivial differences between the 9.1 release ulpt and the 10.0 current ulpt driver. -- George (This is on a Raspberry Pi.) It took me a bit longer than anticipated, but here is the output, from an image built over last weekend: Aug 22 11:15:09 pi kernel: ugen0.5: at usbus0 Aug 22 11:15:09 pi kernel: ulpt_probe: Aug 22 11:15:09 pi kernel: ulpt_probe: Aug 22 11:15:09 pi kernel: ulpt_attach: sc=0xc2d43800 Aug 22 11:15:09 pi kernel: ulpt0: on usbus0 Aug 22 11:15:09 pi kernel: ulpt_attach: setting alternate config number: 0 Aug 22 11:15:09 pi kernel: ulpt_attach: error=USB_ERR_INVAL Aug 22 11:15:09 pi kernel: ulpt_detach: sc=0xc2d43800 Aug 22 11:15:09 pi kernel: device_attach: ulpt0 attach returned 12 ___ 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: why does buildkernel set COMPILER_TYPE?
On Aug 22, 2013, at 06:04, John-Mark Gurney wrote: > I've noticed that if you do a: > make buildworld WITHOUT_CLANG_IS_CC=YES > > and then do a: > make buildkernel > > (w/o the WITHOUT_CLANG_IS_CC=YES option) > that it fails... Why don't you just put the WITHOUT_CLANG_IS_CC setting in /etc/src.conf, where it belongs? That would save you this trouble. I don't think we should support building different parts of the tree with incompatible settings. E.g. compiling part of the tree using WITH_FOO, and some other part using WITHOUT_FOO is *not* supposed to work properly. > Apparently instead of letting buildkernel figure out > which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE > to be what the options specified instead of using what bsd.compiler.mk > figures out... This was added by brooks in r240468 (and further developed in r250659 where he added external compiler support), with what I assume is the explanation in the commit message: "To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world." So I suspect this is really on purpose. Brooks, any comments? :) -Dimitry ___ 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"
