Re: CFT #3: Re: linux libusb again... (now also for 10i386)
On Tue, Mar 18, 2014 at 02:37:17PM +, Bjoern A. Zeeb wrote: > 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. :-) > Done. Thanx for testing! :) Juergen PS: someone wants to test it as Linux libusb-1.0 too? You'd have to ln it yourself but otherwise it might just work as such also... ___ 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)
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.) Happy testing... :) Juergen On Mon, Mar 03, 2014 at 07:18:25PM +0100, Juergen Lock wrote: > HPS found out what was wrong, the linux libusb needs to be built > with COMPAT_32BIT=YES on amd64 since the linuxolator is 32bit... > Using this packages Linux lsusb finally does something. > > So I updated the shar and package at the locations listed below, > please test! :) > > Thanx, > Juergen > > On Wed, Feb 12, 2014 at 12:20:48AM +0100, Juergen Lock wrote: > > On Tue, Feb 11, 2014 at 07:56:50PM +, Wojciech A. Koszek wrote: > > > On Tue, Feb 11, 2014 at 12:11:09AM +0100, Juergen Lock wrote: > > > > On Mon, Feb 10, 2014 at 11:06:27AM +, Bjoern A. Zeeb wrote: > > > > > > > > > > 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 >
CFT #2: Re: linux libusb again, I made an updated port...
HPS found out what was wrong, the linux libusb needs to be built with COMPAT_32BIT=YES on amd64 since the linuxolator is 32bit... Using this packages Linux lsusb finally does something. So I updated the shar and package at the locations listed below, please test! :) Thanx, Juergen On Wed, Feb 12, 2014 at 12:20:48AM +0100, Juergen Lock wrote: > On Tue, Feb 11, 2014 at 07:56:50PM +, Wojciech A. Koszek wrote: > > On Tue, Feb 11, 2014 at 12:11:09AM +0100, Juergen Lock wrote: > > > On Mon, Feb 10, 2014 at 11:06:27AM +, Bjoern A. Zeeb wrote: > > > > > > > > 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 > > > > >
Re: CFT: Re: linux libusb again, I made an updated port...
On Tue, Feb 11, 2014 at 07:56:50PM +, Wojciech A. Koszek wrote: > On Tue, Feb 11, 2014 at 12:11:09AM +0100, Juergen Lock wrote: > > On Mon, Feb 10, 2014 at 11:06:27AM +, Bjoern A. Zeeb wrote: > > > > > > 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. &g
Re: CFT: Re: linux libusb again, I made an updated port...
On Mon, Feb 10, 2014 at 11:06:27AM +, Bjoern A. Zeeb wrote: > > 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. > And my linux_kdump ends like this: 35607 lsusbCALL munmap(0x28247000,0x8000) 35607 lsusbRET munmap 0 35607 lsusbCALL linux_open(0x28090c31,0,0x28081e00) 35607 lsusbNAMI "/compat/linux/dev/usbctl" 35607 lsusbNAMI "/dev/usbctl" 35607 lsusbRET linux_open 3 35607 lsusbCALL linux_ioctl(0x3,0xffe5 ,0xc5d8) 35607 lsusbRET linux_ioctl 0 35607 lsusbCALL close(0x3) 35607 lsusbRET close 0 35607 lsusbCALL linux_exit_group(0x1) 35607 lsusbUNKNOWN(11) and the exit code is 1, so I guess it's failing on an unhandled syscall or something like that. Juergen ___ 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"
CFT: Re: linux libusb again, I made an updated port...
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. > > > 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? Juergen ___ 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: linux libusb again, I made an updated port...
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.) > 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.) Thanx, Juergen ___ 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"
linux libusb again, I made an updated port...
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...) Thanx, Juergen ___ 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: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, Oct 11, 2011 at 09:39:52PM +0200, Hans Petter Selasky wrote: > On Tuesday 11 October 2011 21:31:02 Juergen Lock wrote: > > On Tue, Oct 11, 2011 at 08:35:49PM +0200, Michal Varga wrote: > > > On Tue, 2011-10-11 at 20:21 +0200, Juergen Lock wrote: > > > > No. webcamd has become kind of a misnomer, it's in fact just a > > > > `wrapper' for several kinds of Linux usb kernel drivers to run them in > > > > FreeBSD userland. (We have now at least webcams, dvb tuners, IR > > > > transceivers, and usb tablets. :) > > > > > > Oh god, thank you for mentioning this. I've been personally keeping > > > webcamd out of my installations as "we don't need no stinkin webcams > > > here", but this is something completely different based on what you say > > > (especially the Wacom support). > > > > > > Was there any push to rename webcamd to something more meaningful yet? > > > > I'm not aware of anything like that... > > In my talk at EuroBSDcon I said that webcamd might be renamed in the future. > Does anyone have any good suggestions? Hmm thats tricky... usbd-linux? Can't think of something really good... Juergen ___ 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: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, Oct 11, 2011 at 08:35:49PM +0200, Michal Varga wrote: > On Tue, 2011-10-11 at 20:21 +0200, Juergen Lock wrote: > > > No. webcamd has become kind of a misnomer, it's in fact just a `wrapper' > > for several kinds of Linux usb kernel drivers to run them in FreeBSD > > userland. (We have now at least webcams, dvb tuners, IR transceivers, > > and usb tablets. :) > > > > Oh god, thank you for mentioning this. I've been personally keeping > webcamd out of my installations as "we don't need no stinkin webcams > here", but this is something completely different based on what you say > (especially the Wacom support). > > Was there any push to rename webcamd to something more meaningful yet? I'm not aware of anything like that... Juergen ___ 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: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, Oct 11, 2011 at 01:54:14PM -0400, Jason Hellenthal wrote: > > > On Tue, Oct 11, 2011 at 06:47:16PM +0200, Juergen Lock wrote: > > On Tue, Oct 11, 2011 at 06:23:41PM +0200, Juergen Lock wrote: > > > Hi! > > > > > > My dad likes to paint a bit so I got him a Wacom tablet as a present > > > (Bamboo Pen & Touch), and I thought I could help getting it working > > > on FreeBSD while I was at it... [...] > > > > I guess I should have said getting it working on 8.x and later, I > > suppose the input-wacom port currently in ports still can be made > > to work with the old usb stack in 7.x. > > > > I might be missing something but does this tablet have a webcam built > into it ? this is me not understanding the use of webcamd. No. webcamd has become kind of a misnomer, it's in fact just a `wrapper' for several kinds of Linux usb kernel drivers to run them in FreeBSD userland. (We have now at least webcams, dvb tuners, IR transceivers, and usb tablets. :) HTH, Juergen ___ 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"
Testing Wacom usb tablet with webcamd svn (and mypaint)
Hi! My dad likes to paint a bit so I got him a Wacom tablet as a present (Bamboo Pen & Touch), and I thought I could help getting it working on FreeBSD while I was at it... Asked hps, who kindly prepared a webcamd update that adds support: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/ports cd ports/multimedia/webcamd && make all install clean which I now tested with a preliminary x11-drivers/input-wacom xorg driver update that I prepared: http://people.freebsd.org/~nox/tmp/inputwacom.patch I had to rebuild xorg-server without hal support because apparently hal and thus the xserver picked up webcamd's /dev/input node for the wacom which made my mouse misbehave (proper hal configs to ignore webcamd's device node welcome, :) and I added this to xorg.conf: snip--- Section "ServerLayout" ... InputDevice "stylus" InputDevice "eraser" ... EndSection ... Section "InputDevice" Driver "wacom" Identifier "stylus" Option "Device""/dev/input/event0" Option "Type" "stylus" Option "USB" "on" EndSection Section "InputDevice" Driver "wacom" Identifier "eraser" Option "Device""/dev/input/event0" Option "Type" "eraser" Option "USB" "on" EndSection snip--- ..and that appears to have got graphics/mypaint working (which btw needs x11-toolkits/py-gtk2 rebuilt with the NUMPY knob on), with both the stylus and eraser of my (dad's) tablet. (mypaint ignores the pad device so I removed it from xorg.conf again, see the wacom(4x) manpage and the input-wacom wiki.) Happy testing, and thanks to Hans! Juergen ___ 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: Testing Wacom usb tablet with webcamd svn (and mypaint)
On Tue, Oct 11, 2011 at 06:23:41PM +0200, Juergen Lock wrote: > Hi! > > My dad likes to paint a bit so I got him a Wacom tablet as a present > (Bamboo Pen & Touch), and I thought I could help getting it working > on FreeBSD while I was at it... [...] I guess I should have said getting it working on 8.x and later, I suppose the input-wacom port currently in ports still can be made to work with the old usb stack in 7.x. Sorry... :) Juergen ___ 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: qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()
On Tue, Aug 16, 2011 at 09:54:23PM +0200, Juergen Lock wrote: > On Tue, Aug 16, 2011 at 09:37:39AM +0200, Hans Petter Selasky wrote: > > On Monday 15 August 2011 22:26:56 Juergen Lock wrote: > > > Hi! > > > > > > I just prepared a preliminary update of the emulators/qemu-devel > > > port to 0.15.0 [1], and among other things it now also has a > > > usb network redirection feature using usbredir [2], which uses > > > libusb 1.0 and a function that is missing in our version, > > > libusb_get_device_speed(). I added a stub to the code that > > > always returns LIBUSB_SPEED_UNKNOWN > > > (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]), > > > question for Hans (I guess), would there be an easy way to make a > > > `proper' implementation? > > > > > > If anyone wants to help me test qemu 0.15.0, thanx! > > > > Please try the attached patch to libusb in /usr/src/lib/libusb . > > > > You only need to rebuild libusb: make all install clean > > > > > FETCHENTRY: entry at 22C5484 is of type 2 which is not supported > > > yet processing error - resetting ehci HC > > > > Try my patch first. EHCI needs to know device speed. > > Thanx, tho it turns out: > > a) the FETCHENTRY:.. crash also happens without any device redirection >with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig >docs/ich9-ehci-uhci.cfg), and > > b) if I test this with your patch (working libusb_get_device_speed() >that doesn't just always return LIBUSB_SPEED_UNKNOWN) and redirecting >an usb 2.0 device with ehci enabled using usbredir then qemu >complains like: > > qemu: Warning: speed mismatch trying to attach usb device USB Redirectio > n Device to bus usb.0 > >and ignores the redirected device. So for now I have added a >#define IGNORE_LIBUSB_GET_DEVICE_SPEED to the (updated) preliminary >usbredir FreeBSD port, > > http://people.freebsd.org/~nox/qemu/usbredir.shar > >so that usbredirhost_open() now always works with: > > device_connect.speed = usb_redir_speed_unknown; > > Question: do people also see this problem on Linux? This post has > an usage example: > > http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183 > > Or is the problem just that with the example usage, > > sudo usbredirserver 045e:0772 > ... > qemu ... \ > -readconfig docs/ich9-ehci-uhci.cfg \ > -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ > -device usb-redir,chardev=usbredirchardev,id=usbredirdev > > qemu 0.15.0 tries to attach the redirected usb 2.0 device to the > uhci bus instead of to the ehci one and if yes, how can I fix that? Nevermind, I didn't actually put the -readconfig parameter first. :( (It didn't occur to me that the order would matter...) But now I found that: a) seabios hangs at boot when I redirect an usb 2.0 flashkey with ehci enabled (at least with -cdrom), and b) with ehci disabled I still get the speed mismatch warning and the device is ignored. Maybe the speed mismatch check should be relaxed if there isn't a bus as fast as the device, and the device be attached to the fastest available bus instead? (i.e. also the same is likely to happen with usb 3.0 devices?) Thanx, Juergen (who will leave the FreeBSD usbredir port using usb_redir_speed_unknown for now I guess...) ___ 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: qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()
On Tue, Aug 16, 2011 at 09:37:39AM +0200, Hans Petter Selasky wrote: > On Monday 15 August 2011 22:26:56 Juergen Lock wrote: > > Hi! > > > > I just prepared a preliminary update of the emulators/qemu-devel > > port to 0.15.0 [1], and among other things it now also has a > > usb network redirection feature using usbredir [2], which uses > > libusb 1.0 and a function that is missing in our version, > > libusb_get_device_speed(). I added a stub to the code that > > always returns LIBUSB_SPEED_UNKNOWN > > (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]), > > question for Hans (I guess), would there be an easy way to make a > > `proper' implementation? > > > > If anyone wants to help me test qemu 0.15.0, thanx! > > Please try the attached patch to libusb in /usr/src/lib/libusb . > > You only need to rebuild libusb: make all install clean > > > FETCHENTRY: entry at 22C5484 is of type 2 which is not supported > > yet processing error - resetting ehci HC > > Try my patch first. EHCI needs to know device speed. Thanx, tho it turns out: a) the FETCHENTRY:.. crash also happens without any device redirection with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig docs/ich9-ehci-uhci.cfg), and b) if I test this with your patch (working libusb_get_device_speed() that doesn't just always return LIBUSB_SPEED_UNKNOWN) and redirecting an usb 2.0 device with ehci enabled using usbredir then qemu complains like: qemu: Warning: speed mismatch trying to attach usb device USB Redirectio n Device to bus usb.0 and ignores the redirected device. So for now I have added a #define IGNORE_LIBUSB_GET_DEVICE_SPEED to the (updated) preliminary usbredir FreeBSD port, http://people.freebsd.org/~nox/qemu/usbredir.shar so that usbredirhost_open() now always works with: device_connect.speed = usb_redir_speed_unknown; Question: do people also see this problem on Linux? This post has an usage example: http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183 Or is the problem just that with the example usage, sudo usbredirserver 045e:0772 ... qemu ... \ -readconfig docs/ich9-ehci-uhci.cfg \ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ -device usb-redir,chardev=usbredirchardev,id=usbredirdev qemu 0.15.0 tries to attach the redirected usb 2.0 device to the uhci bus instead of to the ehci one and if yes, how can I fix that? Thanx! :) Juergen ___ 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"
qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()
Hi! I just prepared a preliminary update of the emulators/qemu-devel port to 0.15.0 [1], and among other things it now also has a usb network redirection feature using usbredir [2], which uses libusb 1.0 and a function that is missing in our version, libusb_get_device_speed(). I added a stub to the code that always returns LIBUSB_SPEED_UNKNOWN (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]), question for Hans (I guess), would there be an easy way to make a `proper' implementation? If anyone wants to help me test qemu 0.15.0, thanx! I also updated the net.c and net.h udp patches for gns3 for this qemu version: (the other gns3 patchfiles for qemu 0.14 still apply) http://people.freebsd.org/~nox/qemu/qemu-0.15.0-gns3-patches/ I added this note to the qemu-devel pkg-message about the usb redirection [1]: snip-- - If you want to test the new (in 0.15.0) usb network redirection (USBREDIR option) see this thread by Hans de Goede redhat.com>: http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183 Quote: Example usage: 1) Start usbredirserver for a usb device: sudo usbredirserver 045e:0772 2) Start qemu with usb2 support + a chardev talking to usbredirserver + a usb-redir device using this chardev: qemu ... \ -readconfig docs/ich9-ehci-uhci.cfg \ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ -device usb-redir,chardev=usbredirchardev,id=usbredirdev [you would replace docs/ich9-ehci-uhci.cfg with e.g. /usr/local/share/doc/qemu/docs/ich9-ehci-uhci.cfg, but turns out ehci seems broken for me here with FreeBSD guests at least, I get: FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet processing error - resetting ehci HC Assertion failed: (0), function ehci_advance_state, file /data/ports/emulators/qemu-devel/work/qemu-0.15.0/hw/usb-ehci.c, line 2045. Starting the same without ehci (-readconfig) works, tho usbredirserver crashes when qemu exits.] snip-- Thanx! :) Juergen [1] Changelog: http://wiki.qemu.org/ChangeLog/0.15 Preliminary port: http://people.freebsd.org/~nox/qemu/qemu-devel-0.15.0.shar Patch against current qemu-devel port: http://people.freebsd.org/~nox/qemu/qemu-devel-0.15.0.patch [2] usbredir 0.3: http://cgit.freedesktop.org/~jwrdegoede/usbredir/ Preliminary port: http://people.freebsd.org/~nox/qemu/usbredir.shar ___ 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 umass panic on 7-stable built today
On Wed, Jul 14, 2010 at 08:49:10PM +0400, pluknet wrote:
> On 20 July 2009 01:52, Juergen Lock wrote:
> > Hi!
> >
> > So I wanted to use an usb key on this freshly updated 7-stable box,
> > and got a panic just after plugging it in: :(
> >
> > zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9
> > ...
> > umass0: on uhub5
> > umass0:1:0:-1: Attached to scbus1
> >
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address = 0x290
> > fault code = supervisor read data, page not present
> > instruction pointer = 0x8:0x804d67d4
> > stack pointer = 0x10:0xff8085487da0
> > frame pointer = 0x10:0xff8085487de0
> > code segment = base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process = 38 (usb5)
> > trap number = 12
> > panic: page fault
> > cpuid = 0
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > panic() at panic+0x182
> > trap_fatal() at trap_fatal+0x2b3
> > trap_pfault() at trap_pfault+0x294
> > trap() at trap+0x312
> > calltrap() at calltrap+0x8
> > --- trap 0xc, rip = 0x804d67d4, rsp = 0xff8085487da0, rbp =
> > 0xff8085487de0 ---
> > usb_transfer_complete() at usb_transfer_complete+0x1d4
> > bus_dmamap_load() at bus_dmamap_load+0x314
> > usbd_transfer() at usbd_transfer+0xee
> > usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f
> > usbd_do_request_flags() at usbd_do_request_flags+0x25
> > usbd_get_string_desc() at usbd_get_string_desc+0x9b
> > usbd_get_string() at usbd_get_string+0x83
> > uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9
> > devaddq() at devaddq+0xd5
> > device_attach() at device_attach+0x13a
> > usbd_new_device() at usbd_new_device+0x821
> > uhub_explore() at uhub_explore+0x1bd
> > usb_discover() at usb_discover+0x38
> > usb_event_thread() at usb_event_thread+0x8a
> > fork_exit() at fork_exit+0x11f
> > fork_trampoline() at fork_trampoline+0xe
> > --- trap 0, rip = 0, rsp = 0xff8085488d30, rbp = 0 ---
> > Uptime: 1m1s
> > Physical memory: 8176 MB
> > Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430
> > 4414 4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190
> > 4174 4158 4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950
> > 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710
> > 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470
> > 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230
> > 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990
> > 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750
> > 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510
> > 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270
> > 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030
> > 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790
> > 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550
> > 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390
> 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150
> 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878
> 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574
> 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270
> 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14
> >
> > Reading symbols from /boot/kernel/umass.ko...Reading symbols from
> > /boot/kernel/umass.ko.symbols...done.
> > done.
> > Loaded symbols for /boot/kernel/umass.ko
> > #0 doadump () at pcpu.h:195
> > 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> > (kgdb) bt
> > #0 doadump () at pcpu.h:195
> > #1 0x80567248 in boot (howto=260)
> > at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418
> > #2 0x805676ac in panic (fmt=Variable "fmt" is not available.
> > )
> > at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574
> > #3 0x8082f953 in trap_fatal (frame=0xc, eva=Variable "eva" is not
> > available.
> > )
> > at /usr/hom
Re: patch: (newusb) cdce failed to attach, was ignoring quirks
On Wed, Aug 05, 2009 at 08:00:53PM +0200, Hans Petter Selasky wrote: > On Wednesday 05 August 2009 18:54:32 Juergen Lock wrote: > > I'd say the broader matches must come after the specific ones here or > > the quirks may not be found... (This makes at least my zaurus attach and > > pingable again.) > > Right! > > Thanks for reporting. > > Committed to USB P4: > > http://perforce.freebsd.org/chv.cgi?CH=167039 You're welcome! Juergen (I was glad I was able to spot the bug myself too, given how little I know about usb... :) ___ 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"
patch: (newusb) cdce failed to attach, was ignoring quirks
I'd say the broader matches must come after the specific ones here or
the quirks may not be found... (This makes at least my zaurus attach and
pingable again.)
Index: sys/dev/usb/net/if_cdce.c
@@ -197,9 +197,6 @@
};
static const struct usb_device_id cdce_devs[] = {
- {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_ETHERNET_NETWORKING_CONTROL_MODEL,
0)},
- {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_MOBILE_DIRECT_LINE_MODEL, 0)},
-
{USB_VPI(USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632,
CDCE_FLAG_NO_UNION)},
{USB_VPI(USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250,
CDCE_FLAG_NO_UNION)},
{USB_VPI(USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX,
CDCE_FLAG_NO_UNION)},
@@ -213,6 +210,9 @@
{USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLA300, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
{USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC700, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
{USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC750, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
+
+ {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_ETHERNET_NETWORKING_CONTROL_MODEL,
0)},
+ {USB_IF_CSI(UICLASS_CDC, UISUBCLASS_MOBILE_DIRECT_LINE_MODEL, 0)},
};
static int
___
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"
new umass panic on 7-stable built today
Hi!
So I wanted to use an usb key on this freshly updated 7-stable box,
and got a panic just after plugging it in: :(
zsh triton# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.9
...
umass0: on uhub5
umass0:1:0:-1: Attached to scbus1
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x290
fault code = supervisor read data, page not present
instruction pointer = 0x8:0x804d67d4
stack pointer = 0x10:0xff8085487da0
frame pointer = 0x10:0xff8085487de0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 38 (usb5)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x182
trap_fatal() at trap_fatal+0x2b3
trap_pfault() at trap_pfault+0x294
trap() at trap+0x312
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x804d67d4, rsp = 0xff8085487da0, rbp =
0xff8085487de0 ---
usb_transfer_complete() at usb_transfer_complete+0x1d4
bus_dmamap_load() at bus_dmamap_load+0x314
usbd_transfer() at usbd_transfer+0xee
usbd_do_request_flags_pipe() at usbd_do_request_flags_pipe+0x8f
usbd_do_request_flags() at usbd_do_request_flags+0x25
usbd_get_string_desc() at usbd_get_string_desc+0x9b
usbd_get_string() at usbd_get_string+0x83
uhub_child_pnpinfo_str() at uhub_child_pnpinfo_str+0xd9
devaddq() at devaddq+0xd5
device_attach() at device_attach+0x13a
usbd_new_device() at usbd_new_device+0x821
uhub_explore() at uhub_explore+0x1bd
usb_discover() at usb_discover+0x38
usb_event_thread() at usb_event_thread+0x8a
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8085488d30, rbp = 0 ---
Uptime: 1m1s
Physical memory: 8176 MB
Dumping 4605 MB: 4590 4574 4558 4542 4526 4510 4494 4478 4462 4446 4430 4414
4398 4382 4366 4350 4334 4318 4302 4286 4270 4254 4238 4222 4206 4190 4174 4158
4142 4126 4110 4094 4078 4062 4046 4030 4014 3998 3982 3966 3950 3934 3918 3902
3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646
3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390
3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134
3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878
2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622
2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366
2350 2334 2318 2302 2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110
2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854
1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598
1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342
1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086
1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798
782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478
462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158
142 126 110 94 78 62 46 30 14
Reading symbols from /boot/kernel/umass.ko...Reading symbols from
/boot/kernel/umass.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/umass.ko
#0 doadump () at pcpu.h:195
195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0x80567248 in boot (howto=260)
at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:418
#2 0x805676ac in panic (fmt=Variable "fmt" is not available.
)
at /usr/home/nox/src72s2/src/sys/kern/kern_shutdown.c:574
#3 0x8082f953 in trap_fatal (frame=0xc, eva=Variable "eva" is not
available.
)
at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:756
#4 0x8082fd34 in trap_pfault (frame=0xff8085487cf0, usermode=0)
at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:672
#5 0x808306e2 in trap (frame=0xff8085487cf0)
at /usr/home/nox/src72s2/src/sys/amd64/amd64/trap.c:443
#6 0x80819cce in calltrap ()
at /usr/home/nox/src72s2/src/sys/amd64/amd64/exception.S:218
#7 0x804d67d4 in usb_transfer_complete (xfer=0xff00046b1000)
at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:949
#8 0x80815bf4 in bus_dmamap_load (dmat=0xff0004499880,
map=0xff000478ec00, buf=0xff8085487fe0, buflen=0,
callback=0x804d68b0 ,
callback_arg=0xff00046b1000, flags=0)
at /usr/home/nox/src72s2/src/sys/amd64/amd64/busdma_machdep.c:738
#9 0x804d6f2e in usbd_transfer (xfer=0xff00046b1000)
at /usr/home/nox/src72s2/src/sys/dev/usb/usbdi.c:312
#10 0x804d717f in usbd_do_request_flags_pipe (dev=0xff0004751600,
Re: Failing controls transfers in VMware
In article <200907012107.48635.hsela...@c2i.net> you write:
>On Wednesday 01 July 2009 20:31:41 Markus Dolze wrote:
>> Hans Petter Selasky wrote:
>> > On Tuesday 30 June 2009 22:11:47 Markus Dolze wrote:
>> >> Markus Dolze wrote:
>> >>> To repeat run the attached program:
>> >>>
>> >>>1. Fill in some vendor / product ID of a device detected as ugen
>> >>> device 2. Compile and run the code (devel/libusb must be installed).
>> >
>> > You should use this function when reading strings:
>> >
>> > int usb_get_string_simple(usb_dev_handle * dev, int index, char *buf,
>> > size_t buflen);
>>
>> Yes, this is more easy, but I crafted the control transfers myself to
>> show that actually the control transfer is failing.
>
>Sometimes you have to pass the exact length of the string, and not the maximum
>length when doing the control request.
Just though I'd mention... hplip (ports/print/hplip, actually I am testing
the port for the new version that was posted on -ports) works around a
similar issue (string fetching failing on first try) by simply retrying
the same transfer after a 2s delay. (And I just got that working here on
7-stable by checking for a return value of -EIO in addition to 0 that was
in the original code and made my printer not work.)
Here is that code (with the patch), see also:
http://lists.freebsd.org/pipermail/freebsd-ports/2009-July/055840.html
..
/* This function is similar to usb_get_string_simple, but it handles zero
returns. */
static int get_string_descriptor(usb_dev_handle *dev, int index, char *buf,
size_t buflen)
{
char tbuf[255]; /* Some devices choke on size > 255 */
int ret, si, di, cnt=5;
while (cnt--)
{
ret = usb_control_msg(dev, USB_ENDPOINT_IN, USB_REQ_GET_DESCRIPTOR,
(USB_DT_STRING << 8) + index,
0x409, tbuf, sizeof(tbuf), LIBUSB_CONTROL_REQ_TIMEOUT);
if (ret==0 || ret == -EIO)
{
/* This retry is necessary for lj1000 and lj1005. des 12/12/07
Also HP Photosmart 42xx seems to suffer transient errors with serial
id */
BUG("get_string_descriptor error result %d, retrying in 2 secs...",
ret);
sleep(2);
continue;
}
break;
}
if (ret < 0)
{
BUG("unable get_string_descriptor %d: %m\n", ret);
return ret;
}
if (tbuf[1] != USB_DT_STRING)
{
BUG("invalid get_string_descriptor tag act=%d exp=%d\n", tbuf[1],
USB_DT_STRING);
return -EIO;
}
if (tbuf[0] > ret)
{
BUG("invalid get_string_descriptor size act=%d exp=%d\n", tbuf[0], ret);
return -EFBIG;
}
for (di = 0, si = 2; si < tbuf[0]; si += 2)
{
if (di >= (buflen - 1))
break;
if (tbuf[si + 1]) /* high byte */
buf[di++] = '0';
else
buf[di++] = tbuf[si];
}
buf[di] = 0;
return di;
}
..
Btw, something else since that question also came up on -ports, does the
new stack support accessing e.g. ulpt devices as ugen too? I know the old
one didn't, which is why you have to take out ulpt (and umass depending
on the particular printer) out of the kernel when you want to use hplip,
which you don't have to do e.g. on (sorry :) Linux... (As mentioned in
that other post testing head here is difficult since it has ata issues
on this box. ):
Thanx,
Juergen
___
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: Xorg 7.4 and umass devices - a bad combination?
In article <20090318205909.07625cdb.torfinn.ingolf...@broadpark.no> you write: >Hello, > >More testing. >- I verified that listing the firewire drive while Xorg is running >doesn't seeem to cause any errors. >So I thought: what happens if I start Xorg (using startx), then exit it >and _then_ do an 'ls' on the usb drives? > >First try: 'startx', do a couple of commands (like 'date', 'pwd'), the >exit Xorg again. Then do 'ls' on the usb drives. Result: it works >without errors. > >Second try: 'startx', do a couple of commands (like 'date', 'pwd'), the >exit Xorg again. Then do 'ls' on the usb drives. Result: the erors are >back. Just in case you haven't seen it yet... Apparently there have been issues on some hardware with the way xorg (used to) probe the pci bus, see the `Unhappy Xorg upgrade' thread on -stable, particularly: http://docs.freebsd.org/cgi/mid.cgi?1234292252.1524.38.camel and http://docs.freebsd.org/cgi/mid.cgi?49A81556.2040801 (which details the fix.) HTH, Juergen ___ 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: umass0: BBB reset failed, TIMEOUT (again)
On Sat, Sep 23, 2006 at 06:36:22PM +0200, Hans Petter Selasky wrote: > On Saturday 23 September 2006 16:57, Juergen Lock wrote: > > On Fri, Sep 22, 2006 at 08:34:29AM +0200, Hans Petter Selasky wrote: > > > On Friday 22 September 2006 00:04, Juergen Lock wrote: > > > > On Wed, Sep 20, 2006 at 11:18:32AM +0200, Hans Petter Selasky wrote: > > > > > On Wednesday 20 September 2006 03:11, Juergen Lock wrote: > > > > > > Today for the first time since this box got a new board I tried to > > > > > > copy data onto the usb cardreader, and after copying for a while it > > > > > > suddenly stopped (led stopped flashing, no further io), and after > > > > > > some time i had the above in dmesg. And that was it, cp process > > > > > > hung, no way to kill it. Unplugged the thing, and got the expected > > > > > > panic: vinvalbuf: dirty bufs. Tried the same thing from linux > > > > > > (after dosfsck), and there copying stopped for a while too, but it > > > > > > then continued and finished. Is this is some kind of new hardware > > > > > > quirk of the new board's ehci controller, that linux recovers from? > > > > > > (via, there already is a `dropped interrupt' fix for it, which > > > > > > helped with my last board...) > > > > > > We can easily check for dropped interrupts. If you run: > > > > > > sysctl hw.usb.ehci.debug=15 > > > sysctl hw.usb.umass.debug=-1 > > > > > > When your device hangs. And then send me the log again. > > > > > > > Ok. This time writing worked, but reading back to verify (cmp) seemed > > > > to hang. Did the sysctl (see below), then a while later I got an IO > > > > error. Tried to umount, got another IO error, tried umount -f, got a > > > > panic (probably expected.) I have now installed mtools and won't mount > > > > umass devices on this box anymore... :/ (Btw when I later tried to > > > > mcopy the file off the thing using the original kernel I noticed the > > > > led was off after it hung, dunno if that also was the case when I tried > > > > it with the new code but I would suspect so. At least this time, since > > > > it wasnt mounted, I could unplug it without getting a panic...) > > > > > > > > Oh, one thing that occured to me: Even when you may be able to get > > > > around (what appars to be) hardware quirks like this by retrying IO > > > > or resetting the device, that probably wont work when you have an > > > > umass tape drive (sa), since with tape you can't just retry a > > > > read/write, and resetting it may even rewind, with the next write > > > > erasing everything on the tape. Just a thought... > > > > > > > > Anyway, here's the syslog of the `experiment', beginning after the > > > > sysctl: > > > > > > From the log I see that it looks like the statemachine of your device has > > > locked up. Even the reset command is timing out. That should not happen. > > > We could try to reconfigure the device, when reset fails. > > > > OK. I applied the umass_transfer_start(sc, UMASS_T_BBB_STATUS); > > patch in your other message and tried mcopy'ing off it again. > > This time I got a bunch of errors when first connecting it > > (well, more than usual) and /dev/da2s1 didnt appear, so I had to > > replug. (This may be a quirk of the device not of the board, since, > > unlike the IO problems, it also happened sometimes with my old board.) > > Anyway, I have left logs of that in, just in case... > > The first read this time hung with the led on, I did the sysctls, > > and soon after that (after messages were logged) the mcopy command > > exited without any error, leaving a truncated copy! Just in case, > > I did an fsck_msdos, but it found nothing wrong. Changed the sysctls > > back to 0 and tried another copy, this time it hung with the led off. > > Turned the sysctls back on and waited until mcopy exited, this time > > with an IO error (led was still off.) Unplugged, and bzip2'd the log > > (its big, probably because I left the sysctls on while doing the fsck.) > > > > I guess the usb controller on this board is just weird... :/ > > >From what I can see your device stops responding: > > Sep 23 16:26:55 saturn kernel: QTD(0xc54d55c0) at 0x2b9895c0: > Sep 23 16:26:55 saturn kernel: next=0x2b989580<> altnext=0x0001 > Sep 23 16
Re: umass0: BBB reset failed, TIMEOUT (again)
On Fri, Sep 22, 2006 at 08:34:29AM +0200, Hans Petter Selasky wrote: > On Friday 22 September 2006 00:04, Juergen Lock wrote: > > On Wed, Sep 20, 2006 at 11:18:32AM +0200, Hans Petter Selasky wrote: > > > On Wednesday 20 September 2006 03:11, Juergen Lock wrote: > > > > Today for the first time since this box got a new board I tried to > > > > copy data onto the usb cardreader, and after copying for a while it > > > > suddenly stopped (led stopped flashing, no further io), and after > > > > some time i had the above in dmesg. And that was it, cp process > > > > hung, no way to kill it. Unplugged the thing, and got the expected > > > > panic: vinvalbuf: dirty bufs. Tried the same thing from linux (after > > > > dosfsck), and there copying stopped for a while too, but it then > > > > continued and finished. Is this is some kind of new hardware quirk of > > > > the new board's ehci controller, that linux recovers from? (via, > > > > there already is a `dropped interrupt' fix for it, which helped with > > > > my last board...) > > We can easily check for dropped interrupts. If you run: > > sysctl hw.usb.ehci.debug=15 > sysctl hw.usb.umass.debug=-1 > > When your device hangs. And then send me the log again. > > > > > Ok. This time writing worked, but reading back to verify (cmp) seemed > > to hang. Did the sysctl (see below), then a while later I got an IO error. > > Tried to umount, got another IO error, tried umount -f, got a panic > > (probably expected.) I have now installed mtools and won't mount umass > > devices on this box anymore... :/ (Btw when I later tried to mcopy the > > file off the thing using the original kernel I noticed the led was off > > after it hung, dunno if that also was the case when I tried it with the > > new code but I would suspect so. At least this time, since it wasnt > > mounted, I could unplug it without getting a panic...) > > > > Oh, one thing that occured to me: Even when you may be able to get > > around (what appars to be) hardware quirks like this by retrying IO > > or resetting the device, that probably wont work when you have an > > umass tape drive (sa), since with tape you can't just retry a read/write, > > and resetting it may even rewind, with the next write erasing everything > > on the tape. Just a thought... > > > > Anyway, here's the syslog of the `experiment', beginning after the sysctl: > > > From the log I see that it looks like the statemachine of your device has > locked up. Even the reset command is timing out. That should not happen. We > could try to reconfigure the device, when reset fails. OK. I applied the umass_transfer_start(sc, UMASS_T_BBB_STATUS); patch in your other message and tried mcopy'ing off it again. This time I got a bunch of errors when first connecting it (well, more than usual) and /dev/da2s1 didnt appear, so I had to replug. (This may be a quirk of the device not of the board, since, unlike the IO problems, it also happened sometimes with my old board.) Anyway, I have left logs of that in, just in case... The first read this time hung with the led on, I did the sysctls, and soon after that (after messages were logged) the mcopy command exited without any error, leaving a truncated copy! Just in case, I did an fsck_msdos, but it found nothing wrong. Changed the sysctls back to 0 and tried another copy, this time it hung with the led off. Turned the sysctls back on and waited until mcopy exited, this time with an IO error (led was still off.) Unplugged, and bzip2'd the log (its big, probably because I left the sysctls on while doing the fsck.) I guess the usb controller on this board is just weird... :/ cheers, Juergen messages.bz2 Description: Binary data ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass0: BBB reset failed, TIMEOUT (again)
On Wed, Sep 20, 2006 at 11:18:32AM +0200, Hans Petter Selasky wrote: > On Wednesday 20 September 2006 03:11, Juergen Lock wrote: > > Today for the first time since this box got a new board I tried to > > copy data onto the usb cardreader, and after copying for a while it > > suddenly stopped (led stopped flashing, no further io), and after > > some time i had the above in dmesg. And that was it, cp process > > hung, no way to kill it. Unplugged the thing, and got the expected > > panic: vinvalbuf: dirty bufs. Tried the same thing from linux (after > > dosfsck), and there copying stopped for a while too, but it then > > continued and finished. Is this is some kind of new hardware quirk of > > the new board's ehci controller, that linux recovers from? (via, > > there already is a `dropped interrupt' fix for it, which helped with > > my last board...) I also tried building a RELENG_6 kernel (one > > of the PRs I looked at also suggested this), but it behaved the same. > > Just in case, I took a dump of that too, but I don't really know for > > what to look in there so you'd have to tell me... > > > > Could you have tried my new USB driver and see if the problem is the same? > > # > # First get all the sources > # (you need /usr/ports/devel/subversion installed) > # > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b > > # > # The following commands will > # install the driver on FreeBSD: > # > > cd i4b/trunk/i4b/FreeBSD.usb > make S=../src package > make install > > # > # Then build a new kernel (with modules). > # > > When the device hangs, turn on USB debugging: > > sysctl hw.usb.umass.debug=-1 Ok. This time writing worked, but reading back to verify (cmp) seemed to hang. Did the sysctl (see below), then a while later I got an IO error. Tried to umount, got another IO error, tried umount -f, got a panic (probably expected.) I have now installed mtools and won't mount umass devices on this box anymore... :/ (Btw when I later tried to mcopy the file off the thing using the original kernel I noticed the led was off after it hung, dunno if that also was the case when I tried it with the new code but I would suspect so. At least this time, since it wasnt mounted, I could unplug it without getting a panic...) Oh, one thing that occured to me: Even when you may be able to get around (what appars to be) hardware quirks like this by retrying IO or resetting the device, that probably wont work when you have an umass tape drive (sa), since with tape you can't just retry a read/write, and resetting it may even rewind, with the next write erasing everything on the tape. Just a thought... Anyway, here's the syslog of the `experiment', beginning after the sysctl: Sep 21 21:41:21 saturn kernel: (da2:umass-sim0:0:0:2): Request completed with CAM_REQ_CMP_ERR Sep 21 21:41:21 saturn kernel: (da2:umass-sim0:0:0:2): Retrying Command Sep 21 21:41:26 saturn kernel: (da2:umass-sim0:0:0:2): Request completed with CAM_REQ_CMP_ERR Sep 21 21:41:26 saturn kernel: (da2:umass-sim0:0:0:2): Retrying Command Sep 21 21:41:31 saturn kernel: umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset Sep 21 21:41:31 saturn kernel: umass0:umass_transfer_start: transfer index = 0 Sep 21 21:41:31 saturn kernel: (da2:umass-sim0:0:0:2): Request completed with CAM_REQ_CMP_ERR Sep 21 21:41:31 saturn kernel: umass0:umass_t_bbb_reset1_callback: BBB reset! Sep 21 21:41:31 saturn kernel: umass0:umass_cam_action: 4:0:2:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/16384b data/32b sense Sep 21 21:41:31 saturn kernel: (da2:umass-sim0:0:0:2): Retrying Command Sep 21 21:41:36 saturn kernel: umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset Sep 21 21:41:36 saturn kernel: umass0:umass_transfer_start: transfer index = 0 Sep 21 21:41:36 saturn kernel: (da2:umass-sim0:0:0:2): Request completed with CAM_REQ_CMP_ERR Sep 21 21:41:36 saturn kernel: umass0:umass_t_bbb_reset1_callback: BBB reset! Sep 21 21:41:36 saturn kernel: umass0:umass_cam_action: 4:0:2:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/16384b data/32b sense Sep 21 21:41:36 saturn kernel: (da2:umass-sim0:0:0:2): Retrying Command Sep 21 21:41:41 saturn kernel: umass0:umass_tr_error: transfer error, USBD_TIMEOUT -> reset Sep 21 21:41:41 saturn kernel: umass0:umass_transfer_start: transfer index = 0 Sep 21 21:41:41 saturn kernel: (da2:umass-sim0:0:0:2): Request completed with CAM_REQ_CMP_ERR Sep 21 21:41:41 saturn kernel: (da2:umass-sim0:0:0:2): error 5 Sep 21 21:41:41 saturn kernel: (da2:umass-sim0:0:0:2): Retries Exausted Sep 21 21:41:41 saturn kernel: umass0:umass_t_bbb_reset1_callback: BBB reset! Sep 21 21:41:41 saturn kernel: g_vfs_done():da2s1[READ(offset=616749568, length=16384)]error = 5 Se
umass0: BBB reset failed, TIMEOUT (again)
Today for the first time since this box got a new board I tried to
copy data onto the usb cardreader, and after copying for a while it
suddenly stopped (led stopped flashing, no further io), and after
some time i had the above in dmesg. And that was it, cp process
hung, no way to kill it. Unplugged the thing, and got the expected
panic: vinvalbuf: dirty bufs. Tried the same thing from linux (after
dosfsck), and there copying stopped for a while too, but it then
continued and finished. Is this is some kind of new hardware quirk of
the new board's ehci controller, that linux recovers from? (via,
there already is a `dropped interrupt' fix for it, which helped with
my last board...) I also tried building a RELENG_6 kernel (one
of the PRs I looked at also suggested this), but it behaved the same.
Just in case, I took a dump of that too, but I don't really know for
what to look in there so you'd have to tell me...
Oh, the board now is an Asrock K7VT4A, I think its pretty common too...
bash 10.3# kgdb kernel.debug /var/crash/vmcore.4
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
KDB: enter: manual escape to debugger
panic: from debugger
KDB: stack backtrace:
Uptime: 4m44s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc06967ee in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0xc0696ab4 in panic (fmt=0xc08b7db1 "from debugger")
at ../../../kern/kern_shutdown.c:565
#3 0xc049cab9 in db_panic (addr=-1066731985, have_addr=0, count=-1,
modif=0xe35dfa8c "") at ../../../ddb/db_command.c:438
#4 0xc049ca50 in db_command (last_cmdp=0xc09acbc4, cmd_table=0x0,
aux_cmd_tablep=0xc090f578, aux_cmd_tablep_end=0xc090f594)
at ../../../ddb/db_command.c:350
#5 0xc049cb18 in db_command_loop () at ../../../ddb/db_command.c:458
#6 0xc049e725 in db_trap (type=3, code=0) at ../../../ddb/db_main.c:221
#7 0xc06af8ab in kdb_trap (type=3, code=0, tf=0xe35dfbcc)
at ../../../kern/subr_kdb.c:473
#8 0xc088a14c in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1063263456, tf_esi =
-1063283456, tf_ebp = -480379892, tf_isp = -480379912, tf_ebx = 0, tf_edx = 0,
tf_ecx = -1056878592, tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip =
-1066731985, tf_cs = 32, tf_eflags = 524934, tf_esp = -480379820, tf_ss =
-1064897956})
at ../../../i386/i386/trap.c:594
#9 0xc08781da in calltrap () at ../../../i386/i386/exception.s:139
#10 0xc06af62f in kdb_enter (msg=0x26 )
at cpufunc.h:60
#11 0xc086f25c in scgetc (sc=0xc09fe320, flags=2)
---Type to continue, or q to quit---
at ../../../dev/syscons/syscons.c:3324
#12 0xc086af7c in sckbdevent (thiskbd=0xc4b14800, event=0, arg=0xc09fe320)
at ../../../dev/syscons/syscons.c:659
#13 0xc05923bc in kbdmux_intr (kbd=0xc4b14800, arg=0x0)
at ../../../dev/kbdmux/kbdmux.c:548
#14 0xc0591e16 in kbdmux_kbd_intr (xkbd=0x0, pending=1)
at ../../../dev/kbdmux/kbdmux.c:199
#15 0xc06b64cb in taskqueue_run (queue=0xc4b06e80)
at ../../../kern/subr_taskqueue.c:257
#16 0xc06b6702 in taskqueue_swi_giant_run (dummy=0x0)
at ../../../kern/subr_taskqueue.c:311
#17 0xc0681369 in ithread_execute_handlers (p=0xc4abfa78, ie=0xc4b06e00)
at ../../../kern/kern_intr.c:682
#18 0xc0681474 in ithread_loop (arg=0xc4b44420)
at ../../../kern/kern_intr.c:765
#19 0xc06802f0 in fork_exit (callout=0xc0681420 ,
arg=0xc4b44420, frame=0xe35dfd38) at ../../../kern/kern_fork.c:821
#20 0xc087823c in fork_trampoline () at ../../../i386/i386/exception.s:208
(kgdb) info threads
92 Thread 100101 (PID=1022: systat) 0xc06a803b in sched_switch (
td=0xc5298c00, newtd=0xc4aba600, flags=1) at ../../../kern/sched_4bsd.c:973
91 Thread 100106 (PID=1021: bash) 0xc06a803b in sched_switch (
td=0xc5298480, newtd=0xc5298c00, flags=1) at ../../../kern/sched_4bsd.c:973
90 Thread 100072 (PID=1017: cp) 0xc06a803b in sched_switch (td=0xc5118480,
newtd=0xc4abc000, flags=1) at ../../../kern/sched_4bsd.c:973
89 Thread 100108 (PID=1009: sleep) 0xc06a803b in sched_switch (
td=0xc5298180, newtd=0xc4aba600, flags=1) at ../../../
Re: FreeBSD qemu 0.8.2 update - please test! (and usb cardreader SET_ADDR_FAILED)
On Tue, Jul 25, 2006 at 07:06:02PM -0400, Jung-uk Kim wrote:
> On Tuesday 25 July 2006 01:47 pm, Juergen Lock wrote:
> > @@ -47,21 +43,20 @@
> > void set_float_rounding_mode(int val STATUS_PARAM)
> > {
> > STATUS(float_rounding_mode) = val;
> > --#if defined(_BSD) && !defined(__APPLE__)
> > -+#if defined(_BSD) && !defined(__APPLE__) && \
> > -+(defined(__FreeBSD__) && __FreeBSD_version < 50)
> > +-#if defined(_BSD) && !defined(__APPLE__) || (defined(HOST_SOLARIS) &&
> > HOST_SOLARIS < 10)
> > ++#if (defined(_BSD) && (defined(__FreeBSD__) && __FreeBSD_version <
> > 50)) && !defined(__APPLE__) || (defined(HOST_SOLARIS) && HOST_SOLARIS <
> > 10)
> > fpsetround(val);
> > #elif defined(__arm__)
> > /* nothing to do */
>
> FYI, a parenthesis is misplaced (Note: I just rearranged
> the order to be more clearer):
>
> +-#if defined(_BSD) && !defined(__APPLE__) || (defined(HOST_SOLARIS) &&
> HOST_SOLARIS < 10)
> ++#if (defined(_BSD) && !defined(__APPLE__) && (defined(__FreeBSD__) &&
> __FreeBSD_version < 50)) || \
> ++(defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
Well this should actually be:
#if defined(_BSD) && !defined(__APPLE__) && !defined(__FreeBSD__) || \
(defined(__FreeBSD__) && __FreeBSD_version < 50) || \
(defined(HOST_SOLARIS) && HOST_SOLARIS < 10)
if it ever was going to be merged back. (wrongly excluded non-FreeBSD BSDs)
>
> Actually it is an upstream bug, though.
Nah, the parens there are okay... (|| binds less than &&, i.e.
1 || 0 && 0 evaluates to 1.)
On another note, am i the only one seeing those -kernel-kqemu problems?
thanx,
Juergen
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD qemu 0.8.2 update - please test! (and usb cardreader SET_ADDR_FAILED)
On Mon, Jul 24, 2006 at 12:40:41AM +0200, Juergen Lock wrote: > With the help of Lonnie Mendez (he updated his usb host support patch) > I just put together an experimental qemu port update. For some reason > my usb cardreader didnt want to work today: > uhub1: device problem (SET_ADDR_FAILED), disabling port 1 > (anyone have an idea about this one? this is the first time i tried using > it since I updated this box to 6.1), so the usb host support is untested. > > To test usb best run qemu with -monitor stdio, then do `info usbhost' > when its running and then `usb_add host:' where x.y is the host > device you want to add (`plug into' the guest). also see the port's > pkg-message. some quick test have been done on usb now (cardreader started working again without me doing anything), also Bakul Shah tested usb with a w2k guest. usb is slow tho... (and watch out for the new pkg-message note below.) Also Jung-uk Kim made me aware that FreeBSD has clock_gettime(2) too and provided a patch to enable it. And I noted -kernel-kqemu doesnt seem to be faster than `regular' kqemu anymore (subjectively it once even seemd a little slower!), example startup time of root shell xterm on KANOTIX-2006-Easter-RC4.iso went up from maybe 5 to over 20 seconds, and qemu now takes some 30% cpu here even when the guest is idle. And, I got two qemu hangs (guest suddenly hangs completly, qemu eating 99% cpu) with -kernel-kqemu. So, if anyone has any ideas about this... (can the new timing code slow things down that much?) Oh, host has a single 2.0something GHz athlon cpu and 512 MB ram. new qemu port update below, enjoy, Juergen Removed files: files/patch-malc-17h_aqemu files/patch-sdl.c Index: Makefile === RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v retrieving revision 1.53 diff -u -r1.53 Makefile --- Makefile23 Jul 2006 00:04:01 - 1.53 +++ Makefile23 Jul 2006 15:51:45 - @@ -6,8 +6,7 @@ # PORTNAME= qemu -PORTVERSION= 0.8.1 -PORTREVISION= 2 +PORTVERSION= 0.8.2 CATEGORIES=emulators MASTER_SITES= http://www.qemu.org/:release \ http://people.fruitsalad.org/nox/qemu/:snapshot \ Index: distinfo === RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v retrieving revision 1.31 diff -u -r1.31 distinfo --- distinfo6 May 2006 16:15:41 - 1.31 +++ distinfo23 Jul 2006 15:52:26 - @@ -1,6 +1,6 @@ -MD5 (qemu/qemu-0.8.1.tar.gz) = 67d924324a5ab79d017bd97a1e767285 -SHA256 (qemu/qemu-0.8.1.tar.gz) = a1f83666f5c05eaee9bfc608a3a5034ad95d0fd3c99937bb399bf9235a6aa0c9 -SIZE (qemu/qemu-0.8.1.tar.gz) = 1623264 +MD5 (qemu/qemu-0.8.2.tar.gz) = 5b3a89eb2f256a8a6f3bb07f7b3f1b07 +SHA256 (qemu/qemu-0.8.2.tar.gz) = 2a20d811296c859d678bdd00aa7ca7951a641327234f3af144e822d078f3 +SIZE (qemu/qemu-0.8.2.tar.gz) = 1810909 MD5 (qemu/patch3_cirrus) = ebe7ed9fce804c49e024bc93bfdfc810 SHA256 (qemu/patch3_cirrus) = e862371834b7d895a896fbdb84fd9f70d17b5729a6f6789a48a61504fc941e11 SIZE (qemu/patch3_cirrus) = 8817 Index: pkg-descr === RCS file: /home/ncvs/ports/emulators/qemu/pkg-descr,v retrieving revision 1.3 diff -u -r1.3 pkg-descr --- pkg-descr 19 Jul 2005 06:06:56 - 1.3 +++ pkg-descr 23 Jul 2006 17:46:11 - @@ -12,9 +12,9 @@ cross-debugging. As QEMU requires no host kernel patches to run, it is very safe and easy to use. -(but kqemu is now also supported for the i386 on i386 case) +(but kqemu is now also supported for the i386 on i386 and amd64 case) See also the preconfigured system images on http://oszoo.org/ Many live cd isos also work. -WWW: http://fabrice.bellard.free.fr/qemu/ +WWW: http://qemu.org/ Index: pkg-message === RCS file: /home/ncvs/ports/emulators/qemu/pkg-message,v retrieving revision 1.13 diff -u -r1.13 pkg-message --- pkg-message 23 Jul 2006 00:04:01 - 1.13 +++ pkg-message 25 Jul 2006 17:12:19 - @@ -45,4 +45,9 @@ add path 'ugen*' mode 660 group operator corresponding rc.conf line: devfs_system_ruleset="ugen_ruleset" +- still usb: since the hub is no longer attached to the uchi controller +and the wakeup mechanism, resume interrupt is not implemented yet linux +guests will suspend the bus, i.e. they wont see devices usb_add'ed after +its (linux') uhci module got loaded. workaround: either add devices +before linux loads the module or rmmod and modprobe it afterwards. Index: pkg-plist === RCS file: /home/ncvs/ports/emulators/qemu/pkg-plist,v retrieving revision 1.15 diff -u -r1.15 pkg-plist --- pkg-plist 19 May 2006 08:17:54 - 1.15 +++ pkg-plist 23
qemu 0.8.2 update - please test! (and usb cardreader SET_ADDR_FAILED)
With the help of Lonnie Mendez (he updated his usb host support patch)
I just put together an experimental qemu port update. For some reason
my usb cardreader didnt want to work today:
uhub1: device problem (SET_ADDR_FAILED), disabling port 1
(anyone have an idea about this one? this is the first time i tried using
it since I updated this box to 6.1), so the usb host support is untested.
To test usb best run qemu with -monitor stdio, then do `info usbhost'
when its running and then `usb_add host:' where x.y is the host
device you want to add (`plug into' the guest). also see the port's
pkg-message.
enjoy,
Juergen
Removed files: files/patch-malc-17h_aqemu files/patch-sdl.c
files/patch-vl.c
Index: Makefile
===
RCS file: /home/ncvs/ports/emulators/qemu/Makefile,v
retrieving revision 1.53
diff -u -r1.53 Makefile
--- Makefile23 Jul 2006 00:04:01 - 1.53
+++ Makefile23 Jul 2006 15:51:45 -
@@ -6,8 +6,7 @@
#
PORTNAME= qemu
-PORTVERSION= 0.8.1
-PORTREVISION= 2
+PORTVERSION= 0.8.2
CATEGORIES=emulators
MASTER_SITES= http://www.qemu.org/:release \
http://people.fruitsalad.org/nox/qemu/:snapshot \
Index: distinfo
===
RCS file: /home/ncvs/ports/emulators/qemu/distinfo,v
retrieving revision 1.31
diff -u -r1.31 distinfo
--- distinfo6 May 2006 16:15:41 - 1.31
+++ distinfo23 Jul 2006 15:52:26 -
@@ -1,6 +1,6 @@
-MD5 (qemu/qemu-0.8.1.tar.gz) = 67d924324a5ab79d017bd97a1e767285
-SHA256 (qemu/qemu-0.8.1.tar.gz) =
a1f83666f5c05eaee9bfc608a3a5034ad95d0fd3c99937bb399bf9235a6aa0c9
-SIZE (qemu/qemu-0.8.1.tar.gz) = 1623264
+MD5 (qemu/qemu-0.8.2.tar.gz) = 5b3a89eb2f256a8a6f3bb07f7b3f1b07
+SHA256 (qemu/qemu-0.8.2.tar.gz) =
2a20d811296c859d678bdd00aa7ca7951a641327234f3af144e822d078f3
+SIZE (qemu/qemu-0.8.2.tar.gz) = 1810909
MD5 (qemu/patch3_cirrus) = ebe7ed9fce804c49e024bc93bfdfc810
SHA256 (qemu/patch3_cirrus) =
e862371834b7d895a896fbdb84fd9f70d17b5729a6f6789a48a61504fc941e11
SIZE (qemu/patch3_cirrus) = 8817
Index: pkg-descr
===
RCS file: /home/ncvs/ports/emulators/qemu/pkg-descr,v
retrieving revision 1.3
diff -u -r1.3 pkg-descr
--- pkg-descr 19 Jul 2005 06:06:56 - 1.3
+++ pkg-descr 23 Jul 2006 17:46:11 -
@@ -12,9 +12,9 @@
cross-debugging.
As QEMU requires no host kernel patches to run, it is very safe and easy to
use.
-(but kqemu is now also supported for the i386 on i386 case)
+(but kqemu is now also supported for the i386 on i386 and amd64 case)
See also the preconfigured system images on http://oszoo.org/
Many live cd isos also work.
-WWW: http://fabrice.bellard.free.fr/qemu/
+WWW: http://qemu.org/
Index: pkg-plist
===
RCS file: /home/ncvs/ports/emulators/qemu/pkg-plist,v
retrieving revision 1.15
diff -u -r1.15 pkg-plist
--- pkg-plist 19 May 2006 08:17:54 - 1.15
+++ pkg-plist 23 Jul 2006 17:41:29 -
@@ -13,7 +13,7 @@
%%DATADIR%%/vgabios.bin
%%DATADIR%%/vgabios-cirrus.bin
%%DATADIR%%/ppc_rom.bin
-%%DATADIR%%/proll.elf
+%%DATADIR%%/openbios-sparc32
%%DATADIR%%/video.x
%%DATADIR%%/keymaps/ar
%%DATADIR%%/keymaps/common
Index: files/patch-be
===
RCS file: /home/ncvs/ports/emulators/qemu/files/patch-be,v
retrieving revision 1.2
diff -u -r1.2 patch-be
--- files/patch-be 1 May 2005 07:39:11 - 1.2
+++ files/patch-be 23 Jul 2006 16:30:16 -
@@ -1,16 +1,12 @@
-Index: qemu/vl.c
-@@ -662,6 +662,14 @@
- case QEMU_TIMER_REALTIME:
- #ifdef _WIN32
- return GetTickCount();
-+#elif defined(_BSD)
-+{
-+struct timeval r;
-+if (!gettimeofday(&r, NULL)) {
-+return ((timer_freq * 1000LL) * (int64_t)r.tv_sec
-+ + ((int64_t)r.tv_usec * timer_freq) / 1000) /
timer_freq;
-+}
-+}
- #else
- {
- struct tms tp;
+Index: qemu/Makefile.target
+@@ -404,7 +404,9 @@
+ ifndef CONFIG_DARWIN
+ ifndef CONFIG_WIN32
+ ifndef CONFIG_SOLARIS
+-VL_LIBS=-lutil -lrt
++#VL_LIBS=-lutil -lrt
++# XXX this cant be just merged back...
++VL_LIBS=-lutil
+ endif
+ endif
+ endif
Index: files/patch-bsdusb.patch
===
RCS file: /home/ncvs/ports/emulators/qemu/files/patch-bsdusb.patch,v
retrieving revision 1.4
diff -u -r1.4 patch-bsdusb.patch
--- files/patch-bsdusb.patch29 Apr 2006 09:15:50 - 1.4
+++ files/patch-bsdusb.patch23 Jul 2006 19:58:22 -
@@ -1,6 +1,5 @@
Index: qemu/configure
-@@ -122,7 +122,8 @@
- *)
+@@ -134,6 +134,7 @@
oss="yes"
linux="yes"
user="yes"
@@ -8,18 +7,19 @@
if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
kqemu="yes"
fi
-@@ -131,6 +132,7 @@
+@@
usb panics :(
[this is RELENG_5 with
http://people.freebsd.org/~iedowse/usb_releng_5.diff
and umass being used as a kld because of qemu; please Cc me as I'm
still not subscribed on -usb.]
I wanted to mount an sdcard in a cardreader yesterday and only
got panics. First one was when I plugged the cardreader with the card
in it in, da3s1 didnt appear, unplugged it, panic:
bash 10.3# kgdb kernel.debug /var/crash/vmcore.69
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0 doadump () at pcpu.h:160
160 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:160
#1 0xc05e1fd4 in boot (howto=260)
at /usr/home/nox/src-r5/src/sys/kern/kern_shutdown.c:412
#2 0xc05e2298 in panic (fmt=0xc07b46d9 "%s")
at /usr/home/nox/src-r5/src/sys/kern/kern_shutdown.c:568
#3 0xc0774d6c in trap_fatal (frame=0xd5431be8, eva=8)
at /usr/home/nox/src-r5/src/sys/i386/i386/trap.c:822
#4 0xc0774ac3 in trap_pfault (frame=0xd5431be8, usermode=0, eva=8)
at /usr/home/nox/src-r5/src/sys/i386/i386/trap.c:737
#5 0xc07746c1 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1000156160, tf_esi = 0,
tf_ebp = -717022160, tf_isp = -717022188, tf_ebx = -1000156092, tf_edx = -3,
tf_ecx = -1016466516, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip =
-1069254972, tf_cs = 8, tf_eflags = 66071, tf_esp = -1000156092, tf_ss =
-1044211712})
at /usr/home/nox/src-r5/src/sys/i386/i386/trap.c:427
#6 0xc0766f5a in calltrap ()
at /usr/home/nox/src-r5/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0xc462d400 in ?? ()
#11 0x in ?? ()
#12 0xd5431c30 in ?? ()
---Type to continue, or q to quit---
#13 0xd5431c14 in ?? ()
#14 0xc462d444 in ?? ()
#15 0xfffd in ?? ()
#16 0xc369f3ac in ?? ()
#17 0x in ?? ()
#18 0x000c in ?? ()
#19 0x0002 in ?? ()
#20 0xc04476c4 in camq_remove (queue=0xc462d444, index=0)
at /usr/home/nox/src-r5/src/sys/cam/cam_queue.c:181
#21 0xc044ace6 in xpt_bus_deregister (pathid=6) at cam_queue.h:199
#22 0xc2973ca8 in ?? ()
#23 0x0006 in ?? ()
#24 0xc293a500 in ?? ()
#25 0xd5431c8c in ?? ()
#26 0xc2972c22 in ?? ()
#27 0xc3a1ca00 in ?? ()
#28 0xc293a500 in ?? ()
#29 0xc293a500 in ?? ()
#30 0xc1abb458 in ?? ()
#31 0xd5431ca4 in ?? ()
#32 0xc05f569b in device_detach (dev=0xc3a1ca00) at device_if.h:211
Previous frame inner to this frame (corrupt stack?)
(kgdb) fr 20
#20 0xc04476c4 in camq_remove (queue=0xc462d444, index=0)
at /usr/home/nox/src-r5/src/sys/cam/cam_queue.c:181
181 queue->queue_array[index]->index = index;
(kgdb) p index
$1 = 0
(kgdb) p queue->queue_array[index]
$2 = (cam_pinfo *) 0x0
(kgdb) q
end of dmesg extracted from the dump:
umass0: Genesys USB2.0 card Reader, rev 2.00/91.38, addr 2
umass0:6:0:-1: Attached to scbus6
pass3 at umass-sim0 bus 0 target 0 lun 0
pass3: Removable Direct Access SCSI-0 device
pass3: 40.000MB/s transfers
GEOM: new disk da1
da1 at umass-sim0 bus 0 target 0 lun 0
da1: Removable Direct Access SCSI-0 device
da1: 40.000MB/s transfers
da1: 243MB (498176 512 byte sectors: 64H 32S/T 243C)
(da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da1:umass-sim0:0:0:0): SCSI Status: Check Condition
(da1:umass-sim0:0:0:0): NOT READY asc:3a,0
(da1:umass-sim0:0:0:0): Medium not present
(da1:umass-sim0:0:0:0): (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0
0 0 0 0 0
(da1:umass-sim0:0:0:0): NOT READY asc:3a,0
(da1:umass-sim0:0:0:0): Medium not present
Unretryable error
(da1:umass-sim0:0:0:0): error 6
(da1:umass-sim0:0:0:0): Unretryable Error
Opened disk da1 -> 6
(da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da1:umass-sim0:0:0:0): SCSI Status: Check Condition
(da1:umass-sim0:0:0:0): NOT READY asc:3a,0
(da1:umass-sim0:0:0:0): Medium not present
(da1:umass-sim0:0:0:0): (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0
0 0 0 0 0
(da1:umass-sim0:0:0:0): NOT READY asc:3a,0
(da1:umass-sim0:0:0:0): Medium not present
Unretryable error
(da1:umass-sim0:0:0:0): error 6
(da1:umass-sim0:0:0:0): Unretryable Error
Opened disk da1 -> 6
(da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0
(da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error
(da1:umass-sim0:0:0:0): SCSI Status: Check Condition
(da1:umass-sim0:0:0:0): NOT READY asc:3a,0
(da1:umass-sim0:0:0:0): Medium not present
(da1:umass-sim0:0:0:0): (da1:umass-sim0
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Thu, Feb 02, 2006 at 02:39:01AM +, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Peter Jeremy writes: > >On Tue, 2006-Jan-31 22:00:21 +, Ian Dowse wrote: > >>In the case of USB, there is actually no need for it to perform > >>large contiguous allocations because the host controllers all support > >>some limited scatter-gather functionality so they can mostly access > >>the caller's memory buffer directly via bus_dmamap_load(). This is > >>something I implemented a year or to ago but I haven't got around > >>to finishing the last few details of the patch yet. > > > >I'd looked into the specs far enough to determine that this was > >possible but haven't looked at how difficult it would be to implement > >it. I think this is a preferable solution and would be interested in > >helping you finish your patch. > > I've updated > > http://people.freebsd.org/~iedowse/usb.diff > > with the latest patch I have. I think there are still one or two > places where DMAADDR() calls have been replaced without all the > necessary logic to handle programming segment information into the > host controller descriptors (e.g. the "XXX, fixme" comment in > ohci.c). > > I only updated the OHCI interrupt transfer code and the sl811hs > driver recently so there may be problems there, but most of the > older changes have had a reasonable amount of testing as I've been > using them on a low-memory soekris box for a couple of years. Do you have a RELENG_5 version of that patch too? (And i guess others would be interested in a RELENG_6 one as well? :) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: your RELENG_5 usb patches (was: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h)
On Thu, Feb 16, 2006 at 02:04:54AM +, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Juergen Lock writes: > >I finally got around testing this patch on today's RELENG_5. I built > >my custom kernel (mostly based on GENERIC but with ehci), booted that, > >copied the kernel to an 16 MB sdcard i had lying around using an usb > >multi-cardreader, which worked. umounted, disconnected, reconnected, > >mounted again and verified the kernel, which worked as well. Then I > >noticed this in dmesg: > > da3: 1.000MB/s transfers > >so it wasn't using ehci apparently. I thought, maybe this is > >intermittent too like with my externally powered devices, so I > >disconnected and reconnected again, but this time da3s1 didn't appear. > >(dmesg also shows da1, sometimes with 1 and sometimes with 40 MB/s, > >but I never saw a /dev/da1s1 appear.) I wanted to try again, and when > >disconnecting I got the following panic: > > I'm not sure about the intermittent probing behaviour, but there > are known bugs in CAM that cause it to crash in camisr() if a device > goes away while being probed. There have been some improvements in > this area in -CURRENT, so if you like you could try a CAM patch > too: > > http://people.freebsd.org/~iedowse/cam_remove_releng_5.diff > > Note that this is just a blind backport - I haven't even tested > that it compiles. It does, and i think it should go in because I couldnt panic the box by playing around with the cardreader anymore. This time (and i did that twice) I mounted, accessed, and disconnected it a few times until mounting gave an error again. Disconnected, got no panic as mentioned, reconnected, but still couldnt mount. ls -l /dev/da3* then found two instances of da3s1: bash 10.3# ll /dev/da3* crw-r- 1 root operator4, 108 Feb 16 17:00 /dev/da3 crw-r- 1 root operator4, 93 Feb 16 17:00 /dev/da3s1 crw-r- 1 root operator4, 93 Feb 16 17:00 /dev/da3s1 but it isnt accessible: bash 10.3# dd count=1 /dev/null bash: /dev/da3s1: Device not configured da3 is: bash 10.3# dd count=1 /dev/null 1+0 records in 1+0 records out 512 bytes transferred in 0.001324 secs (386725 bytes/sec) disconnecting leaves one instance of da3s1: bash 10.3# ll /dev/da3* crw-r- 1 root operator4, 93 Feb 16 17:00 /dev/da3s1 I had to reboot to get the cardreader mountable again. (the above log is from doing the whole thing a second time.) here is boot -v dmesg of a normal connect (btw, this time it did use ehci): umass0: Genesys USB2.0 card Reader, rev 2.00/91.38, addr 2 umass0:6:0:-1: Attached to scbus6 pass3 at umass-sim0 bus 0 target 0 lun 0 pass3: Removable Direct Access SCSI-0 device pass3: 40.000MB/s transfers GEOM: new disk da1 da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 14MB (29120 512 byte sectors: 64H 32S/T 14C) (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): NOT READY asc:3a,0 (da1:umass-sim0:0:0:0): Medium not present (da1:umass-sim0:0:0:0): (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): NOT READY asc:3a,0 (da1:umass-sim0:0:0:0): Medium not present Unretryable error (da1:umass-sim0:0:0:0): error 6 (da1:umass-sim0:0:0:0): Unretryable Error Opened disk da1 -> 6 (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): NOT READY asc:3a,0 (da1:umass-sim0:0:0:0): Medium not present (da1:umass-sim0:0:0:0): (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): NOT READY asc:3a,0 (da1:umass-sim0:0:0:0): Medium not present Unretryable error (da1:umass-sim0:0:0:0): error 6 (da1:umass-sim0:0:0:0): Unretryable Error Opened disk da1 -> 6 (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da1:umass-sim0:0:0:0): SCSI Status: Check Condition (da1:umass-sim0:0:0:0): NOT READY asc:3a,0 (da1:umass-sim0:0:0:0): Medium not present (da1:umass-sim0:0:0:0): (da1:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da1:umass-sim0:0:0:0): NOT READY asc:3a,0 (da1:umass-sim0:0:0:0): Medium not present Unretryable error (da1:umass-sim0:0:0:0): error 6 (da1:umass-sim0:0:0:0): Unretryable Error Opened disk da1 -> 6 pass4 at umass-sim0 bus 0 target 0 lun 1 pass4: Removable Direct Access SCSI-0 device pass4: 40.000MB/s transfers GEOM: new disk da2 (da2:umass-sim0:0:0:1): error 6 (da2:umass-sim0:0:0:1): Unretryable Error da2 at umass-sim0 bus 0 target 0 lun 1 da2: Removable Direct Access SCSI-0 d
Re: your RELENG_5 usb patches (was: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h)
On Wed, Feb 15, 2006 at 08:09:20PM +0100, I wrote: >[...] > I finally got around testing this patch on today's RELENG_5. [...] PS: the usb 1.1 controller on this box is uhci and I dont have an usb printer so others will have to do the rest of the testing. (maybe you want to ask on -stable, i guess there are more ppl subscribed there than on -usb?) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
your RELENG_5 usb patches (was: Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h)
On Sun, Jan 29, 2006 at 06:08:49PM +, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Juergen Lock writes:
> >
> >Here is what I use on RELENG_5_4:
>
> Thanks - that's merged into RELENG_5 now. Could somebody test if
> the following additional patch works? This includes a number of
> changes that are in RELENG_6 but haven't made it to 5.x yet, including
> ohci and ulpt bug fixes and improved umass and ums device support.
> For this to apply you will need the latest RELENG_5 (29th Jan). I
> don't have a RELENG_5 box here so this might not even compile. The
> patch is at:
>
> http://people.freebsd.org/~iedowse/usb_releng_5.diff
I finally got around testing this patch on today's RELENG_5. I built
my custom kernel (mostly based on GENERIC but with ehci), booted that,
copied the kernel to an 16 MB sdcard i had lying around using an usb
multi-cardreader, which worked. umounted, disconnected, reconnected,
mounted again and verified the kernel, which worked as well. Then I
noticed this in dmesg:
da3: 1.000MB/s transfers
so it wasn't using ehci apparently. I thought, maybe this is
intermittent too like with my externally powered devices, so I
disconnected and reconnected again, but this time da3s1 didn't appear.
(dmesg also shows da1, sometimes with 1 and sometimes with 40 MB/s,
but I never saw a /dev/da1s1 appear.) I wanted to try again, and when
disconnecting I got the following panic:
bash 10.3# kgdb kernel.debug /var/crash/vmcore.20
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0 doadump () at pcpu.h:160
160 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:160
#1 0xc05e52d8 in boot (howto=260)
at /usr/home/nox/src-r5/src/sys/kern/kern_shutdown.c:412
#2 0xc05e559c in panic (fmt=0xc07b83b0 "%s")
at /usr/home/nox/src-r5/src/sys/kern/kern_shutdown.c:568
#3 0xc0777f8c in trap_fatal (frame=0xd41f6b90, eva=8)
at /usr/home/nox/src-r5/src/sys/i386/i386/trap.c:822
#4 0xc0777ce3 in trap_pfault (frame=0xd41f6b90, usermode=0, eva=8)
at /usr/home/nox/src-r5/src/sys/i386/i386/trap.c:737
#5 0xc07778e1 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1044148224, tf_esi = 0,
tf_ebp = -736138280, tf_isp = -736138308, tf_ebx = -1040247808, tf_edx = 1,
tf_ecx = -1044096896, tf_eax = -1040246016, tf_trapno = 12, tf_err = 2, tf_eip
= -1069254537, tf_cs = 8, tf_eflags = 66118, tf_esp = -1034639872, tf_ss =
-1040247808}) at /usr/home/nox/src-r5/src/sys/i386/i386/trap.c:427
#6 0xc076a17a in calltrap ()
at /usr/home/nox/src-r5/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0xc1c39000 in ?? ()
#11 0x in ?? ()
#12 0xd41f6bd8 in ?? ()
---Type to continue, or q to quit---
#13 0xd41f6bbc in ?? ()
#14 0xc1ff1400 in ?? ()
#15 0x0001 in ?? ()
#16 0xc1c45880 in ?? ()
#17 0xc1ff1b00 in ?? ()
#18 0x000c in ?? ()
#19 0x0002 in ?? ()
#20 0xc0447877 in camq_remove (queue=0xc1ff1400, index=0)
at /usr/home/nox/src-r5/src/sys/cam/cam_queue.c:182
#21 0xc044a364 in xpt_run_dev_allocq (bus=0xc1ff1300)
at /usr/home/nox/src-r5/src/sys/cam/cam_xpt.c:3766
#22 0xc044ac06 in xpt_release_ccb (free_ccb=0x0)
at /usr/home/nox/src-r5/src/sys/cam/cam_xpt.c:4317
#23 0xc044c30a in probedone (periph=0xc2450480, done_ccb=0xc1c29c00)
at /usr/home/nox/src-r5/src/sys/cam/cam_xpt.c:5899
#24 0xc044d0dd in camisr (V_queue=0xc087aee0)
at /usr/home/nox/src-r5/src/sys/cam/cam_xpt.c:7074
#25 0xc05d1399 in ithread_loop (arg=0xc198aa80)
at /usr/home/nox/src-r5/src/sys/kern/kern_intr.c:547
#26 0xc05d062c in fork_exit (callout=0xc05d1248 ,
arg=0xc198aa80, frame=0xd41f6d38)
at /usr/home/nox/src-r5/src/sys/kern/kern_fork.c:791
#27 0xc076a1dc in fork_trampoline ()
---Type to continue, or q to quit---
at /usr/home/nox/src-r5/src/sys/i386/i386/exception.s:209
(kgdb) fr 20
#20 0xc0447877 in camq_remove (queue=0xc1ff1400, index=0)
at /usr/home/nox/src-r5/src/sys/cam/cam_queue.c:182
182 heap_down(queue->queue_array, index, queue->entries -
1);
(kgdb) p queue
$1 = (struct camq *) 0xc1ff1400
(kgdb) p queue->queue_array
$2 = (cam_pinfo **) 0xc1c45880
(kgdb) p queue->entries
$3 = 1
(kgdb) p *queue
$4 = {queue_array = 0xc1c45880, array_size = 3, entries = 1, generation = 17,
qfrozen_cnt = 1}
(kgdb) p *queue
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Tue, Jan 31, 2006 at 10:00:21PM +, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Juergen Lock writes: > >> Alright, looks like it was paging: (usb_block_allocmem ending up > >> calling contigmalloc... which makes me wonder what would happen > >> there if someone had swap on a umass device? swap here is on > >> ad4s2b which is on the sata card.) > > > >Ah, seems the actual problem is that it is sleeping although > >bus_dmamem_alloc is called with BUS_DMA_NOWAIT, and there even is > >a pr for that: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=78179 > >The pr is still open so i guess there is no fix yet? > > Ok, yes, this is a known problem that occurs if you access USB > devices for the first time when the physical memory is too fragmented > for a contiguous allocation to succeed immediately. A workaround > is to add more RAM or access the USB devices soon after booting. > Once the USB system has successfully allocated the memory it needs, > it will then work reliably. > > In the case of USB, there is actually no need for it to perform > large contiguous allocations because the host controllers all support > some limited scatter-gather functionality so they can mostly access > the caller's memory buffer directly via bus_dmamap_load(). This is > something I implemented a year or to ago but I haven't got around > to finishing the last few details of the patch yet. Hmm, couldnt the usb code just pre-allocate the needed memory at, say, the open() syscall of an umass device instead? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Tue, Jan 31, 2006 at 07:20:46PM +0100, Juergen Lock wrote: > On Tue, Jan 31, 2006 at 01:12:35AM +, Ian Dowse wrote: > > In message <[EMAIL PROTECTED]>, Juergen Lock writes: > > > Alright, here comes that: > > > > >intr_context = 3, > > > > Interesting - this actually suggests that two threads might be in > > the the interrupt service routine at the same time, which should > > not be possible unless there is a bug causing a callback to sleep. > > > > Could you see if you can find the EHCI interrupt thread in the output of: > > > > ps -axl -M vmcore -N kernel | grep irq > > > > It might show up like "[irq3: ehci" but if there are other interrupts > > shared with it you might need to look through dmesg output to find the > > IRQ number used by ehci and then look for that thread instead. > > Had to look at dmesg, ehci is sharing irq 11 with the promise sata > card and the symbios scsi card. > > > > Then from gdb, use 'info threads' to find the gdb thread ID for it > > (look for the PID=XX then read the first column). Finally, "thread > > TID" followed by "bt" should show what that thread is doing. e.g. > > if you see > > > > 7 Thread 12 (PID=14: irq3: ehci0) 0xc050bb23 in ... > > > > then use "thread 7" and "bt". > > Alright, looks like it was paging: (usb_block_allocmem ending up > calling contigmalloc... which makes me wonder what would happen > there if someone had swap on a umass device? swap here is on > ad4s2b which is on the sata card.) Ah, seems the actual problem is that it is sleeping although bus_dmamem_alloc is called with BUS_DMA_NOWAIT, and there even is a pr for that: http://www.freebsd.org/cgi/query-pr.cgi?pr=78179 The pr is still open so i guess there is no fix yet? ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Tue, Jan 31, 2006 at 01:12:35AM +, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Juergen Lock writes:
> > Alright, here comes that:
>
> >intr_context = 3,
>
> Interesting - this actually suggests that two threads might be in
> the the interrupt service routine at the same time, which should
> not be possible unless there is a bug causing a callback to sleep.
>
> Could you see if you can find the EHCI interrupt thread in the output of:
>
> ps -axl -M vmcore -N kernel | grep irq
>
> It might show up like "[irq3: ehci" but if there are other interrupts
> shared with it you might need to look through dmesg output to find the
> IRQ number used by ehci and then look for that thread instead.
Had to look at dmesg, ehci is sharing irq 11 with the promise sata
card and the symbios scsi card.
>
> Then from gdb, use 'info threads' to find the gdb thread ID for it
> (look for the PID=XX then read the first column). Finally, "thread
> TID" followed by "bt" should show what that thread is doing. e.g.
> if you see
>
> 7 Thread 12 (PID=14: irq3: ehci0) 0xc050bb23 in ...
>
> then use "thread 7" and "bt".
Alright, looks like it was paging: (usb_block_allocmem ending up
calling contigmalloc... which makes me wonder what would happen
there if someone had swap on a umass device? swap here is on
ad4s2b which is on the sata card.)
bash 10.3# kgdb kernel.debug /var/crash/vmcore.10
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0 doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) info threads
...
151 PID22 TID 100016 (irq11: atapci0 sym*) 0xc05f239b in sched_switch (
td=0xc1983900, newtd=0xc1987180, flags=1)
at /usr/home/nox/src54/usr/src/sys/kern/sched_4bsd.c:881
...
(kgdb) thread 151
[Switching to thread 151 (PID22 TID 100016)]#0 0xc05f239b in sched_switch
(td=0xc1983900, newtd=0xc1987180, flags=1)
at /usr/home/nox/src54/usr/src/sys/kern/sched_4bsd.c:881
881 cpu_switch(td, newtd);
(kgdb) bt
#0 0xc05f239b in sched_switch (td=0xc1983900, newtd=0xc1987180, flags=1)
at /usr/home/nox/src54/usr/src/sys/kern/sched_4bsd.c:881
#1 0xc05e8eaa in mi_switch (flags=1, newtd=0x0)
at /usr/home/nox/src54/usr/src/sys/kern/kern_synch.c:355
#2 0xc05fecaa in sleepq_switch (wchan=0x0)
at /usr/home/nox/src54/usr/src/sys/kern/subr_sleepqueue.c:406
#3 0xc05fee93 in sleepq_wait (wchan=0xcbe86030)
at /usr/home/nox/src54/usr/src/sys/kern/subr_sleepqueue.c:518
#4 0xc05e8bea in msleep (ident=0xcbe86030, mtx=0xc08a6a40, priority=68,
wmesg=0xc07e8c8e "swwrt", timo=0)
at /usr/home/nox/src54/usr/src/sys/kern/kern_synch.c:228
#5 0xc0629267 in bwait (bp=0xcbe86030, pri=68 'D', wchan=0xc07e8c8e "swwrt")
at /usr/home/nox/src54/usr/src/sys/kern/vfs_bio.c:3763
#6 0xc0727b15 in swap_pager_putpages (object=0xc25bfce4, m=0xd41fdaa4,
count=1, sync=1, rtvals=0xd41fda70)
at /usr/home/nox/src54/usr/src/sys/vm/swap_pager.c:1365
#7 0xc0725840 in default_pager_putpages (object=0xc25bfce4, m=0xd41fdaa4,
c=1, sync=1, rtvals=0xd41fda70)
at /usr/home/nox/src54/usr/src/sys/vm/default_pager.c:132
#8 0xc0739743 in vm_pageout_flush (mc=0xd41fdaa4, count=1, flags=1)
at vm_pager.h:147
#9 0xc073809e in vm_contig_launder_page (m=0xc18fee00)
at /usr/home/nox/src54/usr/src/sys/vm/vm_contig.c:121
---Type to continue, or q to quit---
#10 0xc0738b6e in vm_page_alloc_contig (npages=16, low=0, high=4294967295,
alignment=1, boundary=0)
at /usr/home/nox/src54/usr/src/sys/vm/vm_contig.c:451
#11 0xc0738ef7 in contigmalloc (size=65536, type=0xc0829c40, flags=1, low=0,
high=4294967295, alignment=1, boundary=0)
at /usr/home/nox/src54/usr/src/sys/vm/vm_contig.c:555
#12 0xc0760194 in bus_dmamem_alloc (dmat=0xc2d0f400, vaddr=0xc2a24cc8,
flags=0, mapp=0x0)
at /usr/home/nox/src54/usr/src/sys/i386/i386/busdma_machdep.c:504
#13 0xc0582a63 in usb_block_allocmem (tag=0x0, size=65536, align=1,
dmap=0xc297a63c) at /usr/home/nox/src54/usr/src/sys/dev/usb/usb_mem.c:187
#14 0xc0582b40 in usb_allocmem (bus=0x0, size=65536, align=0, p=0xc297a63c)
at /usr/home/nox/src54/usr/src/sys/dev/usb/usb_mem.c:248
#15 0xc056e03b in ehci_allocm (bus=0xc1a3f800, dma=0xc297a63c, size=64512)
at /usr/home/n
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Mon, Jan 30, 2006 at 09:57:36PM +, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Juergen Lock writes:
> > Well ehci_intrlist_timeout belongs to the ehci patch in the Subject
> >so its pretty new... (I don't know the code enough to know if it
> >matters, but shouldnt the timer only be scheduled if the interrupt
> >did appear too early, i.e. the transfer indeed wasnt complete yet?
> >Not all transfers hung before i applied the patch, so it only
> >happens `sometimes'...)
>
> Calling the driver's interrupt service routine should be safe at
> any time (assuming sufficient locking, which should be OK), since
> this can happen with shared interrupts, so if anything it's more
> likely to be an existing problem that just gets triggered more often
> by having the ISR called via the new timer.
Ah, OK.
>
> Try applying the patch I posted yesterday and see if that helps.
> It includes a change to usb_transfer_complete() that might be
> relevant - the EHCI driver touches the transfer structure in its
> done() method, and the usb_transfer_complete() change makes it safe
> to do this when a callback function reuses the transfer structure.
> The umass driver shouldn't normally reuse its transfer structures
> during callbacks, but maybe it can during some error recovery
> condition.
>
OK, will do.
> Could you also do the following from gdb on the crash dump you have?
> It might possibly provide further hints as to what went wrong.
>
> p *(struct ehci_xfer *)0xc1aaf300
> p *(struct ehci_softc *)0xc1a3f800
Alright, here comes that:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0 doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) p *(struct ehci_xfer *)0xc1aaf300
No struct type named ehci_xfer.
(kgdb) p *(struct ehci_softc *)0xc1a3f800
$1 = {sc_bus = {bdev = 0xc1a9da00, methods = 0xc081d440, pipe_size = 80,
root_hub = 0xc1ac2c00, devices = {0x0, 0xc1ac2c00, 0xc2881680,
0x0 }, needs_explore = 0 '\0', use_polling = 0 '\0',
usbctl = 0xc1a9cc40, stats = {uds_requests = {76, 0, 69, 1}},
intr_context = 3, no_intrs = 99, usbrev = 4, dmatag = 0x0}, sc_flags = 3,
iot = 1, ioh = 3713073152, sc_size = 0, ih = 0xc1abd000,
io_res = 0xc1a7d380, irq_res = 0xc1abd040, sc_offs = 16,
sc_vendor = "VIA", '\0' , sc_id_vendor = 0, sc_cmd = 0,
sc_ncomp = 3, sc_npcomp = 2, sc_comps = {0xc1a81640, 0xc1a90b80, 0xc1a90700,
0x0, 0x0, 0x0, 0x0, 0x0}, sc_fldma = {block = 0xc1a9ce40, offs = 0,
len = 4096}, sc_flist = 0xc1ab2000, sc_flsize = 1024, sc_islots = {{
sqh = 0xc1ab1f60}, {sqh = 0xc1ab1f00}, {sqh = 0xc1ab1ea0}, {
sqh = 0xc1ab1e40}, {sqh = 0xc1ab1de0}, {sqh = 0xc1ab1d80}, {
sqh = 0xc1ab1d20}, {sqh = 0xc1ab1cc0}, {sqh = 0xc1ab1c60}, {
sqh = 0xc1ab1c00}, {sqh = 0xc1ab1ba0}, {sqh = 0xc1ab1b40}, {
sqh = 0xc1ab1ae0}, {sqh = 0xc1ab1a80}, {sqh = 0xc1ab1a20}, {
sqh = 0xc1ab19c0}, {sqh = 0xc1ab1960}, {sqh = 0xc1ab1900}, {
sqh = 0xc1ab18a0}, {sqh = 0xc1ab1840}, {sqh = 0xc1ab17e0}, {
sqh = 0xc1ab1780}, {sqh = 0xc1ab1720}, {sqh = 0xc1ab16c0}, {
sqh = 0xc1ab1660}, {sqh = 0xc1ab1600}, {sqh = 0xc1ab15a0}, {
sqh = 0xc1ab1540}, {sqh = 0xc1ab14e0}, {sqh = 0xc1ab1480}, {
sqh = 0xc1ab1420}, {sqh = 0xc1ab13c0}, {sqh = 0xc1ab1360}, {
sqh = 0xc1ab1300}, {sqh = 0xc1ab12a0}, {sqh = 0xc1ab1240}, {
---Type to continue, or q to quit---
sqh = 0xc1ab11e0}, {sqh = 0xc1ab1180}, {sqh = 0xc1ab1120}, {
sqh = 0xc1ab10c0}, {sqh = 0xc1ab1060}, {sqh = 0xc1ab1000}, {
sqh = 0xc1ab0f60}, {sqh = 0xc1ab0f00}, {sqh = 0xc1ab0ea0}, {
sqh = 0xc1ab0e40}, {sqh = 0xc1ab0de0}, {sqh = 0xc1ab0d80}, {
sqh = 0xc1ab0d20}, {sqh = 0xc1ab0cc0}, {sqh = 0xc1ab0c60}, {
sqh = 0xc1ab0c00}, {sqh = 0xc1ab0ba0}, {sqh = 0xc1ab0b40}, {
sqh = 0xc1ab0ae0}, {sqh = 0xc1ab0a80}, {sqh = 0xc1ab0a20}, {
sqh = 0xc1ab09c0}, {sqh = 0xc1ab0960}, {sqh = 0xc1ab0900}, {
sqh = 0xc1ab08a0}, {sqh = 0xc1ab0840}, {sqh = 0xc1ab07e0}, {
sqh = 0xc1ab0780}, {sqh = 0xc1ab0720}, {sqh = 0xc1ab06c0}, {
sqh = 0xc1ab0660}, {sqh = 0xc1ab0600}, {sqh = 0xc1ab05a0}, {
sqh = 0xc1ab0540}, {sqh = 0xc1ab04e0}, {sqh = 0xc1ab0480}, {
sqh = 0xc1ab0420}, {sqh = 0xc1ab03c0}, {sqh = 0xc1ab0360}, {
sqh = 0xc1ab0300}, {sqh = 0xc1ab02a0}, {sqh = 0xc1ab0240}, {
sqh = 0xc1ab01e0}, {sqh = 0xc1ab0180}, {sqh = 0x
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Mon, Jan 30, 2006 at 12:51:25AM +, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Juergen Lock writes: > >Hmm. Now I just got the following panic with it, pipe->queue.stqh_first > >shouldn't be NULL right? (Maybe it already got a new command for the > >same umass device while there still is an ehci_intrlist_timeout pending > >for the last command and so the new one interferes?) > > Is that with umass devices only, or were there other USB devices > in use? Yes only the umass device was in use, even the mouse on that box is on ps2. > The trace looks familiour so it might be something that has > been fixed in -current. Well ehci_intrlist_timeout belongs to the ehci patch in the Subject so its pretty new... (I don't know the code enough to know if it matters, but shouldnt the timer only be scheduled if the interrupt did appear too early, i.e. the transfer indeed wasnt complete yet? Not all transfers hung before i applied the patch, so it only happens `sometimes'...) > Could you see if there were any related > console messages just before the crash with > > dmesg -a -M vmcore_file -N kernel_file > Ok, appended below. > and if possible recompile your kernel to contain the drivers for > any USB devices you use rather than loading modules? Using modules > causes the stack trace to miss out information from module frames. I alread had usb in the kernel, so no usb related klds were in use. -snip (sa0:umass-sim0:0:0:0): Retrying Command (sa0:umass-sim0:0:0:0): error 28 (sa0:umass-sim0:0:0:0): Unretryable Error Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4c fault code = supervisor read, page not present instruction pointer = 0x8:0xc0584f7d stack pointer = 0x10:0xd420cc3c frame pointer = 0x10:0xd420cc58 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 27 (swi5: clock sio) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c1987180,10,d420cbfc,c) at kdb_backtrace+0x29 panic(c07b08f4,c07ee5b5,0,f,c198e59b) at panic+0xa8 trap_fatal(d420cbfc,4c,c1987180,0,c) at trap_fatal+0x27c trap_pfault(d420cbfc,0,4c) at trap_pfault+0x1ef trap(18,10,10,0,c29a6b80) at trap+0x315 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0584f7d, esp = 0xd420cc3c, ebp = 0xd420cc58 --- usb_transfer_complete(c1aaf300,1f,c29a6b80,c1aaf300,c1a3f800) at usb_transfer_complete+0xcd ehci_idone(c1aaf300,c2881680,c1aaf36c,c1aaf354,0) at ehci_idone+0x120 ehci_check_intr(c1a3f800,c1aaf300) at ehci_check_intr+0x73 ehci_softintr(c1a3f800,d420ccc8,c056f833,c1a3f800,d420ccf4) at ehci_softintr+0x25 usb_schedsoftintr(c1a3f800) at usb_schedsoftintr+0xd ehci_intrlist_timeout(c1a3f800) at ehci_intrlist_timeout+0xb softclock(0) at softclock+0x25e ithread_loop(c197d500,d420cd48) at ithread_loop+0x151 fork_exit(c05ce974,c197d500,d420cd48) at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd420cd7c, ebp = 0 --- Uptime: 10h2m19s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Sun, Jan 29, 2006 at 06:08:49PM +, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Juergen Lock writes:
> >
> >Here is what I use on RELENG_5_4:
>
> Thanks - that's merged into RELENG_5 now. [...]
Hmm. Now I just got the following panic with it, pipe->queue.stqh_first
shouldn't be NULL right? (Maybe it already got a new command for the
same umass device while there still is an ehci_intrlist_timeout pending
for the last command and so the new one interferes?)
bash 10.3# kgdb kernel.debug /var/crash/vmcore.10
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
#0 doadump () at pcpu.h:159
159 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc05e27aa in boot (howto=260)
at /usr/home/nox/src54/usr/src/sys/kern/kern_shutdown.c:410
#2 0xc05e2a70 in panic (fmt=0xc07b08f4 "%s")
at /usr/home/nox/src54/usr/src/sys/kern/kern_shutdown.c:566
#3 0xc0771cac in trap_fatal (frame=0xd420cbfc, eva=76)
at /usr/home/nox/src54/usr/src/sys/i386/i386/trap.c:817
#4 0xc0771a07 in trap_pfault (frame=0xd420cbfc, usermode=0, eva=76)
at /usr/home/nox/src54/usr/src/sys/i386/i386/trap.c:735
#5 0xc0771605 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -1030067328,
tf_ebp = -736048040, tf_isp = -736048088, tf_ebx = -1045761280, tf_edx = 0,
tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1067954307, tf_cs
= 8, tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at /usr/home/nox/src54/usr/src/sys/i386/i386/trap.c:425
#6 0xc076411a in calltrap ()
at /usr/home/nox/src54/usr/src/sys/i386/i386/exception.s:140
#7 0x0018 in ?? ()
#8 0x0010 in ?? ()
#9 0x0010 in ?? ()
#10 0x in ?? ()
#11 0xc29a6b80 in ?? ()
#12 0xd420cc58 in ?? ()
---Type to continue, or q to quit---
#13 0xd420cc28 in ?? ()
#14 0xc1aaf300 in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x in ?? ()
#18 0x000c in ?? ()
#19 0x in ?? ()
#20 0xc0584f7d in usb_transfer_complete (xfer=0xc1aaf300)
at /usr/home/nox/src54/usr/src/sys/dev/usb/usbdi.c:833
#21 0xc056d9b0 in ehci_idone (ex=0xc1aaf300)
at /usr/home/nox/src54/usr/src/sys/dev/usb/ehci.c:877
#22 0xc056d887 in ehci_check_intr (sc=0xc1a3f800, ex=0xc1aaf300)
at /usr/home/nox/src54/usr/src/sys/dev/usb/ehci.c:762
#23 0xc056d7bd in ehci_softintr (v=0xc1a3f800)
at /usr/home/nox/src54/usr/src/sys/dev/usb/ehci.c:696
#24 0xc0582281 in usb_schedsoftintr (bus=0x0)
at /usr/home/nox/src54/usr/src/sys/dev/usb/usb.c:870
#25 0xc056f833 in ehci_intrlist_timeout (arg=0xc1a3f800)
at /usr/home/nox/src54/usr/src/sys/dev/usb/ehci.c:2731
#26 0xc05ee626 in softclock (dummy=0x0)
at /usr/home/nox/src54/usr/src/sys/kern/kern_timeout.c:279
#27 0xc05ceac5 in ithread_loop (arg=0xc197d500)
at /usr/home/nox/src54/usr/src/sys/kern/kern_intr.c:547
---Type to continue, or q to quit---
#28 0xc05cdd58 in fork_exit (callout=0xc05ce974 ,
arg=0xc197d500, frame=0xd420cd48)
at /usr/home/nox/src54/usr/src/sys/kern/kern_fork.c:791
#29 0xc076417c in fork_trampoline ()
at /usr/home/nox/src54/usr/src/sys/i386/i386/exception.s:209
(kgdb) fr 20
#20 0xc0584f7d in usb_transfer_complete (xfer=0xc1aaf300)
at /usr/home/nox/src54/usr/src/sys/dev/usb/usbdi.c:833
833 SIMPLEQ_REMOVE_HEAD(&pipe->queue, next);
(kgdb) p *pipe
$1 = {iface = 0xc2e126a0, device = 0xc2881680, endpoint = 0xc2c8a940,
refcnt = 1, running = 1 '\001', aborting = 0 '\0', queue = {
stqh_first = 0x0, stqh_last = 0xc29a6b94}, next = {le_next = 0x0,
le_prev = 0xc262381c}, intrxfer = 0x0, repeat = 0 '\0', interval = -1,
methods = 0xc081d4bc}
(kgdb) p *pipe->queue.stqh_last
$2 = (struct usbd_xfer *) 0x0
(kgdb) q
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
On Thu, Jan 26, 2006 at 02:03:28AM +, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Juergen Lock writes:
> >Can this commit,
> >http://lists.freebsd.org/pipermail/cvs-src/2006-January/058150.html
> >(sorry I dont have the msgid) be mfc'd to 6 and 5 before the freeze?
> >I merged (cvs up -j...) it on 5.4 and it fixes ehci hangs for me.
>
> Hi, I've just merged this to RELENG_6. The USB code in RELENG_5 is
> missing a number of bug fixes at this stage, but I don't have a
> RELENG_5 box handy to test on. If you'd like to send a patch you've
> tested then I'll be able to check that it matches up and commit it.
Here is what I use on RELENG_5_4:
Index: ehci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.14.2.9
diff -u -r1.14.2.9 ehci.c
--- ehci.c 31 Mar 2005 19:47:11 - 1.14.2.9
+++ ehci.c 17 Jan 2006 23:03:31 -
@@ -155,6 +155,7 @@
Static voidehci_idone(struct ehci_xfer *);
Static voidehci_timeout(void *);
Static voidehci_timeout_task(void *);
+Static voidehci_intrlist_timeout(void *);
Static usbd_status ehci_allocm(struct usbd_bus *, usb_dma_t *, u_int32_t);
Static voidehci_freem(struct usbd_bus *, usb_dma_t *);
@@ -491,6 +492,7 @@
EOWRITE4(sc, EHCI_ASYNCLISTADDR, sqh->physaddr | EHCI_LINK_QH);
usb_callout_init(sc->sc_tmo_pcd);
+ usb_callout_init(sc->sc_tmo_intrlist);
lockinit(&sc->sc_doorbell_lock, PZERO, "ehcidb", 0, 0);
@@ -694,6 +696,12 @@
ehci_check_intr(sc, ex);
}
+ /* Schedule a callout to catch any dropped transactions. */
+ if ((sc->sc_flags & EHCI_SCFLG_LOSTINTRBUG) &&
+ !LIST_EMPTY(&sc->sc_intrhead))
+ usb_callout(sc->sc_tmo_intrlist, hz / 5, ehci_intrlist_timeout,
+ sc);
+
#ifdef USB_USE_SOFTINTR
if (sc->sc_softwake) {
sc->sc_softwake = 0;
@@ -942,6 +950,7 @@
EOWRITE4(sc, EHCI_USBINTR, sc->sc_eintrs);
EOWRITE4(sc, EHCI_USBCMD, 0);
EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET);
+ usb_uncallout(sc->sc_tmo_intrlist, ehci_intrlist_timeout, sc);
usb_uncallout(sc->sc_tmo_pcd, ehci_pcd_enable, sc);
#if defined(__NetBSD__) || defined(__OpenBSD__)
@@ -2701,6 +2710,29 @@
splx(s);
}
+/*
+ * Some EHCI chips from VIA seem to trigger interrupts before writing back the
+ * qTD status, or miss signalling occasionally under heavy load. If the host
+ * machine is too fast, we we can miss transaction completion - when we scan
+ * the active list the transaction still seems to be active. This generally
+ * exhibits itself as a umass stall that never recovers.
+ *
+ * We work around this behaviour by setting up this callback after any softintr
+ * that completes with transactions still pending, giving us another chance to
+ * check for completion after the writeback has taken place.
+ */
+void
+ehci_intrlist_timeout(void *arg)
+{
+ ehci_softc_t *sc = arg;
+ int s = splusb();
+
+ DPRINTFN(3, ("ehci_intrlist_timeout\n"));
+ usb_schedsoftintr(&sc->sc_bus);
+
+ splx(s);
+}
+
//
Static usbd_status
Index: ehci_pci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ehci_pci.c,v
retrieving revision 1.14.2.1
diff -u -r1.14.2.1 ehci_pci.c
--- ehci_pci.c 31 Mar 2005 19:45:09 - 1.14.2.1
+++ ehci_pci.c 17 Jan 2006 23:03:31 -
@@ -298,6 +298,10 @@
return ENXIO;
}
+ /* Enable workaround for dropped interrupts as required */
+ if (pci_get_vendor(self) == PCI_EHCI_VENDORID_VIA)
+ sc->sc_flags |= EHCI_SCFLG_LOSTINTRBUG;
+
/*
* Find companion controllers. According to the spec they always
* have lower function numbers so they should be enumerated already.
Index: ehcivar.h
===
RCS file: /home/ncvs/src/sys/dev/usb/ehcivar.h,v
retrieving revision 1.4.2.4
diff -u -r1.4.2.4 ehcivar.h
--- ehcivar.h 22 Mar 2005 00:56:54 - 1.4.2.4
+++ ehcivar.h 17 Jan 2006 23:03:31 -
@@ -93,6 +93,7 @@
#define EHCI_COMPANION_MAX 8
#define EHCI_SCFLG_DONEINIT0x0001 /* ehci_init() has been called. */
+#define EHCI_SCFLG_LOSTINTRBUG 0x0002 /* workaround for VIA chipsets */
typedef struct ehci_softc {
struct usbd_bus sc_bus; /* base device */
@@ -149,6 +150,7 @@
struct lock sc_doorbell_lock;
usb_callout_t sc_tmo_pcd;
+ usb_callout_t sc_tmo_intrlist;
device_ptr_t sc_child; /* /dev/usb# device */
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src/sys/dev/usb ehci.c ehci_pci.c ehcivar.h
Can this commit, http://lists.freebsd.org/pipermail/cvs-src/2006-January/058150.html (sorry I dont have the msgid) be mfc'd to 6 and 5 before the freeze? I merged (cvs up -j...) it on 5.4 and it fixes ehci hangs for me. Thanx, Juergen ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ehci not used(?) when connected device turned on later
On Tue, Jan 17, 2006 at 04:38:51PM -0700, Warner Losh wrote: > From: Warner Losh <[EMAIL PROTECTED]> > Subject: Re: ehci not used(?) when connected device turned on later > Date: Tue, 17 Jan 2006 16:29:38 -0700 (MST) > > > From: Juergen Lock <[EMAIL PROTECTED]> > > Subject: ehci not used(?) when connected device turned on later > > Date: Tue, 17 Jan 2006 23:51:31 +0100 > > > > > Is this a known problem with the 5.4 usb code? > > > > > > 1. connect an externally powered umass device (eg a harddrive with > > > its own psu) thats turned off > > > 2. boot freebsd > > > 3. turn the device on later > > > > > > then it gets only usb 1.1 speed even when ehci is in the kernel. > > > You have to reconnect it _while being turned on_ to get usb2 speed. > > > Same problem if you turn it off after use and later turn it back on > > > while still being connected... > > > > > > Is there a fix? (With linux it works as expected, if that means > > > anything... :) > > > > > > Oh, please Cc me with followups, I'm not subscribed on -usb (yet?) > > > > I have no idea what you are saying. > > > > ehci is used for me when I plug in my devices, or when I turn them > > on. Do you have ehci in your kernel? It was disabled by default in > > 5.4. > > Oh, I'm slow today... > > I'm pretty sure that -current does the right thing, but I'll double > check tonight. I got one instance of `40.000MB/s transfers' dmesg after turning it on today, so apparently it only `sometimes' doesnt work. (Next try it didn't.) Some kind of race? Maybe the `rate of success' depends on the device as well, as you haven't seen the problem at all... (right?) ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ehci not used(?) when connected device turned on later
Is this a known problem with the 5.4 usb code? 1. connect an externally powered umass device (eg a harddrive with its own psu) thats turned off 2. boot freebsd 3. turn the device on later then it gets only usb 1.1 speed even when ehci is in the kernel. You have to reconnect it _while being turned on_ to get usb2 speed. Same problem if you turn it off after use and later turn it back on while still being connected... Is there a fix? (With linux it works as expected, if that means anything... :) Oh, please Cc me with followups, I'm not subscribed on -usb (yet?) Juergen ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
