USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted signature.asc Description: OpenPGP digital signature
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Thu, Jun 21, 2012 at 11:01 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? I don't personally have any relevant experience with this device, but having the exact revisions of code where this was working and where it was failing would be helpful, in order to perform a binary search to determine whether or not this is a regression. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Friday 22 June 2012 08:01:38 O. Hartmann wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted Hi, After plugging the device, try: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
incapable of handling the 64GB drive. I do not have issues with USB it's not about capacity. But seems some quirks for that pendrive (which have buggy firmware) has to be added, as it doesn't respond for inquiry command. sorry i am not USB expert. umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Fri, 22 Jun 2012 08:22:19 +0200 Hans Petter Selasky hsela...@c2i.net wrote: (snip) I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) My elder colleague often told me that it is the easiest and well-working way to check whether the one is certified to work for Mac OS X to get USB mass storage devices which work with *BSD :) Just my 5 yen, -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 22.06.12 09:22, Hans Petter Selasky wrote: I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. Morale of the story: Don't even dare put any hardware that you need working on FreeBSD under control of Linux or Windows. grin OS X is safe. By the way, I am serious! Sometimes, I am inclined to believe the conspiracy theory that those operating systems do this on purpose. Often to claim superiority as in see, it works with our OS, ok?. I believe if we get enough details of how this particular USB stick is exactly recognized an quirk definition for it could be added to save future users from such behavior. But the bit it was used with Linux might need to be supplied by the user. Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SIGSEGV in lots of processes (head i386 @r237440)
Just updated my laptop's head slice from r237378 to r237440; while it did manage to get to multi-user mode, I was only able to login as root, and whenever I tried to do much of anything, the sell (csh) exited with a SIGSEGV. I finally gave it a 3-fingered salute, [Ctl-Alt-Del], and init appeared to enter a non-terminating SIGSEGV loop. My build machine is still building the kernel; assuming(!) I see similar behavior on that, I should be able to poke around a bit, as I have a serial console on it (though I'll be remote from it, as I'll be at work). Anyway, I thought I'd mention this in case it might help someone. The typescript from the svn update and the resulting build may be found at http://www/~david/FreeBSD/head_r237440.txt. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgplZUM8R7zfr.pgp Description: PGP signature
Re: SIGSEGV in lots of processes (head i386 @r237440)
On Fri, Jun 22, 2012 at 06:49:59AM -0700, David Wolfskill wrote: Just updated my laptop's head slice from r237378 to r237440; while it did manage to get to multi-user mode, I was only able to login as root, and whenever I tried to do much of anything, the sell (csh) exited with a SIGSEGV. I finally gave it a 3-fingered salute, [Ctl-Alt-Del], and init appeared to enter a non-terminating SIGSEGV loop. My build machine is still building the kernel; assuming(!) I see similar behavior on that, I should be able to poke around a bit, as I have a serial console on it (though I'll be remote from it, as I'll be at work). Anyway, I thought I'd mention this in case it might help someone. The typescript from the svn update and the resulting build may be found at http://www/~david/FreeBSD/head_r237440.txt. This is on i386, right ? Can you boot single-user and just type date in the shell ? Does it segfault ? If yes, does setting sysctl kern.timecounter.fast_gettime to 0 fix segfault from date(1) ? pgp7vmob4tOeP.pgp Description: PGP signature
Re: SIGSEGV in lots of processes (head i386 @r237440)
On Fri, Jun 22, 2012 at 05:10:20PM +0300, Konstantin Belousov wrote: On Fri, Jun 22, 2012 at 06:49:59AM -0700, David Wolfskill wrote: Just updated my laptop's head slice from r237378 to r237440; while it did manage to get to multi-user mode, I was only able to login as root, and whenever I tried to do much of anything, the sell (csh) exited with a SIGSEGV. I finally gave it a 3-fingered salute, [Ctl-Alt-Del], and init appeared to enter a non-terminating SIGSEGV loop. My build machine is still building the kernel; assuming(!) I see similar behavior on that, I should be able to poke around a bit, as I have a serial console on it (though I'll be remote from it, as I'll be at work). Anyway, I thought I'd mention this in case it might help someone. The typescript from the svn update and the resulting build may be found at http://www/~david/FreeBSD/head_r237440.txt. This is on i386, right ? Can you boot single-user and just type date in the shell ? Does it segfault ? If yes, does setting sysctl kern.timecounter.fast_gettime to 0 fix segfault from date(1) ? Ok, I probably can guess the cause. I suppose that 'date' does not segfaults. Please try the following (which I forgot to commit). Sorry. diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c index f0546b0..30efecd 100644 --- a/sys/i386/i386/machdep.c +++ b/sys/i386/i386/machdep.c @@ -469,7 +469,8 @@ osendsig(sig_t catcher, ksiginfo_t *ksi, sigset_t *mask) } regs-tf_esp = (int)fp; - regs-tf_eip = PS_STRINGS - szosigcode; + regs-tf_eip = p-p_sysent-sv_sigcode_base + szsigcode - + szosigcode; regs-tf_eflags = ~(PSL_T | PSL_D); regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; @@ -596,7 +597,8 @@ freebsd4_sendsig(sig_t catcher, ksiginfo_t *ksi, sigset_t *mask) } regs-tf_esp = (int)sfp; - regs-tf_eip = PS_STRINGS - szfreebsd4_sigcode; + regs-tf_eip = p-p_sysent-sv_sigcode_base + szsigcode - + szfreebsd4_sigcode; regs-tf_eflags = ~(PSL_T | PSL_D); regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; @@ -747,7 +749,7 @@ sendsig(sig_t catcher, ksiginfo_t *ksi, sigset_t *mask) } regs-tf_esp = (int)sfp; - regs-tf_eip = PS_STRINGS - *(p-p_sysent-sv_szsigcode); + regs-tf_eip = p-p_sysent-sv_sigcode_base; regs-tf_eflags = ~(PSL_T | PSL_D); regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; pgpchlQV7q2nw.pgp Description: PGP signature
Re: SIGSEGV in lots of processes (head i386 @r237440)
On Fri, Jun 22, 2012 at 06:22:16PM +0300, Konstantin Belousov wrote: ... found at http://www/~david/FreeBSD/head_r237440.txt. This is on i386, right ? Yes. Can you boot single-user and just type date in the shell ? Does it segfault ? If yes, does setting sysctl kern.timecounter.fast_gettime to 0 fix segfault from date(1) ? Ok, I probably can guess the cause. I suppose that 'date' does not segfaults. Correct; it did not. Please try the following (which I forgot to commit). Sorry. diff --git a/sys/i386/i386/machdep.c b/sys/i386/i386/machdep.c index f0546b0..30efecd 100644 --- a/sys/i386/i386/machdep.c +++ b/sys/i386/i386/machdep.c ... That seems to bring behavior back to normal: I can now log in via ssh (vs. having sshd segfault coredump): FreeBSD freebeast.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #851 237440M: Fri Jun 22 08:42:54 PDT 2012 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 Thank you very much for the quick response, despite my rather vague hand-waving. And I apologize for not directly responding to your earlier note -- I have no connectivity during most of my commute. (And we really don't want me trying it for the part on my bicycle!) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpN67uvzh6ZG.pgp Description: PGP signature
Re: minor GEOM disk API change coming
Hi. I understand problem you are going to fix and I think your patch should do it. What I don't very like is addition of new GEOM method. Now GEOM doesn't need it because all internal open/close operations and provider destructions there protected by the topology SX lock. Unluckily that lock doesn't cover g_wither_provider(), called by disk_gone() while holding CAM SIM lock. If not that SIM lock, it would be enough to just grab and drop GEOM topology lock to ensure that no new open() calls will follow. Indirect way to do it could be to post GEOM event that would drop the reference as soon as it will be handled and can obtain the topology lock. Unluckily it uses malloc() for event storage and also can be unreliable if called from under the SIM mutex lock. So it seems many things would be much easier if it was possible to drop SIM lock inside periph invalidate method, but now it is unsafe That is not an objection, just some thoughts about. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFT] llquantize for FreeBSD's dtrace
Hello; I am not a Dtrace user (yet) but I started to port the Log/linear quantizations from Illumos: http://dtrace.org/blogs/bmc/2011/02/08/llquantize/ Apparently this patch should do it: http://people.freebsd.org/~pfg/patches/patch-llquantize-complete Unfortunately when I tried to build current with Dtrace support, my i386 Virtualbox VM got stuck in ctfmerge so this is completely untested. Testers that know how to use it are welcome :). best regards, Pedro. ps. just for reference, the original code was taken from here: https://hg.openindiana.org/upstream/illumos/illumos-gate/rev/15b74a2a9a9d ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Fri, Jun 22, 2012 at 1:01 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted I see similar behavior and output on my Dell M6500 notebook running CURRENT, but only on two ports which are some type of hybrid USB 2.0/3.0 (configurable via BIOS setting). If I use either of these ports with a USB 2.0 device while running the ports in USB 3.0 mode (using xhci(4)), I can't reliably get a device to properly attach. I say reliably, because every once in a while, I can plug a device in and it works fine, even multiple times and after reboots. If I configure these ports to run in USB 2.0 mode (using ehci(4)), all of my USB 2.0 devices seem to work without fail. However, USB 3.0 devices do not attach on these ports when they are configured as USB 2.0 ports. So, at least on my notebook, these ports must be configured at either 2.0 or 3.0, depending on which device I plan on using :( I have one other port on this same system that is USB 2.0-only, and it works all of the time :) I'll have to try and add a hub into the mix to see if perhaps it is a power issue (although with a recent Linux kernel and Windows 7, all is well no matter what configuration I provide). It may be that FreeBSD's USB subsystem lacks some extra bit of code required to configure the ports properly in regard to power. -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
