Re: SELECT() returns 1 But FIONREAD says (Input/output error)

Robert Hancock wrote: It's because you haven't done anything to handle the error which is still persisting. Likely the only thing sane you can do in this case is close the fd and try to reopen it later. This seems to be true, but not for what you might think. It appears that if u plug the U

Re: SELECT() returns 1 But FIONREAD says (Input/output error)

David Schwartz wrote: The misunderstanding is from the docs. The select() does not report device errors. Select will just "more precisely, to see if a read will not block". This is a much slighter misunderstanding. The result of the 'select' function tells you nothing about what a particular 'r

Re: SELECT() returns 1 But FIONREAD says (Input/output error)

David Schwartz wrote: David Schwartz wrote: Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code keeps asking the kernel if something interesting has happened, the kernel keeps telling it yes, and it refuses to

Re: SELECT() returns 1 But FIONREAD says (Input/output error)

David Schwartz wrote: In this case what, will reset the "something interesting has happened" report from the SELECT call? Will it ever be reset in this case? Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code

Re: SELECT() returns 1 But FIONREAD says (Input/output error)

David Schwartz wrote: Nope. An errored connection is always ready for read/write -- there is nothing to wait for as far as the kernel is concerned. Your code keeps asking the kernel if something interesting has happened, the kernel keeps telling it yes, and it refuses to do anything about it. T

SELECT() returns 1 But FIONREAD says (Input/output error)

i am using the GARMIN_GPS/usb driver to read a gps receiver. In testing the ability of my software to recover from various errors, I try this: unplug the gps/USB cable from the usb hub. Interestingly enough the thread spins. the SELECT() waits for something to happen, and I get one channel that

Re: slow latencies on IDE disk drives( controller? )

The fix is a lot simpler. It has to be placed in release notes that the generic ide can cause the sound device to distort the sound stream. Would that be a fair statement ? Andre Hedrick wrote: > > > > This is your fix > > Andre Hedrick > - To unsubscribe from this list: send the line "u

Re: slow latencies on IDE disk drives( controller? )

t is given. Is this a PIO/DMA process is it a laptop or > unsupported hardware? > > On Mon, 26 Mar 2001, Uncle George wrote: > > > I am processing sound data on /dev/dsp. Generally the ~61k devive buffer > > is enough to keep the device satiated && gives the program tim

slow latencies on IDE disk drives( controller? )

I am processing sound data on /dev/dsp. Generally the ~61k devive buffer is enough to keep the device satiated && gives the program time to fill up the device buffer when there is 16k of buffer space that needs to be filled. But on occasion the /dev/dsp device "slurrs" ( sounds like what happens

Conversion of float denorm values

in arch/alpha/math-emu/math.c, one needs to disassemble the 32bit float value as 32 bit integer, and not presuppose it to be a 64 bit value with a double mentality. One this change is applied, then my sample test works everywhere. /gat case FOP_FNC_CVTxS: