Re: UPD regression with

[Alexander Hall]

On May 13, 2015 3:37:39 AM GMT+02:00, David Higgs  wrote:
>On May 11, 2015, at 9:02 PM, David Higgs  wrote:
>> 
>>> On May 11, 2015, at 8:21 PM, David Higgs > wrote:
>>> 
>>> On Mon, May 11, 2015 at 8:07 PM, Alexander Hall >wrote:
>>> Upgrading to the latest snapshot, I noticed my upd sensors had been
>>> disturbingly crippled.
>>> 
>>>  uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton
>3S" rev 2.00/1.00 addr 2
>>>  uhidev0: iclass 3/0, 32 report ids
>>>  upd0 at uhidev0
>>> 
>>> Diff below is what happens from upd.c r1.13 to r1.14.
>>> 
>>> -hw.sensors.upd0.indicator0=On (ACPresent), OK
>>> -hw.sensors.upd0.indicator1=On (Charging), OK
>>> -hw.sensors.upd0.indicator2=Off (Discharging), OK
>>> -hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
>>> -hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
>>> -hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
>>> +hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
>>> +hw.sensors.upd0.indicator1=On (ACPresent), OK
>>> 
>>> Is this an expected fallout? Can I provide more info to assist? Full
>>> dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows.
>
>>> 
>>> It seems your device doesn't have a BatteryPresent report, or it is
>somehow getting mangled.  Can you run lsusb -v on your device and check
>if "Battery Present" is shown?
>>> 
>>> If it is not, we'll have to make sensor dependencies less strict. 
>I'll start thinking about how to do this.
>> 
>> Alternatively, you could try the following diff, which flattens the
>sensor dependency tree when a parent sensor isn’t available.
>
>Below is a diff which has the correct number of parentheses and
>actually compiles.  Sorry for the noise.

Committed by mpi@. Thanks!

/Alexander 

