[cups.bugs] tcgetattr() causes lockup in USB backend on FreeBSD6-STABLE

[Peter van Heusden]

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.

Peter

Michael Sweet wrote:
> Peter van Heusden wrote:
>   
>> I recently upgrade CUPS on my FreeBSD 6-STABLE server to version 1.2.10,
>> and it took a while to get the USB backend working (I have a USB-connect
>> HP LaserJet 1010). After some debugging, it turned out that the code in
>> usb-unix.c that calls tcgetattr() on /dev/ulptN in print_device() was at
>> fault - what happens is that tcgetattr() blocks, and the USB backend
>> then hangs. I'm still waiting for a response from the FreeBSD developers
>> on this behaviour, but in any event from my reading of the kernel it
>> seems that ioctl() on a FreeBSD ulpt is a no-op anyway.
>>     
>
> The use_bc stuff doesn't control whether ioctl() (via tcget/setattr)
> is used to set "raw" mode, so a separate fix will be needed.
>
> That said, this sounds like a serious FreeBSD bug - ioctl is needed
> for POSIX conformance on all character devices.
>
>