Read errors accessing DS18B20 on Pi using w1

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Read errors accessing DS18B20 on Pi using w1

Colin Law
As in an earlier thread I am using an DS18B20 directly connected to
GPIO pins of a Pi Zero with 1.5k pullup, operating at 3.3v. Owserver
is version 3.1p1-6 from raspbian testing.

I have specified
dtoverlay=w1-gpio,gpiopin=4
and done
sudo modprobe w1-gpio pullup=1

This basically works, both when connected in parasitic and 3 wire mode
but about 1 in 20 reads I get a read error (in both modes).  It is
operating on the bench so the bus is only a few inches long.  I have
started owserver in debug mode and below is what I see when there is
an error (it was connected in parasitic mode when the debug was
collected). If anyone can suggest what the problem may be I will be
very grateful.

Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_tcp_read.c:(63)
attempt 24 bytes Time: 10.000000 seconds
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_tcp_read.c:(113)
read: 24 - 0 = 24
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: from_client.c:(66)
FromClient payload=28 size=8192 type=2 sg=0x20 offset=0
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: from_client.c:(74)
FromClient (no servermessage) payload=28 size=8192 type=2
controlflags=0x20 offset=0
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_tcp_read.c:(63)
attempt 28 bytes Time: 10.000000 seconds
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_tcp_read.c:(113)
read: 28 - 0 = 28
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: handler.c:(153) START
handler 28.62DABD030000/temperature
Sep  5 13:48:03 piz002 owserver[2462]: CALL: data.c:(103) DataHandler:
parse path=28.62DABD030000/temperature
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_parseobject.c:(163)
28.62DABD030000/temperature
Sep  5 13:48:03 piz002 owserver[2462]: CALL: ow_parsename.c:(104)
path=[28.62DABD030000/temperature]
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_regex.c:(154) Not found
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_regex.c:(201) 0:
0->15 found <><28.62DABD030000><>
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_regex.c:(201) 1: 0->2
found <><28><.62DABD030000>
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_regex.c:(201) 2:
3->15 found <28.><62DABD030000><>
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_cache.c:(912) Looking
for device 28 62 DA BD 03 00 00 B8
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_cache.c:(1070) Search
in cache sn 28 62 DA BD 03 00 00 B8 pointer=0xb6ebd618 index=0 size=4
Sep  5 13:48:03 piz002 owserver[2462]: DEBUG: ow_cache.c:(1102) Value
found in cache, but expired by 0 seconds.
Sep  5 13:48:03 piz002 owserver[2462]: DETAIL: ow_presence.c:(80)
Checking presence of /28.62DABD030000/temperature
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_transaction.c:(379)
pack=RESET END VERIFY
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_transaction.c:(254)
Item cannot be bundled
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_transaction.c:(274)
Ship Packets=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_select.c:(70)
Selecting a path (and device) path=/28.62DABD030000/temperature SN=28
62 DA BD 03 00 00 B8 last path=00 00 00 00 00 00 00 00
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_select.c:(84)
Continuing root branch
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1.c:(103) Sending w1
reset message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_send.c:(132)
Netlink send -----------------
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=52 type=3
(NLMSG_DONE) flags=5 seq=1|301 pid=2465
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|301 ack=65837 len=16 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=4 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=5
(W1_CMD_RESET) len=0
Sep  5 13:48:04 piz002 owserver[2462]: NULL data
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=301
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(229) Loop
waiting for netlink piped message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(162) Pipe
header: len=52 type=3 seq=1|300 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(195) Pipe
read --------------------
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=52 type=3
(NLMSG_DONE) flags=0 seq=1|300 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|300 ack=65836 len=16 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=4 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=4
(W1_CMD_TOUCH) len=0
Sep  5 13:48:04 piz002 owserver[2462]: NULL data
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(236)
Netlink sequence number out of order
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(120)
Pre-parse header: 16 bytes len=36 type=3 seq=0|0 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(67)
Netlink (w1) Bad message length (36)
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(172)
Dispatch loop
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(112) Wait
to peek at message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(120)
Pre-parse header: 16 bytes len=52 type=3 seq=1|301 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(141)
Netlink read -----------------
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=52 type=3
(NLMSG_DONE) flags=0 seq=1|301 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|301 ack=65837 len=16 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=4 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=5
(W1_CMD_RESET) len=0
Sep  5 13:48:04 piz002 owserver[2462]: NULL data
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(91)
Netlink message directed to W1 bus master 1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(148)
Sending this packet to w1_bus_master1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(172)
Dispatch loop
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(112) Wait
to peek at message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(229) Loop
waiting for netlink piped message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(162) Pipe
header: len=52 type=3 seq=1|301 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(195) Pipe
read --------------------
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=52 type=3
(NLMSG_DONE) flags=0 seq=1|301 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|301 ack=65837 len=16 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=4 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=5
(W1_CMD_RESET) len=0
Sep  5 13:48:04 piz002 owserver[2462]: NULL data
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1.c:(260) Sending w1
send/receive data message for 28 62 DA BD 03 00 00 B8
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_send.c:(132)
Netlink send -----------------
Sep  5 13:48:04 piz002 owserver[2462]: Byte buffer Data, length=25
Sep  5 13:48:04 piz002 owserver[2462]: --000: F0 DB BE 6F FB B6 7F FB
FE FD DF FF EF FF B6 6D
Sep  5 13:48:04 piz002 owserver[2462]: --016: DB B6 6D DB B6 6D DB FE EF
Sep  5 13:48:04 piz002 owserver[2462]: <...o...........m..m..m...>
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=77 type=3
(NLMSG_DONE) flags=5 seq=1|302 pid=2465
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|302 ack=65838 len=41 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=29 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=4
(W1_CMD_TOUCH) len=25
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=302
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(120)
Pre-parse header: 16 bytes len=36 type=3 seq=0|0 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(67)
Netlink (w1) Bad message length (36)
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(172)
Dispatch loop
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(112) Wait
to peek at message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(120)
Pre-parse header: 16 bytes len=77 type=3 seq=1|302 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(141)
Netlink read -----------------
Sep  5 13:48:04 piz002 owserver[2462]: Byte buffer Data, length=25
Sep  5 13:48:04 piz002 owserver[2462]: --000: F0 92 AA 4A AA A4 56 AA
5A B5 55 DB AA AD 84 6D
Sep  5 13:48:04 piz002 owserver[2462]: --016: DB B6 6D DB B6 6D DB FE EF
Sep  5 13:48:04 piz002 owserver[2462]: <...J..V.Z.U....m..m..m...>
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=77 type=3
(NLMSG_DONE) flags=0 seq=1|302 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|302 ack=65839 len=41 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=29 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=4
(W1_CMD_TOUCH) len=25
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(91)
Netlink message directed to W1 bus master 1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(148)
Sending this packet to w1_bus_master1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(172)
Dispatch loop
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(112) Wait
to peek at message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(229) Loop
waiting for netlink piped message
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(162) Pipe
header: len=77 type=3 seq=1|302 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(195) Pipe
read --------------------
Sep  5 13:48:04 piz002 owserver[2462]: Byte buffer Data, length=25
Sep  5 13:48:04 piz002 owserver[2462]: --000: F0 92 AA 4A AA A4 56 AA
5A B5 55 DB AA AD 84 6D
Sep  5 13:48:04 piz002 owserver[2462]: --016: DB B6 6D DB B6 6D DB FE EF
Sep  5 13:48:04 piz002 owserver[2462]: <...J..V.Z.U....m..m..m...>
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=77 type=3
(NLMSG_DONE) flags=0 seq=1|302 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|302 ack=65839 len=41 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=29 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=4
(W1_CMD_TOUCH) len=25
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(249)
About to call nrs_callback
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(251)
Called nrs_callback
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_transaction.c:(222) verify = 1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_presence.c:(272)
Presence of 28 62 DA BD 03 00 00 B8 NOT found on bus w1_bus_master1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_parsename.c:(164) Set
error to 27 <Path - bad path syntax>
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_parsename.c:(63)
/28.62DABD030000/temperature
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: data.c:(106)
DataHandler: OWQ_create failed cm.ret=-1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: data.c:(207)
DataHandler: cm.ret=-1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: to_client.c:(76)
payload=0 size=0, ret=-1, sg=0x20 offset=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: to_client.c:(85) No data
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: data.c:(226) Finished
with client request
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: handler.c:(135) OWSERVER
handler done
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_net_server.c:(259)
Normal completion.
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(120)
Pre-parse header: 16 bytes len=52 type=3 seq=1|302 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(141)
Netlink read -----------------
Sep  5 13:48:04 piz002 owserver[2462]: NLMSGHDR: len=52 type=3
(NLMSG_DONE) flags=0 seq=1|302 pid=0
Sep  5 13:48:04 piz002 owserver[2462]: CN_MSG: idx/val=3/1 (CN_W1_IDX)
seq=1|302 ack=65838 len=16 flags=0
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_MSG: type=4
(W1_MASTER_CMD) len=4 id=1
Sep  5 13:48:04 piz002 owserver[2462]: W1_NETLINK_CMD: cmd=4
(W1_CMD_TOUCH) len=0
Sep  5 13:48:04 piz002 owserver[2462]: NULL data
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(91)
Netlink message directed to W1 bus master 1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(148)
Sending this packet to w1_bus_master1
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_dispatch.c:(172)
Dispatch loop
Sep  5 13:48:04 piz002 owserver[2462]: DEBUG: ow_w1_parse.c:(112) Wait
to peek at message