>
>--david
>
>--- a/upd.c
>+++ b/upd.c
>@@ -225,8 +225,12 @@ upd_attach_sensor_tree(struct upd_softc
> 
>   for (i = 0; i < nentries; i++) {
>   entry = entries + i;
>-  if (!upd_lookup_usage_entry(desc, size, entry, &item))
>+  if (!upd_lookup_usage_entry(desc, size, entry, &item)) {
>+  /* dependency missing, add children to parent */
>+  upd_attach_sensor_tree(sc, desc, size,
>+  entry->nchildren, entry->children, queue);
>   continue;
>+  }
> 
>   DPRINTF(("%s: found %s on repid=%d\n", DEVNAME(sc),
>   entry->usage_name, item.report_ID));

Re: UPD regression with

[Alexander Hall]

On 05/13/15 03:37, David Higgs wrote:

On May 11, 2015, at 9:02 PM, David Higgs  wrote:



On May 11, 2015, at 8:21 PM, David Higgs mailto:hig...@gmail.com>> wrote:

On Mon, May 11, 2015 at 8:07 PM, Alexander Hall mailto:alexan...@beard.se>>wrote:
Upgrading to the latest snapshot, I noticed my upd sensors had been
disturbingly crippled.

  uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev 
2.00/1.00 addr 2
  uhidev0: iclass 3/0, 32 report ids
  upd0 at uhidev0

Diff below is what happens from upd.c r1.13 to r1.14.

-hw.sensors.upd0.indicator0=On (ACPresent), OK
-hw.sensors.upd0.indicator1=On (Charging), OK
-hw.sensors.upd0.indicator2=Off (Discharging), OK
-hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
-hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
-hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
+hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
+hw.sensors.upd0.indicator1=On (ACPresent), OK

Is this an expected fallout? Can I provide more info to assist? Full
dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows.

It seems your device doesn't have a BatteryPresent report, or it is somehow getting 
mangled.  Can you run lsusb -v on your device and check if "Battery Present" is 
shown?

If it is not, we'll have to make sensor dependencies less strict.  I'll start 
thinking about how to do this.


Alternatively, you could try the following diff, which flattens the sensor 
dependency tree when a parent sensor isn’t available.


Below is a diff which has the correct number of parentheses and actually 
compiles.  Sorry for the noise.


I don't mind noise that fixes stuff. Thanks! :-)

$ alexander@bunke:~>sysctl hw.sensors
hw.sensors.km0.temp0=41.62 degC
hw.sensors.upd0.indicator0=On (Charging), OK
hw.sensors.upd0.indicator1=Off (Discharging), OK
hw.sensors.upd0.indicator2=Off (ShutdownImminent), OK
hw.sensors.upd0.indicator3=On (ACPresent), OK
hw.sensors.upd0.percent0=100.00% (RemainingCapacity), OK
hw.sensors.upd0.percent1=100.00% (FullChargeCapacity), OK

...aaand we're back in business!

OK by me. Not my field, so anyone else care to eyeball and commit?

Martin?

/Alexander



--david

--- a/upd.c
+++ b/upd.c
@@ -225,8 +225,12 @@ upd_attach_sensor_tree(struct upd_softc

for (i = 0; i < nentries; i++) {
entry = entries + i;
-   if (!upd_lookup_usage_entry(desc, size, entry, &item))
+   if (!upd_lookup_usage_entry(desc, size, entry, &item)) {
+   /* dependency missing, add children to parent */
+   upd_attach_sensor_tree(sc, desc, size,
+   entry->nchildren, entry->children, queue);
continue;
+   }

DPRINTF(("%s: found %s on repid=%d\n", DEVNAME(sc),
entry->usage_name, item.report_ID));

Re: UPD regression with

[David Higgs]

On May 11, 2015, at 9:02 PM, David Higgs  wrote:
> 
>> On May 11, 2015, at 8:21 PM, David Higgs > > wrote:
>> 
>> On Mon, May 11, 2015 at 8:07 PM, Alexander Hall > >wrote:
>> Upgrading to the latest snapshot, I noticed my upd sensors had been
>> disturbingly crippled.
>> 
>>  uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev 
>> 2.00/1.00 addr 2
>>  uhidev0: iclass 3/0, 32 report ids
>>  upd0 at uhidev0
>> 
>> Diff below is what happens from upd.c r1.13 to r1.14.
>> 
>> -hw.sensors.upd0.indicator0=On (ACPresent), OK
>> -hw.sensors.upd0.indicator1=On (Charging), OK
>> -hw.sensors.upd0.indicator2=Off (Discharging), OK
>> -hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
>> -hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
>> -hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
>> +hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
>> +hw.sensors.upd0.indicator1=On (ACPresent), OK
>> 
>> Is this an expected fallout? Can I provide more info to assist? Full
>> dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows. 
>> 
>> It seems your device doesn't have a BatteryPresent report, or it is somehow 
>> getting mangled.  Can you run lsusb -v on your device and check if "Battery 
>> Present" is shown?
>> 
>> If it is not, we'll have to make sensor dependencies less strict.  I'll 
>> start thinking about how to do this.
> 
> Alternatively, you could try the following diff, which flattens the sensor 
> dependency tree when a parent sensor isn’t available.

Below is a diff which has the correct number of parentheses and actually 
compiles.  Sorry for the noise.

--david

--- a/upd.c
+++ b/upd.c
@@ -225,8 +225,12 @@ upd_attach_sensor_tree(struct upd_softc
 
for (i = 0; i < nentries; i++) {
entry = entries + i;
-   if (!upd_lookup_usage_entry(desc, size, entry, &item))
+   if (!upd_lookup_usage_entry(desc, size, entry, &item)) {
+   /* dependency missing, add children to parent */
+   upd_attach_sensor_tree(sc, desc, size,
+   entry->nchildren, entry->children, queue);
continue;
+   }
 
DPRINTF(("%s: found %s on repid=%d\n", DEVNAME(sc),
entry->usage_name, item.report_ID));

Re: UPD regression with

[David Higgs]

> On May 11, 2015, at 8:21 PM, David Higgs  wrote:
> 
> On Mon, May 11, 2015 at 8:07 PM, Alexander Hall  >wrote:
> Upgrading to the latest snapshot, I noticed my upd sensors had been
> disturbingly crippled.
> 
>  uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev 
> 2.00/1.00 addr 2
>  uhidev0: iclass 3/0, 32 report ids
>  upd0 at uhidev0
> 
> Diff below is what happens from upd.c r1.13 to r1.14.
> 
> -hw.sensors.upd0.indicator0=On (ACPresent), OK
> -hw.sensors.upd0.indicator1=On (Charging), OK
> -hw.sensors.upd0.indicator2=Off (Discharging), OK
> -hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
> -hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
> -hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
> +hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
> +hw.sensors.upd0.indicator1=On (ACPresent), OK
> 
> Is this an expected fallout? Can I provide more info to assist? Full
> dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows. 
> 
> It seems your device doesn't have a BatteryPresent report, or it is somehow 
> getting mangled.  Can you run lsusb -v on your device and check if "Battery 
> Present" is shown?
> 
> If it is not, we'll have to make sensor dependencies less strict.  I'll start 
> thinking about how to do this.

Alternatively, you could try the following diff, which flattens the sensor 
dependency tree when a parent sensor isn’t available.

Thanks.

--david

--- a/upd.c
+++ b/upd.c
@@ -225,8 +225,12 @@ upd_attach_sensor_tree(struct upd_softc
 
for (i = 0; i < nentries; i++) {
entry = entries + i;
-   if (!upd_lookup_usage_entry(desc, size, entry, &item))
+   if (!upd_lookup_usage_entry(desc, size, entry, &item) {
+   /* dependency missing, add children to parent */
+   upd_attach_sensor_tree(sc, desc, size,
+   entry->nchildren, entry->children, queue);
continue;
+   }
 
DPRINTF(("%s: found %s on repid=%d\n", DEVNAME(sc),
entry->usage_name, item.report_ID));

Re: UPD regression with

[David Higgs]

On Mon, May 11, 2015 at 8:07 PM, Alexander Hall  wrote:

> Upgrading to the latest snapshot, I noticed my upd sensors had been
> disturbingly crippled.
>
>  uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev
> 2.00/1.00 addr 2
>  uhidev0: iclass 3/0, 32 report ids
>  upd0 at uhidev0
>
> Diff below is what happens from upd.c r1.13 to r1.14.
>
> -hw.sensors.upd0.indicator0=On (ACPresent), OK
> -hw.sensors.upd0.indicator1=On (Charging), OK
> -hw.sensors.upd0.indicator2=Off (Discharging), OK
> -hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
> -hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
> -hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
> +hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
> +hw.sensors.upd0.indicator1=On (ACPresent), OK
>
> Is this an expected fallout? Can I provide more info to assist? Full
> dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows.


It seems your device doesn't have a BatteryPresent report, or it is somehow
getting mangled.  Can you run lsusb -v on your device and check if "Battery
Present" is shown?

If it is not, we'll have to make sensor dependencies less strict.  I'll
start thinking about how to do this.

Thanks for the report.

--david

UPD regression with

[Alexander Hall]

Upgrading to the latest snapshot, I noticed my upd sensors had been
disturbingly crippled.

 uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev 
2.00/1.00 addr 2
 uhidev0: iclass 3/0, 32 report ids
 upd0 at uhidev0

Diff below is what happens from upd.c r1.13 to r1.14.

-hw.sensors.upd0.indicator0=On (ACPresent), OK
-hw.sensors.upd0.indicator1=On (Charging), OK
-hw.sensors.upd0.indicator2=Off (Discharging), OK
-hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
-hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
-hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
+hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
+hw.sensors.upd0.indicator1=On (ACPresent), OK

Is this an expected fallout? Can I provide more info to assist? Full
dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows.

/Alexander


OpenBSD 5.7-current (GENERIC.MP) #2: Tue May 12 01:50:04 CEST 2015
alexan...@bunke.beard.se:/bigtmp/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1996029952 (1903MB)
avail mem = 1931755520 (1842MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfb330 (35 entries)
bios0: vendor HP version "O41" date 10/01/2013
bios0: HP ProLiant MicroServer
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC MCFG SPMI OEMB HPET EINJ BERT ERST HEST SSDT
acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) 
PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4) PE20(S4) PE21(S4) 
PE22(S4) PE23(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Turion(tm) II Neo N54L Dual-Core Processor, 2196.67 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu0: AMD erratum 721 detected and fixed
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Turion(tm) II Neo N54L Dual-Core Processor, 2196.36 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,NODEID,ITSC
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 
16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative
cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative
cpu1: AMD erratum 721 detected and fixed
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpi0: unable to load \\_SB_._INI.EXH1
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P0P1)
acpiprt2 at acpi0: bus -1 (PCE2)
acpiprt3 at acpi0: bus 2 (PCE4)
acpiprt4 at acpi0: bus 3 (PCE6)
acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpibtn0 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: 2196 MHz: speeds: 2200 1900 1600 1300 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD RS880 Host" rev 0x00
ppb0 at pci0 dev 1 function 0 vendor "Hewlett-Packard", unknown product 0x9602 
rev 0x00
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 5 function 0 "ATI Mobility Radeon HD 4200" rev 0x00
drm0 at radeondrm0
radeondrm0: apic 2 int 18
ppb1 at pci0 dev 4 function 0 "AMD RS780 PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
vendor "Marvell", unknown product 0x9192 (class mass storage subclass RAID, rev 
0x13) at pci2 dev 0 function 0 not configured
ppb2 at pci0 dev 6 function 0 "AMD RS780 PCIE" rev 0x00
pci3 at ppb2 bus 3
bge0 at pci3 dev 0 function 0 "Broadcom BCM5723" rev 0x10, BCM5784 A1 
(0x5784100): msi, address 38:ea:a7:a9:e9:86
brgphy0 at bge0 phy 1: BCM5784 10/100/1000baseT PHY, rev. 4
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, AHCI 
1.2
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 3.0Gb/s
ahci0: port 2: 3.0Gb/s
ahci0: port 3: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed 
naa.50025388a01a9722
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.50014ee2b613deca
sd1: 5723166MB, 512 bytes/sector, 11721045168 sectors
sd2 at scsibus1 targ 2 lun 0:  SCSI3 0/direct 
fixed naa.5000cca221dd6beb
sd2: 1907729MB, 512 byte