Date: Thu, 3 May 2007 19:15:30 +0400 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: pvh@wfeet.za.net Cc: freebsd-stable@freebsd.org Subject: Re: [cups.bugs] tcgetattr() causes lockup in USB backend on FreeBSD6-STABLE Message-ID: <20070503151530.GE27817@codelabs.ru> In-Reply-To: <4639FA65.7010005@wfeet.za.net> References: <5560-cups.bugs@news.easysw.com> <5561-cups.bugs@news.easysw.com> <4639FA65.7010005@wfeet.za.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter, good day. Thu, May 03, 2007 at 05:06:13PM +0200, Peter van Heusden wrote: > Sorry, a bit more investigation revealed that my earlier comments were > wrong. Yes, the tcgetattr() call *does* "hang" - on my system it takes > 10 seconds to return, before returning ENODEV (the only thing that ioctl > on a ulpt returns on FreeBSD, according to my reading of the kernel). > That, however, isn't the real problem - the real hang occurs when > backendRunLoop() in runloop.c tries to read backchannel data from the > ulpt - despite select() saying that there is data available, the read() > blocks (I've even tried making the read buffer's size 1 byte, the > problem persists). This causes the usb backend hang. So indeed, setting > use_bc = 0 solves the problem. I'm not sure why select() / read() > interact like this. Seems like the FreeBSD kernel reports your device as the bi-directional one? I mean that 'dmesg | grep directi' shows something like 'ulpt0: using bi-directional mode'? If yes, then adding your device to the USB quirks as the uni-directional one should fix your problem. If you can rebuild the kernel, but don't know how to correct the quirks, send me the output of the 'usbdevs -v' with the printer plugged in and I will try to send you the patch for the USB quirks file. -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070503151530.GE27817>