Date: Fri, 8 Sep 2006 20:35:37 +0200 (CEST) From: Jan-Espen Pettersen <sigsegv@radiotube.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: usb/103046: [patch] ulpt event driven I/O with select(2) and nonblock Message-ID: <200609081835.k88IZbrE001253@endeavour.localnet.radiotube.org> Resent-Message-ID: <200609081840.k88IeOhq088855@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 103046 >Category: usb >Synopsis: [patch] ulpt event driven I/O with select(2) and nonblock >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-usb >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Fri Sep 08 18:40:23 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Jan-Espen Pettersen <sigsegv@radiotube.org> >Release: FreeBSD 6.1-STABLE i386 >Organization: >Environment: System: FreeBSD endeavour.localnet.radiotube.org 6.1-STABLE FreeBSD 6.1-STABLE #4: Fri Sep 8 19:19:26 CEST 2006 sigsegv@endeavour.localnet.radiotube.org:/usr/obj/usr/src/FreeBSD-6/sys/ENDEAVOUR i386 ports: cups-1.2.0 cups-base-1.2.2 ulpt0: Samsung Electronics Co., Ltd. Samsung ML-1710, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode >Description: cups 1.2 started to use select(2) to check for "backchannel" data. Since the ulpt driver does not have a poll function, and therefore select(2) will return with an read-event immediately. But since some printers just doesn't return any backchannel data the subsequent read(2) syscall will just block forever. This effectively prevents printing with default settings to these printers. I will therefore suggest having some minimal nonblocking I/O with a select(2) syscall that works for reading data from the printer. >How-To-Repeat: This can be repeated with printers that does not give any data back on the receive pipe. Bulk reads initiated by read(2) syscalls blocks forever. You can see this with 'cat /dev/ulpt0'. It'll just hang. But the most serious issue is that cups tries to read from these printers effectively blocking the print job in a read(2) syscall. >Fix: I can see mainly two ways to solve this issue, either: * time out the bulk reads and return EIO or similar if the printer does not respond. * or, implement event driven and/or nonblocking I/O. I have created a patch that at least currently applies to 6.1-STABLE that implements minimal event driven I/O for reading and nonblocking reads: http://www.radiotube.org/ulpt_poll.diff >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609081835.k88IZbrE001253>