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 a
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] NSLUG2 and OWFS
Hello from Gregg C Levine I tried that. Worse luck was that I only found our posts, because I could not recall two things. The date Mr. Rude posted his message, and the exact subject line. Besides it's not that important. I only posted it because of the fuss and the noise I'm seeing on the NSLUG2 lists. Gregg C Levine [EMAIL PROTECTED] --- The Force will be with you... Always. Obi-Wan Kenobi -Original Message- From: [EMAIL PROTECTED] [mailto:owfs-developers- [EMAIL PROTECTED] On Behalf Of Alfille, Paul H.,M.D. Sent: Tuesday, June 28, 2005 12:41 AM To: owfs-developers@lists.sourceforge.net Subject: RE: [Owfs-developers] NSLUG2 and OWFS Hi Gregg, Do you want to look up the fellow? The OWFS list is searchable on GMANE (http://dir.gmane.org/gmane.comp.file-systems.owfs.devel) and Mail Archive (http://www.mail-archive.com/owfs-developers%40lists.sourceforge.net/) \ I'm sure we could get OWFS to run on the NSLU2, or practically any linux-enabled device. Christian has ported it to everything including a Coldfire board, and the memory and resource requirements are quite modest. Clearly our architecture works very well with these devices. owserver can run locally or remotely, and we can aggregate multiple sources easily and flexibly. The only reason I explored the LinkSys router specifically is that wireless access is sometimes essential for an application. If wiring were possible, the sensor could have been connected directly. The speculation is that the serial headers on the board were for design and posssible expansion. The processor has dedicated serial pins natively, and being able to put a serial port in during the design and testing phase was probably useful. Get one of these devices. It's fun! Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gregg C Levine Sent: Monday, June 27, 2005 11:32 PM To: owfs-developers@lists.sourceforge.net Subject: [Owfs-developers] NSLUG2 and OWFS Hello from Gregg C Levine Paul here's a bit of a nasty poser for you. I remember when the OWFS list was just cranking up, and we were discussing the porting to the LinkSys wireless router of the OWFS binaries, this came up; a decidedly frustrated and rather angry poster complained to use that he couldn't get his USB fob to work on this device after building the OWFS binaries and installing them. Naturally I don't have my local archives of the list. I had a bit of a computer problem last month. It happens that the fellow, who provided the photos for opening the wireless router, and installing the serial ports on it, also did one for the NSLUG2 device. Also another gentleman has gotten the famous, or is that infamous one wire weather station to work on his NSLUG2 device it seems to me that he's followed a totally different route for such work. He originally brought that thing to Linux, and then discovered that Linux ran on the NSLUG2, and followed suit. Almost forgot, here's the location for the whole business, http://oww.sourceforge.net/index.html Of course what's interesting to me is the obvious thing, is this, what prompted LinkSys to have these serial ports on their hardware? And why didn't they tell us about them to begin with? I suppose I raised this issue when we started I suppose at some point I'll probably buy one of those things. --- Gregg C Levine [EMAIL PROTECTED] --- The Force will be with you... Always. Obi-Wan Kenobi --- 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=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
