I have removed the extra delay in *_reset() for ds2404 alarm compliance.
Only if such a device is found, it's enabled. That will improve response
time with 5ms.
I will see if I can find some more delays to optimize.
/Christian
On Tue, 2005-06-28 at 08:20 -0400, Alfille, Paul H.,M.D. wrote:
This is great. We needed to do this stress-testing for a while now.
It's also amazing how many of these small bugs weren't found when we never
tried
to reconnect.
Next project:
I wonder if we can try upping the serial connection speed for the DS9097U. My
tests indicate serial is slower than USB but uses less CPU time -- suggesting
a
lot of time waiting.
My thought was to slowly up the speed, until bugs appear, them adjust speed
over
time based on recent success. There must be a good algorithm.
Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Christian Magnusson
Sent: Tuesday, June 28, 2005 7:54 AM
To: owfs-developers@lists.sourceforge.net
Subject: RE: [Owfs-developers] More on Hanging Problems
I feel pretty comfortable with the USB reconnection now. I started
owhttpd and made a loop reading some files from an iButton.
owhttpd -p -s 3001
owserver --foreground -u -p 3001 --error_level=1
#!/bin/sh
while [ 1 ]; do
lynx --source http://172.20.1.122:/uncached/ /dev/null
lynx --source http://172.20.1.122:/uncached/02.6537C200/memory
/dev/null
lynx --source
http://172.20.1.122:/uncached/02.6537C200/pages/ident.ALL
/dev/null
echo -n .
done
When I removed one iButton and really tried to simulate bad connection
by moving it around close to the connectors, it failed in the
BUS_select_low() and DS9490_reset() very often. I found some
null-pointer bug when the usb-port was closed, but it reconnects
all the time for me now. Hopefully it works when adapter hangs in other
situations too.
Could Jan test this version and tell us how it works for him...
Some debug-output from owserver:
(adapter reconnects at first attempt)
ERR: USB DS9490 adapter reconnected
(adapter tries to reconnect but fails)
ERR: Error setting up USB DS9490 adapter at 004/002.
ERR: Failed to reconnect USB DS9490 adapter!
ERR: BUS_reconnect, returned error = -5
(at next read it reconnects with success)
ERR: USB DS9490 adapter reconnected
On Tue, 2005-06-28 at 07:31 +0200, Christian Magnusson wrote:
I agree... 3 attempts are perhaps not necessary. If it fails it should
only be necessary to try 1 attempt and then return read-error, since
it's not possible to retry the old on-going operation anyway.
I tried to start owserver to /dev/ttyS0 and then launch minicom on
/dev/ttyS0 too. This will trig the read errors at once since minicom
set the speed to 19200 baud and they will probably grab some chars
each... :)
When minicom exits everything initialize and owserver works again.
I noticed one bug with oldSerialTio on COM_open() which should be
separate for each serial port though.
/Christian
On Mon, 2005-06-27 at 18:40 -0400, Alfille, Paul H.,M.D. wrote:
Nice changes, Christian.
I'm a little worried about burning CPU cycles if the adapter is unplugged.
We
will aggressively try to reconnect.
I notice you make 3 attempts at reconnecting each time. That will be
multiplied
by the 3 attempts ar read/write.
Would there be any harm in a delay before the 2nd and third reconnect
attempt? 1
second? I suppose we could also allow a command line parameter to change
that
value for embedded systems where precisely tuning delays and utilization
is
important. Jan can offer some feedback on this.
Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Christian Magnusson
Sent: Monday, June 27, 2005 7:18 AM
To: owfs-developers@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: Re: [Owfs-developers] More on Hanging Problems
Try the latest cvs again... I have fixed a missing
usb_release_interface() and some other statistics from those errors.
/Christian
On Mon, 2005-06-27 at 11:34 +0200, Jan Kandziora wrote:
Am Montag, 27. Juni 2005 05:26 schrieb Gregg C Levine:
Hello from Gregg C Levine
Paul, explain this phrase in better detail please:
In any case, it's great that Jan has a setup where he can
consistently trigger the errors. In an embedded an environment it is
sometimes considered desirable to stress test the file system by
triggering power cycles. There's an article on that, and the methods
used somewhere on the Linux-MTD site.
What I do isn't stress-testing. That would mean to get parameters when
some
component will probably fail and has to be replaced. That's not what
I'm
after, at least at the moment.
I just ran into that failure - it