Cheers

Colin

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Jan Kandziora
Am 05.09.2016 um 17:23 schrieb Colin Law:

> As in an earlier thread I am using an DS18B20 directly connected to
> GPIO pins of a Pi Zero with 1.5k pullup, operating at 3.3v. Owserver
> is version 3.1p1-6 from raspbian testing.
>
> I have specified
> dtoverlay=w1-gpio,gpiopin=4
> and done
> sudo modprobe w1-gpio pullup=1
>
> This basically works, both when connected in parasitic and 3 wire mode
> but about 1 in 20 reads I get a read error (in both modes).
>
That's something you have to take provisions for. OWFS doesn't retry
itself. I have spurious errors in my machines too (of course, a lot of
chips and cabling) with I²C and USB host adapters.

With the bitbanging host, I think it's connected to CPU frequency
scaling and other powersave measures. You could try to disable all this
and check if it gets better.

But I would just retry. YOu have to in any case for other errors.

Kind regards

        Jan



------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Colin Law
On 5 September 2016 at 20:13, Jan Kandziora <[hidden email]> wrote:

> Am 05.09.2016 um 17:23 schrieb Colin Law:
>> As in an earlier thread I am using an DS18B20 directly connected to
>> GPIO pins of a Pi Zero with 1.5k pullup, operating at 3.3v. Owserver
>> is version 3.1p1-6 from raspbian testing.
>>
>> I have specified
>> dtoverlay=w1-gpio,gpiopin=4
>> and done
>> sudo modprobe w1-gpio pullup=1
>>
>> This basically works, both when connected in parasitic and 3 wire mode
>> but about 1 in 20 reads I get a read error (in both modes).
>>
> That's something you have to take provisions for. OWFS doesn't retry
> itself. I have spurious errors in my machines too (of course, a lot of
> chips and cabling) with I²C and USB host adapters.
>
> With the bitbanging host, I think it's connected to CPU frequency
> scaling and other powersave measures. You could try to disable all this
> and check if it gets better.
>
> But I would just retry. YOu have to in any case for other errors.

