IIO (+ more general?) Error condition handling (e.g. wire fell out errors)

IIO (+ more general?) Error condition handling (e.g. wire fell out errors)

[Jonathan Cameron]

I'm not sure how general this is, hence sent to LKML and IIO.

Some of the devices we have can produce interrupts indicating
that everything has gone horribly wrong. Sometimes this is
also embedded in the main data stream.

The best examples are all the 'wonderful' ways the ad2s1210 resolver
can go wrong.  None of these would be expected to be part of normal
operating conditions.

So, the question is - do we want these to go through our main
events stream?  They are weird and wonderful and often don't
align well with our existing event codes.  Loss of data error
for example (a wire came out).  Others could possibly be made
to fit but that would loose some of the semantics.  Loss of
tracking could be a rate of change threshold event, but it
really is meant to tell you the data could be garbage.

So three options come to mind:

1) Have a magic set of event codes for device class specific
fault events and push through our main event path.  For reference of
non IIO types - that is an anon file descriptor obtained by an
ioctl on the devices chrdev.  Events are a simple timestamp / eventcode
pair.

2)  Add another anon file that you get via an ioctl as a separate
event reporting channel. We then define a big list of error codes
without aiming for any real structure.  Drivers would then need to
document what they can throw out (preferably under sysfs?)

3) Consider these out of band (from the out of band event data)
and look at other options for reporting them.

Is there anything general out there for reporting hardware failures
that would be appropriate?  Sometime these conditions are the sort
of thing that should cause a siren to go off.
They might be sensor failure.... or they might mean you have
a runaway train heading for a station... 

(p.s. I hope no one is using the current driver for trains, though
that might explain British trains...)

Thanks,

Jonathan

Re: IIO (+ more general?) Error condition handling (e.g. wire fell out errors)

[Alan Cox]

> 3) Consider these out of band (from the out of band event data)
> and look at other options for reporting them.

Treat it like a socket/pipe perhaps - if it "goes down" then report it as
having hung up and deliver a SIGPIPE or similar and with an appropriate
error code for those catching it (-EIO ?)

That generally gets noticed.

> Is there anything general out there for reporting hardware failures
> that would be appropriate?  Sometime these conditions are the sort
> of thing that should cause a siren to go off.
> They might be sensor failure

There are two things here - one is making sure the app notices (where we
have equivalent handling in other interfaces) the other is what to do
about it. We don't have a general framework for reporting system
component failure. That's something that ought to get fixed generally to
report everything from "that new nasty smell was formerly your hard disk"
to a sensor fail.

> (p.s. I hope no one is using the current driver for trains, though
> that might explain British trains...)

Tssh... there is Linux on UK trains, but it's usually driving annoying
announcement/video systems.

Alan

Re: IIO (+ more general?) Error condition handling (e.g. wire fell out errors)

[Jonathan Cameron]

Sorry for the slow reply!
>> 3) Consider these out of band (from the out of band event data)
>> and look at other options for reporting them.
> 
> Treat it like a socket/pipe perhaps - if it "goes down" then report it as
> having hung up and deliver a SIGPIPE or similar and with an appropriate
> error code for those catching it (-EIO ?)
I guess that will work.  Feels a little clunky, but such is life.
> 
> That generally gets noticed.
> 
>> Is there anything general out there for reporting hardware failures
>> that would be appropriate?  Sometime these conditions are the sort
>> of thing that should cause a siren to go off.
>> They might be sensor failure
> 
> There are two things here - one is making sure the app notices (where we
> have equivalent handling in other interfaces) the other is what to do
> about it. We don't have a general framework for reporting system
> component failure. That's something that ought to get fixed generally to
> report everything from "that new nasty smell was formerly your hard disk"
> to a sensor fail.
It does seem like that would be useful. 
> 
>> (p.s. I hope no one is using the current driver for trains, though
>> that might explain British trains...)
> 
> Tssh... there is Linux on UK trains, but it's usually driving annoying
> announcement/video systems.
:) Good thing their are no 'this runs Linux' badges on the speakers.
I've nothing against them using Linux, just the driver in question which
is currently 'interesting'.

Thanks,

Jonathan