I have actually also noticed some of those problems too... I have one
of my LCD-displays in my office very close to the lamp-switch, and
sometimes owserver has hanged at the same time as I entered the room
and switched on the lamp and just walked through the room to get a
screwdriver or something else. The 1-wire bus is connected to my uClinux
board in the office too, so I have had those thoughts for some time
that it has to be some connection between the EMC and the 1-wire
bus stability.
I have never needed to remove the power supply to the 1-wire adapter
when the problem has occurred. I have just needed to restart owserver
and I had plans to do this automatically for a long time.
It would be nice if you could look in the /bus.0/statistics/errors
and see where the errors increase when you have problem next time.
(Either from owhttp or owfs and connect to the failing owserver)
When I have had problems, it's usually DS2480_reset_errors which
increase every time I try to read something on the 1-wire bus.
I think it would be safe to add a re-initialization of the 1-wire
adapter when some of those errors occur:
DS2480_reset_errors
DS9097_reset_errors
DS9490_reset_errors
(and perhaps if DS2480_read_timeout is large I think...)
if(DS2480_reset_errors || DS9097_reset_errors || DS9490_reset_errors) {
COM_close(in);
usleep(100000);
COM_open(in);
if ( DS2480_detect(in) ) {
if ( DS9097_detect(in) ) {
ret = -ENODEV;
}
}
}
Something like this would probably be enough to make a reset of the
adapter when the 1-wire bus fails.
On Mon, 2005-06-20 at 22:46 -0400, Paul Alfille wrote:
> On Monday 20 June 2005 04:38 pm, Jan Kandziora wrote:
> > Dear Paul,
> >
> > I've investigated further on the problem I described last week (in the
> > thread "owtcl and writing data").
> >
> > It seems to be related to EMC: Nearly every time I switch on a large
> > 240/24V AC transformer I need for my project, I get a single error of the
> > kind I described. But sometimes, it is even a cascade of such errors, which
> > I can't bring into connection to any action I took (not). Maybe, it was the
> > fluorescent light on last week, but today, I didn't turn them on and still
> > got cascades of such errors (over about 1 minute).
> >
> > Then again, everything is fine for a couple of minutes.
> >
> Is it possible to add shielding?
> > I checked for USB errors with dmesg, and got very few USB disconnects
> > (about 1 of 30 times), but no other USB link layer errors. On the most
> > tries, only the 1-wire seemed to be affected.
> >
> The question is what is the program/port's state after one of these errors.
> It
> seems like there is nor recovery after an error. (i.e., the system doesn't
> work intermittently, only yes or no). If the error causes the USB port to
> close, life is easy.
>
> We can re-open the USB port more easily than a full restart. We don't need to
> enumerate the devices, or resort the internal data structures.
>
> > I tested all this with the tcl script I posted before, and put an
> >
> > OW::finish
> > OW::init usb1
> >
> > into the catch sequence to restart on error. Slow, but worked.
> >
> >
> > As there is little to do against EMC, I would suspect to change the
> > software a way it automatically reinitialize the connections if there is an
> > (until now) unrecoverable error. That leads me to following questions:
> >
> > 1. Is there any way to detect an "unrecoverable" error on bus side?
> > 2. I want to use owserver. You offered to change owserver to restart the
> > connection automatically: How is the development status for this?
> > 3. Is there any way to process the init sequence faster? For USB errors, it
> > would not be so dramatic if it takes 3 to 5 seconds to recover, as I expect
> > them to be very rare. However, the 1-Wire error happens *every time* a big
> > inductive load is switched near the device, so a faster recovery would be a
> > big help.
> >
> Ho do I tell the "1-wire error" from normal failures? (Wrong addresses, bits
> lost, ...)
>
> > Kind regards
> >
> > Jan
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Owfs-developers mailing list
> > Owfs-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
--
Christian Magnusson <[EMAIL PROTECTED]>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
