On Mon, Oct 24, 2016 at 3:01 PM, Mark Kettenis wrote:
>> Date: Mon, 24 Oct 2016 23:01:22 +0300
>> From: Paul Irofti
>>
>> On Mon, Oct 24, 2016 at 10:50:00PM +0300, Paul Irofti wrote:
>> > On Mon, Oct 24, 2016 at 07:46:33PM +0200, Mark Kettenis wrote:
>>
> Date: Mon, 24 Oct 2016 23:01:22 +0300
> From: Paul Irofti
>
> On Mon, Oct 24, 2016 at 10:50:00PM +0300, Paul Irofti wrote:
> > On Mon, Oct 24, 2016 at 07:46:33PM +0200, Mark Kettenis wrote:
> > > > From: Paul Irofti
> > > > Date: Mon, 24 Oct 2016 17:12:01
On Mon, Oct 24, 2016 at 10:50:00PM +0300, Paul Irofti wrote:
> On Mon, Oct 24, 2016 at 07:46:33PM +0200, Mark Kettenis wrote:
> > > From: Paul Irofti
> > > Date: Mon, 24 Oct 2016 17:12:01 +0300
> > >
> > > Any thoughts on this?
> >
> > Sorry, yes. Adding the crs "index" as the
On Mon, Oct 24, 2016 at 07:46:33PM +0200, Mark Kettenis wrote:
> > From: Paul Irofti
> > Date: Mon, 24 Oct 2016 17:12:01 +0300
> >
> > Any thoughts on this?
>
> Sorry, yes. Adding the crs "index" as the last argument of the
> callback function seems a bit non-intuitive to me.
15:34
> CÄtre: "Mark Kettenis" <mark.kette...@xs4all.nl>
> Cc: "guent...@gmail.com" <guent...@gmail.com>; "tech@openbsd.org"
> <tech@openbsd.org>
> Subiect: Re: acpiec on acer aspire S7 with CURRENT
>
> > I'm not really happy about
Any thoughts on this?
-Mesaj original-
De la: "Paul Irofti" <p...@irofti.net>
Trimis: 22.10.2016 15:34
Către: "Mark Kettenis" <mark.kette...@xs4all.nl>
Cc: "guent...@gmail.com" <guent...@gmail.com>; "tech@openbsd.org"
> I'm not really happy about the use of the static variable in the
> resource parsing function. It feels like the aml_parse_resource API
> should be changed to pass the resource number to the callback
> function.
I hated doing that as well, but I was afraid it wouldn't be justified to
change the
> Date: Fri, 21 Oct 2016 10:37:08 +0300
> From: Paul Irofti
>
> On Tue, Oct 18, 2016 at 09:01:59PM -0700, Ilya Kaliman wrote:
> > Thanks! Now everything seems to work. Minor tweak - maybe need extra
> > newline after "acpiec0 at acpi0"
>
> New diff that fixes the printfs,
Works for me. Ok.
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0
acpiec0: Not running on HW-Reduced ACPI type 8
acpiec0: invalid resource #3 type 134
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at
On Tue, Oct 18, 2016 at 09:01:59PM -0700, Ilya Kaliman wrote:
> Thanks! Now everything seems to work. Minor tweak - maybe need extra
> newline after "acpiec0 at acpi0"
New diff that fixes the printfs, removes dead code (suggested by
guenther@) and takes care of some small style(9) nits. OK?
Thanks! Now everything seems to work. Minor tweak - maybe need extra
newline after "acpiec0 at acpi0"
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0acpiec0: Not running on HW-Reduced ACPI type
On Tue, Oct 18, 2016 at 10:22:06AM -0700, Ilya Kaliman wrote:
> Hi!
>
> The patch seems to work partially - acpiec now gets initialized. The
> suspend-on-lid-close does not work anymore, though (it works with my
> initial patch).
Right, that's because I had an off-by-one in the switch case. I
Hi!
The patch seems to work partially - acpiec now gets initialized. The
suspend-on-lid-close does not work anymore, though (it works with my
initial patch).
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0acpiec0: invalid
> Perhaps acpiec should use aml_parse_resource() instead of the hand-crafted
> parsing it does right now? That would solve the second problem, at
> least.
Like this?
To the OP can you please test this diff on your system and let me know
if it fixes things?
I will move on to adding support
On Fri, 14 Oct 2016, Ilya Kaliman wrote:
> dmesg:
> OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep 8 16:32:34 PDT 2016
> i...@puffy.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
..
> acpiec0 at acpi0: Failed to read resource settings
...
> acpidump:
I've taken a brief look at this. The
dmesg:
OpenBSD 6.0 (GENERIC.MP) #1: Thu Sep 8 16:32:34 PDT 2016
i...@puffy.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 8468033536 (8075MB)
avail mem = 8206921728 (7826MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at
> Which acpi table should I attach?
Use sendbug(1). See also
http://www.openbsd.org/report.html#bugtypes
Hi!
Thanks for looking into this. I've tried the patch and the "found GPIO
port" printf is not triggered because sc->sc_acpi->sc_hw_reduced is 0
for me.
Which acpi table should I attach?
Thanks,
Ilya
RSD PTR: Checksum=188, OEMID=ACRSYS, RsdtAddress=0x9aafe124
RSDT: Length=112, Revision=1,
> The diff you sent simply ignores the issue which obviously can not be
> used in the tree.
The following diff starts working in the right direction, but there is
probably more to do in order to support machines like yours.
It would be interesting to see if that printf gets triggered though, so
On Mon, Oct 10, 2016 at 03:04:33PM -0700, Ilya Kaliman wrote:
> Hi tech,
>
> while trying the latest snapshot I've noticed that the following
> warning is printed to a console several times a second (this does not
> happen in 6.0):
>
> acpi0: WARNING EC not initialized
>
> The investigation
Hi tech,
while trying the latest snapshot I've noticed that the following
warning is printed to a console several times a second (this does not
happen in 6.0):
acpi0: WARNING EC not initialized
The investigation shows that the acpiec initialization fails in
acpiec.c line 484:
if (size != 2 ||
21 matches
Mail list logo