My 'production' software does retry.  On other parts of my system I
have used adaptors such as the LinkUSB and get read errors only at a
very low level, below 0.1% I think, so I had not expected it to be 100
times worse.  However I can see that bit-banging is inherently going
to be much less reliable so I will make sure my system can cope with
that.

Thanks

Colin

------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
This post has NOT been accepted by the mailing list yet.
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

Linux raspberrypi 4.4.21+ #911 Thu Sep 15 14:17:52 BST 2016 armv6l GNU/Linux
owfs-3.1p4

eni
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
In reply to this post by Colin Law
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

Linux raspberrypi 4.4.21+ #911 Thu Sep 15 14:17:52 BST 2016 armv6l GNU/Linux
owfs-3.1p4

eni
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
In reply to this post by Colin Law
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in
the second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

Linux raspberrypi 4.4.21+ #911 Thu Sep 15 14:17:52 BST 2016 armv6l
GNU/Linux
owfs-3.1p4

eni

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Colin Law
In reply to this post by eni
On 5 November 2016 at 07:03, eni <[hidden email]> wrote:
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the
second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

I suspect, as Jan suggested that it is due to the fact that the kernel uses 'bit banging' which means that it drives the 1-wire directly under s/w control. This is inherently unreliable as occasionally something more important will come along that the processor needs to do and the 1-wire signal gets disrupted. I think probably best just to accept that retries are necessary when driving the bus in this way.

