Re: slow USB 3.0 on -current
On Sun, Jul 12, 2020 at 2:55 PM John-Mark Gurney wrote: > Hans Petter Selasky wrote this message on Sun, Jul 12, 2020 at 09:57 +0200: > > On 2020-07-12 00:44, John-Mark Gurney wrote: > > > Hello, > > > > > > I'm having issues getting good ethernet performance from a USB ethernet > > > adapter (ure) under FreeBSD on an HP EliteDesk 705 G2 Mini[1]. It's an > > > AMD PRO A10-8700B based system using the AMD A78 FCH chipset. > > > > > > Under FreeBSD -current (r362596), 12.1-R and 11.4-R, the RealTek USB > > > adapter only gets around 10MB/sec performance. During the transfer, > > > the CPU usage is only around 3-5%, so it's definitely not CPU bound. > > > > > > I have tested Windows 10 and NetBSD 9.0 performance, and both provide > > > 100MB/sec+ w/o troubles. > > > > > > I have attached dmesg from both FreeBSD -current and NetBSD 9.0. > > > > > > Any hints on how to fix this? > > > > > > This may be related, but I'm also having issues w/ booting when I have > > > both a SD USB 2.0 card reader AND the ure plugged into USB 3.0 ports. > > > > > > If I move the SD card reader to USB 2.0, the umass device will attach > > > and work. I have also attached a clip of the dmesg from that > > > happening. > > > > > > Has anyone else seen this issue? Ideas or thoughts on how to resolve > > > the performance issues? > > > > Can you check the output from ifconfig. What is the actual link speed. I > > suspect it has something to do with the MII bus code/implementation. > > ifconfig is reporting it's 1000baseT. > > > Also check output from "vmstat -i" during usage to see if the number of > > IRQ/s is low. > > Not sure what is considered low, but I'm seeing consistently around > 7800 int/s for xhci0. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > This is just for clarification, but is 'MB' MBytes? In the networking world that is what it would mean, but the context leads me to think that you mean Mbits. It's also possible that some numbers are in bits and some in Bytes, causing real confusion. I'm sure that 1000baseT is bits, of course. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: Digi Watchport/T temperature sensor as /dev/ttyU
1 interfaces. > > > > root@thor: [src] man ugensa > > > > No manual entry for ugensa > > > > root@localhost: [src] ll /dev/cuaU0* > > > > 203 crw-rw 1 uucp dialer - 0xcb Jul 24 07:51 /dev/cuaU0 > > > > 204 crw-rw 1 uucp dialer - 0xcc Jul 24 07:51 > > > > /dev/cuaU0.init > > > > 205 crw-rw 1 uucp dialer - 0xcd Jul 24 07:51 > > > > /dev/cuaU0.lock > > > > > > > > > > > > I'll try now to get informations out of the device, I let you > > > > know whether that is a > > > > success. But anyway, again, thank you for helping making the > > > > device visible and > > > > available. > > > > > > > > > I had no luck with retrieving informations out of the device by the > > Perl5 script provided > > by Nagios.org. A prerequisite for the Perl script is the FreeBSD port > > > > comms/p5-Device-SerialPort > > > > Patching the script is trivial, but I do not know whether the > > backend, > > comms/p5-Device-SerialPort, works a sexpected. So the first, dirty, > > trial ended up in > > nothing - since the information gained from the sensor is an empty > > string/nothing. > > > > I'm not familiar with serial devices, so far, so probably there is > > something trivial > > missing. > > I looked around for some info on these Watchport devices. Their manual > indicates that they use both serial comms to send commands and receive > data, and they use serial-comms modem control signals (RTS/CTS, DTR, > etc). Some googling makes it look like they use a TI 5052 USB serial > chip. On linux, that would be handled by the io_ti USB serial driver. > > All of that adds up to the freebsd ugensa driver (which is "generic > serial IO") probably not working. The ugensa driver has nothing chip > -specific in it, it's for accessing devices which can do bulk > read/write without needing to configure any of the other serial comms > parameters. The ugensa driver works with things like gps receivers > that have simple text-only interfaces. > > I think these watchport devices will likely need real serial comms > configuration -- baud rate at least, to even be able to talk to them. > In other words, freebsd needs a real driver for TI 5052 chips. It > looks like a fairly complete datasheet for the chip is available (but I > don't have time to write a driver myself). > > -- Ian > There are several different USB serial drivers. Off-hand I see ubser, ubsa, uchcom, ucom, ucycom, uftdi, ubgensa, umcs, umct, umoscom, uplcom, usb_serial, uslcom, and uvscom. Whether any of these will support the TI chip, I can't say. Most have man pages, but a few, as has been noted, are lacking one. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: VirtualBox 4.3.6 and USB Mass Storage problems
On Mon, Feb 24, 2014 at 4:42 AM, Bernhard Fröhlich wrote: > No, USB passthrough never worked reliably. So it is not a regression > but something > that should be fixed. > > > > -- > Bernhard Froehlich > http://www.bluelife.at/ > > I've had good luck with really slow devices like serial ports, but no luck with higher-speed devices. IIRC, the USB support is 1.0 with no 2.0 capability. At least on other platforms only the closed source version supports 2.0. I suspect mny faster devices just are not happy with the low USB speeds of which VB-OSE is capable. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: FYI: Advanced USB compliance testing tool now in the tree (10-current only)
On Fri, Aug 9, 2013 at 1:33 PM, Hans Petter Selasky wrote: > Hi, > > For those of you that want to make sure your USB mass storage device > behaves correctly when using FreeBSD, typically for critical applications, > I've just added an advanced USB testing tool to the FreeBSD source tree. It > can be used to stress your USB mass storage device in ways that are beyond > what "bonnie" will do. See tools/tools/usbtest or the following commit: > > http://svnweb.freebsd.org/**changeset/base/254159<http://svnweb.freebsd.org/changeset/base/254159> > > --HPS Looks very nice. While it is now only in head, is there a reason it could not be built and used on a 9.2-BETA system? (I have not tried. Just wondering if I should.) -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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: high system load when using i915kms
1 0 > Total1573941 25386 > interrupt total rate > irq1: atkbd0 187 2 > irq9: acpi0 94 1 > irq12: psm0 24 0 > irq16: uhci0 uhci3 3056916 42457 > irq19: ehci0 uhci2 2 0 > irq20: hpet0 44423616 > irq23: uhci1 ehci195 1 > irq256: hdac0 71 0 > irq257: alc0 634 8 > irq258: iwn02494 34 > irq259: ahci0 4772 66 > irq260: vgapci0 10 0 > Total3109722 43190 > > PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU > COMMAND >11 root 2 155 ki31 0K32K RUN 1 4:16 120.35% idle >12 root 18 -84- 0K 288K WAIT0 0:57 76.34% intr > > I've got this after second boot today, although I couldn't reproduce it > yesterday even after ten attempts. But sometimes it's quite nasty and I > have > to reboot the system several times to get rid of it. > > Max > So the issue is that that the interrupts from one or another of the USB devices has exploded from near zero to around 40K when the kernel module is loaded? A couple of possibly irrelevant questions. Do you normally manually load the module? I did not research the issue, but when I manually load the module I was seeing things just grind to a halt. If I started Gnome, the module was loaded automatically by X, and things worked. Why loading the Intel KMS module would cause a massive increase in interrupts on a USB interface completely baffles me, but I suspect some sort of race is going on when the module is pre-loaded. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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: 8.x grudges
backward-compatibility aliases > are a fine idea and really improves user's experience... No, this one is due to a major re-structuring of how disks work in V8. As has been oft noted, "dangerously dedicated" is called that because it IS dangerous. While commonly used, it does not play nicely with standards and is prone to some fairly serious potential issues on upgrade. "dangerously dedicated" has been marked as "use it at your own risk", so you are likely to see issues (in this case a fairly minor one). >8. > I tried to do an install on one of the systems via netbooting > (pxeload) the disk1-image. It booted, but the sysinstall had to be > started manually and, once started, did not act the same as when > booted off of CD-ROM. Seems like a simple bit to correct so that > setting "init" to /usr/sbin/sysinstall/manually on every boot/ is > not necessary... Have not tried this. >9. > The k8temp utility (installed by sysutils/k8temp > <http://www.freshports.org/sysutils/k8temp>), which worked fine on > both of my AMD-machines, no longer works on the Athlon one (still > works on the Opteron-based server). I reinstalled the port, but > that did not help -- the utility runs, but does not say anything. > Requeting debug-info is of little help: > > *ro...@quokka:~ (101) k8temp > *ro...@quokka:~ (102) k8temp -d > CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0 > Advanced Power Management=0x1 > Temperature sensor: Yes > Frequency ID control: No > Voltage ID control: No >THERMTRIP support: No > HW Thermal control: No > SW Thermal control: No > 100MHz multipliers: No > HW P-State control: No >TSC Invariant: No k8temp is for older AMD system running K8 cores. It has been mostly replaced with amdtemp which works on newer cores. I'm not sure if amdtemp will work on K8 cores, though. > If any of the above can be corrected or, at least, documented, before > release, we stand a little bit better chance of getting the praise > otherwise well-deserved by FreeBSD... Thanks. Yours, Documentation in FreeBSD seems quite a bit better than that of other open source projects, but it is not perfect and the handbook, in particular, will always lag a bit. Feel free to contribute suggested changes to the documentation team (doc@). I hope to spend a bit of time in this area after I retire. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: HEADSUP new usb code coming in.
> From: Hans Petter Selasky <[EMAIL PROTECTED]> > Date: Tue, 19 Aug 2008 22:44:20 +0200 > > On Tuesday 19 August 2008, Kevin Oberman wrote: > > > Date: Tue, 19 Aug 2008 12:44:13 -0700 > > > From: Alfred Perlstein <[EMAIL PROTECTED]> > > > Sender: [EMAIL PROTECTED] > > > > > > After a long period of review and testing I am on the verge of > > > committing Hans Peter's new usb stack to -current. > > > > > > The patchset requires a SMALL _493_ line diff to the main code, > > > mostly bug fixes to arm. And then a large number of new files > > > for the usb system. > > > > > > The new usb system will be committed as separate files with > > > the intention of folding them over the old files before the > > > 9.0 release. > > > > > > The diff to the main files is here: > > > http://mu.org/~bright/usb2/usb2_release_001.diff > > > > > > The whole diff, including new files is here: > > > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > > > > > FAQ: > > > Q. Has this been reviewed? > > > A. Yes, pretty strongly by myself and we've consulted with > > > various others, Warner, Scott and Andrew for review/testing. > > > I wouldn't say that Warner or Scott have given full review > > > but just about all questions have been answered. > > > > > > Q. Can we change the name from "usb2_" to my favorite name? > > > A. No. This is for a short period, stop being so annoying. > > > > > > Q. What about the old usb code? > > > A. What about it? :D > > > > > > Q. What about ttys? > > > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > > > Hans is very responsive to SMP issues. > > > > > > Q. Shouldn't you wait? > > > A. Wait for what? No. > > > > > > Q. I have some whitespace nits, can you do those? > > > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > > > to get all whitespace right, but you're welcome to point things out after > > > the commit. > > > > Cool! I've been waiting for this for a loong time. Thanks to you, > > Hans Peter and all of the folks who have helped! > > > > Not on the FAQ: > > > > Q: Other then no longer requiring giant [MPSAFE], what does usb2 give > >us? Does it fix the battery-eating on laptops? Does it allow the > >system to reach C3 and lower sleep states? (These are at least > >closely linked issues.) > > Hi, > > Regarding power save there is no news. But I have been thinking about it, and > a simple patch like turning off the ASYNC and SYNC schedules when no devices > are plugged is not impossible. Only that it hasn't been done yet, because > there is already plenty of USB stuff to do. > > New stuff (all of which I can remember right now): > > - Full support for Split transactions, which means you can use your full > speed USB audio on a high speed USB HUB. > - Full support for HS ISOC transactions, which makes writing drivers for > various HS webcams possible, for example > - Full support for USB on embedded platforms, mostly cache flushing and > buffer invalidating stuff. > - Safer parsing of USB descriptors. > - Autodetect of annoying USB install disks. > - Support for USB device side (and a handful of USB device side chips) > - Support for USB transfers like I/O vectors, means more throughput and > less > interrupts. > - New UGEN backend and libusb library, finally solves the "driver > unloading" > problem. > - A new USB API. > - Many USB drivers are now running Giant free. > - Linux USB kernel compat layer. > - ... see the FreeBSD quarterly status reports > > --HPS > Very impressive. Yes, turning off polling when there are no connected devices would help with the battery drain in that regard, but I don't see how this would solve the problem of getting to C3 or lower when a USB device is connected. I know that Windows once had this problem early in the XP days and they fixed it in some way. I am not at all expert on USB, so I don't know at what frequency USB polls, but I would hope it's not so high that a system can't even get to C3, but with the current stack, C2 is the best you can get and C2 does not save a lot of power on most systems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpnK7zpfLfpg.pgp Description: PGP signature
Re: HEADSUP new usb code coming in.
> Date: Tue, 19 Aug 2008 12:44:13 -0700 > From: Alfred Perlstein <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > After a long period of review and testing I am on the verge of > committing Hans Peter's new usb stack to -current. > > The patchset requires a SMALL _493_ line diff to the main code, > mostly bug fixes to arm. And then a large number of new files > for the usb system. > > The new usb system will be committed as separate files with > the intention of folding them over the old files before the > 9.0 release. > > The diff to the main files is here: > http://mu.org/~bright/usb2/usb2_release_001.diff > > The whole diff, including new files is here: > http://mu.org/~bright/usb2/usb4bsd.diff.gz > > FAQ: > Q. Has this been reviewed? > A. Yes, pretty strongly by myself and we've consulted with > various others, Warner, Scott and Andrew for review/testing. > I wouldn't say that Warner or Scott have given full review > but just about all questions have been answered. > > Q. Can we change the name from "usb2_" to my favorite name? > A. No. This is for a short period, stop being so annoying. > > Q. What about the old usb code? > A. What about it? :D > > Q. What about ttys? > A. I don't know, we'll address the mpsafe aspects of ttys shortly, > Hans is very responsive to SMP issues. > > Q. Shouldn't you wait? > A. Wait for what? No. > > Q. I have some whitespace nits, can you do those? > A. No. It's a 100k line diff and a 3meg delta, we tried really hard > to get all whitespace right, but you're welcome to point things out after > the commit. Cool! I've been waiting for this for a loong time. Thanks to you, Hans Peter and all of the folks who have helped! Not on the FAQ: Q: Other then no longer requiring giant [MPSAFE], what does usb2 give us? Does it fix the battery-eating on laptops? Does it allow the system to reach C3 and lower sleep states? (These are at least closely linked issues.) I have not been running current for a while and this might be enough incentive to get me to kick the tires. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpblkJzn5to4.pgp Description: PGP signature
Re: USB issues (not just Re: PR backlog)
> From: Mikhail Teterin <[EMAIL PROTECTED]> > Date: Thu, 27 Dec 2007 12:39:21 -0500 > Sender: [EMAIL PROTECTED] > > ÞÅÔ×ÅÒ 27 ÇÒÕÄÅÎØ 2007 12:33 ÐÏ, M. Warner Losh ÷É ÎÁÐÉÓÁÌÉ: > > I did the bulk of the work for the 7.0 stuff, at least getting things > > into the tree. Since I did the work, my last job got totally insane > > and then I switched jobs. > > As the old Russian saying went: if vodka interferes with your job, you > have to stop working. Which explains why there are not more old Russians. :-) > > We can all agree that this is long overdue. But we need to make sure > > of a few critical details so we don't create another mess for > > ourselves down the line. > > Seriosly, thank you and do get back to it whenever you can. As to the original issue, I reported the same thing with my Olympus camera. It used to work fine, so this is a regression. It crashes current but simply fails when I use the HPS USB stack. (After a few seconds, the camera simply turns itself off.) As the original posted offered, I can provide a dump and posted the backtrace. I'd really love to be able to download pictures again, but I am not optimistic. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpS19kuzx7lH.pgp Description: PGP signature
New USB drivers
I have now been running the Hans Petter's USB drivers for about a week and they have been working pretty well. That said, I have seen two things that concern me. 1. Today I connected a USB disk to the system. It ran fine, but then I dismounted it (using nautilus and hald), the window informing me that the device could be safely removed popped up and I unplugged the drive. At that point, my system live-locked. I did see some updates to windows, but I could not change focus to a different window nor could I move to a different desktop. I tried CTRL-ALT-BS to kill X, but it would not work. I tried CTRL-ALT-DEL to reboot the system. No joy. The system was at least partly alive as the disk activity LED would flash now and then. I eventually had to power-cycle it. :-( As a result I have pretty much no information to help track this one down. 2. I use dd to mirror my system disk on a weekly basis. I track the performance of dd during this operation and, with no other changes than the USB stack being added to the kernel, the average transfer rate dropped from 17.43 MB to 17.15 MB. Not huge, but quite noticeable when copying an 80 GB drive. I run this in single-user mode with no partitions mounted (except root mounted read-only), so USB previously had not even been loaded, so the old drivers may have had even a greater impact. And the difference may not be the USB stack, but nothing else was changed. It will take more time to tell if there is a real problem here, but I wanted to provide a little (very little, I admit) information on my experience. Thanks, Hans, for all of your work on this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpPEhqn4VumP.pgp Description: PGP signature
Re: cpu.cx usage no longer available?
> Date: Thu, 03 May 2007 11:27:36 -0400 > From: "Alexandre \"Sunny\" Kovalenko" <[EMAIL PROTECTED]> > > On Tue, 2007-05-01 at 15:45 -0700, Kevin Oberman wrote: > > > > > I am VERY pleased to see that Hans Petter's new USB drivers do allow the > > system to drop into C3! It will require a bit more testing, but I hope > > to be able to leave USB in my kernel without serious battery life > > impact. > > > > I have heard that the new USB drivers are unlikely to make it into V7.0 > > due to lack of testing. I really hope a few more people give it a whirl > > and report back on the results, good or bad, so that the drivers can > > either be fixed or added to current. > > I have not seen it in your original E-mail... was this -CURRENT? I was > under the impression that new USB stack patch is RELENG_6 only ATM. > > usb@ CC'ed. > > Alexandre "Sunny" Kovalenko. > It was only V6, but the trivial fix to deal with the different API in current has now been added and it is working very nicely for me on current. (I had previously patched the V6-only version for current at Hans Petter's direction. It was just one or two lines.) I think the message that it could be applied to current went out to the current mailer earlier this week. acpi@ removed from distribution. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpbrwHWXj5vS.pgp Description: PGP signature
Re: Problems with USB devices connecting to UHCI instead of EHCI
> From: Hans Petter Selasky <[EMAIL PROTECTED]> > Date: Sun, 11 Mar 2007 19:25:14 +0100 > > On Sunday 11 March 2007 02:04, Kevin Oberman wrote: > > If I load umass after plugging in a disk or flash fob, it will be > > connected as a UHCI device. If I load umass and then connect the device, > > it is properly connected as EHCI. When connected as a UHCI device, it is > > too slow to be useful. > > > > Looks like a race condition as the EHCI is the last USB device probed. I > > suspect that the disk is already connected to a UHCI device before an > > EHCI device is found. > > > > uhci0: port > > 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] > > uhci0: [ITHREAD] > > usb0: on uhci0 > > usb0: USB revision 1.0 > > uhub0: on usb0 > > uhub0: 2 ports with 2 removable, self powered > > uhci1: port > > 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] > > uhci1: [ITHREAD] > > usb1: on uhci1 > > usb1: USB revision 1.0 > > uhub1: on usb1 > > uhub1: 2 ports with 2 removable, self powered > > uhci2: port > > 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] > > uhci2: [ITHREAD] > > usb2: on uhci2 > > usb2: USB revision 1.0 > > uhub2: on usb2 > > uhub2: 2 ports with 2 removable, self powered > > uhci3: port > > 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] > > uhci3: [ITHREAD] > > usb3: on uhci3 > > usb3: USB revision 1.0 > > uhub3: on usb3 > > uhub3: 2 ports with 2 removable, self powered > > ehci0: mem 0xb000-0xb3ff > > irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] > > ehci0: [ITHREAD] > > usb4: EHCI version 1.0 > > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > > usb4: on ehci0 > > usb4: USB revision 2.0 > > uhub4: on usb4 > > uhub4: 8 ports with 8 removable, self powered > > > > Any idea if this is fixable? Not a huge problem, but an annoying > > one. Will the new USB system (hopefully coming soon) deal with this? > > It might have something to do with the probe order. Did you try the new USB > stack. I recommend you install it on 6-stable, because on 7-current it needs > some small patches to compile, due to some changes in the kernel API lately. Yes, I suspect the probe order is significant, but the only system I use USB devices on is my laptop and I really don't want to roll it back to stable. I can continue to work around it until you have a set of current patches for me to try. I'm really anxious to try out the new stack as I am hoping it will make USB behave better in terma of power management on my laptop. That's why i don't build USB into my kernel, but just load it when I need it. I don't normally read usb@, so I may drop you a note in a couple of weeks to see if the stack has been updated for current. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp67M6s7ux5Z.pgp Description: PGP signature
Problems with USB devices connecting to UHCI instead of EHCI
If I load umass after plugging in a disk or flash fob, it will be connected as a UHCI device. If I load umass and then connect the device, it is properly connected as EHCI. When connected as a UHCI device, it is too slow to be useful. Looks like a race condition as the EHCI is the last USB device probed. I suspect that the disk is already connected to a UHCI device before an EHCI device is found. uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1860-0x187f irq 11 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xb000-0xb3ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered Any idea if this is fixable? Not a huge problem, but an annoying one. Will the new USB system (hopefully coming soon) deal with this? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp8CAqL8ksPZ.pgp Description: PGP signature
