From owner-freebsd-usb@FreeBSD.ORG Sat Jan 15 10:38:47 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D20E616A4CE for ; Sat, 15 Jan 2005 10:38:47 +0000 (GMT) Received: from szamoca.krvarr.bc.ca (s142-179-111-232.bc.hsia.telus.net [142.179.111.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3393B43D1F for ; Sat, 15 Jan 2005 10:38:45 +0000 (GMT) (envelope-from sandy@krvarr.bc.ca) Received: from szamoca.krvarr.bc.ca (localhost [127.0.0.1]) by szamoca.krvarr.bc.ca (8.13.1/8.12.11) with ESMTP id j0FAbsTZ000862; Sat, 15 Jan 2005 02:37:54 -0800 (PST) (envelope-from sandy@szamoca.krvarr.bc.ca) Received: (from sandy@localhost) by szamoca.krvarr.bc.ca (8.13.1/8.12.11/Submit) id j0FAbrIw000859; Sat, 15 Jan 2005 02:37:53 -0800 (PST) (envelope-from sandy) From: Sandy Rutherford MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="W0AcZiywTF" Content-Transfer-Encoding: 7bit Message-ID: <16872.62081.209945.743448@szamoca.krvarr.bc.ca> Date: Sat, 15 Jan 2005 02:37:53 -0800 To: Julian Elischer In-Reply-To: <41E6D483.8050005@elischer.org> References: <16870.6275.128262.61361@szamoca.krvarr.bc.ca> <41E6D483.8050005@elischer.org> X-Mailer: VM 7.07 under Emacs 21.3.1 cc: freebsd-usb@freebsd.org Subject: Re: ulpt hangs on offline status X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 10:38:48 -0000 --W0AcZiywTF Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Julian, On Thu, 13 Jan 2005 you wrote: > Sandy Rutherford wrote: >> >> [root@szamoca:14] usbdevs -v -d >> Controller /dev/usb0: >> addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 >> uhub0 >> port 1 powered >> port 2 addr 2: full speed, power 98 mA, config 1, Centronics connector(0x0006), Entrega(0x1645), rev 1.00 >> ulpt0 >> >> I am willing to muck around with the driver to try to fix this myself, >> but it would be useful to know if anybody else has seen or worked on >> this problem. >> > not yet but I'm willing to believe that you may need to poll the device > to see the change in status. > That would be handled in the "interrupt" type transfers.. > We do not support them very well yet. This evening, I threw a bunch of print statements into ulpt.c to see what was happening. This is for /sys/dev/usb/ulpt.c in FreeBSD 4.10. As expected, it hangs trying to open the connection. First it runs a tsleep loop: for (spin = 0; (ulpt_status(sc) & LPS_SELECT) == 0; spin += STEP) { DPRINTF(("ulpt_open: waiting a while\n")); if (spin >= TIMEOUT) { error = EBUSY; sc->sc_state = 0; goto done; } /* wait 1/4 second, give up if we get a signal */ error = tsleep(sc, LPTPRI | PCATCH, "ulptop", STEP); if (error != EWOULDBLOCK) { sc->sc_state = 0; goto done; } if (sc->sc_dying) { error = ENXIO; sc->sc_state = 0; goto done; } } If the printer is offline, the tsleap returns an EAGAIN (resource temporarily unavailable) error. After the loop, it tries to open input and output pipes. If any of these fail, `error' is set to one of EIO or ENOMEM and we `goto done'. The problem is that if the printer comes back on line during the tsleep loop, this is not caught and the tsleep loop exits with `error == EAGAIN'. If subsequently, the input and output pipes are opened successfully, `error' remains set to EAGAIN and this is what `ulptopen' returns. It should really return 0, because we have a good connection and we should start writing data. Therefore, I stuck the following just before the `done: ' tag: /* If we get to here with error == EAGAIN (resource temporarily */ /* unavailable), it means open out and open in succeeded, even */ /* though the tsleep failed. This probably means that */ /* the printer came online during the tsleep loop and we now */ /* have a connection. Return 0 to start ulptwrite. */ /* --SR sandy@krvarr.bc.ca */ if (error == EAGAIN) { DPRINTF(("error=%d. Connection established?", error)); error = 0; } done: if (--sc->sc_refcnt < 0) usb_detach_wakeup(USBDEV(sc->sc_dev)); DPRINTF(("ulptopen: done, error=%d\n", error)); return (error); } It does the job for me. ulpt now starts up when the printer comes back online. If anybody else has a similar problem, you might try this patch. I'll attach a proper patch file below. If anybody does try this and it messes something else up, please let me know. USB devices are notoriously flakey. After testing this further for a few days, I'll send in a pr with the patch. BTW, I am running FreeBSD on i386 hardware. The specifics of my USB setup are: usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 addr 2: full speed, power 98 mA, config 1, Centronics connector(0x0006), Entrega(0x1645), rev 1.00 Sandy --W0AcZiywTF Content-Type: application/octet-stream Content-Description: ulpt.c patch Content-Disposition: attachment; filename="ulpt.c.patch" Content-Transfer-Encoding: base64 KioqIHVscHQuYy5vcmlnCVdlZCBKYW4gMTIgMjA6MTM6MTggMjAwNQotLS0gdWxwdC5jCVNhdCBK YW4gMTUgMDE6NTI6MDAgMjAwNQoqKioqKioqKioqKioqKioKKioqIDYwNyw2MTIgKioqKgotLS0g NjA3LDYyNCAtLS0tCiAgCiAgCXNjLT5zY19zdGF0ZSA9IFVMUFRfT1BFTjsKICAKKyAKKyAJLyog SWYgd2UgZ2V0IHRvIGhlcmUgd2l0aCBlcnJvciA9PSBFQUdBSU4gKHJlc291cmNlIHRlbXBvcmFy aWx5ICovCisgCS8qIHVuYXZhaWxhYmxlKSwgaXQgbWVhbnMgb3BlbiBvdXQgYW5kIG9wZW4gaW4g c3VjY2VlZGVkLCBldmVuICAqLworICAgICAgICAgLyogdGhvdWdoIHRoZSB0c2xlZXAgZmFpbGVk LiAgVGhpcyBwcm9iYWJseSBtZWFucyB0aGF0ICAgICAgICAgICovCisgICAgICAgICAvKiB0aGUg cHJpbnRlciBjYW1lIG9ubGluZSBkdXJpbmcgdGhlIHRzbGVlcCBsb29wIGFuZCB3ZSBub3cgICAg Ki8gCisgICAgICAgICAvKiBoYXZlIGEgY29ubmVjdGlvbi4gIFJldHVybiAwIHRvIHN0YXJ0IHVs cHR3cml0ZS4gICAgICAgICAgICAgKi8KKyAgICAgICAgIC8qIC0tU1Igc2FuZHlAa3J2YXJyLmJj LmNhICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworIAlpZiAoZXJyb3Ig PT0gIEVBR0FJTikgeworIAkgIERQUklOVEYoKCJlcnJvcj0lZC4gIENvbm5lY3Rpb24gZXN0YWJs aXNoZWQ/IiwgZXJyb3IpKTsKKyAJICBlcnJvciA9IDA7CisgCX0KKyAKICAgZG9uZToKICAJaWYg KC0tc2MtPnNjX3JlZmNudCA8IDApCiAgCQl1c2JfZGV0YWNoX3dha2V1cChVU0JERVYoc2MtPnNj X2RldikpOwo= --W0AcZiywTF--