Re: Make sysctl_file more smp friendly

[Philip Guenther]

Vitaliy,

As I told you directly last week, proposing changes in anticipation of 
future work requires some sort of plan about that future work.  Without 
some sort of model for locking the access paths, it's impossible to judge 
whether the proposed change is useful or pointless.


On Fri, 8 May 2015, Vitaliy Makkoveev wrote:
> sysctl_file() has 2 cases: KERN_FILE_BY_PID and KERN_FILE_BYUID. In 
> these cases sysctl_file() can access file descriptor table from other 
> processes. File descriptor table of caller process can be accessed by 
> other threads too. The file instances from file descriptor table will be 
> accessed too. So file descriptor table and the file instances within 
> should be protected in these cases. The patch below adds protection to 
> file instances only. Really, each foreign process should be locked here, 
> not only file descriptor table, but not in this patch. Races between 
> sysctl_file() and process destruction denied by kernel lock.

You need to be a lot more specific about the sequence of events that 
you're concerned with.  Protections against what?

So while it's not clear what problem this diff is supposed to solve, it 
does make the *real* problem with this sysctl, lock of locking of the 
process, much more likely to be hit, thus making things worse instead of 
better.  You need a lot more than handwaving to justify that.


Philip Guenther

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

Brainy: Kernel Use-after-free & Memory Leak in hifn

[Maxime Villard]

Hi,
I put here two bugs among others:

 sys/dev/pci/hifn7751.c 

2757
if (!(m0->m_flags & M_EXT))
m_freem(m0);
len = MCLBYTES;

totlen -= len;
m0->m_pkthdr.len = m0->m_len = len;
mlast = m0;



Use-after-free with 'm0'.

 sys/dev/pci/hifn7751.c 

2766
MGET(m, M_DONTWAIT, MT_DATA);
if (m == NULL) {
m_freem(m0);
return (NULL);
}
MCLGET(m, M_DONTWAIT);
if (!(m->m_flags & M_EXT)) {
m_freem(m0);
return (NULL);
}
len = MCLBYTES;



'm' is leaked.

Found by The Brainy Code Scanner.

Maxime

Re: vfs_shutdown would like to do polled I/O at least on panic

[Mark Kettenis]

> Date: Mon, 11 May 2015 16:54:54 +0200
> From: Mike Belopuhov 
> 
> On Fri, May 08, 2015 at 20:28 +0200, Mark Kettenis wrote:
> > > Date: Fri, 8 May 2015 20:15:58 +0200
> > > From: Mike Belopuhov 
> > > 
> > > On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
> > > > > I think tsleep(9) and msleep(9) need to release and re-acquire the
> > > > > kernel lock in the "cold || panicstr" case.
> > > > 
> > > > Well, it's not hard to do really, but...
> > > > 
> > > > > We might need this for
> > > > > handling interrupts during autoconf as soon as we start distributing
> > > > > interrupts over CPUs.
> > > > >
> > > > 
> > > > ...cold might mean that interrupts are not ready yet.  So then we might
> > > > need another flag for shutdown?
> > > 
> > > This is what I have come up with.  Chunks were taken directly from
> > > mi_switch and it seems to do the job just fine.  Right now I'm not
> > > using any additional flags and it seems to work here.  I'll resume
> > > testing on Monday, but it looks fairly complete.  Any comments?
> > 
> > Makes sense to me.  The msleep/tsleep code could be simplified to:
> > 
> > if (__mp_lock_held(&kernel_lock)) {
> > hold_count = __mp_release_all(&kernel_lock);
> > __mp_acquire_count(&kernel_lock, hold_count);
> > }
> >
> 
> Indeed.
> 
> > I'm also wondering whether we should change __mp_release_all() to
> > simple return 0 if the current CPU does not hold the lock, such that
> > the __mp_lock_held() check isn't needed anymore.  But that's a
> > separate issue.
> > 
> 
> It would have made the __mp_release_all safer as well since it
> wouldn't require an external check.
> 
> I don't have any firther input on this, diff works fine here.
> 
> OK?

ok kettenis@