Colin
 

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
Hello Colin,

I've found a workaround - only use an other path to read from owfs-server and dont need any retry anymore.
Workaround is to use /bus.x/<ADDRESS>/<VALUE> instead of /<ADDRESS>/<VALUE>.
Have you a possibility to try, if this is working on your system also?

I dont found the reason for that, but it works stable (with 0 retry) since 24 hours (14 devices, on 4 buses, read/write every 20 seconds) on my owfs-server.

So I hope, it would be possible to get this working stable also with access over /<ADDRESS>/<VALUE>


Could it have do something with this hint in the kernel-driver from 1w-gpio

https://www.kernel.org/doc/Documentation/w1/w1.generic
=========
...
It is possible that between 1. and 2. w1 master thread will reset bus for searching
and slave device will be even removed, but in this case 0xff will
be read, since no device was selected.
...
=========

I've seen in the debuglevel-log from owfs-server that this is searching on each bus-master when I access with /<ADDRESS>/<VALUE>.

eni


On 05.11.2016 09:08, Colin Law wrote:
On 5 November 2016 at 07:03, eni <[hidden email]> wrote:
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the
second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

I suspect, as Jan suggested that it is due to the fact that the kernel uses 'bit banging' which means that it drives the 1-wire directly under s/w control. This is inherently unreliable as occasionally something more important will come along that the processor needs to do and the 1-wire signal gets disrupted. I think probably best just to accept that retries are necessary when driving the bus in this way.

Colin
 


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Colin Law
On 5 November 2016 at 08:30, Enrico Hoepfner <[hidden email]> wrote:
Hello Colin,

I've found a workaround - only use an other path to read from owfs-server and dont need any retry anymore.
Workaround is to use /bus.x/<ADDRESS>/<VALUE> instead of /<ADDRESS>/<VALUE>.
Have you a possibility to try, if this is working on your system also?

Sorry I don't understand exactly what you mean by that. Could you give a specific example of what you mean?

Colin

 

I dont found the reason for that, but it works stable (with 0 retry) since 24 hours (14 devices, on 4 buses, read/write every 20 seconds) on my owfs-server.

So I hope, it would be possible to get this working stable also with access over /<ADDRESS>/<VALUE>


Could it have do something with this hint in the kernel-driver from 1w-gpio

https://www.kernel.org/doc/Documentation/w1/w1.generic
=========
...
It is possible that between 1. and 2. w1 master thread will reset bus for searching
and slave device will be even removed, but in this case 0xff will
be read, since no device was selected.
...
=========

I've seen in the debuglevel-log from owfs-server that this is searching on each bus-master when I access with /<ADDRESS>/<VALUE>.

eni



On 05.11.2016 09:08, Colin Law wrote:
On 5 November 2016 at 07:03, eni <[hidden email]> wrote:
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the
second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

I suspect, as Jan suggested that it is due to the fact that the kernel uses 'bit banging' which means that it drives the 1-wire directly under s/w control. This is inherently unreliable as occasionally something more important will come along that the processor needs to do and the 1-wire signal gets disrupted. I think probably best just to accept that retries are necessary when driving the bus in this way.

Colin
 


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
Hello Colin,

 the workaround is for instance, to use

owget -s 192.168.1.183:10000 /bus.2/28.F51ECA030000/temperature9

instead of

