On 2013/04/30 17:39, I wrote:
> Seems to work well enough; and unlike my uthum (one of the dual-sensor ones)
> it seems to stay attached without dropping out all the time.

So I've tracked this uthum problem down a bit further...

uthum: ntc tuning start. cur state = 0x66, val = 0x8435
uthum: ntc tuning done. state change: 0x66->0x66
uthum: broken ntc data 0x16 0x10 0x31
uthum: ntc data read fail
uthum: broken ntc data 0x17 0x50 0x31
uthum: ntc data read fail
uthum: broken ntc data 0x17 0xe0 0x31
uthum: ntc data read fail
uthum: broken ntc data 0x18 0x00 0x31
uthum: ntc data read fail
uthum: broken ntc data 0x18 0xd0 0x31
uthum: ntc data read fail
...

The 0x31 (CMD_GETDATA_EOF) looks like this is a response to a read
instruction for a ds75, but we just asked it to read the ntc..

I've seen it happen at other times than after ntc tuning, but so far
with those it only repeated the "data read fail" / "broken ntc data"
a couple of times, and then resumed working normally.

I'm finding it fairly hard to trigger on the slow sparc64 I'm testing
on now, whereas it happens more easily on a faster machine. And I haven't
managed to trigger it at all with an added small (2-char, no \n) printf
to uthum_read_data() to show the target_cmd, which adds support to the
idea that we might not be waiting long enough.

As I've seen this happen right after tuning (without recovering), and
seen it very occasionally at other times, I thought of maybe increasing
the delay that uthum_ntc_getdata passes to uthum_read_data to tsleep,
and adding a new tsleep in uthum_ntc_tuning. Since I have no hardware
docs for the device it's guesswork so I'm trying this..fairly hefty
delays in this diff; I tried smaller values (in the range 10-50 for
uthum_read_data and hz/2, hz, hz*2 for the new tsleep) which didn't
immediately help so I used fairly high values to see if it stays
working overnight.

Pity we can't differentiate the various possible ds75 sensors,
otherwise we could just look at the received data to decide which
sensor it's for. Anyone have suggestions other than this sledgehammer
approach?


Index: uthum.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/uthum.c,v
retrieving revision 1.19
diff -u -p -r1.19 uthum.c
--- uthum.c     15 Apr 2013 09:23:02 -0000      1.19
+++ uthum.c     4 May 2013 00:19:28 -0000
@@ -515,7 +515,7 @@ uthum_ntc_getdata(struct uthum_softc *sc
                return EIO;
 
        /* get sensor value */
-       if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 10) != 0) {
+       if (uthum_read_data(sc, CMD_GETDATA_NTC, buf, sizeof(buf), 1000) != 0) {
                DPRINTF(("uthum: data read fail\n"));
                return EIO;
        }
@@ -600,6 +600,7 @@ uthum_ntc_tuning(struct uthum_softc *sc,
                }
                ostate = state;
        }
+       tsleep(&sc->sc_sensortask, 0, "uthum", hz * 10);
 
        DPRINTF(("uthum: ntc tuning done. state change: 0x%.2x->0x%.2x\n",
            s->cur_state, state));

Reply via email to