Hello all,
currently it seems that select keeps blocking when the USB device behind
ttyUSBx gets unplugged. My understanding is, that select should return
when the next call to one of the operations (read/write) will not block.
This is certainly true for failing with ENODEV. So, is this an issue
that will be fixed or should I poll (not the syscall) the device? Or is
there another way to monitor for a vanishing tty (it should not be USB
specific).
Thanks in advance
Joerg
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
On Tue, 8 Mar 2005, Joerg Pommnitz wrote:
> Hello all,
> currently it seems that select keeps blocking when the USB device behind
> ttyUSBx gets unplugged. My understanding is, that select should return
> when the next call to one of the operations (read/write) will not block.
> This is certainly true for failing with ENODEV. So, is this an issue
> that will be fixed or should I poll (not the syscall) the device? Or is
> there another way to monitor for a vanishing tty (it should not be USB
> specific).
>
> Thanks in advance
> Joerg
In principle, you need to set your device handle (socket or fd)
to non-blocking before you use select() or poll(). It was never
resolved if the current behavior is a BUG. Nevertheless, it
is unlikely that it will be fixed because there is the belief
that it is NOT a BUG and even if it is a BUG, programs depend
upon this BUG to work.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Joerg Pommnitz wrote:
> Hello all,
> currently it seems that select keeps blocking when the USB device behind
> ttyUSBx gets unplugged. My understanding is, that select should return
> when the next call to one of the operations (read/write) will not block.
> This is certainly true for failing with ENODEV. So, is this an issue
> that will be fixed or should I poll (not the syscall) the device? Or is
> there another way to monitor for a vanishing tty (it should not be USB
> specific).
If you just do a blocking read() on the USB serial port, what happens
when you pull the device? At one point (2.4.20 is the last I checked)
nothing happened when you did this, the process would just sit there
forever. There was discussion at one point about doing a tty_hangup()
when the USB device was disconnected (this causes the read() to return
with 0 bytes and future open attempts to fail), and a patch was put out
to do this. I thought this had been merged, but I could be wrong.
I should think that if that works, then your select should be working as
well..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> There was discussion at one point about doing a tty_hangup() when the >
USB device was disconnected (this causes the read() to return with 0 > >
bytes and future open attempts to fail), and a patch was put out to do >
this. I thought this had been merged, but I could be wrong.
Well, I observed the hanging select with SuSE kernel 2.6.8-24.11, so it is
fairly current. I'm seeing this problem with an Option Wireless UMTS data
card. This card is interesting. It is a CardBus card that presents a USB
OHCI hub to the system. Internally it claims to plug in a USB serial
connector. If you issue a RESET AT command, the kernel tells me that the
USB device virtually plugged into the hub got disconnected. A few seconds
later the gets plugged in again. At this point I would have to reopen the
tty. Unfortunately the disconnect event does not propagate to the
application. I could poke the tty to see whether it is still really there,
but this seems quite hackish.
Regards
Joerg
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Robert Hancock wrote:
> I thought this (hangup on remove [jpo]) had been merged, but I could be
> wrong.
I just checked bitkeeper. The patch went in some time ago:
4 months eolson 1.126 usb-serial: add tty_hangup on disconnect
Regards
Joerg
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de