owget -s 192.168.1.183:10000 /28.F51ECA030000/temperature9

 eni

On 05.11.2016 09:35, Colin Law wrote:
On 5 November 2016 at 08:30, Enrico Hoepfner <[hidden email]> wrote:
Hello Colin,

I've found a workaround - only use an other path to read from owfs-server and dont need any retry anymore.
Workaround is to use /bus.x/<ADDRESS>/<VALUE> instead of /<ADDRESS>/<VALUE>.
Have you a possibility to try, if this is working on your system also?

Sorry I don't understand exactly what you mean by that. Could you give a specific example of what you mean?

Colin

 

I dont found the reason for that, but it works stable (with 0 retry) since 24 hours (14 devices, on 4 buses, read/write every 20 seconds) on my owfs-server.

So I hope, it would be possible to get this working stable also with access over /<ADDRESS>/<VALUE>


Could it have do something with this hint in the kernel-driver from 1w-gpio

https://www.kernel.org/doc/Documentation/w1/w1.generic
=========
...
It is possible that between 1. and 2. w1 master thread will reset bus for searching
and slave device will be even removed, but in this case 0xff will
be read, since no device was selected.
...
=========

I've seen in the debuglevel-log from owfs-server that this is searching on each bus-master when I access with /<ADDRESS>/<VALUE>.

eni



On 05.11.2016 09:08, Colin Law wrote:
On 5 November 2016 at 07:03, eni <[hidden email]> wrote:
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the
second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

I suspect, as Jan suggested that it is due to the fact that the kernel uses 'bit banging' which means that it drives the 1-wire directly under s/w control. This is inherently unreliable as occasionally something more important will come along that the processor needs to do and the 1-wire signal gets disrupted. I think probably best just to accept that retries are necessary when driving the bus in this way.

Colin
 


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Jan Kandziora
In reply to this post by eni
Am 05.11.2016 um 09:30 schrieb Enrico Hoepfner:

>
> Could it have do something with this hint in the kernel-driver from 1w-gpio
>
> https://www.kernel.org/doc/Documentation/w1/w1.generic
> =========
> ...
>
> It is possible that between 1. and 2. w1 master thread will reset bus
> for searching
> and slave device will be even removed, but in this case 0xff will
> be read, since no device was selected.
> ...
>
> =========
>
> I've seen in the debuglevel-log from owfs-server that this is searching
> on each bus-master when I access with /<ADDRESS>/<VALUE>.
>
Uh, this explains it pretty much. A race condition.

You could also check whether disabling the w1 search algorithm solves it
for you, too:

# echo 0 >/sys/devices/w1_bus_master1/w1_master_search

owfs doesn't need that searching, it explicitly advises w1 to search the
bus when /uncached is listed or after 60s when / is listed. But in owfs
you can also address any chip without having it listed previously. That
w1 search function is purely for populating the sysfs' w1 devices directory.

Kind regards

        Jan





------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Colin Law
In reply to this post by eni
OK, got it thanks

Colin

On 5 November 2016 at 09:05, Enrico Hoepfner <[hidden email]> wrote:
Hello Colin,

 the workaround is for instance, to use

owget -s 192.168.1.183:10000 /bus.2/28.F51ECA030000/temperature9

instead of

owget -s 192.168.1.183:10000 /28.F51ECA030000/temperature9

 eni


On 05.11.2016 09:35, Colin Law wrote:
On 5 November 2016 at 08:30, Enrico Hoepfner <[hidden email]> wrote:
Hello Colin,

I've found a workaround - only use an other path to read from owfs-server and dont need any retry anymore.
Workaround is to use /bus.x/<ADDRESS>/<VALUE> instead of /<ADDRESS>/<VALUE>.
Have you a possibility to try, if this is working on your system also?

Sorry I don't understand exactly what you mean by that. Could you give a specific example of what you mean?

Colin

 

I dont found the reason for that, but it works stable (with 0 retry) since 24 hours (14 devices, on 4 buses, read/write every 20 seconds) on my owfs-server.

So I hope, it would be possible to get this working stable also with access over /<ADDRESS>/<VALUE>


Could it have do something with this hint in the kernel-driver from 1w-gpio

