Re: select(2), usbserial, tty's and disconnect

Re: select(2), usbserial, tty's and disconnect

[Robert Hancock]

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 hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: select(2), usbserial, tty's and disconnect

[Joerg Pommnitz]

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

Re: select(2), usbserial, tty's and disconnect

[Joerg Pommnitz]

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

select(2), usbserial, tty's and disconnect

[Joerg Pommnitz]

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

Re: select(2), usbserial, tty's and disconnect

[linux-os]

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.