Hi Jan,
sorry for that - in my sent-folder looks the message ok.
owserver hangs some minutes when sequence number run over 0x
Signed-off: "Enrico Hoepfner nlmsg_seq) != (unsigned int) seq ) {
+ if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL
Hi Jan,
Thank you for the help and thepatience!
owserver hangs some minutes when sequence number run over 0x
Signed-off: "Enrico Hoepfner nlmsg_seq) != (unsigned int) seq ) {
+ if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL_SEQ(seq) ) {
LEVEL_DEBUG(
owserver hangs some minutes when sequence number run over 0x
Signed-off: "Enrico Hoepfner nlmsg_seq) != (unsigned int) seq ) {
+ if ( NL_SEQ(nlp.nlm->nlmsg_seq) != NL_SEQ(seq) ) {
LEVEL_DEBUG("Netlink sequence number
r --stdout
c14b0e446e686b4ab158bad2d6b4ac111df14c8f..79382f3e10c6566ae2e189fb708dade77e077fd2
From 79382f3e10c6566ae2e189fb708dade77e077fd2 Mon Sep 17 00:00:00 2001
From: Enrico Hoepfner
Date: Thu, 17 Nov 2016 17:39:29 +0100
Subject: [PATCH] fix sequence number bug in w1 host adaptor code
---
module/o
Hello,
the patch below works perfectly! thank you all for your help!
how can I commit this patch to owfs source?
can this do someone of the developers or is there a description how I
can do that?
best regards
eni
On 15.11.2016 16:36, Enrico Hoepfner wrote:
Hello Stefano,
reference to
er to avoid a
bug surfacing in another point of the code is nooot good.
S.
On 13 Nov 2016, at 11:10, Jan Kandziora <mailto:j...@gmx.de>> wrote:
Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
Hi Jan,
Thank you for the fast answer!
I dont understand exacly , which patch and test
s a point in
the source where this masking is not done properly, and that is the
bug to be corrected. Fudging the sequence number in order to avoid a
bug surfacing in another point of the code is nooot good.
S.
On 13 Nov 2016, at 11:10, Jan Kandziora <mailto:j...@gmx.de>> wrote:
Am 1
ng.
Best regards
eni
On 13.11.2016 11:10, Jan Kandziora wrote:
> Am 13.11.2016 um 00:53 schrieb Enrico Hoepfner:
>> Hi Jan,
>>
>> Thank you for the fast answer!
>> I dont understand exacly , which patch and test from Paul you mean.
>> Maybe I have take the diff i
= NL_SEQ(++in->master.w1.seq);
+ LEVEL_DEBUG("NETLINK sequence number overrun");
+ }
bus = in->master.w1.id;
}
Best regards
eni
On 12.11.2016 22:34, Jan Kandziora wrote:
> Am 12.11.2016 um 19:31 schrieb Enrico Hoep
in my opinion there is a bug in ow_w1_send.c - that sequence number for
netlink can run over 0x.
this makes the problem that the message which is send (65536 & 0x),
has a different sequence number as the Response is watinting for (65536).
I've try the following patch to reset sequence nu
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 sen
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
>
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
>&g
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
Hello Colin,
the workaround is for instance, to use
owget -s 192.168.1.183:1 /bus.2/28.F51ECA03/temperature9
instead of
owget -s 192.168.1.183:1 /28.F51ECA03/temperature9
eni
On 05.11.2016 09:35, Colin Law wrote:
On 5 November 2016 at 08:30, Enrico Hoepfner
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// instead of //.
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 (wit
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
17 matches
Mail list logo