> diff --git sys/kern/kern_synch.c sys/kern/kern_synch.c
> index 03308b4..6f573fc 100644
> --- sys/kern/kern_synch.c
> +++ sys/kern/kern_synch.c
> @@ -103,10 +103,13 @@ extern int safepri;
>  int
>  tsleep(const volatile void *ident, int priority, const char *wmesg, int timo)
>  {
>   struct sleep_state sls;
>   int error, error1;
> +#ifdef MULTIPROCESSOR
> + int hold_count;
> +#endif
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH)) == 0);
>  
>  #ifdef MULTIPROCESSOR
>   KASSERT(timo || __mp_lock_held(&kernel_lock));
> @@ -120,10 +123,16 @@ tsleep(const volatile void *ident, int priority, const 
> char *wmesg, int timo)
>* don't run any other procs or panic below,
>* in case this is the idle process and already asleep.
>*/
>   s = splhigh();
>   splx(safepri);
> +#ifdef MULTIPROCESSOR
> + if (__mp_lock_held(&kernel_lock)) {
> + hold_count = __mp_release_all(&kernel_lock);
> + __mp_acquire_count(&kernel_lock, hold_count);
> + }
> +#endif
>   splx(s);
>   return (0);
>   }
>  
>   sleep_setup(&sls, ident, priority, wmesg);
> @@ -149,10 +158,13 @@ int
>  msleep(const volatile void *ident, struct mutex *mtx, int priority,
>  const char *wmesg, int timo)
>  {
>   struct sleep_state sls;
>   int error, error1, spl;
> +#ifdef MULTIPROCESSOR
> + int hold_count;
> +#endif
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
>   KASSERT(mtx != NULL);
>  
>   if (cold || panicstr) {
> @@ -163,10 +175,16 @@ msleep(const volatile void *ident, struct mutex *mtx, 
> int priority,
>* in case this is the idle process and already asleep.
>*/
>   spl = MUTEX_OLDIPL(mtx);
>   MUTEX_OLDIPL(mtx) = safepri;
>   mtx_leave(mtx);
> +#ifdef MULTIPROCESSOR
> + if (__mp_lock_held(&kernel_lock)) {
> + hold_count = __mp_release_all(&kernel_lock);
> + __mp_acquire_count(&kernel_lock, hold_count);
> + }
> +#endif
>   if ((priority & PNORELOCK) == 0) {
>   mtx_enter(mtx);
>   MUTEX_OLDIPL(mtx) = spl;
>   } else
>   splx(spl);
> diff --git sys/kern/vfs_subr.c sys/kern/vfs_subr.c
> index a26fbe2..a373789 100644
> --- sys/kern/vfs_subr.c
> +++ sys/kern/vfs_subr.c
> @@ -1664,10 +1664,13 @@ int
>  vfs_syncwait(int verbose)
>  {
>   struct buf *bp;
>   int iter, nbusy, dcount, s;
>   struct proc *p;
> +#ifdef MULTIPROCESSOR
> + int hold_count;
> +#endif
>  
>   p = curproc? curproc : &proc0;
>   sys_sync(p, (void *)0, (register_t *)0);
>  
>   /* Wait for sync to finish. */
> @@ -1698,11 +1701,21 @@ vfs_syncwait(int verbose)
>   }
>   if (nbusy == 0)
>   break;
>   if (verbose)
>   printf("%d ", nbusy);
> +#ifdef MULTIPROCESSOR
> + if (__mp_lock_held(&kernel_lock))
> + hold_count = __mp_release_all(&kernel_lock);
> + else
> + 

Re: vfs_shutdown would like to do polled I/O at least on panic

[Mike Belopuhov]

On Fri, May 08, 2015 at 20:28 +0200, Mark Kettenis wrote:
> > Date: Fri, 8 May 2015 20:15:58 +0200
> > From: Mike Belopuhov 
> > 
> > On Fri, May 08, 2015 at 12:34 +0200, Mike Belopuhov wrote:
> > > > I think tsleep(9) and msleep(9) need to release and re-acquire the
> > > > kernel lock in the "cold || panicstr" case.
> > > 
> > > Well, it's not hard to do really, but...
> > > 
> > > > We might need this for
> > > > handling interrupts during autoconf as soon as we start distributing
> > > > interrupts over CPUs.
> > > >
> > > 
> > > ...cold might mean that interrupts are not ready yet.  So then we might
> > > need another flag for shutdown?
> > 
> > This is what I have come up with.  Chunks were taken directly from
> > mi_switch and it seems to do the job just fine.  Right now I'm not
> > using any additional flags and it seems to work here.  I'll resume
> > testing on Monday, but it looks fairly complete.  Any comments?
> 
> Makes sense to me.  The msleep/tsleep code could be simplified to:
> 
>   if (__mp_lock_held(&kernel_lock)) {
>   hold_count = __mp_release_all(&kernel_lock);
>   __mp_acquire_count(&kernel_lock, hold_count);
>   }
>

Indeed.

> I'm also wondering whether we should change __mp_release_all() to
> simple return 0 if the current CPU does not hold the lock, such that
> the __mp_lock_held() check isn't needed anymore.  But that's a
> separate issue.
> 

It would have made the __mp_release_all safer as well since it
wouldn't require an external check.

I don't have any firther input on this, diff works fine here.

OK?

diff --git sys/kern/kern_synch.c sys/kern/kern_synch.c
index 03308b4..6f573fc 100644
--- sys/kern/kern_synch.c
+++ sys/kern/kern_synch.c
@@ -103,10 +103,13 @@ extern int safepri;
 int
 tsleep(const volatile void *ident, int priority, const char *wmesg, int timo)
 {
struct sleep_state sls;
int error, error1;
+#ifdef MULTIPROCESSOR
+   int hold_count;
+#endif
 
KASSERT((priority & ~(PRIMASK | PCATCH)) == 0);
 
 #ifdef MULTIPROCESSOR
KASSERT(timo || __mp_lock_held(&kernel_lock));
@@ -120,10 +123,16 @@ tsleep(const volatile void *ident, int priority, const 
char *wmesg, int timo)
 * don't run any other procs or panic below,
 * in case this is the idle process and already asleep.
 */
s = splhigh();
splx(safepri);
+#ifdef MULTIPROCESSOR
+   if (__mp_lock_held(&kernel_lock)) {
+   hold_count = __mp_release_all(&kernel_lock);
+   __mp_acquire_count(&kernel_lock, hold_count);
+   }
+#endif
splx(s);
return (0);
}
 
sleep_setup(&sls, ident, priority, wmesg);
@@ -149,10 +158,13 @@ int
 msleep(const volatile void *ident, struct mutex *mtx, int priority,
 const char *wmesg, int timo)
 {
struct sleep_state sls;
int error, error1, spl;
+#ifdef MULTIPROCESSOR
+   int hold_count;
+#endif
 
KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
KASSERT(mtx != NULL);
 
if (cold || panicstr) {
@@ -163,10 +175,16 @@ msleep(const volatile void *ident, struct mutex *mtx, int 
priority,
 * in case this is the idle process and already asleep.
 */
spl = MUTEX_OLDIPL(mtx);
MUTEX_OLDIPL(mtx) = safepri;
mtx_leave(mtx);
+#ifdef MULTIPROCESSOR
+   if (__mp_lock_held(&kernel_lock)) {
+   hold_count = __mp_release_all(&kernel_lock);
+   __mp_acquire_count(&kernel_lock, hold_count);
+   }
+#endif
if ((priority & PNORELOCK) == 0) {
mtx_enter(mtx);
MUTEX_OLDIPL(mtx) = spl;
} else
splx(spl);
diff --git sys/kern/vfs_subr.c sys/kern/vfs_subr.c
index a26fbe2..a373789 100644
--- sys/kern/vfs_subr.c
+++ sys/kern/vfs_subr.c
@@ -1664,10 +1664,13 @@ int
 vfs_syncwait(int verbose)
 {
struct buf *bp;
int iter, nbusy, dcount, s;
struct proc *p;
+#ifdef MULTIPROCESSOR
+   int hold_count;
+#endif
 
p = curproc? curproc : &proc0;
sys_sync(p, (void *)0, (register_t *)0);
 
/* Wait for sync to finish. */
@@ -1698,11 +1701,21 @@ vfs_syncwait(int verbose)
}
if (nbusy == 0)
break;
if (verbose)
printf("%d ", nbusy);
+#ifdef MULTIPROCESSOR
+   if (__mp_lock_held(&kernel_lock))
+   hold_count = __mp_release_all(&kernel_lock);
+   else
+   hold_count = 0;
+#endif
DELAY(4 * iter);
+#ifdef MULTIPROCESSOR
+   if (hold_count)
+   __mp_acquire_count(&kernel_lock, hold_count);
+#endif
}
 
return nbusy;
 }
 

Re: Async upd(4) - patch 7/7

[Martin Pieuchot]

On 2015-05-07 04:19, David Higgs wrote:

On Apr 30, 2015, at 7:09 AM, Martin Pieuchot  wrote:
[...]


Your tweaks were good, so I tweaked it further:
- When submit fails, invalidate affected sensors as described above.
- When invalidating sensors, do it recursively.
- When battery is not present, invalidate children but not 
BatteryPresent.


Let me know what you think.


Committed thanks!.

I'm looking forward to see more supported sensors added to upd(4) :)

M.

Re: OpenBSD on Kosagi Novena open-source ARM board/desktop/laptop

[Damien Miller]

On Mon, 11 May 2015, Jonathan Gray wrote:

> Index: imxesdhc.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/imx/imxesdhc.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 imxesdhc.c
> --- imxesdhc.c8 May 2015 03:38:26 -   1.7
> +++ imxesdhc.c11 May 2015 06:57:10 -
> @@ -262,6 +262,9 @@ imxesdhc_attach(struct device *parent, s
>   sc->sc_ih = arm_intr_establish(aa->aa_dev->irq[0], IPL_SDMMC,
>  imxesdhc_intr, sc, sc->sc_dev.dv_xname);
>  
> + HSET4(sc, SDHC_HOST_CTRL_CAP, SDHC_HOST_CTRL_CAP_VS18 |
> + SDHC_HOST_CTRL_CAP_VS30);

no change with this

Re: OpenBSD on Kosagi Novena open-source ARM board/desktop/laptop

[Stefan Sperling]

On Mon, May 11, 2015 at 02:49:14PM +1000, Jonathan Gray wrote:
> Getting at the atheros wlan/mini pcie slot would need something along
> the lines of Patrick's imxpcibr work.

And once you're there you'll need AR9285 support in athn(4) as well.

Or swap in a supported card.
I suppose there's no wifi whitelist in BIOS? ;)

Re: process stuck in a sched_yield() loop

[Stuart Henderson]

On 2015/05/09 16:31, Philip Guenther wrote:
> On Thu, 7 May 2015, David Coppa wrote:
> > Can somebody with the necessary skills help me with this?
> > 
> > $ cd /usr/ports/devel/libinotify/ && make clean fake && make test 
> > 
> > I remember this used to work... Now, most of the times, the
> > 'check_libinotify' process brings the CPU to 100% and it's stuck
> > in a sched_yield() loop:
> 
> Looks like the problem is that while one thread is calling vfork(), 
> another thread does something that acquires the spinlock inside 
> rthread_dl_lock() (probably another vfork).  The child of the vfork tries 
> to acquire the spinlock so that it can release the recursive lock itself 
> and spins forever.  The solution is to have the child reset that lock.  
> I'm unable to reproduce after applying the diff below.

Oh, I wonder if this will fix icinga2...

Re: OpenBSD on Kosagi Novena open-source ARM board/desktop/laptop

[Jonathan Gray]

On Mon, May 11, 2015 at 04:31:30PM +1000, Damien Miller wrote:
> On Mon, 11 May 2015, Jonathan Gray wrote:
> 
> > > If you can get an installation completed (the imxenet is pretty flaky,
> > > possibly because of an all-0 MAC address), then you'll also need to
> > > copy bsd*.IMX.umg to the /boot partition of the sdcard under Linux
> > > (OpenBSD can't access the sdcard yet) and arrange uboot to fatload
> > > it from there. Something like:
> > 
> > There are two sd slots which one doesn't work?
> > 
> > The (internal?) micro-sd slot doesn't have card detect
> > the (external?) normal sized sd slot does
> 
> I haven't tried the external one, but the internal one doesn't work.
> I'm not sure which is which in the dmesg:
> 
> imxesdhc0 at imx0
> sdmmc0 at imxesdhc0
> imxesdhc1 at imx0
> sdmmc1 at imxesdhc1
> ...
> sdmmc1: can't enable card
> 
> -d

That reminds me of the problem I ran into with my bbb a while ago.
Here is what should be the equivalent diff for imx.

Index: imxesdhc.c
===
RCS file: /cvs/src/sys/arch/armv7/imx/imxesdhc.c,v
retrieving revision 1.7
diff -u -p -r1.7 imxesdhc.c
--- imxesdhc.c  8 May 2015 03:38:26 -   1.7
+++ imxesdhc.c  11 May 2015 06:57:10 -
@@ -262,6 +262,9 @@ imxesdhc_attach(struct device *parent, s
sc->sc_ih = arm_intr_establish(aa->aa_dev->irq[0], IPL_SDMMC,
   imxesdhc_intr, sc, sc->sc_dev.dv_xname);
 
+   HSET4(sc, SDHC_HOST_CTRL_CAP, SDHC_HOST_CTRL_CAP_VS18 |
+   SDHC_HOST_CTRL_CAP_VS30);
+
/*
 * Reset the host controller and enable interrupts.
 */