Date: Fri, 21 Nov 2003 01:59:57 +0100 (CET) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: freebsd-stable@freebsd.org Subject: Re: hang of new usb stack [was Re: Patch for boot-time USB hangs in 4.9-PRERELEASE] Message-ID: <200311210059.hAL0xuZ01392@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> References: <200309271405.aa30238@salmon.maths.tcd.ie> <20031005190822.GC4548@genius.tao.org.uk> <20031006211517.64c5d916.tijl@ulyssis.org> <20031011115001.GE1028@genius.tao.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] A month late for this message, but I'm still catching up... Hey Joe, > > > The new usb patch to RELENG_4 as of today is at: > > > http://www.josef-k.net/misc/RELENG_4-USB-20031005.patch.gz Great! That looks like what I was hacking on, except two differences: it requires much less work on my part, and it almost works right out of the box... > You're right! I didn't add the usb tools to that patch set. I'll make > sure that they are there for the next one. I needed to add a few other minor hacks, to build the usb module (for historical reasons I use a kernel module rather than building it into the kernel, which buys me nothing since I can't unload the module so I end up rebooting if I need to make changes anyhows). Should I send those hacks upstream, or is it possible I'm missing some critical info, as I never downloaded or looked closely at the earlier patchset and remember little of the archives of that time? Basically, it works great for me, on a kernel built 15.Oct, from sources of earlier vintage -- looks like no later than 22.Sep -- and the usb hanging patch applied. Except I can't really use it in service, so I'm not. The problem I have is that the USB2.0 external hub I have, described in the -hackers list, errors (stalls) talking to the ehci controller, which disables that port. At boot, the hub is first attached to the ohci companion I have, which has no problems communicating with it, but then ehci takes over. I've meant to try to dig into that logic and see if it's possible for the ehci controller, upon seeing that particular hub, not to attach it at high speed, but leave it to the companion at full speed, but even if I could, I'm still looking for a round tuit. Since I can't use any devices attached to that hub, it makes it pretty useless for me. I could back out my makefile hacks for ehci support, but then I wouldn't see any benefit from the USB2.0-capable external drive (that I instead attach via firewire, so that's no excuse). Speaking of the USB2 external drive, I can see that it's faster than the default USB1 speed of 650k reported -- though not terribly faster as the ten-year-old machine itself is the bottleneck, but I can `dd' at a few MB/sec at least, matching the firewire ability. So I took a look at the diffs between the -current and -stable applicable SCSI code, to see if I could hack in a more accurate speed... My lack of sleep may be catching up to me, but I'd suspect one of the following is what (I presume) makes -current report a more accurate transfer rate from USB2 devices (no personal experience there, though a year ago I saw NetBSD doing that with its ehci support). I should probably hack myself to see if I can make it work, but I am reluctant to reboot or risk crashing this machine that's doing other long-running processes, so maybe some guru could offer advice or explanation... freq = scsi_calc_syncsrate(spi->sync_period); speed = freq; and/or speed *= (0x01 << spi->bus_width); and/or maybe even if (fc->valid & CTS_FC_VALID_SPEED) { speed = fc->bitrate; (all of which are in -current before printing the alleged device transfer rate, but missing from RELENG_4's source) The other odd thing, unrelated to these patches, is that while the USB2 drive is attached by ehci, a printer I have only reports full speed and is attached to ohci. I'm assuming the following means it's USB2-capable; if I'm ass-u-me-ing wrong, please enlighten me. DEVICE addr 4 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=2.00 bDeviceClass=0 bDeviceSubClass=0 ^^^^^^^^ bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x03f0 idProduct=0x3c02 bcdDevice=100 iManufacturer=1(hp) iProduct=2(photosmart 7350) iSerialNumber=3(MY31K432VG6M) bNumConfigurations=1 I'd show `usbdevs' output with the patched driver, but I neglected to save a copy when I tested it, and now I'm not using it and at the moment, unable to trivially reboot to capture it, so that will have to wait until RSN. Sorry... Thanks, Barry B0uwsma
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200311210059.hAL0xuZ01392>