Re: owncloudclient GUI issues - core dumps when non-root

[Otto Moerbeek]

On Wed, May 04, 2016 at 06:58:32AM +0200, Otto Moerbeek wrote:

> On Tue, May 03, 2016 at 09:05:36PM -0400, Nick wrote:
> 
> > Thanks for your advice, however it makes no difference changing login.conf 
> > in the way you mentioned.. Still errors out and core dumps.
> > Root can't get access to it now either. Here's my login.conf, I changed the:
> > 
> > :openfiles-cur=2048:\
> > :openfiles-max=4096:\
> > 
> > on my staff group as well, for which I'm a member of.
> 
> login class != group
> 
> The question is, which login group are you in. Also, the synatx of

err, login class above

> login.conf is a bit tricky. Check which login class you are in with
> useinfo  and check you actual limits with  ulimit -a,

userinfo 

sorry, for the typos, it's early here

> 
>   -Otto
> 
> > 
> > *-*-*-*-*-*-*-*-*-*-*-*-*-* MY LOGIN.CONF: -*-*-*-*-*-*-*-*-*-*-*-*-
> > # /etc/login.conf
> > 
> > default:\
> > :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/$
> > :umask=022:\
> > :datasize-max=2048M:\
> > :datasize-cur=2048M:\
> > :maxproc-max=1024:\
> > :maxproc-cur=512:\
> > :openfiles-cur=2048:\
> > :openfiles-max=4096:\
> > :stacksize-cur=4M:\
> > :localcipher=blowfish,8:\
> > :tc=auth-defaults:\
> > :tc=auth-ftp-defaults:
> > 
> > *-*-*-*-*-*-*-*-*-*-*-*-*-* AS REGULAR USER: -*-*-*-*-*-*-*-*-*-*-*-*-
> > $ owncloud
> > 
> > (owncloud:29572): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> > files
> > 
> > Trace/BPT trap (core dumped)
> > 
> > *-*-*-*-*-*-*-*-*-*-*-*-*-* AND AS ROOT: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> > $ su
> > $ owncloud
> > 
> > (process:3224): GConf-WARNING **: Client failed to connect to the D-BUS 
> > daemon:
> > Did not receive a reply. Possible causes include: the remote application 
> > did not send a reply, the message bus security policy blocked the reply, 
> > the reply timeout expired, or the network connection was broken.
> > 
> > (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS 
> > daemon:
> > Did not receive a reply. Possible causes include: the remote application 
> > did not send a reply, the message bus security policy blocked the reply, 
> > the reply timeout expired, or the network connection was broken.
> > 
> > (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS 
> > daemon:
> > Did not receive a reply. Possible causes include: the remote application 
> > did not send a reply, the message bus security policy blocked the reply, 
> > the reply timeout expired, or the network connection was broken.
> > 
> > (owncloud:3224): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> > files
> > 
> > Trace/BPT trap
> > 
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> > 
> > I can't think what could be causing this issue, not entirely sure how to 
> > debug this.
> > 
> > 
> > 
> >  Original Message 
> > Subject: Re: owncloudclient GUI issues - core dumps when non-root
> > Local Time: May 3, 2016 9:58 PM
> > UTC Time: May 3, 2016 8:58 PM
> > From: zel...@zeloff.org
> > To:
> > CC: misc@openbsd.org
> > 
> > On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote:
> > > The owncloudclient refuses to work and core dumps on non-root user
> > > Works but throws out warnings on root.. although I feel a little edgy 
> > > running this client as root.
> > >
> > > Application: owncloudclient
> > > System: 5.9 Stable
> > >
> > > ###
> > > $ owncloud
> > > (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many 
> > > open files
> > > Trace/BPT trap (core dumped)
> > 
> > You need to bump openfiles on login.conf, e.g.
> > 
> > :openfiles-cur=2048:\
> > :openfiles-max=4096:\
> > 
> > see login.conf(5), and don't forget to run cap_mkdb when you're done.
> > You'll also need to log out and back in for it to take effect. When in
> > doubt check things with ulimit -a and ulimit -Ha
> > 
> > 
> > > $ gdb owncloud owncloud.core
> > > #0 0x066932b634c5 in _g_log_abort ()
> > > from /usr/local/lib/libglib-2.0.so.4200.2
> > >
> > > #
> > >
> > > $ su root
> > > $ owncloud
> > >
> > > (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> > > daemon:
> > > Did not receive a reply. Possible causes include: the remote application 
> > > did not send a reply, the message bus security policy blocked the reply, 
> > > the reply timeout expired, or the network connection was broken.
> > >
> > > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> > > daemon:
> > > Did not receive a reply. Possible causes include: the remote application 
> > > did not send a reply, the message bus security policy blocked the reply, 
> > > the reply timeout expired, or the network connection was broken.
> > > Qt: Session management error: Authentication Rejected, reason : None of 
> > > the authentication protocols specified are supported and host-based 
> > > authentication failed
> > >
> > > 

Re: owncloudclient GUI issues - core dumps when non-root

[Otto Moerbeek]

On Tue, May 03, 2016 at 09:05:36PM -0400, Nick wrote:

> Thanks for your advice, however it makes no difference changing login.conf in 
> the way you mentioned.. Still errors out and core dumps.
> Root can't get access to it now either. Here's my login.conf, I changed the:
> 
> :openfiles-cur=2048:\
> :openfiles-max=4096:\
> 
> on my staff group as well, for which I'm a member of.

login class != group

The question is, which login group are you in. Also, the synatx of
login.conf is a bit tricky. Check which login class you are in with
useinfo  and check you actual limits with  ulimit -a,

-Otto

> 
> *-*-*-*-*-*-*-*-*-*-*-*-*-* MY LOGIN.CONF: -*-*-*-*-*-*-*-*-*-*-*-*-
> # /etc/login.conf
> 
> default:\
> :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/$
> :umask=022:\
> :datasize-max=2048M:\
> :datasize-cur=2048M:\
> :maxproc-max=1024:\
> :maxproc-cur=512:\
> :openfiles-cur=2048:\
> :openfiles-max=4096:\
> :stacksize-cur=4M:\
> :localcipher=blowfish,8:\
> :tc=auth-defaults:\
> :tc=auth-ftp-defaults:
> 
> *-*-*-*-*-*-*-*-*-*-*-*-*-* AS REGULAR USER: -*-*-*-*-*-*-*-*-*-*-*-*-
> $ owncloud
> 
> (owncloud:29572): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> files
> 
> Trace/BPT trap (core dumped)
> 
> *-*-*-*-*-*-*-*-*-*-*-*-*-* AND AS ROOT: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> $ su
> $ owncloud
> 
> (process:3224): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
> 
> (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
> 
> (owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
> 
> (owncloud:3224): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> files
> 
> Trace/BPT trap
> 
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
> 
> I can't think what could be causing this issue, not entirely sure how to 
> debug this.
> 
> 
> 
>  Original Message 
> Subject: Re: owncloudclient GUI issues - core dumps when non-root
> Local Time: May 3, 2016 9:58 PM
> UTC Time: May 3, 2016 8:58 PM
> From: zel...@zeloff.org
> To:
> CC: misc@openbsd.org
> 
> On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote:
> > The owncloudclient refuses to work and core dumps on non-root user
> > Works but throws out warnings on root.. although I feel a little edgy 
> > running this client as root.
> >
> > Application: owncloudclient
> > System: 5.9 Stable
> >
> > ###
> > $ owncloud
> > (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> > files
> > Trace/BPT trap (core dumped)
> 
> You need to bump openfiles on login.conf, e.g.
> 
> :openfiles-cur=2048:\
> :openfiles-max=4096:\
> 
> see login.conf(5), and don't forget to run cap_mkdb when you're done.
> You'll also need to log out and back in for it to take effect. When in
> doubt check things with ulimit -a and ulimit -Ha
> 
> 
> > $ gdb owncloud owncloud.core
> > #0 0x066932b634c5 in _g_log_abort ()
> > from /usr/local/lib/libglib-2.0.so.4200.2
> >
> > #
> >
> > $ su root
> > $ owncloud
> >
> > (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> > daemon:
> > Did not receive a reply. Possible causes include: the remote application 
> > did not send a reply, the message bus security policy blocked the reply, 
> > the reply timeout expired, or the network connection was broken.
> >
> > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> > daemon:
> > Did not receive a reply. Possible causes include: the remote application 
> > did not send a reply, the message bus security policy blocked the reply, 
> > the reply timeout expired, or the network connection was broken.
> > Qt: Session management error: Authentication Rejected, reason : None of the 
> > authentication protocols specified are supported and host-based 
> > authentication failed
> >
> > (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> > daemon:
> > Did not receive a reply. Possible causes include: the remote application 
> > did not send a reply, the message bus security policy blocked the reply, 
> > the reply timeout expired, or the network connection was broken.
> 
> This doesn't crash /probably/ because owncloud using root's owncloud
> configuration (whatever 

Re: Openbsd broke my hard drive twice! Getting frustrated

[Gabriel Guzman]

On 12/29, Gabriel Guzman wrote:
> I've been seeing a similar issue on a DELL XPS 13" Developer edition I got
> back in June -- ran fine with ubuntu as shipped with Dell, and then I 
> wiped and installed OpenBSD and now can't even access the BIOS.  

I figured out the issue.  On my machine (DEL XPS 13) it was the "Intel
Rapid Boot" option in BIOS.  Disabling that resolved all my boot issues.
I can now boot with MBR or GPT off the internal SSD.  And, I can also
access the BIOS with the internal SSD installed in the system (this was
not possible before)

gabe. 

Re: getentropy(2) and random(4) at boot

[Theo de Raadt]

> The random(4) device on FreeBSD will block until the generator is
> seeded [0], but not after, unless kern.random.sys.seeded is changed.
> 
> Is this the case for getentropy(2) or random(4) on OpenBSD, and if
> not, would it be a good idea to make it do so?
> 
> [0] https://www.freebsd.org/cgi/man.cgi?query=random=4

it does not need to block, because it is *always* seeded.

http://www.openbsd.org/papers/hackfest2014-arc4random/index.html

getentropy(2) and random(4) at boot

[Delan Azabani]

The random(4) device on FreeBSD will block until the generator is
seeded [0], but not after, unless kern.random.sys.seeded is changed.

Is this the case for getentropy(2) or random(4) on OpenBSD, and if
not, would it be a good idea to make it do so?

[0] https://www.freebsd.org/cgi/man.cgi?query=random=4

Re: Short maximum interpreter length

[Donald Allen]

On Tue, May 3, 2016 at 9:21 PM, Ted Unangst  wrote:
> Aioi Yuuko wrote:
>> Why is MAXINTERP in  only 128? I can think of a few:
>>
>> 1. It's been that way a while and nobody's complained
>> 2. If someone's shebangs are longer than that, they're probably doing 
>> whatever they're doing horribly, horribly wrong
>> 3. Historical compatibility
>>
>> Is it one of those? If not, is it something else?
>
> Why does it need to be more?

So we can run 
/usr/bin/5CBC4234CA9D027019381215FAFB31E6482D4B252A36E1EBD5FCFAD12F9E10B85C4C2C917E3DBE6C765CED9719F4F449C47AC9263513458BBEA76B617339B75A
scripts.

Re: Short maximum interpreter length

[Ted Unangst]

Aioi Yuuko wrote:
> Why is MAXINTERP in  only 128? I can think of a few:
> 
> 1. It's been that way a while and nobody's complained
> 2. If someone's shebangs are longer than that, they're probably doing 
> whatever they're doing horribly, horribly wrong
> 3. Historical compatibility
> 
> Is it one of those? If not, is it something else?

Why does it need to be more?

Re: owncloudclient GUI issues - core dumps when non-root

[Nick]

Thanks for your advice, however it makes no difference changing login.conf in 
the way you mentioned.. Still errors out and core dumps.
Root can't get access to it now either. Here's my login.conf, I changed the:

:openfiles-cur=2048:\
:openfiles-max=4096:\

on my staff group as well, for which I'm a member of.

*-*-*-*-*-*-*-*-*-*-*-*-*-* MY LOGIN.CONF: -*-*-*-*-*-*-*-*-*-*-*-*-
# /etc/login.conf

default:\
:path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/$
:umask=022:\
:datasize-max=2048M:\
:datasize-cur=2048M:\
:maxproc-max=1024:\
:maxproc-cur=512:\
:openfiles-cur=2048:\
:openfiles-max=4096:\
:stacksize-cur=4M:\
:localcipher=blowfish,8:\
:tc=auth-defaults:\
:tc=auth-ftp-defaults:

*-*-*-*-*-*-*-*-*-*-*-*-*-* AS REGULAR USER: -*-*-*-*-*-*-*-*-*-*-*-*-
$ owncloud

(owncloud:29572): GLib-ERROR **: Creating pipes for GWakeup: Too many open files

Trace/BPT trap (core dumped)

*-*-*-*-*-*-*-*-*-*-*-*-*-* AND AS ROOT: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
$ su
$ owncloud

(process:3224): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

(owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

(owncloud:3224): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

(owncloud:3224): GLib-ERROR **: Creating pipes for GWakeup: Too many open files

Trace/BPT trap

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

I can't think what could be causing this issue, not entirely sure how to debug 
this.



 Original Message 
Subject: Re: owncloudclient GUI issues - core dumps when non-root
Local Time: May 3, 2016 9:58 PM
UTC Time: May 3, 2016 8:58 PM
From: zel...@zeloff.org
To:
CC: misc@openbsd.org

On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote:
> The owncloudclient refuses to work and core dumps on non-root user
> Works but throws out warnings on root.. although I feel a little edgy running 
> this client as root.
>
> Application: owncloudclient
> System: 5.9 Stable
>
> ###
> $ owncloud
> (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> files
> Trace/BPT trap (core dumped)

You need to bump openfiles on login.conf, e.g.

:openfiles-cur=2048:\
:openfiles-max=4096:\

see login.conf(5), and don't forget to run cap_mkdb when you're done.
You'll also need to log out and back in for it to take effect. When in
doubt check things with ulimit -a and ulimit -Ha


> $ gdb owncloud owncloud.core
> #0 0x066932b634c5 in _g_log_abort ()
> from /usr/local/lib/libglib-2.0.so.4200.2
>
> #
>
> $ su root
> $ owncloud
>
> (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
>
> (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
> Qt: Session management error: Authentication Rejected, reason : None of the 
> authentication protocols specified are supported and host-based 
> authentication failed
>
> (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.

This doesn't crash /probably/ because owncloud using root's owncloud
configuration (whatever that is), i.e., it's not monitoring the same
folder as when it is run by you.

>
> -*-*-*
>
> Thanks
>

--

Short maximum interpreter length

[Aioi Yuuko]

Why is MAXINTERP in  only 128? I can think of a few:

1. It's been that way a while and nobody's complained
2. If someone's shebangs are longer than that, they're probably doing whatever 
they're doing horribly, horribly wrong
3. Historical compatibility

Is it one of those? If not, is it something else?

Re: FW: Re: watchdog suport for new hardware

[Mike Larkin]

On Tue, May 03, 2016 at 03:32:34PM -0500, Chase Davis wrote:
> Mike,
> 
> We took your suggestion and re-wrote the driver to model sdhc_acpi. I
> have attached the new code. However, the match function never returns
> a 1. We put temporary print statements in the match routine. It is
> being called several times during the kernel boot process, but it
> never finds a device with HID SEL0002. Do you have any suggestions for
> why it would show up in the DSDT tables when we do an acpidump, but
> that the match routine never finds it?
> 
> This is a snippet from the dmesg boot log
> 
> Attempting to match SEL: result (0)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> Attempting to match SEL: result (0)
> Attempting to match SEL: result (0)
> Attempting to match SEL: result (0)
> Attempting to match SEL: result (0)
> acpihpet0 at acpi0: 14318179 Hz
> Attempting to match SEL: result (0)
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> 
> int
> sel_acpi_match(struct device *parent, void *match, void *aux)
> {
> struct acpi_attach_args *aaa = aux;
> struct cfdata *cf = match;
> printf("Attempting to match SEL: ");
> int res = acpi_matchhids(aaa, sel_hids, cf->cf_driver->cd_name);
> printf("result (%d)\n", res);
> return res;
> }
> 
> Thanks,
> Chase

I think this diff is missing some parts. Like GENERIC?

Also, you need a NULL after your last HID or matchhids will walk all
through memory until it hits a NULL.

-ml

> /*$OpenBSD: sel.c,v 1.0 2016/04/01 05:00:00 jsg Exp $ */
> /*
>  * Copyright (c) 2016 PREMIER System Integrators
>  *
>  * Permission to use, copy, modify, and distribute this software for any
>  * purpose with or without fee is hereby granted, provided that the above
>  * copyright notice and this permission notice appear in all copies.
>  *
>  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
>  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
>  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
>  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
>  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
>  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>  *
>  * Schweitzer Engineering Laboratories: SEL-3355 Embedded controller
> */
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include 
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #include 
> 
> struct sel_host;
> 
> struct sel_softc {
>   /* sc_dev must be the first item in the struct */
>   struct device   sc_dev;
>   struct sel_host **sc_host;
> };
> 
> struct sel_acpi_softc {
>   struct sel_softcsc;
>   struct acpi_softc   *sc_acpi;
>   struct aml_node *sc_node;
> 
>   /* device access through bus space */
>   bus_space_tag_t sc_iot;
>   bus_space_handle_t  sc_ioh;
>   bus_addr_t  sc_addr;
>   bus_size_t  sc_size;
> 
>   struct sel_host *sc_host;
> };
> 
> int sel_wait(bus_space_tag_t, bus_space_handle_t, bool);
> 
> /* Autoconfiguration glue */
> int sel_acpi_match(struct device *, void *, void *);
> void sel_acpi_attach(struct device *, struct device *, void *);
> int sel_print(void *, const char *);
> int sel_wd_cb(void *, int);
> 
> /* functions to interact with the controller */
> void sel_write_wdog(bus_space_tag_t, bus_space_handle_t, int);
> u_int8_t sel_read_wdog(bus_space_tag_t, bus_space_handle_t);
> u_int8_t sel_read_status(bus_space_tag_t, bus_space_handle_t);
> void sel_abort(bus_space_tag_t, bus_space_handle_t);
> u_int32_t sel_read_boardid(bus_space_tag_t, bus_space_handle_t);
> u_int32_t sel_read_mcversion(bus_space_tag_t, bus_space_handle_t);
> u_int16_t sel_read_pciboardid(bus_space_tag_t, bus_space_handle_t);
> u_int8_t sel_read_ledctl0(bus_space_tag_t, bus_space_handle_t);
> void sel_write_ledctl0(bus_space_tag_t, bus_space_handle_t, u_int8_t);
> u_int8_t sel_read_ledctl1(bus_space_tag_t, bus_space_handle_t);
> void sel_write_ledctl1(bus_space_tag_t, bus_space_handle_t, u_int8_t);
> u_int8_t sel_read_miscctl0(bus_space_tag_t, bus_space_handle_t);
> u_int8_t sel_read_miscctl1(bus_space_tag_t, bus_space_handle_t);
> void sel_read_modelno(bus_space_tag_t, bus_space_handle_t, char*);
> void sel_read_serialno(bus_space_tag_t, bus_space_handle_t, char*);
> void sel_read_configid(bus_space_tag_t, bus_space_handle_t, char*);
> 
> /* macros to extract bits from the status register */
> #define EC_STATUS_IBF(status) (((status) >> 0x1) & 0x1)
> #define EC_STATUS_OBF(status) (((status) & 0x1))
> #define EC_STATUS_BUSY(status)(((status) >> 0x4) & 0x1)
> #define EC_STATUS_STATE(status)   (((status) >> 0x6) & 0x3)
> 
> struct cfattach sel_acpi_ca = {
>   sizeof(struct sel_acpi_softc), sel_acpi_match, sel_acpi_attach
> };
> 
> struct 

Re: owncloudclient GUI issues - core dumps when non-root

[Zé Loff]

On Tue, May 03, 2016 at 04:20:37PM -0400, Nick wrote:
> The owncloudclient refuses to work and core dumps on non-root user
> Works but throws out warnings on root.. although I feel a little edgy running 
> this client as root.
> 
> Application: owncloudclient
> System: 5.9 Stable
> 
> ###
> $ owncloud
> (owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open 
> files
> Trace/BPT trap (core dumped)

You need to bump openfiles on login.conf, e.g.

  :openfiles-cur=2048:\
  :openfiles-max=4096:\

see login.conf(5), and don't forget to run cap_mkdb when you're done.
You'll also need to log out and back in for it to take effect. When in
doubt check things with ulimit -a and ulimit -Ha


> $ gdb owncloud owncloud.core
> #0 0x066932b634c5 in _g_log_abort ()
> from /usr/local/lib/libglib-2.0.so.4200.2
> 
> #
> 
> $ su root
> $ owncloud
> 
> (process:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
> 
> (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.
> Qt: Session management error: Authentication Rejected, reason : None of the 
> authentication protocols specified are supported and host-based 
> authentication failed
> 
> (owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
> daemon:
> Did not receive a reply. Possible causes include: the remote application did 
> not send a reply, the message bus security policy blocked the reply, the 
> reply timeout expired, or the network connection was broken.

This doesn't crash /probably/ because owncloud using root's owncloud
configuration (whatever that is), i.e., it's not monitoring the same
folder as when it is run by you.

> 
> -*-*-*
> 
> Thanks
> 

-- 

Re: FW: Re: watchdog suport for new hardware

[Chase Davis]

Mike,

We took your suggestion and re-wrote the driver to model sdhc_acpi. I
have attached the new code. However, the match function never returns
a 1. We put temporary print statements in the match routine. It is
being called several times during the kernel boot process, but it
never finds a device with HID SEL0002. Do you have any suggestions for
why it would show up in the DSDT tables when we do an acpidump, but
that the match routine never finds it?

This is a snippet from the dmesg boot log

Attempting to match SEL: result (0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
Attempting to match SEL: result (0)
Attempting to match SEL: result (0)
Attempting to match SEL: result (0)
Attempting to match SEL: result (0)
acpihpet0 at acpi0: 14318179 Hz
Attempting to match SEL: result (0)
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat

int
sel_acpi_match(struct device *parent, void *match, void *aux)
{
struct acpi_attach_args *aaa = aux;
struct cfdata *cf = match;
printf("Attempting to match SEL: ");
int res = acpi_matchhids(aaa, sel_hids, cf->cf_driver->cd_name);
printf("result (%d)\n", res);
return res;
}

Thanks,
Chase

[demime 1.01d removed an attachment of type text/x-csrc which had a name of 
sel_acpi.c]

[demime 1.01d removed an attachment of type text/x-chdr which had a name of 
selreg.h]

owncloudclient GUI issues - core dumps when non-root

[Nick]

The owncloudclient refuses to work and core dumps on non-root user
Works but throws out warnings on root.. although I feel a little edgy running 
this client as root.

Application: owncloudclient
System: 5.9 Stable

###
$ owncloud
(owncloud:30815): GLib-ERROR **: Creating pipes for GWakeup: Too many open files
Trace/BPT trap (core dumped)

$ gdb owncloud owncloud.core
#0 0x066932b634c5 in _g_log_abort ()
from /usr/local/lib/libglib-2.0.so.4200.2

#

$ su root
$ owncloud

(process:12834): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

(owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
daemon:
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
Qt: Session management error: Authentication Rejected, reason : None of the 
authentication protocols specified are supported and host-based authentication 
failed

(owncloud:12834): GConf-WARNING **: Client failed to connect to the D-BUS 
daemon:
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.

-*-*-*

Thanks

owncloud forgetting stored user and admin passwords. 5.9-Stable

[Nick]

I have been having these issues with owncloud on 5.9 Stable where I will go to 
log in and says password is wrong, I have two set ups - one in the cloud and 
one at home, both are randomly doing this. My partner had to change password 8 
times last night before it would actually work on next log back in login.

Anyone else been having similar issues?

Re: Will mmap and the read buffer cache be unified, anyone working with it?

[Tinker]

A separate question about combining mmap access and file
IO in the current absence of a unified buffer cache:

If I have a readonly mmap and do fwrite to it, could I use
fsync (or msync or any other call) right after the fwrite, as a tool to 
guarantee that the memory mapping interface is up to date?



Also between the fwrite and that call, the possible data inconsistency 
would be limited to the particular bytes written right?


On 2015-11-12 15:45, Stuart Henderson wrote:

Re: mfs vs tmpfs: advantages and disadvantages

[bytevolcano]

On Tue, 03 May 2016 02:53:36 -0600
Theo de Raadt  wrote:

> mfs is reliable.

> tmpfs has bugs, and as a result of those bugs, it has fewer and fewer
> users.

> Or, maybe there are fewer problem reports because fewer people use
> it, because those who tried to use it ran into problems and walked
> away from it?

Thanks Theo, that explains a lot. The future doesn't look too good for
tmpfs in this case.

> Absolutely no way, that makes no sense.

Understood; I wasn't going to write anything until I was sure anyway.

Re: mfs vs tmpfs: advantages and disadvantages

[bytevolcano]

I actually wrote a patch to that a while back, and it was not accepted.
Looking back, I am not disappointed that it was rejected, and it forced
me to find another solution: shell scripts, included below.

However, in light of what Theo said, I'm possibly going to move back to
mfs; even if I haven't had any issues with tmpfs yet, I feel
the need to be somewhat proactive.

Whilst not exactly Michelangelo's finest work of art, it's probably
better than the original set of patches I submitted.


I use the following in /etc/fstab:

swap /var/log tmpfs.sh rw,nodev,noexec,nosuid,-s=64M,-P=/M/var/log


Stored in /sbin/mount_tmpfs.sh:

#!/bin/sh

while getopts :g:m:n:o:P:s:u: OPT; do
if [ "$OPT" == 'P' ]; then
TEMPLATE=$OPTARG
else
MCPARAM="$MCPARAM -$OPT $OPTARG"
fi
done
shift `expr $OPTIND - 1`

/sbin/mount_tmpfs $MCPARAM $*

if [ "$TEMPLATE" != "" ]; then
shift `expr $# - 1`
(cd "$TEMPLATE"; /bin/pax -rw -pe . "$1")
fi
 


On Tue, 3 May 2016 04:57:54 -0400
Jiri B  wrote:

> On Tue, May 03, 2016 at 05:08:06PM +1000, bytevolc...@safe-mail.net
> wrote:
> > With tmpfs being in the tree for the last 2+ years (since OpenBSD
> > 5.5), I would like to ask, besides the "-P" option in mount_mfs,
> > what is the advantage of using mfs over tmpfs?  
> 
> tmpfs on Bitrig does support snapshots, which can be used as an
> alternative to mpf's "-P". If you are interested check it out.
> 
> j.

rwhod in 5.9 ?

[stan]

Building 5.9 machines to replace 5.5 ones. Looking in /usr/src on the 5.9
machines, I do not see the code for rwhod. Has this been removed, and if
so, why? We use this on all of our mahcines.


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: mfs vs tmpfs: advantages and disadvantages

[Jiri B]

On Tue, May 03, 2016 at 05:08:06PM +1000, bytevolc...@safe-mail.net wrote:
> With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5),
> I would like to ask, besides the "-P" option in mount_mfs, what is the
> advantage of using mfs over tmpfs?

tmpfs on Bitrig does support snapshots, which can be used as an alternative
to mpf's "-P". If you are interested check it out.

j.

Re: mfs vs tmpfs: advantages and disadvantages

[Theo de Raadt]

> With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5),
> I would like to ask, besides the "-P" option in mount_mfs, what is the
> advantage of using mfs over tmpfs?

mfs is reliable.

> It seems tmpfs has the following advantages:
> 
>  - Can grow or shrink; shrinks when files are erased.
>  - Can impose definite limits on number of inodes/files (then again,
>this happens in mfs too).
>  - Dedicated memory structures used, rather than just plonking an
>entire disk FS onto it.

tmpfs has bugs, and as a result of those bugs, it has fewer and fewer
users.

> I have seen discussions here:
> http://marc.info/?l=openbsd-tech=139935771507987=2
> 
> There is a claim that tmpfs is not as stable on that thread, but that
> was back in 2014 when this was still new.

Or, maybe there are fewer problem reports because fewer people use
it, because those who tried to use it ran into problems and walked
away from it?

> I am willing to write a patch (or series of patches) to remove mfs
> support if it is deemed to be unused/unnecessary; unfortunately I only
> have access to an old amd64 machine for testing.

Absolutely no way, that makes no sense.

mfs vs tmpfs: advantages and disadvantages

[bytevolcano]

Hello,

With tmpfs being in the tree for the last 2+ years (since OpenBSD 5.5),
I would like to ask, besides the "-P" option in mount_mfs, what is the
advantage of using mfs over tmpfs?

It seems tmpfs has the following advantages:

 - Can grow or shrink; shrinks when files are erased.
 - Can impose definite limits on number of inodes/files (then again,
   this happens in mfs too).
 - Dedicated memory structures used, rather than just plonking an
   entire disk FS onto it.

I have seen discussions here:
http://marc.info/?l=openbsd-tech=139935771507987=2

There is a claim that tmpfs is not as stable on that thread, but that
was back in 2014 when this was still new.

I am willing to write a patch (or series of patches) to remove mfs
support if it is deemed to be unused/unnecessary; unfortunately I only
have access to an old amd64 machine for testing.

Thoughts?

Re: Laptop not waking from suspend on opening lid

[Anthony Campbell]

On 03 May 2016, Anthony Campbell wrote:
> On 02 May 2016, Mike Larkin wrote:
> > On Sun, May 01, 2016 at 04:08:28PM +0100, Anthony Campbell wrote:
> > > This is on a Thinkpad Z61m running amd64. Suspend on lid closure has
> > > worked without problems for many months with numerous snapshots. After
> > > upgrading on 30 April the machine no longer wakes on lid opening. The
> > > sleep symbol below the screen blinks repeatedly but nothing else
> > > happens.
> > > 
> > > If I suspend it with Fn+F4 the same thing happens; it is impossible to
> > > wake the machine.
> > > 
> > > Another Thinkpad running i386 is not affected.
> > > 
> > 
> > When did it last work? Eg, when before "30 April"?
> > 
> > -ml
> > 
> 
> Yes, it was fine with pretty regular snapsot upgrades until 30 April.
> The problem began after that upgrade. A further upgrade on 1 May did not
> restore things.
> 

I forgot to say that the same problem, also beginning on 30 April, was
discussed on openbsd-bugs@. The suggestion there was that it was only
occurring on one laptop, but clearly that isn't the case since I have it
too. See  http://marc.info/?l=openbsd-bugs=145979568820455=2.

Anthony
-- 
Anthony Campbellhttp://www.acampbell.uk

Re: Laptop not waking from suspend on opening lid

[Anthony Campbell]

On 02 May 2016, Mike Larkin wrote:
> On Sun, May 01, 2016 at 04:08:28PM +0100, Anthony Campbell wrote:
> > This is on a Thinkpad Z61m running amd64. Suspend on lid closure has
> > worked without problems for many months with numerous snapshots. After
> > upgrading on 30 April the machine no longer wakes on lid opening. The
> > sleep symbol below the screen blinks repeatedly but nothing else
> > happens.
> > 
> > If I suspend it with Fn+F4 the same thing happens; it is impossible to
> > wake the machine.
> > 
> > Another Thinkpad running i386 is not affected.
> > 
> 
> When did it last work? Eg, when before "30 April"?
> 
> -ml
> 

Yes, it was fine with pretty regular snapsot upgrades until 30 April.
The problem began after that upgrade. A further upgrade on 1 May did not
restore things.

Anthony



-- 
Anthony Campbellhttp://www.acampbell.uk