Re: [Owfs-developers] More on Hanging Problems
Hallo Christian Magnusson, am Donnerstag, 7. Juli 2005 00:17 schriebst du:
Could you try a couple of things...
Does your adapter reconnect if you unplug it manually and then
insert it again?
If you look in owfs/modules/owlib/src/c/ow_ds9490.c, then find following
comment on row 437 or something..
LEVEL_DEFAULT(Found device [%s] on adapter [%s] (want: %s)\n, i);
Change #if 0 to #if 1 just a few lines before that to get some more
info about devices found on the adapter which recently was found.
Changed that, compiled, installed - But I don't get the message in the log.
It seems
/* Do a quick directory listing and find the DS1420 id */
(ret=BUS_select(pn)) || (ret=BUS_first(sn,pn)) ;
while (ret==0) {
#if 1
char id[17];
char id2[17];
bytes2string(id, sn, 8) ;
id[16] = 0;
bytes2string(id2, pn-in-connin.usb.ds1420_address, 8) ;
id2[16] = 0;
LEVEL_DEFAULT(Found device [%s] on adapter [%s] (want: %s)\n, id,
name, id2);
#endif
if(!memcmp(sn, pn-in-connin.usb.ds1420_address, 8)) break;
(ret=BUS_select(pn)) || (ret=BUS_next(sn,pn)) ;
}
does never return (ret==0). What next?
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=7477alloc_id=16492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Can you try this command after you have the problem...
ls -l /proc/`pidof owserver`/fd/
total 5
lrwx-- 1 root root 64 Jul 7 10:54 0 - /dev/pts/13
lrwx-- 1 root root 64 Jul 7 10:54 1 - /dev/pts/13
lrwx-- 1 root root 64 Jul 7 10:54 2 - /dev/pts/13
lrwx-- 1 root root 64 Jul 7 10:54 4 - socket:[4120248]
lrwx-- 1 root root 64 Jul 7 10:54 5 - /proc/bus/usb/004/062
It will show owserver's open file-descriptors to the usb-adapters.
In this case one is open and seem to be working... I was a bit worried
about it since you get an error message when usb_release_interface() is
called according to the output you sent.
If you for some reason have many file-descriptors open to the same
usb-device there are other things to fix for me.
BTW: which kernel do you use?
/Christian
On Thu, 2005-07-07 at 08:58 +0200, Jan Kandziora wrote:
Hallo Christian Magnusson, am Donnerstag, 7. Juli 2005 00:17 schriebst du:
Could you try a couple of things...
Does your adapter reconnect if you unplug it manually and then
insert it again?
If you look in owfs/modules/owlib/src/c/ow_ds9490.c, then find following
comment on row 437 or something..
LEVEL_DEFAULT(Found device [%s] on adapter [%s] (want: %s)\n, i);
Change #if 0 to #if 1 just a few lines before that to get some more
info about devices found on the adapter which recently was found.
Changed that, compiled, installed - But I don't get the message in the log.
It seems
/* Do a quick directory listing and find the DS1420 id */
(ret=BUS_select(pn)) || (ret=BUS_first(sn,pn)) ;
while (ret==0) {
#if 1
char id[17];
char id2[17];
bytes2string(id, sn, 8) ;
id[16] = 0;
bytes2string(id2, pn-in-connin.usb.ds1420_address, 8) ;
id2[16] = 0;
LEVEL_DEFAULT(Found device [%s] on adapter [%s] (want: %s)\n, id,
name, id2);
#endif
if(!memcmp(sn, pn-in-connin.usb.ds1420_address, 8)) break;
(ret=BUS_select(pn)) || (ret=BUS_next(sn,pn)) ;
}
does never return (ret==0). What next?
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=7477alloc_id=16492op=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=7477alloc_id=16492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Am Donnerstag, 30. Juni 2005 15:41 schrieb Christian Magnusson: Have you succeeded to use the latest cvs-version yet? Just wondering... Now I had the time to test a bit. I have to say: unfortunately not. $ /opt/owfs/bin/owserver -u1 -p19160 --foreground --error_level=9 ... INFO: PARSENAME path=12.86973600/PIO.A INFO: PARSENAME path=12.86973600/PIO.A INFO: PARSENAME path=12.86973600/PIO.A ... Now doing something naughty ... ERR: Release interface failed ret=-19 : No such device ERR: Closed USB DS9490 adapter at 001/002. ret=0 : No such device ERR: Opened USB DS9490 adapter at 001/004. : Permission denied ERR: Couldn't find correct ds1420 chip on this adapter [001/004] : Resource temporarily unavailable ERR: Closed USB DS9490 adapter at 001/002. ret=0 : Resource temporarily unavailable ERR: BUS_selection_error returned error = -5 : Resource temporarily unavailable INFO: PARSENAME path=12.86973600/PIO.A ERR: Opened USB DS9490 adapter at 001/004. : No data available ERR: Couldn't find correct ds1420 chip on this adapter [001/004] : Resource temporarily unavailable ERR: Closed USB DS9490 adapter at 001/002. ret=0 : Resource temporarily unavailable ERR: Opened USB DS9490 adapter at 001/004. : No data available ERR: Couldn't find correct ds1420 chip on this adapter [001/004] : Resource temporarily unavailable ERR: Closed USB DS9490 adapter at 001/002. ret=0 : Resource temporarily unavailable ERR: BUS_selection_error returned error = -5 : Resource temporarily unavailable INFO: PARSENAME path=12.86973600/PIO.A ERR: Opened USB DS9490 adapter at 001/004. : No data available ERR: Couldn't find correct ds1420 chip on this adapter [001/004] : Resource temporarily unavailable ERR: Closed USB DS9490 adapter at 001/002. ret=0 : Resource temporarily unavailable ERR: Opened USB DS9490 adapter at 001/004. : No data available ERR: Couldn't find correct ds1420 chip on this adapter [001/004] : Resource temporarily unavailable ERR: Closed USB DS9490 adapter at 001/002. ret=0 : Resource temporarily unavailable ERR: BUS_selection_error returned error = -5 : Resource temporarily unavailable INFO: PARSENAME path=12.86973600/PIO.A $ dmesg says usb 1-1: USB disconnect, address 2 usb 1-1: new full speed USB device using uhci_hcd and address 4 0: addr=81, size=32, dir=IN, type=3 1: addr=2, size=16, dir=OUT, type=2 2: addr=83, size=16, dir=IN, type=2 I'd say, we are on the right way but there is some little thing wrong. Which? 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
Hi again, Even my friend Thomas who use owfs and temploggerd had an enumerated USB adapter 2 days ago, and he doesn't have any light switches or anything else close to the adapter. I think I finally have solved the problem now. I made some updates at work on a Fedora core 4 with a 2.6.11 kernel. It worked pretty good, but when I tested the code on my server at home with 2.4.22 I had some hard USB errors and even some kernel panics. It seems like it's impossible to handle an usb-device with timeouts and read-errors in a good way, so I have to close the usb-handle and re-open it every time I get some communication problem. It doesn't take much time at all, but it's not necessary to do that on the 2.6.11 kernel. If the adapter couldn't be found, then owfs will continue with scanning the usb-bus every time until it's found again. Anyway, the code need some more cleanup, but it works very good on my two servers now You can disconnect a device and plugin it somewhere else if you want, and it will be reconnected and used like before. The 81 or 01 device is saved as a unique identifier to the adapter. If those aren't found (if user have a single DS2490 chip), the last found 1-wire device is saved as an identifier. /Christian On Fri, 2005-07-01 at 17:50, Alfille, Paul H.,M.D. wrote: This works for newer DS9490s, the older ones used an 01 device. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christian Magnusson Sent: Friday, July 01, 2005 5:26 AM To: owfs-developers@lists.sourceforge.net Cc: Paul Alfille; [EMAIL PROTECTED] Subject: Re: [Owfs-developers] More on Hanging Problems I have done some testing with it, and have managed to reconnect the adapter even if it's unplugged manually. It's perhaps not a very nice solution, but it works at least. Right now it detects the 1-wire adapters as usual at startup. At the first 1-wire scan, the serial number of the ds1420 chip (81.00) is saved in the connin.usb struct. If the adapter fails at *_reset(), owserver tries to close the usb-handle, and reopen it as I did before (it solves most situations). If it's not possible to reopen the usb device, then I assume the USB adapter is unplugged (manually or by some EMP problem). It will then do a full usb device-scan (which is done at startup). If an USB adapter is found, I make a 1-wire scan on it. If the 1-wire device 81.00 is found, I use this usb-adapter in the future. It works even if you unplug it and reconnect it to some other usb-hub. It works pretty good for me, and I assume it will solve your problem too when it's a small glitch and the kernel thinks it's disconnected. I will cleanup the source and checkin the changes during the day. It will be nice to hear if it works for you too after that. Paul, do you have any comments about it? /Christian --- 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Am Donnerstag, 30. Juni 2005 21:56 schrieb Christian Magnusson: You are right... The kernel thinks the usb adapter is physically removed and then inserted again and get a new device number. This problem is very fatal and question is if such thing should be handled by owfs. Hm. owserver does handle the whole 1-Wire tunneling. If it could not handle exceptional situations, like network breakdown, by itself it has very few benefits to use it. In that case, I would have to implement a secondary client-server-connection, which detects at least the errors correctly. In such a setup, owserver is no longer needed because my connection could transfer the 1-Wire data, too. It could of course be added to detect a new 1-wire adapter if it disappears, but strange things can happen. Does this apply if the hardware of the machine is not touched? Have you heard about any printer or scanner driver which solve the issue of a disconnected device? That's a different world: home or small office appliances are known to fail often, most times beyond repair. That's totally different from a commercial or industrial automation environment, where anthing must work as long as possible and any error that could be recovered from automatically must be recovered automatically. And sure, I can think of a driver which recovers from failures itself: TCP. I think it's best to solve this issue inside owserver. It is a network component and networks fail if someone pulls the cable. BTW: A backup ethernet connection for owserver is something to think of - I don't need it for now, but this is really hot in high-available automation environments. Let say you have 2 DS9490 adapters. (Called A B) Start: owfs -p19160 -u /var/1wire /var/1wire/system/adapter/name.0 = DS9490 (The first found adapter A) If adapter A get a hard error (like you) or is physically removed and inserted, the second adapter B will easily replace the first adapter which disappeared. It's perhaps possible to solve in some way, but I hope you understand this issue I see as a problem. What miserably fails in that situation? From the owfs point of view, it's totally indifferent on which adapter a chip connects - they are all put into one directory tree. The only situation I can think of this as a problem is with several owservers, where each one connects to a different adapter, and the chips keep seperated all up the line, even in the applications - and that's a setup which hardly anybody would use. My usb-adapter have a unique id 81.01010101010101 which could be used to find the same adapter when re-connected, but does every adapter have a unique id? I thought there where old adapters without this feature... The passive ones don't have. But it's only a small problem anyway, as the passive adapters won't get you into USB disconnect troubles. Kind regards Jan -- Where do you want Bill Gates to go today? --- 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
I have done some testing with it, and have managed to reconnect the adapter even if it's unplugged manually. It's perhaps not a very nice solution, but it works at least. Right now it detects the 1-wire adapters as usual at startup. At the first 1-wire scan, the serial number of the ds1420 chip (81.00) is saved in the connin.usb struct. If the adapter fails at *_reset(), owserver tries to close the usb-handle, and reopen it as I did before (it solves most situations). If it's not possible to reopen the usb device, then I assume the USB adapter is unplugged (manually or by some EMP problem). It will then do a full usb device-scan (which is done at startup). If an USB adapter is found, I make a 1-wire scan on it. If the 1-wire device 81.00 is found, I use this usb-adapter in the future. It works even if you unplug it and reconnect it to some other usb-hub. It works pretty good for me, and I assume it will solve your problem too when it's a small glitch and the kernel thinks it's disconnected. I will cleanup the source and checkin the changes during the day. It will be nice to hear if it works for you too after that. Paul, do you have any comments about it? /Christian On Fri, 2005-07-01 at 09:06 +0200, Jan Kandziora wrote: Am Donnerstag, 30. Juni 2005 21:56 schrieb Christian Magnusson: You are right... The kernel thinks the usb adapter is physically removed and then inserted again and get a new device number. This problem is very fatal and question is if such thing should be handled by owfs. Hm. owserver does handle the whole 1-Wire tunneling. If it could not handle exceptional situations, like network breakdown, by itself it has very few benefits to use it. In that case, I would have to implement a secondary client-server-connection, which detects at least the errors correctly. In such a setup, owserver is no longer needed because my connection could transfer the 1-Wire data, too. It could of course be added to detect a new 1-wire adapter if it disappears, but strange things can happen. Does this apply if the hardware of the machine is not touched? Have you heard about any printer or scanner driver which solve the issue of a disconnected device? That's a different world: home or small office appliances are known to fail often, most times beyond repair. That's totally different from a commercial or industrial automation environment, where anthing must work as long as possible and any error that could be recovered from automatically must be recovered automatically. And sure, I can think of a driver which recovers from failures itself: TCP. I think it's best to solve this issue inside owserver. It is a network component and networks fail if someone pulls the cable. BTW: A backup ethernet connection for owserver is something to think of - I don't need it for now, but this is really hot in high-available automation environments. Let say you have 2 DS9490 adapters. (Called A B) Start: owfs -p19160 -u /var/1wire /var/1wire/system/adapter/name.0 = DS9490 (The first found adapter A) If adapter A get a hard error (like you) or is physically removed and inserted, the second adapter B will easily replace the first adapter which disappeared. It's perhaps possible to solve in some way, but I hope you understand this issue I see as a problem. What miserably fails in that situation? From the owfs point of view, it's totally indifferent on which adapter a chip connects - they are all put into one directory tree. The only situation I can think of this as a problem is with several owservers, where each one connects to a different adapter, and the chips keep seperated all up the line, even in the applications - and that's a setup which hardly anybody would use. My usb-adapter have a unique id 81.01010101010101 which could be used to find the same adapter when re-connected, but does every adapter have a unique id? I thought there where old adapters without this feature... The passive ones don't have. But it's only a small problem anyway, as the passive adapters won't get you into USB disconnect troubles. Kind regards Jan -- 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
This works for newer DS9490s, the older ones used an 01 device. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christian Magnusson Sent: Friday, July 01, 2005 5:26 AM To: owfs-developers@lists.sourceforge.net Cc: Paul Alfille; [EMAIL PROTECTED] Subject: Re: [Owfs-developers] More on Hanging Problems I have done some testing with it, and have managed to reconnect the adapter even if it's unplugged manually. It's perhaps not a very nice solution, but it works at least. Right now it detects the 1-wire adapters as usual at startup. At the first 1-wire scan, the serial number of the ds1420 chip (81.00) is saved in the connin.usb struct. If the adapter fails at *_reset(), owserver tries to close the usb-handle, and reopen it as I did before (it solves most situations). If it's not possible to reopen the usb device, then I assume the USB adapter is unplugged (manually or by some EMP problem). It will then do a full usb device-scan (which is done at startup). If an USB adapter is found, I make a 1-wire scan on it. If the 1-wire device 81.00 is found, I use this usb-adapter in the future. It works even if you unplug it and reconnect it to some other usb-hub. It works pretty good for me, and I assume it will solve your problem too when it's a small glitch and the kernel thinks it's disconnected. I will cleanup the source and checkin the changes during the day. It will be nice to hear if it works for you too after that. Paul, do you have any comments about it? /Christian On Fri, 2005-07-01 at 09:06 +0200, Jan Kandziora wrote: Am Donnerstag, 30. Juni 2005 21:56 schrieb Christian Magnusson: You are right... The kernel thinks the usb adapter is physically removed and then inserted again and get a new device number. This problem is very fatal and question is if such thing should be handled by owfs. Hm. owserver does handle the whole 1-Wire tunneling. If it could not handle exceptional situations, like network breakdown, by itself it has very few benefits to use it. In that case, I would have to implement a secondary client-server-connection, which detects at least the errors correctly. In such a setup, owserver is no longer needed because my connection could transfer the 1-Wire data, too. It could of course be added to detect a new 1-wire adapter if it disappears, but strange things can happen. Does this apply if the hardware of the machine is not touched? Have you heard about any printer or scanner driver which solve the issue of a disconnected device? That's a different world: home or small office appliances are known to fail often, most times beyond repair. That's totally different from a commercial or industrial automation environment, where anthing must work as long as possible and any error that could be recovered from automatically must be recovered automatically. And sure, I can think of a driver which recovers from failures itself: TCP. I think it's best to solve this issue inside owserver. It is a network component and networks fail if someone pulls the cable. BTW: A backup ethernet connection for owserver is something to think of - I don't need it for now, but this is really hot in high-available automation environments. Let say you have 2 DS9490 adapters. (Called A B) Start: owfs -p19160 -u /var/1wire /var/1wire/system/adapter/name.0 = DS9490 (The first found adapter A) If adapter A get a hard error (like you) or is physically removed and inserted, the second adapter B will easily replace the first adapter which disappeared. It's perhaps possible to solve in some way, but I hope you understand this issue I see as a problem. What miserably fails in that situation? From the owfs point of view, it's totally indifferent on which adapter a chip connects - they are all put into one directory tree. The only situation I can think of this as a problem is with several owservers, where each one connects to a different adapter, and the chips keep seperated all up the line, even in the applications - and that's a setup which hardly anybody would use. My usb-adapter have a unique id 81.01010101010101 which could be used to find the same adapter when re-connected, but does every adapter have a unique id? I thought there where old adapters without this feature... The passive ones don't have. But it's only a small problem anyway, as the passive adapters won't get you into USB disconnect troubles. Kind regards Jan -- 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=7477alloc_id=16492op=click
Re: [Owfs-developers] More on Hanging Problems
Have you succeeded to use the latest cvs-version yet? Just wondering... /Christian On Tue, 2005-06-28 at 16:21 +0200, Jan Kandziora wrote: Am Dienstag, 28. Juni 2005 13:54 schrieb Christian Magnusson: 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... Yes, I will do so in the evening and tell you the result. 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=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Am Montag, 27. Juni 2005 13:17 schrieb Christian Magnusson:
Try the latest cvs again... I have fixed a missing
usb_release_interface() and some other statistics from those errors.
/Christian
Sorry for the delay. I had my business partners here, which messed up things a lot.
I've done some testing with the owfs-2005-06-29.tar.gz daily configured package. Again, no luck. I've done
$ /opt/owfs/bin/owserver -p19160 -u1 --foreground --error_level 9
and started the owtcl test skript:
package require ow
OW::init localhost:19160
set DEVICES [ OW::get ]
set DEVICE [ lindex $DEVICES [ lsearch -glob $DEVICES {12.*} ] ]
puts $DEVICE
set STATE 0
for { set I 0 } { 1 } { incr I } \
{
set STATE [ expr 1-$STATE ]
puts $I: OW::put ${DEVICE}PIO.A $STATE
if [ catch { OW::put ${DEVICE}PIO.A $STATE } message ] \
{
puts $message
puts $errorCode
puts $errorInfo
}
after 500
}
The log of owserver:
INFO: PARSENAME path=(null)
: Success
ERR: Opened USB DS9490 adapter at 001/016.
: Permission denied
INFO: PARSENAME path=
: Success
INFO: PARSENAME path=/12.86973600
: Success
INFO: PARSENAME path=/12.15973600
: Success
INFO: PARSENAME path=/81.198C2400
: Success
INFO: PARSENAME path=12.86973600/PIO.A
: Success
The last two lines continue with every switch of PIO.A
Then I turned the mains switch, and got log lines like this:
ERR: Closed USB DS9490 adapter at 001/016.
: Protocol error
ERR: Failed to configure/claim interface on USB DS9490 adapter at 001/016.
: Protocol error
ERR: Failed to reconnect USB DS9490 adapter!
: Protocol error
ERR: BUS_reconnect, returned error = -5
: Protocol error
INFO: PARSENAME path=12.86973600/PIO.A
: Success
ERR: Failed to open USB DS9490 adapter at 001/016.
: Permission denied
ERR: Failed to reconnect USB DS9490 adapter!
: Permission denied
ERR: Failed to open USB DS9490 adapter at 001/016.
: Permission denied
ERR: Failed to reconnect USB DS9490 adapter!
: Permission denied
ERR: BUS_reconnect, returned error = -5
: Permission denied
INFO: PARSENAME path=12.86973600/PIO.A
: Success
The last block has been printed again with every attempt to switch PIO.A.
In the meantime, I got from dmesg USB error messages like this:
usb 1-1: new full speed USB device using uhci_hcd and address 15
0: addr=81, size=32, dir=IN, type=3
1: addr=2, size=16, dir=OUT, type=2
2: addr=83, size=16, dir=IN, type=2
usb 1-1: USB disconnect, address 15
usb 1-1: new full speed USB device using uhci_hcd and address 16
0: addr=81, size=32, dir=IN, type=3
1: addr=2, size=16, dir=OUT, type=2
2: addr=83, size=16, dir=IN, type=2
usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd owserver rqt 64 rq 2 len 0 ret -71
usb 1-1: USB disconnect, address 16
usb 1-1: new full speed USB device using uhci_hcd and address 17
0: addr=81, size=32, dir=IN, type=3
1: addr=2, size=16, dir=OUT, type=2
2: addr=83, size=16, dir=IN, type=2
I think the problem is the usb adapter gets enumerated automatically, and gets address 17 instead of 16, so it can't be found by the reconnect function.
Hope that helps.
Jan
--
I'm not a programmer, but I play one at Microsoft.
Re: [Owfs-developers] More on Hanging Problems
You are right... The kernel thinks the usb adapter is physically
removed and then inserted again and get a new device number.
This problem is very fatal and question is if such thing should
be handled by owfs. It could of course be added to detect a new
1-wire adapter if it disappears, but strange things can happen.
Have you heard about any printer or scanner driver which solve the
issue of a disconnected device?
Let say you have 2 DS9490 adapters. (Called A B)
Start: owfs -p19160 -u /var/1wire
/var/1wire/system/adapter/name.0 = DS9490 (The first found adapter A)
If adapter A get a hard error (like you) or is physically removed and
inserted, the second adapter B will easily replace the first adapter
which disappeared. It's perhaps possible to solve in some way, but I
hope you understand this issue I see as a problem.
My usb-adapter have a unique id 81.01010101010101 which could be used to
find the same adapter when re-connected, but does every adapter have
a unique id? I thought there where old adapters without this feature...
Paul, do you have any idea how to solve it in a good way?
/Christian
On Thu, 2005-06-30 at 20:26, Jan Kandziora wrote:
Am Montag, 27. Juni 2005 13:17 schrieb Christian Magnusson:
Try the latest cvs again... I have fixed a missing
usb_release_interface() and some other statistics from those errors.
/Christian
Sorry for the delay. I had my business partners here, which messed up
things a lot.
I've done some testing with the owfs-2005-06-29.tar.gz daily
configured package. Again, no luck. I've done
$ /opt/owfs/bin/owserver -p19160 -u1 --foreground --error_level 9
and started the owtcl test skript:
package require ow
OW::init localhost:19160
set DEVICES [ OW::get ]
set DEVICE [ lindex $DEVICES [ lsearch -glob $DEVICES {12.*} ] ]
puts $DEVICE
set STATE 0
for { set I 0 } { 1 } { incr I } \
{
set STATE [ expr 1-$STATE ]
puts $I: OW::put ${DEVICE}PIO.A $STATE
if [ catch { OW::put ${DEVICE}PIO.A $STATE } message ] \
{
puts $message
puts $errorCode
puts $errorInfo
}
after 500
}
The log of owserver:
INFO: PARSENAME path=(null)
: Success
ERR: Opened USB DS9490 adapter at 001/016.
: Permission denied
INFO: PARSENAME path=
: Success
INFO: PARSENAME path=/12.86973600
: Success
INFO: PARSENAME path=/12.15973600
: Success
INFO: PARSENAME path=/81.198C2400
: Success
INFO: PARSENAME path=12.86973600/PIO.A
: Success
The last two lines continue with every switch of PIO.A
Then I turned the mains switch, and got log lines like this:
ERR: Closed USB DS9490 adapter at 001/016.
: Protocol error
ERR: Failed to configure/claim interface on USB DS9490 adapter at
001/016.
: Protocol error
ERR: Failed to reconnect USB DS9490 adapter!
: Protocol error
ERR: BUS_reconnect, returned error = -5
: Protocol error
INFO: PARSENAME path=12.86973600/PIO.A
: Success
ERR: Failed to open USB DS9490 adapter at 001/016.
: Permission denied
ERR: Failed to reconnect USB DS9490 adapter!
: Permission denied
ERR: Failed to open USB DS9490 adapter at 001/016.
: Permission denied
ERR: Failed to reconnect USB DS9490 adapter!
: Permission denied
ERR: BUS_reconnect, returned error = -5
: Permission denied
INFO: PARSENAME path=12.86973600/PIO.A
: Success
The last block has been printed again with every attempt to switch
PIO.A.
In the meantime, I got from dmesg USB error messages like this:
usb 1-1: new full speed USB device using uhci_hcd and address 15
0: addr=81, size=32, dir=IN, type=3
1: addr=2, size=16, dir=OUT, type=2
2: addr=83, size=16, dir=IN, type=2
usb 1-1: USB disconnect, address 15
usb 1-1: new full speed USB device using uhci_hcd and address 16
0: addr=81, size=32, dir=IN, type=3
1: addr=2, size=16, dir=OUT, type=2
2: addr=83, size=16, dir=IN, type=2
usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd owserver rqt 64 rq 2 len 0
ret -71
usb 1-1: USB disconnect, address 16
usb 1-1: new full speed USB device using uhci_hcd and address 17
0: addr=81, size=32, dir=IN, type=3
1: addr=2, size=16, dir=OUT, type=2
2: addr=83, size=16, dir=IN, type=2
I think the problem is the usb adapter gets enumerated automatically,
and gets address 17 instead of 16, so it can't be found by the
reconnect function.
Hope that helps.
Jan
--
I'm not a programmer, but I play one at Microsoft.
---
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=7477alloc_id=16492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
RE: [Owfs-developers] More on Hanging Problems
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
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 makes 1-wire completely unusable for my application. Now I can see for myself how a rigged system would be desirable for stress testing the file system that we've created. But a detailed explanation would be good thing. Jan, what are you running? Which distribution? What is the hardware configuration? I walked into this meeting late, and left my agenda and most of my notes in a different location. I'm designing a semiautomatic vending machine with a lot of attached devices (flow-rate sensors and solenoid driven valves), most of them in a ten-meter range around the machine, but some of them about 100m far away. The computer which will be built into this will be a MIPS based embedded board, which isn't completed yet. The computer I use to test is a Gene6310 embedded (more like barebone) PC board. Its i386-family based. This computer is working and would be used as a backup solution, if the MIPS board is not completed in time. I have a testbench, where I can arrange the devices like they were already put into that vending machine. I hooked up the 1-wire to USB via
RE: [Owfs-developers] More on Hanging Problems
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 makes 1-wire completely unusable for my application. Now I can see for myself how a rigged system would be desirable for stress testing the file system that we've created. But a detailed explanation would be good thing. Jan, what are you running? Which distribution? What is the hardware configuration? I walked into this meeting late, and left my agenda and most of my notes in a different location. I'm
RE: [Owfs-developers] More on Hanging Problems
I noticed there were a missing usb_release_interface() before trying to reconnect. That was probably why it didn't work as you wanted. It could never claim the interface without this missing call. BTW: Do you mind if I add a semi-colon to all lock function-calls like STATLOCK, STATUNLOCK etc. It screw up my emacs-indent and I think it looks much cleaner if there are an ending semi-colon too... :) I will checkin some changes within a few minutes and this should work much better I hope.. :) /Christian On Sun, 2005-06-26 at 20:39 -0400, Alfille, Paul H.,M.D. wrote: Actually, Jan says it didn't help. My next attempt will be to re-enumerate as part of the reconnect -- Apparently the old USB device structure pointer doesn't work. Things get a little more complicated if more than one USB adapter is used. We can reconnect, but the order may have changed. In any case, it's great that Jan has a setup where he can consistently trigger the errors. Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christian Magnusson Sent: Sunday, June 26, 2005 4:31 PM To: owfs-developers Subject: Re: [Owfs-developers] More on Hanging Problems This seem to be a god idea... Perhaps a debug counter should be there to show how many reconnects there have been too. I'll try to add the reconnect-code for the serial adapter tomorrow if I get some spare time at work. /Christian On Sun, 2005-06-26 at 06:27, Paul Alfille wrote: On Saturday 25 June 2005 04:32 am, Jan Kandziora wrote: Am Samstag, 25. Juni 2005 05:50 schrieb Paul Alfille: Your logs show mainly BUS_select_low_errors increasing. And DS... errors. But I think that's just a summary, am I right? Unfortunately there are 5 places in file ow_bus.c function BUS_select_low where that variable is incremented. I've added some (temporary) printf's to run the program in foreground and flip the garbalizer. Ok, I've attempted a fix. We now have a reconnect method for each adapter (ony the USB is really implemented). If there is an error of the type you've been finding, the USB adapter is closed and reopened and reinitialized. I hop it works. Give it a try. Paul --- 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=7477alloc_id=16492op=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=7477alloc_id=16492op=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_idt77alloc_id492opÌk ___ 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_idt77alloc_id492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
I think most of us have seen the occasional failures from these EMC effects, but without your setup and observations it would be hard to hunt down. Again, thank you. Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jan Kandziora Sent: Monday, June 27, 2005 5:35 AM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] More on Hanging Problems 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 makes 1-wire completely unusable for my application. Now I can see for myself how a rigged system would be desirable for stress testing the file system that we've created. But a detailed explanation would be good thing. Jan, what are you running? Which distribution? What is the hardware configuration? I walked into this meeting late, and left my agenda and most of my notes in a different location. I'm designing a semiautomatic vending machine with a lot of attached devices (flow-rate sensors and solenoid driven valves), most of them in a ten-meter range around the machine, but some of them about 100m far away. The computer which will be built into this will be a MIPS based embedded board, which isn't completed yet. The computer I use to test is a Gene6310 embedded (more like barebone) PC board. Its i386-family based. This computer is working and would be used as a backup solution, if the MIPS board is not completed in time. I have a testbench, where I can arrange the devices like they were already put into that vending machine. I hooked up the 1-wire to USB via a off-the-shelf DS9490 adapter to the barebone. There is a mains transformer 230/24V~ 150W (completely passive, not a switching one), which is the power supply for the sensors and solenoids. The actual transformer for the machine will be a 400W type, which makes things even worse. This mains transformer generates some kind of EMC when switching it ON or OFF with an ordinary 230V switch. This is understandable if the switching happens outside of the zero-cross of voltage (ON-switching) or current (OFF- switching). The EMC pulse causes either the USB or the 1-wire (or both) to disconnect - which leads owfs into an unusable state. I'm pretty sure I can minimize this EMC by putting a zero-cross and snubbing circuit into my transformer - but I'm very unsure other appliances in the pub or gas station where the vending machines will be mounted are so kind. That's why I think we have to be able to recover from this error automatically. Kind regards Jan -- There's light at the other end of the the Windows. --- 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=7477alloc_id=16492op=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_idt77alloc_id492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
I was wondering about that. I've been making changes and sending a tar-ball of the source to Jan for testing. The semicolon sounds like a good idea. My indents are also screwed up. Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christian Magnusson Sent: Monday, June 27, 2005 6:20 AM To: owfs-developers@lists.sourceforge.net Subject: RE: [Owfs-developers] More on Hanging Problems I noticed there were a missing usb_release_interface() before trying to reconnect. That was probably why it didn't work as you wanted. It could never claim the interface without this missing call. BTW: Do you mind if I add a semi-colon to all lock function-calls like STATLOCK, STATUNLOCK etc. It screw up my emacs-indent and I think it looks much cleaner if there are an ending semi-colon too... :) I will checkin some changes within a few minutes and this should work much better I hope.. :) /Christian On Sun, 2005-06-26 at 20:39 -0400, Alfille, Paul H.,M.D. wrote: Actually, Jan says it didn't help. My next attempt will be to re-enumerate as part of the reconnect -- Apparently the old USB device structure pointer doesn't work. Things get a little more complicated if more than one USB adapter is used. We can reconnect, but the order may have changed. In any case, it's great that Jan has a setup where he can consistently trigger the errors. Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christian Magnusson Sent: Sunday, June 26, 2005 4:31 PM To: owfs-developers Subject: Re: [Owfs-developers] More on Hanging Problems This seem to be a god idea... Perhaps a debug counter should be there to show how many reconnects there have been too. I'll try to add the reconnect-code for the serial adapter tomorrow if I get some spare time at work. /Christian On Sun, 2005-06-26 at 06:27, Paul Alfille wrote: On Saturday 25 June 2005 04:32 am, Jan Kandziora wrote: Am Samstag, 25. Juni 2005 05:50 schrieb Paul Alfille: Your logs show mainly BUS_select_low_errors increasing. And DS... errors. But I think that's just a summary, am I right? Unfortunately there are 5 places in file ow_bus.c function BUS_select_low where that variable is incremented. I've added some (temporary) printf's to run the program in foreground and flip the garbalizer. Ok, I've attempted a fix. We now have a reconnect method for each adapter (ony the USB is really implemented). If there is an error of the type you've been finding, the USB adapter is closed and reopened and reinitialized. I hop it works. Give it a try. Paul --- 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=7477alloc_id=16492op=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=7477alloc_id=16492op=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_idt77alloc_id492opÌk ___ 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_idt77alloc_id492op=ick ___ 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
RE: [Owfs-developers] More on Hanging Problems
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 makes 1-wire completely unusable for my application. Now I can see for myself how a rigged system would be desirable for stress testing the file system that we've created. But a detailed explanation would be good thing. Jan, what are you running? Which distribution? What is the hardware configuration? I walked into this meeting late, and left my agenda and most of my notes in a different location. I'm designing a semiautomatic vending machine with a lot of attached devices (flow-rate sensors and solenoid driven valves), most of them in a ten-meter range around the machine, but some of them about 100m far away. The computer which will be built into this will be a MIPS based embedded board, which isn't completed yet. The computer I use to test is a Gene6310 embedded (more like barebone) PC board. Its i386-family based. This computer is working and would be used as a backup solution, if the MIPS board is not completed in time. I have a testbench, where I can arrange the devices like they were already put into that vending machine. I hooked up the 1-wire to USB via a off-the-shelf DS9490 adapter to the barebone. There is a mains transformer 230/24V~ 150W (completely passive, not a switching one), which is the power supply for the sensors and solenoids. The actual transformer for the machine will be a 400W type, which makes things even worse. This mains transformer generates some kind of EMC when switching it ON or OFF with an ordinary 230V switch. This is understandable if the switching happens outside of the zero-cross of voltage (ON-switching) or current (OFF- switching). The EMC pulse causes either the USB or the 1-wire (or both) to disconnect - which leads owfs into an unusable state. I'm pretty sure I can minimize this EMC by putting a zero-cross and snubbing circuit into my transformer - but I'm very unsure other appliances in the pub or gas station where the vending machines will be mounted are so kind. That's why I think we have to be able to recover from this error automatically. Kind regards Jan -- 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=7477alloc_id=16492op=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_idt77alloc_id492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
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 makes 1-wire completely unusable for my application. Now I can see for myself how a rigged system would be desirable for stress testing the file system that we've created. But a detailed explanation would be good thing. Jan, what are you running? Which distribution? What is the hardware configuration? I walked into this meeting late, and left my agenda and most of my notes in a different location. I'm designing a semiautomatic vending machine with a lot of attached devices (flow-rate sensors and solenoid driven valves), most of them in a ten-meter range around the machine, but some of them about 100m far away. The computer which will be built into this will be a MIPS based embedded board, which isn't completed yet. The computer I use to test is a Gene6310 embedded (more like barebone) PC board. Its i386-family based. This computer is working and would be used as a backup solution, if the MIPS board is not completed in time. I have a testbench, where I can arrange the devices like they were already put into that vending machine. I hooked up the 1-wire to USB via a off-the-shelf DS9490 adapter to the barebone. There is a mains transformer 230/24V~ 150W (completely passive, not a switching one), which is the power supply for the sensors and solenoids. The actual transformer for the machine will be a 400W type, which makes things even worse. This mains transformer generates some kind of EMC when switching it ON or OFF with an ordinary 230V switch. This is understandable if the switching happens outside of the zero-cross of voltage (ON-switching) or current (OFF- switching). The EMC pulse causes either the USB or the 1-wire (or both) to disconnect - which leads owfs into an unusable state. I'm pretty sure I can minimize this EMC by putting a zero-cross and snubbing circuit into my transformer - but I'm very unsure other appliances in the pub or gas station where the vending machines will be mounted are so kind. That's why I think we have to be able to recover from this error automatically. Kind regards Jan -- 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=7477alloc_id=16492op=click
Re: [Owfs-developers] More on Hanging Problems
Am Samstag, 25. Juni 2005 05:50 schrieb Paul Alfille: Your logs show mainly BUS_select_low_errors increasing. And DS... errors. But I think that's just a summary, am I right? Unfortunately there are 5 places in file ow_bus.c function BUS_select_low where that variable is incremented. I've added some (temporary) printf's to run the program in foreground and flip the garbalizer. Can you pull from the latest CVS and try it out? Is the nightly build OK? Otherwise I have to configure a cvs client first. 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
On Saturday 25 June 2005 04:32 am, Jan Kandziora wrote: Am Samstag, 25. Juni 2005 05:50 schrieb Paul Alfille: Your logs show mainly BUS_select_low_errors increasing. And DS... errors. But I think that's just a summary, am I right? Probably. Unfortunately there are 5 places in file ow_bus.c function BUS_select_low where that variable is incremented. I've added some (temporary) printf's to run the program in foreground and flip the garbalizer. Can you pull from the latest CVS and try it out? Is the nightly build OK? Otherwise I have to configure a cvs client first. Sure, though the timing is unclear. I sent you the file directly. 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=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
On Saturday 25 June 2005 04:32 am, Jan Kandziora wrote: Am Samstag, 25. Juni 2005 05:50 schrieb Paul Alfille: Your logs show mainly BUS_select_low_errors increasing. And DS... errors. But I think that's just a summary, am I right? Unfortunately there are 5 places in file ow_bus.c function BUS_select_low where that variable is incremented. I've added some (temporary) printf's to run the program in foreground and flip the garbalizer. Ok, I've attempted a fix. We now have a reconnect method for each adapter (ony the USB is really implemented). If there is an error of the type you've been finding, the USB adapter is closed and reopened and reinitialized. I hop it works. Give it a try. Paul --- 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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Am Dienstag, 21. Juni 2005 13:18 schrieb Alfille, Paul H.,M.D.:
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(10);
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.
--
This would work, but there may be a more efficient DS9490_detect, I made
room for the USB device handle in connection_in
in-connin.usb.dev so we can break out the internal part of DS9490_detect
and save re-enumerating the entire USB bus.
Perhaps a fallback of re-enumerating if the simpler routine fails.
Paul
In the meanwhile, I made some logs of the statistics/errors directory:
init.log: Directly after owfs -u1 mnt/1wire
ok1.log: After starting and stopping test.sh
ok2.log: After starting and stopping test.sh again.
So far, no errors. Now the critical ones:
on1.log: After switching the mains transformer ON (blinking stopped before)
on2.log: After starting and stopping test.sh again.
Then I did killall owfs and restarted owfs -u1 mnt/1wire, start test.sh.
off1.log: After switching the mains transformer OFF (blinking stopped
before)
off2.log: After starting and stopping test.sh again.
off3.log is just a repetition of off2.log after killall owfs and restarting
all again.
I hope you now can find a way to detect this kind of error and automatically
re-initialize.
Kind regards
Jan
logs.tar.bz2
Description: application/tbz
Re: [Owfs-developers] More on Hanging Problems
Your logs show mainly BUS_select_low_errors increasing.
Unfortunately there are 5 places in file ow_bus.c function BUS_select_low
where that variable is incremented. I've added some (temporary) printf's to
run the program in foreground and flip the garbalizer.
Can you pull from the latest CVS and try it out?
Once we know which point fails, we can further select that best place to test
for garbage and fix the problem.
Paul
On Friday 24 June 2005 10:01 am, Jan Kandziora wrote:
Am Dienstag, 21. Juni 2005 13:18 schrieb Alfille, Paul H.,M.D.:
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(10);
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.
--
This would work, but there may be a more efficient DS9490_detect, I made
room for the USB device handle in connection_in
in-connin.usb.dev so we can break out the internal part of DS9490_detect
and save re-enumerating the entire USB bus.
Perhaps a fallback of re-enumerating if the simpler routine fails.
Paul
In the meanwhile, I made some logs of the statistics/errors directory:
init.log: Directly after owfs -u1 mnt/1wire
ok1.log: After starting and stopping test.sh
ok2.log: After starting and stopping test.sh again.
So far, no errors. Now the critical ones:
on1.log: After switching the mains transformer ON (blinking stopped
before) on2.log: After starting and stopping test.sh again.
Then I did killall owfs and restarted owfs -u1 mnt/1wire, start
test.sh.
off1.log: After switching the mains transformer OFF (blinking stopped
before)
off2.log: After starting and stopping test.sh again.
off3.log is just a repetition of off2.log after killall owfs and restarting
all again.
I hope you now can find a way to detect this kind of error and
automatically re-initialize.
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=7477alloc_id=16492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Am Dienstag, 21. Juni 2005 04:46 schrieb Paul Alfille: 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? From overall engineering point of view, shielding makes things worse. Cables are thicker and harder to bend, heat is dissipated worse and even then, there is no guarantee you won't encounter any problems - There is hardly any shielding that could withstand a large electromagnetic pulse sent by a mains transformator or other impedance switched on at maximum voltage of the sine wave. To allow this, the shielding has to be connected to earth with a maximum resistance about 1 milliohms, which rules out any kind of connectors (and most kinds of earth, too). This is a general problem. All better transmission protocols have some retry-funtion, if such a situation happens - which is often. 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. I tried about 70..80 switches, only 2 times the USB connection broke; most times, the 1-wire connection broke; sometimes, nothing happened (must have switched on near zero-cross) 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. Ok. That would bring down the recovery time for usb fail to the values for recovery of 1-wire. 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, ...) All the device nodes in the mnt/1wire/uncached directory are gone in that case, even the one for the adaptor chip! owserver just fails in that situation. I think there already is a function that cleans up that directory or exit()s owserver. 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_idt77alloc_id492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
Am Dienstag, 21. Juni 2005 08:43 schrieb Christian Magnusson:
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'm glad I'm not the only person who encountered this kind of error. I just
thought I will either lose my credibility or my mind.
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.
Yes, same for me. But it takes about 2 seconds to detect a failed owserver and
to restart it - for local owserver. For remote owserver, things are even
worse. It would be far better owserver wouldn't fail in this situation, but
just re-initialize, maybe only the 1-wire, to get rid of the problem.
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.
Ok, I will do this in the evening.
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(10);
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.
I'm willing to dig into owlib to make up the necessary functions if someone
guides me. Then I can try out if it helps.
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=7477alloc_id=16492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
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(10);
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.
--
This would work, but there may be a more efficient DS9490_detect, I made room
for the USB device handle in connection_in
in-connin.usb.dev so we can break out the internal part of DS9490_detect and
save re-enumerating the entire USB bus.
Perhaps a fallback of re-enumerating if the simpler routine fails.
Paul
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_idt77alloc_id492op=click
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
RE: [Owfs-developers] More on Hanging Problems
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jan Kandziora Sent: Tuesday, June 21, 2005 4:12 AM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] More on Hanging Problems Am Dienstag, 21. Juni 2005 04:46 schrieb Paul Alfille: 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? From overall engineering point of view, shielding makes things worse. Cables are thicker and harder to bend, heat is dissipated worse and even then, there is no guarantee you won't encounter any problems - There is hardly any shielding that could withstand a large electromagnetic pulse sent by a mains transformator or other impedance switched on at maximum voltage of the sine wave. To allow this, the shielding has to be connected to earth with a maximum resistance about 1 milliohms, which rules out any kind of connectors (and most kinds of earth, too). This is a general problem. All better transmission protocols have some retry-funtion, if such a situation happens - which is often. 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. I tried about 70..80 switches, only 2 times the USB connection broke; most times, the 1-wire connection broke; sometimes, nothing happened (must have switched on near zero-cross) 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. Ok. That would bring down the recovery time for usb fail to the values for recovery of 1-wire. 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, ...) All the device nodes in the mnt/1wire/uncached directory are gone in that case, even the one for the adaptor chip! owserver just fails in that GREAT! ^^ something to test. situation. I think there already is a function that cleans up that directory or exit()s owserver. 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_idt77alloc_id492op=ick ___ 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_idt77alloc_id492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] More on Hanging Problems
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=7477alloc_id=16492op=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=7477alloc_id=16492op=click ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