https://www.kernel.org/doc/Documentation/w1/w1.generic
=========
...
It is possible that between 1. and 2. w1 master thread will reset bus for searching
and slave device will be even removed, but in this case 0xff will
be read, since no device was selected.
...
=========

I've seen in the debuglevel-log from owfs-server that this is searching on each bus-master when I access with /<ADDRESS>/<VALUE>.

eni



On 05.11.2016 09:08, Colin Law wrote:
On 5 November 2016 at 07:03, eni <[hidden email][hidden email]> wrote:
Hello Colin,

I've exactly the same problem, also with raspberry pi and w1-kernel-modul.
I've implemented a retry on client-side (OWNet.pm), this works mostly in the
second try, maximum at the fourth time.
could it be there is a timing problem with w1-kernel-modul?

I suspect, as Jan suggested that it is due to the fact that the kernel uses 'bit banging' which means that it drives the 1-wire directly under s/w control. This is inherently unreliable as occasionally something more important will come along that the processor needs to do and the 1-wire signal gets disrupted. I think probably best just to accept that retries are necessary when driving the bus in this way.

Colin
 


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Owfs-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/owfs-developers
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
In reply to this post by Jan Kandziora
Hi Jan,

  Thank you for th answer!
I've tested your recommendation

# echo 0 >/sys/devices/w1_bus_master1/w1_master_search

but with this, I need the retrys againto read/write a value. (sometimes,
not always)

I've attach a trace (loglevel=9) where a read command get no value.
/28.EEA90F171602/temperature11

maybe this could help to reproduce what goes wrong.

to my system:
I use w1_gpio on 4 pins, so I have 4 1wire-buses
bus.1: 9x DS18B20
bus.2: 1x DS2408
bus.3: 3x DS18B20
bus.4: 1x DS2408

best regards
  eni


On 05.11.2016 10:14, Jan Kandziora wrote:

> Am 05.11.2016 um 09:30 schrieb Enrico Hoepfner:
>> Could it have do something with this hint in the kernel-driver from 1w-gpio
>>
>> https://www.kernel.org/doc/Documentation/w1/w1.generic
>> =========
>> ...
>>
>> It is possible that between 1. and 2. w1 master thread will reset bus
>> for searching
>> and slave device will be even removed, but in this case 0xff will
>> be read, since no device was selected.
>> ...
>>
>> =========
>>
>> I've seen in the debuglevel-log from owfs-server that this is searching
>> on each bus-master when I access with /<ADDRESS>/<VALUE>.
>>
> Uh, this explains it pretty much. A race condition.
>
> You could also check whether disabling the w1 search algorithm solves it
> for you, too:
>
> # echo 0 >/sys/devices/w1_bus_master1/w1_master_search
>
> owfs doesn't need that searching, it explicitly advises w1 to search the
> bus when /uncached is listed or after 60s when / is listed. But in owfs
> you can also address any chip without having it listed previously. That
> w1 search function is purely for populating the sysfs' w1 devices directory.
>
> Kind regards
>
> Jan
>
>
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

syslog_EEA90F171602 (44K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Jan Kandziora
Am 05.11.2016 um 20:25 schrieb Enrico Hoepfner:
>
> to my system:
> I use w1_gpio on 4 pins, so I have 4 1wire-buses
> bus.1: 9x DS18B20
> bus.2: 1x DS2408
> bus.3: 3x DS18B20
> bus.4: 1x DS2408
>
I think this is a setup hardly tested by Evgeniy Polyakov. Most people
only have a single GPIO for w1_gpio. Any specific reason we you use more
than one? Star topology network?

Kind regards

        Jan



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
Hello Jan,

Thank you for the answer!

  I have 4 buses because
1) DS18B20 an DS2408 need different pullup-resistors
2) the 4 buses goes to different locations

on my production enviroment the 4 buses are realized with a DS2482-800
(directly used by owfs, without w1-kernel-modul) and it works verry
well, with owfs - no retry since over a month.
on this new test enviroment I would use a way without DS2482-800.
 From the kernel I get 4 bus-master-devices, owfs is working with
