Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI
The following reply was made to PR usb/140477; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-follo...@freebsd.org, rea-f...@codelabs.ru Cc: Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI Date: Thu, 12 Nov 2009 07:28:03 + (UTC) Hi, has this changed recently, that it no longer works? I seem to remember that it had perfectly worked before this year. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI
The following reply was made to PR usb/140477; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: Eygene Ryabinkin Cc: bug-follo...@freebsd.org Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI Date: Thu, 12 Nov 2009 10:43:56 + (UTC) On Thu, 12 Nov 2009, Eygene Ryabinkin wrote: Hi, > Bjoern, good day. > > Thu, Nov 12, 2009 at 07:28:03AM +0000, Bjoern A. Zeeb wrote: >> has this changed recently, that it no longer works? I seem to >> remember that it had perfectly worked before this year. > > Yes, it used to work with up to 7.. But it seems that with > the new USB stack we have asynchronous discovery and attachment, so > other subsystems are started when this process isn't yet fully > completed, so root mount is getting "closer" and, for my case, root > mount typically waits only for the completion of USB tasks. > > My gut feeling is that the device discovery prior to the USBv2 was > done synchronously, but with USBv2 kernel use async callbacks. Though, > I may be wrong in this judgement. > > You can try it yourself -- plugged USB stick with geli volume that is > marked as attach-on-boot should show the current behaviour. I am doing that regularly, on HEAD (last updated in October). But I see I lacked coffee this morning, wanted to say "earlier this year". -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: New uhso(4) device: Globetrotter HSUPA Modem Option N.V.
On Mon, 21 Feb 2011, Brandon Gooch wrote: On Mon, Feb 21, 2011 at 1:28 PM, Brandon Gooch wrote: Yeah, I got that message. Not connecting and not getting an serial console is a bit different. From the output above it looks like random garbage on the serial port. Try connecting to all different serial ports (without uhsoctl running) with minicom or cu and try typing AT. (The diagnostic port doesn't work, so skip that one). I just encountered a panic when the driver attaches after plugging in the device. The panic stems from uhso_attach(), and seems due to my kernel having the VIMAGE option compiled in -- it doesn't panic on my non-VIMAGE kernel (which I need to rebuild to continue helping debug). I'm trying to get a textdump ATM... Looks like I exceeded the VNET if_indexlim in /usr/src/sys/net/if.c on line 190: static VNET_DEFINE(int, if_indexlim) = 8; Maybe I'll bump it up and give it another go... Bjoern, is there any reason I shouldn't be able to increase the number from 8 to say, 16? I am lacking context reading about serial ports and network interfaces. If you create a network interface from USB you are currently running into the problem that CURVNETs are not properly setup. The indexlim, should just increase itself up to 64k if needed - see if_grow() in if.c. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
usb4bsd patch review [was Re: ...]
On Mon, 18 Aug 2008, Alfred Perlstein wrote: Hi Alfred, CC:ing freebsd-usb for additional review. A few initial comments on the patch The delta is here: http://mu.org/~bright/usb4bsd.diff.gz The patch only includes kernel parts, is there any impact on userland? There are various style bugs introduced. That could be fixed easily I guess? In kern/subr_bus.c you are taking steps to avoid zero size allocations, which haven't been there up to now. Why do we need that? There is a question about whether to avoid the conditional locking in dev/sound/pcm/channel.c in favour of recursive locking? The locking in dev/sound/pcm/mixer.c appears to be strange; the locking appears to have substantially changed without corresponding changes to the non-USB drivers. Some of the new sound drivers are Giant-locked? I am not sure we should be adding new drivers that are not mpsafe. There seems to be a README.TXT but no manpages for the new API or drivers. Are these pending? Some of the files have $FreeBSD$ strings already expanded, probably because they were copied from existing files. Why is the diff to compat/ndis/ntoskrnl_var.h necessary? Regards, Bjoern, Kris, Ed S., Ollivier (sitting together at king's, cam.ac.uk devsummit) -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CFR: usb switchover patches
On Thu, 19 Feb 2009, Andrew Thompson wrote: On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. The changeover requires that the old usb stack be available until 8.0 is branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason for this location is to reduce the changes in #includes (using -I compiler hacks). The patch doesnt show userland changes required for usbdevs and friends but they will be done. Also, I wasnt planning on keeping the old usb kernel modules hooked into the build unless someone particularly wants them. They can all still be built into the kernel. what about renaming it to dev/usb1 instead of starting another top level directory in sys/ ? I mean I like legacy and would prefer to move netinet/ in there asap but;-)) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: CFR: usb switchover patches
On Fri, 20 Feb 2009, M. Warner Losh wrote: In message: <20090220100115.r53...@maildrop.int.zabbadoz.net> "Bjoern A. Zeeb" writes: : On Thu, 19 Feb 2009, Andrew Thompson wrote: : : > On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: : >> Hi, : >> : >> : >> I have put together a proposed set of changes for moving USB2 to its : >> permanent location. The layout has some differences to how it is right : >> now so I am looking for feedback. : >> : >> The changeover requires that the old usb stack be available until 8.0 is : >> branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason : >> for this location is to reduce the changes in #includes (using -I : >> compiler hacks). The patch doesnt show userland changes required for : >> usbdevs and friends but they will be done. : > : > Also, I wasnt planning on keeping the old usb kernel modules hooked into : > the build unless someone particularly wants them. They can all still be : > built into the kernel. : : what about renaming it to dev/usb1 instead of starting another top : level directory in sys/ ? I mean I like legacy and would prefer to : move netinet/ in there asap but;-)) We'd have to hack all the old usb1 drivers. Moving to sys/legacy/dev/usb means minimal frobbing of the code. ok, that explains. #include . -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: CFT: Re: linux libusb again, I made an updated port...
On 09 Feb 2014, at 13:59 , Juergen Lock wrote: Hi guys, > On Sun, Feb 09, 2014 at 02:56:24AM +, Wojciech A. Koszek wrote: >> On sob, lut 08, 2014 at 09:45:46 +0100, Juergen Lock wrote: >>> On Fri, Feb 07, 2014 at 08:49:28PM +, Wojciech A. Koszek wrote: >>>> On pi??, lut 07, 2014 at 09:12:08 +0100, Juergen Lock wrote: >>>>> Hi! >>>>> >>>>> This came up on irc so I tried to build a linux libusb port (before >>>>> I learned about ports/146895), mine uses linux_base-gentoo-stage3 >>>>> like linux_kdump with a src/lib/libusb head snapshot so it's more >>>>> up to date than wkoszek's build (ports/146895), and it's really >>>>> easy to update it again. Also maybe it can be used as linux >>>>> libusb-1.0.so too; I didn't actually test it tho. >>>>> >>>>> Should this be committed? Is wkoszek's version better since it >>>>> also builds on < 10.x? Comments welcome... >>>>> >>>>> wkoszek's version: >>>>> >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=146895 >>>>> >>>>> Mine: >>>>> >>>>> http://people.freebsd.org/~nox/tmp/linux_libusb.shar >>>>> >>>>> Distfile: >>>>> >>>>> >>>>> http://people.freebsd.org/~nox/tmp/distfiles/linux_libusb-11.0r261448.tar.bz2 >>>>> >>>>> 10/amd64 package: >>>>> >>>>> >>>>> http://people.freebsd.org/~nox/tmp/packages/10amd64/linux_libusb-11.0r261448.txz >>>>> >>>>> (built via: >>>>> >>>>> poudriere bulk -v -j 10amd64 -p custom devel/linux_libusb >>>>> >>>>> - btw for some reason the dependency emulators/linux_base-gentoo-stage3 >>>>> doesn't build for 10i386 in poudriere bulk, I get a pkg segfault. bapt >>>>> Cc'd...) >>>>> >>>> >>>> Juergen, >>> Hi! >>>> >>>> What would be the reason for this update? >>>> >>>> My stuff may be out of date, but it was all tested and working. I verified >>>> it with Linux'ish lsusb(1) and USB-based FPGA JTAG programmer, for which >>>> this stuff was written. >>>> >>> I was just thinking an updated version may be useful, but if it's >>> already working for everyone maybe less so... >>> >>> Or would it work as a linux libusb-1.0.so too? I know the libusb 1.0 >>> stuff added some functions since 9.x at least... maybe hps would know >>> (Cc'd.) >>> >> >> Juergen, >> >> I think this package is useful and is looking for maintainer, so if you have >> time and energy, I'm OK with upgrading it, but I suggest testing it first. >> Bjoern might be interested too. >> > You mean bz@ ? Cc'd. I tried testing lsusb from debian sid but it printed Thanks. > nothing, neither with my nor with your older version, but maybe it's just > `too new' for our current linuxolator. I got a lsusb to work after a bit more hacking. But that wasn’t the end of the story. > >>>> Can you show the diff between USB code from src/lib and from the distfile? >>>> >>> That's just a checkout from head, see the port Makefile for how it's >>> generated. (.if defined(BOOTSTRAP)...) >>> >>>> Instead of having a port with .c code, I'd drive towards having src/lib >>>> changes (if any) be commited. And then that port only has to do: >>>> >>>>cp -rf src/lib/libusb port/tmp/dir >>>> >>>> and build it with different -DDEFINES if necessary. >>>> >>> That's what I orginally had but hps suggested I check out from head >>> instead. (Tho that was when I couldn't get it building at first, which >>> turned out to be just a CFLAGS -I problem so the 10.0 code should now >>> build this way as well.) >> >> I guess it's the same stuff if the code is there with no modification. If we >> could have this port checked in to the ports/ repository, this would be >> great. Basically I'd concentrate on delivering good end-user experience >> >> Thanks for working on it. Lots of people will apprecite it. >> > Ok so let's wait for more testers then? I’ll give it a spin the next days. Since I last talked to some of you I had a lot of findings yet I had not been able to make any possible solution to fully work yet. The in-tree which supposedly should compile with a Ubuntu was unfortunately ruled out the earliest:( Some had glibc dependencies I kicked out which the F10 (our current default) environment didn’t provide, others are just not doing the right thing in some cases and required hacking. In the end I stayed with Wojciech’s version as it was the best option to start with and I could make the most progress quickly. /bz — Bjoern A. Zeeb ? ??? ??? ??: '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? ?? ?? ? ', ? ?, "??? ? ?? ?", ?.??? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: CFT: Re: linux libusb again, I made an updated port...
On 10 Feb 2014, at 04:18 , Wojciech A. Koszek wrote: > On nie, lut 09, 2014 at 02:59:06 +0100, Juergen Lock wrote: >> On Sun, Feb 09, 2014 at 02:56:24AM +, Wojciech A. Koszek wrote: >>> On sob, lut 08, 2014 at 09:45:46 +0100, Juergen Lock wrote: >>>> On Fri, Feb 07, 2014 at 08:49:28PM +, Wojciech A. Koszek wrote: >>>>> On pi??, lut 07, 2014 at 09:12:08 +0100, Juergen Lock wrote: >>>>>> Hi! >>>>>> >>>>>> This came up on irc so I tried to build a linux libusb port (before >>>>>> I learned about ports/146895), mine uses linux_base-gentoo-stage3 >>>>>> like linux_kdump with a src/lib/libusb head snapshot so it's more >>>>>> up to date than wkoszek's build (ports/146895), and it's really >>>>>> easy to update it again. Also maybe it can be used as linux >>>>>> libusb-1.0.so too; I didn't actually test it tho. >>>>>> >>>>>> Should this be committed? Is wkoszek's version better since it >>>>>> also builds on < 10.x? Comments welcome... >>>>>> >>>>>> wkoszek's version: >>>>>> >>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=146895 >>>>>> >>>>>> Mine: >>>>>> >>>>>> http://people.freebsd.org/~nox/tmp/linux_libusb.shar >>>>>> >>>>>> Distfile: >>>>>> >>>>>> >>>>>> http://people.freebsd.org/~nox/tmp/distfiles/linux_libusb-11.0r261448.tar.bz2 >>>>>> >>>>>> 10/amd64 package: >>>>>> >>>>>> >>>>>> http://people.freebsd.org/~nox/tmp/packages/10amd64/linux_libusb-11.0r261448.txz >>>>>> >>>>>> (built via: >>>>>> >>>>>> poudriere bulk -v -j 10amd64 -p custom devel/linux_libusb >>>>>> >>>>>> - btw for some reason the dependency emulators/linux_base-gentoo-stage3 >>>>>> doesn't build for 10i386 in poudriere bulk, I get a pkg segfault. bapt >>>>>> Cc'd...) >>>>>> >>>>> >>>>> Juergen, >>>> Hi! >>>>> >>>>> What would be the reason for this update? >>>>> >>>>> My stuff may be out of date, but it was all tested and working. I verified >>>>> it with Linux'ish lsusb(1) and USB-based FPGA JTAG programmer, for which >>>>> this stuff was written. >>>>> >>>> I was just thinking an updated version may be useful, but if it's >>>> already working for everyone maybe less so... >>>> >>>> Or would it work as a linux libusb-1.0.so too? I know the libusb 1.0 >>>> stuff added some functions since 9.x at least... maybe hps would know >>>> (Cc'd.) >>>> >>> >>> Juergen, >>> >>> I think this package is useful and is looking for maintainer, so if you have >>> time and energy, I'm OK with upgrading it, but I suggest testing it first. >>> Bjoern might be interested too. >>> >> You mean bz@ ? Cc'd. I tried testing lsusb from debian sid but it printed >> nothing, neither with my nor with your older version, but maybe it's just >> `too new' for our current linuxolator. > > I assume you have at least 1 USB device while trying this. I don't remember > exactly, but while trying within Linuxolator, you may need devfs/procfs to > be mounted under Linuxolator's root directory. My understanding and from looking at trace is that if we cannot find it in /compat/linux we ale search in /; so no need for an extra mount unless maybe you run chrooted. > So you'll have to figure this out. > > Does it return with 0 exit code? > > If not, lsusb should be simple enough to let you place printf() all over the > place and understand out when it's failing. For me the problem was a clock_gettime() call in the libusb which my glibc did not provide. That made all things fail (silently) until I used linux “rtld" tracing to see the unresolved symbol from libusb/the commercial 3rd party software dynamically loading libusb. — Bjoern A. Zeeb ? ??? ??? ??: '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? ?? ?? ? ', ? ?, "??? ? ?? ?", ?.??? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: CFT #3: Re: linux libusb again... (now also for 10i386)
On Sat, 15 Mar 2014, Juergen Lock wrote: Hi! I now have changed my port to use devel/linux-f10-devtools instead of emulators/linux_base-gentoo-stage3 (you need linux-f10-devtools-10_1 because of http://www.freebsd.org/cgi/query-pr.cgi?pr=187609 ), which not only allows it to build outside of tb/powderkeg but also works around the missing 10i386 package issue: http://people.freebsd.org/~nox/tmp/linux_libusb-002.shar Packages: http://people.freebsd.org/~nox/tmp/packages/10amd64/linux_libusb-11.0r261448_1.txz http://people.freebsd.org/~nox/tmp/packages/10i386/linux_libusb-11.0r261448_1.txz (Seems you can also manually untar them and use them on 9.x, at least Linux lsusb seems to do something on 9.2/amd64 too.) I just fetched the amd64 package and instaled it on 10.0-RC5 and it just worked. Please get it in. :-) -- Bjoern A. Zeeb ? ??? ??? ??: '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? ?? ?? ? ', ? ?, "??? ? ?? ?", ?.??? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