w1-kernel-modul, and owfs can also handle more than one 1wire buses - so
I thought this would be no problem.

with the workaround to access directly on the bus, where the device is
present, it works stable.
I dont understand why owfs is checking presence of the device of all
buses - seems like owserver has forgotten where the device is connected
and check all buses, if there is presence this one.

best regeards
  eni


On 05.11.2016 20:54, Jan Kandziora wrote:

> Am 05.11.2016 um 20:25 schrieb Enrico Hoepfner:
>> to my system:
>> I use w1_gpio on 4 pins, so I have 4 1wire-buses
>> bus.1: 9x DS18B20
>> bus.2: 1x DS2408
>> bus.3: 3x DS18B20
>> bus.4: 1x DS2408
>>
> I think this is a setup hardly tested by Evgeniy Polyakov. Most people
> only have a single GPIO for w1_gpio. Any specific reason we you use more
> than one? Star topology network?
>
> Kind regards
>
> Jan
>
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

Jan Kandziora
Am 05.11.2016 um 21:54 schrieb Enrico Hoepfner:
> Hello Jan,
>
> Thank you for the answer!
>
>   I have 4 buses because
> 1) DS18B20 an DS2408 need different pullup-resistors
>
How? Both should be fine with 1.5k to 3.3V.


> 2) the 4 buses goes to different locations
>
Star topology. Okay.


>
> I dont understand why owfs is checking presence of the device of all
> buses - seems like owserver has forgotten where the device is connected
> and check all buses, if there is presence this one.
>
This is a deliberate choice. Owfs does not remember where a device was
connected. Because it could have been moved since last access. It's up
to the application to keep track.

Kind regards

        Jan

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

Re: Read errors accessing DS18B20 on Pi using w1

eni
Hello Jan,

Thank you for the answer and the help!

I understand this so:
owfs does not knows on which bus a device is connected (only it is
cached). when I access with /<ADDRESS> owfs must check all buses where
this decvice is connected. This maybe a problem for the w1-kernel-modul,
when I use more than one bus-master.
When I access with /<BUS>/<ADDRESS> owfs access only to this one bus,
without checking presence/reset the bus.

This mean, it is always better to access over /<BUS>/<ADDRESS>, in order
to avoid problems with w1-kernel-modul and also for the performance.

Thank you verry much for the help, to understand this behavior

best regards
  eni

On 05.11.2016 22:31, Jan Kandziora wrote:

> Am 05.11.2016 um 21:54 schrieb Enrico Hoepfner:
>> Hello Jan,
>>
>> Thank you for the answer!
>>
>>    I have 4 buses because
>> 1) DS18B20 an DS2408 need different pullup-resistors
>>
> How? Both should be fine with 1.5k to 3.3V.
>
>
>> 2) the 4 buses goes to different locations
>>
> Star topology. Okay.
>
>
>> I dont understand why owfs is checking presence of the device of all
>> buses - seems like owserver has forgotten where the device is connected
>> and check all buses, if there is presence this one.
>>
> This is a deliberate choice. Owfs does not remember where a device was
> connected. Because it could have been moved since last access. It's up
> to the application to keep track.
>
> Kind regards
>
> Jan
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
eni
Reply | Threaded
Open this post in threaded view
|

owserver hang 5 minutes - after NETLINK seq=65536

eni
In reply to this post by Jan Kandziora
Hello,

my owserver hangs sometime for 5 minutes.
he is working on one request, but need 5 minutes to get the answer.

In the logfile I've seen that this is happen when NETLINK sequence
number is running over 65535.

Nov  6 12:32:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=65535
Nov  6 12:32:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=65536
Nov  6 12:33:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=65537
Nov  6 12:34:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=65538
Nov  6 12:35:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=65539
Nov  6 12:36:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=65540


 From the time when NETLINK sequence number is 1 - the owserver works
perfektly again

Nov  6 12:37:23 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=1
Nov  6 12:37:24 raspberrypi OWFS[17573]:   DEBUG: ow_w1_send.c:(143)
NETLINK sent seq=2

could this overrun of sequence number be the reason for the hanging?

Best regards
  eni


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers