Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 7:16 PM Daniel Eischen  wrote:
>
> On Tue, 13 Nov 2018, Conrad Meyer wrote:
>
> > On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> >> I've attached it.  If it gets filtered by the mail list, I'll
> >> make it http accessible.
> >
> > Thanks Daniel.
> >
> > It looks like your hostbridge zero device has a different device id
> > than in my first generation Ryzen system.  Would you please try the
> > following patch and see if it attaches on your system?  I don't
> > actually have documentation for Ryzen 2, unfortunately, so I'm not
> > totally sure if the SMN is accessed in the same way for the new
> > hostbridge device id.  The change below should at least attempt
> > attaching to hostb0 on your system.
>
> That seems to have done the trick, thanks!  Output
> attached.

Thanks for the quick test!  I've committed Johannes' substantially
similar patch as r340425.

Cheers,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rebecca Cran]

On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote:

> The 2700 has an offset of 0 though (2700X has 10).
> And I'm seeing a difference of more than 30 degrees. I guess something
> else must be happening here.

I had thought 54 was the right offset for my 2990WX system, but now it's under 
load building ports the temperature reported via dev.amdtemp is 183C! 
Meanwhile the readout on the motherboard says "CPU Temp 53 C".

-- 
Rebecca


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Conrad Meyer wrote:


On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:

I've attached it.  If it gets filtered by the mail list, I'll
make it http accessible.


Thanks Daniel.

It looks like your hostbridge zero device has a different device id
than in my first generation Ryzen system.  Would you please try the
following patch and see if it attaches on your system?  I don't
actually have documentation for Ryzen 2, unfortunately, so I'm not
totally sure if the SMN is accessed in the same way for the new
hostbridge device id.  The change below should at least attempt
attaching to hostb0 on your system.


That seems to have done the trick, thanks!  Output
attached.

--
 DEnet.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.usb.template: -1
kstat.zfs.misc.arcstats.arc_tempreserve: 0
kstat.zfs.misc.zcompstats.attempts: 18438
dev.amdtemp.0.core0.sensor0: 28.1C
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.%parent: hostb0
dev.amdtemp.0.%pnpinfo: 
dev.amdtemp.0.%location: 
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent: 
dev.cpu.7.temperature: 28.1C
dev.cpu.6.temperature: 28.1C
dev.cpu.5.temperature: 28.1C
dev.cpu.4.temperature: 28.1C
dev.cpu.3.temperature: 28.1C
dev.cpu.2.temperature: 28.1C
dev.cpu.1.temperature: 28.1C
dev.cpu.0.temperature: 28.1C
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Of course, Johannes has already thought of this!  See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228480 and
https://reviews.freebsd.org/D15567 .
On Tue, Nov 13, 2018 at 6:41 PM Conrad Meyer  wrote:
>
> On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> > I've attached it.  If it gets filtered by the mail list, I'll
> > make it http accessible.
>
> Thanks Daniel.
>
> It looks like your hostbridge zero device has a different device id
> than in my first generation Ryzen system.  Would you please try the
> following patch and see if it attaches on your system?  I don't
> actually have documentation for Ryzen 2, unfortunately, so I'm not
> totally sure if the SMN is accessed in the same way for the new
> hostbridge device id.  The change below should at least attempt
> attaching to hostb0 on your system.
>
> diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
> index 17792dd922cd..6fe36b4cc4da 100644
> --- a/sys/dev/amdsmn/amdsmn.c
> +++ b/sys/dev/amdsmn/amdsmn.c
> @@ -60,7 +60,8 @@ struct amdsmn_softc {
>  static struct pciid {
> uint32_tdevice_id;
>  } amdsmn_ids[] = {
> -   { 0x14501022 },
> +   { 0x14501022 }, /* Ryzen */
> +   { 0x15d01022 }, /* Ryzen 2 */
>  };
>
>  /*
> diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
> index 2463212c25f5..765e660a8461 100644
> --- a/sys/dev/amdtemp/amdtemp.c
> +++ b/sys/dev/amdtemp/amdtemp.c
> @@ -102,6 +102,7 @@ static struct amdtemp_product {
> { VENDORID_AMD, DEVICEID_AMD_MISC16_M30H },
> { VENDORID_AMD, DEVICEID_AMD_MISC17 },
> { VENDORID_AMD, DEVICEID_AMD_HOSTB17H },
> +   { VENDORID_AMD, 0x15d0 },
>  };
>
>  /*
>
>
> Thanks,
> Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191

Kubilay Kocak  changed:

   What|Removed |Added

Summary|Cannot check battery status |Cannot check battery status
   |after upgrading to  |after upgrading to
   |12-CURRENT after r330957|12-CURRENT after r330957
   |(ACPI problems) |(ACPI _STA method removed)
 CC||curr...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 6:26 PM Daniel Eischen  wrote:
> I've attached it.  If it gets filtered by the mail list, I'll
> make it http accessible.

Thanks Daniel.

It looks like your hostbridge zero device has a different device id
than in my first generation Ryzen system.  Would you please try the
following patch and see if it attaches on your system?  I don't
actually have documentation for Ryzen 2, unfortunately, so I'm not
totally sure if the SMN is accessed in the same way for the new
hostbridge device id.  The change below should at least attempt
attaching to hostb0 on your system.

diff --git a/sys/dev/amdsmn/amdsmn.c b/sys/dev/amdsmn/amdsmn.c
index 17792dd922cd..6fe36b4cc4da 100644
--- a/sys/dev/amdsmn/amdsmn.c
+++ b/sys/dev/amdsmn/amdsmn.c
@@ -60,7 +60,8 @@ struct amdsmn_softc {
 static struct pciid {
uint32_tdevice_id;
 } amdsmn_ids[] = {
-   { 0x14501022 },
+   { 0x14501022 }, /* Ryzen */
+   { 0x15d01022 }, /* Ryzen 2 */
 };

 /*
diff --git a/sys/dev/amdtemp/amdtemp.c b/sys/dev/amdtemp/amdtemp.c
index 2463212c25f5..765e660a8461 100644
--- a/sys/dev/amdtemp/amdtemp.c
+++ b/sys/dev/amdtemp/amdtemp.c
@@ -102,6 +102,7 @@ static struct amdtemp_product {
{ VENDORID_AMD, DEVICEID_AMD_MISC16_M30H },
{ VENDORID_AMD, DEVICEID_AMD_MISC17 },
{ VENDORID_AMD, DEVICEID_AMD_HOSTB17H },
+   { VENDORID_AMD, 0x15d0 },
 };

 /*


Thanks,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Conrad Meyer wrote:


Hi Daniel,

On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen  wrote:


Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.


Maybe not.  If they do not attach, it suggests that maybe the Ryzen 2
has a different hostbridge PCI devid.


...
The amdtemp module loads fine (including the dependent amdsmn), but
doesn't report any temperature related sysctls.


Can you run 'devinfo -v' and send or paste the output?  Thank you.


I've attached it.  If it gets filtered by the mail list, I'll
make it http accessible.

--
DEnexus0
  cryptosoft0
  vtvga0
  apic0
  ram0
  acpi0
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
  acpi_perf0
  hwpstate0
  acpi_throttle0
  cpufreq0
cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.P001
  acpi_perf1
  hwpstate1
  acpi_throttle1
cpu2 pnpinfo _HID=none _UID=0 at handle=\_PR_.P002
  acpi_perf2
  hwpstate2
  acpi_throttle2
cpu3 pnpinfo _HID=none _UID=0 at handle=\_PR_.P003
  acpi_perf3
  hwpstate3
  acpi_throttle3
cpu4 pnpinfo _HID=none _UID=0 at handle=\_PR_.P004
  acpi_perf4
  hwpstate4
  acpi_throttle4
cpu5 pnpinfo _HID=none _UID=0 at handle=\_PR_.P005
  acpi_perf5
  hwpstate5
  acpi_throttle5
cpu6 pnpinfo _HID=none _UID=0 at handle=\_PR_.P006
  acpi_perf6
  hwpstate6
  acpi_throttle6
cpu7 pnpinfo _HID=none _UID=0 at handle=\_PR_.P007
  acpi_perf7
  hwpstate7
  acpi_throttle7
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P008
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P009
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00A
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00B
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00C
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00D
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00E
unknown pnpinfo _HID=none _UID=0 at handle=\_PR_.P00F
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
  pci0
hostb0 pnpinfo vendor=0x1022 device=0x15d0 subvendor=0x1043 
subdevice=0x876b class=0x06 at slot=0 function=0 dbsf=pci0:0:0:0 
handle=\_SB_.PCI0.D004
unknown pnpinfo vendor=0x1022 device=0x15d1 subvendor=0x1022 
subdevice=0x15d1 class=0x080600 at slot=0 function=2 dbsf=pci0:0:0:2 
handle=\_SB_.PCI0.IOMA
hostb1 pnpinfo vendor=0x1022 device=0x1452 subvendor=0x 
subdevice=0x class=0x06 at slot=1 function=0 dbsf=pci0:0:1:0
pcib1 pnpinfo vendor=0x1022 device=0x15d3 subvendor=0x1043 
subdevice=0x876b class=0x060400 at slot=1 function=2 dbsf=pci0:0:1:2 
handle=\_SB_.PCI0.GPP1
  pci1
xhci0 pnpinfo vendor=0x1022 device=0x43d0 subvendor=0x1b21 
subdevice=0x1142 class=0x0c0330 at slot=0 function=0 dbsf=pci0:1:0:0 
handle=\_SB_.PCI0.GPP1.PTXH
  usbus0
uhub2
ahci0 pnpinfo vendor=0x1022 device=0x43c8 subvendor=0x1b21 
subdevice=0x1062 class=0x010601 at slot=0 function=1 dbsf=pci0:1:0:1 
handle=\_SB_.PCI0.GPP1.PT01
  ahcich0 at channel=0
  ahcich1 at channel=1
  ahcich2 at channel=2
  ahcich3 at channel=3
  ahcich4 at channel=4
  ahcich5 at channel=5
  ahcich6 at channel=6
  ahcich7 at channel=7
pcib2 pnpinfo vendor=0x1022 device=0x43c6 subvendor=0x1b21 
subdevice=0x0201 class=0x060400 at slot=0 function=2 dbsf=pci0:1:0:2 
handle=\_SB_.PCI0.GPP1.PT02
  pci2
pcib3 pnpinfo vendor=0x1022 device=0x43c7 subvendor=0x1b21 
subdevice=0x3306 class=0x060400 at slot=0 function=0 dbsf=pci0:2:0:0 
handle=\_SB_.PCI0.GPP1.PT02.PT20
  pci3
pcib4 pnpinfo vendor=0x1022 device=0x43c7 subvendor=0x1b21 
subdevice=0x3306 class=0x060400 at slot=4 function=0 dbsf=pci0:2:4:0 
handle=\_SB_.PCI0.GPP1.PT02.PT24
  pci4
xhci1 pnpinfo vendor=0x1b21 device=0x1242 subvendor=0x1043 
subdevice=0x8675 class=0x0c0330 at slot=0 function=0 dbsf=pci0:4:0:0 
handle=\_SB_.PCI0.GPP1.PT02.PT24.AS42
  usbus1
uhub0
  ukbd0 pnpinfo vendor=0x046d product=0xc31c 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x6400 mode=host 
intclass=0x03 intsubclass=0x01 intprotocol=0x01 at bus=1 hubaddr=1 port=3 
devaddr=2 interface=0 ugen=ugen1.2
  uhid0 pnpinfo vendor=0x046d product=0xc31c 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x6400 mode=host 
intclass=0x03 intsubclass=0x00 intprotocol=0x00 at bus=1 hubaddr=1 port=3 
devaddr=2 interface=1 ugen=ugen1.2
  ums0 pnpinfo vendor=0x046d product=0xc014 
devclass=0x00 devsubclass=0x00 devproto=0x00 sernum="" release=0x0340 mode=h

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 5:15 PM Rozhuk Ivan  wrote:
>
> On Tue, 13 Nov 2018 19:41:47 -0500
> Daniel Eischen  wrote:
>
> > >> I'm trying to track down a couple of things.  amdtemp doesn't
> > >> report any temperature sensors, and acpi seems to have some
> > >> errors.  Not sure if they are related.
> > >
> > > It s a bit legacy )
> > > Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> > > does not use amdsmn.
> >
> > Thanks, I think?!  I tried it and it panic'd as soon as it was
> > kldload'd.  I don't have the trace back handy, but it was in a mtx
> > lock after a pci_write.  I'm running 13-current, so it could be
> > something different between that and -stable or whatever you're
> > testing it on.
>
>
> I do not test it on 13.
> Make sure that you have not amdtemp and amdsmn built in kernel and that they 
> not loaded.

Your amdtemp_rtc_temp_sysctl has a lock recursion bug and any
INVARIANTS kernel will panic running it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 19:41:47 -0500
Daniel Eischen  wrote:

> >> I'm trying to track down a couple of things.  amdtemp doesn't
> >> report any temperature sensors, and acpi seems to have some
> >> errors.  Not sure if they are related.  
> > 
> > It s a bit legacy )
> > Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> > does not use amdsmn.  
> 
> Thanks, I think?!  I tried it and it panic'd as soon as it was
> kldload'd.  I don't have the trace back handy, but it was in a mtx
> lock after a pci_write.  I'm running 13-current, so it could be
> something different between that and -stable or whatever you're
> testing it on.


I do not test it on 13.
Make sure that you have not amdtemp and amdsmn built in kernel and that they 
not loaded.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

Hi Daniel,

On Tue, Nov 13, 2018 at 10:01 AM Daniel Eischen  wrote:
>
> Greetings,
>
> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.

Maybe not.  If they do not attach, it suggests that maybe the Ryzen 2
has a different hostbridge PCI devid.

> ...
> The amdtemp module loads fine (including the dependent amdsmn), but
> doesn't report any temperature related sysctls.

Can you run 'devinfo -v' and send or paste the output?  Thank you.

All the best,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

> On Nov 13, 2018, at 2:06 PM, Rozhuk Ivan  wrote:
> 
> On Tue, 13 Nov 2018 12:59:59 -0500 (EST)
> Daniel Eischen  wrote:
> 
>> I'm trying to track down a couple of things.  amdtemp doesn't
>> report any temperature sensors, and acpi seems to have some
>> errors.  Not sure if they are related.
> 
> It s a bit legacy )
> Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> does not use amdsmn.

Thanks, I think?!  I tried it and it panic'd as soon as it was kldload'd.  I 
don't have the trace back handy, but it was in a mtx lock after a pci_write.  
I'm running 13-current, so it could be something different between that and 
-stable or whatever you're testing it on.

--
DE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Stefan Ehmann]

On 11/13/18 10:14 PM, Conrad Meyer wrote:
> On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann  wrote:
>> After kldload amdtemp I see the following sysctls:
>> dev.cpu.0.temperature: 77.1C
>> dev.amdtemp.0.core0.sensor0: 77.1C
>>
>> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
>> know if just the offset is wrong or the numbers are completely bogus.
>>
>> Numbers from sysutils/xmbmon look saner but not sure if they are correct.
> 
> You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
> amdtemp sysctl gives you the unadjusted value.  On different Ryzen
> models the raw value is wrong by different amounts.  E.g. on my 1950X,
> I have sensor_offset set to "-27" to show correct temperature
> readings.
> 
> See this link for a table of offset values for various Ryzen models:
> https://www.guru3d.com/articles-pages/amd-ryzen-7-2700-review,7.html

Thanks for the link.

The 2700 has an offset of 0 though (2700X has 10).
And I'm seeing a difference of more than 30 degrees. I guess something
else must be happening here.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Stefan Ehmann]

On 11/13/18 10:40 PM, Daniel Eischen wrote:
> 
>> On Nov 13, 2018, at 4:02 PM, Stefan Ehmann  wrote:
>>
>>> On 11/13/18 8:59 PM, Daniel Eischen wrote:
>>>> On Tue, 13 Nov 2018, Greg V wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
>>>> wrote:
>>>>> Greetings,
>>>>>
>>>>> I'm trying to track down a couple of things.  amdtemp doesn't
>>>>> report any temperature sensors, and acpi seems to have some
>>>>> errors.  Not sure if they are related.
>>>>>
>>>>> These are the ACPI-related warnings and errors during boot.
>>>>>
>>>>>Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
>>>>> valid Length but zero Address: 0x/0x1
>>>>> (20181031/tbfadt-796)
>>>>
>>>> I see this one on my R7 1700 / X370 system, seems harmless.
>>
>> I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
>> But I don't get the Firmware errors below.
> 
> What BIOS version are you using?  I'm running 13-current built from just a 
> few days ago.  Never had any temp sysctls since initial install (beginning of 
> October).

Latest Version (4024), but I think I've tried it before with an older
version. Didn't notice any differences though.

But I guess amdtemp is more dependent on the CPU than on the main board.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 13:14:46 -0800
Conrad Meyer  wrote:

> You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
> amdtemp sysctl gives you the unadjusted value.  On different Ryzen
> models the raw value is wrong by different amounts.  E.g. on my 1950X,
> I have sensor_offset set to "-27" to show correct temperature
> readings.
> 

Looks like new AGESA/BIOS change something, my fork of amdtemp now show (read) 
same value as on onboard led in "CurTmpTjSel"
...
dev.amdtemp.0.rtc.CurTmpTjSel: 47.7C
dev.amdtemp.0.rtc.CurTmp: 96.7C
...
49C diff, this was some sort of offset for older AMD CPU, used to calc 
CurTmpTjSel then it set to 3.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

> On Nov 13, 2018, at 4:02 PM, Stefan Ehmann  wrote:
> 
>> On 11/13/18 8:59 PM, Daniel Eischen wrote:
>>> On Tue, 13 Nov 2018, Greg V wrote:
>>> 
>>> 
>>> 
>>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
>>> wrote:
>>>> Greetings,
>>>> 
>>>> I'm trying to track down a couple of things.  amdtemp doesn't
>>>> report any temperature sensors, and acpi seems to have some
>>>> errors.  Not sure if they are related.
>>>> 
>>>> These are the ACPI-related warnings and errors during boot.
>>>> 
>>>>Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
>>>> valid Length but zero Address: 0x/0x1
>>>> (20181031/tbfadt-796)
>>> 
>>> I see this one on my R7 1700 / X370 system, seems harmless.
> 
> I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
> But I don't get the Firmware errors below.

What BIOS version are you using?  I'm running 13-current built from just a few 
days ago.  Never had any temp sysctls since initial install (beginning of 
October).

>>>>acpi0:  on motherboard
>>>>Firmware Error (ACPI): Failure creating [\134_SB.SMIC],
>>>> AE_ALREADY_EXISTS (20181031/dswload2-477)
>>>>ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
>>>> (20181031/psobject-372)
>>>>Firmware Error (ACPI): Failure creating [\134_SB.SMIB],
>>>> AE_ALREADY_EXISTS (20181031/dsfield-803)
>>> 
>>> Looks like people see these on Linux:
>>> 
>>> https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5
>>> 
>>> 
>>> Are you on the latest firmware ("BIOS") revision for your board?
>> 
>> Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
>> BIOS from 2018 September 21, version 4024.
>> 
>>   https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/
>> 
> 
> After kldload amdtemp I see the following sysctls:
> dev.cpu.0.temperature: 77.1C
> dev.amdtemp.0.core0.sensor0: 77.1C
> 
> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
> know if just the offset is wrong or the numbers are completely bogus.
> 
> Numbers from sysutils/xmbmon look saner but not sure if they are correct.

Yeah, I don't have any sensors detected, but my BIOS reports around 39C, right 
around the same as yours.  There are both motherboard and CPU temps in BIOS, 
reporting just a couple of degrees difference.

Overall, this system is very stable, haven't had any crashes or hangs.

--
DE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Conrad Meyer]

On Tue, Nov 13, 2018 at 1:04 PM Stefan Ehmann  wrote:
> After kldload amdtemp I see the following sysctls:
> dev.cpu.0.temperature: 77.1C
> dev.amdtemp.0.core0.sensor0: 77.1C
>
> The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
> know if just the offset is wrong or the numbers are completely bogus.
>
> Numbers from sysutils/xmbmon look saner but not sure if they are correct.

You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
amdtemp sysctl gives you the unadjusted value.  On different Ryzen
models the raw value is wrong by different amounts.  E.g. on my 1950X,
I have sensor_offset set to "-27" to show correct temperature
readings.

See this link for a table of offset values for various Ryzen models:
https://www.guru3d.com/articles-pages/amd-ryzen-7-2700-review,7.html

Take care,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Stefan Ehmann]

On 11/13/18 8:59 PM, Daniel Eischen wrote:
> On Tue, 13 Nov 2018, Greg V wrote:
> 
>>
>>
>> On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen 
>> wrote:
>>> Greetings,
>>>
>>> I'm trying to track down a couple of things.  amdtemp doesn't
>>> report any temperature sensors, and acpi seems to have some
>>> errors.  Not sure if they are related.
>>>
>>> These are the ACPI-related warnings and errors during boot.
>>>
>>>    Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has
>>> valid Length but zero Address: 0x/0x1
>>> (20181031/tbfadt-796)
>>
>> I see this one on my R7 1700 / X370 system, seems harmless.

I also see this warning on the X470-pro with Ryzen 7 2700 on 12.0-BETA.
But I don't get the Firmware errors below.

>>>    acpi0:  on motherboard
>>>    Firmware Error (ACPI): Failure creating [\134_SB.SMIC],
>>> AE_ALREADY_EXISTS (20181031/dswload2-477)
>>>    ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog
>>> (20181031/psobject-372)
>>>    Firmware Error (ACPI): Failure creating [\134_SB.SMIB],
>>> AE_ALREADY_EXISTS (20181031/dsfield-803)
>>
>> Looks like people see these on Linux:
>>
>> https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5
>>
>>
>> Are you on the latest firmware ("BIOS") revision for your board?
> 
> Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
> BIOS from 2018 September 21, version 4024.
> 
>   https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/
> 

After kldload amdtemp I see the following sysctls:
dev.cpu.0.temperature: 77.1C
dev.amdtemp.0.core0.sensor0: 77.1C

The temperature I see in BIOS is much lower (maybe around 40.0C). Don't
know if just the offset is wrong or the numbers are completely bogus.

Numbers from sysutils/xmbmon look saner but not sure if they are correct.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

On Tue, 13 Nov 2018, Greg V wrote:




On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?


Yes, it's an ASUS Prime X-470 PRO, and I'm running with the latest
BIOS from 2018 September 21, version 4024.

  https://www.asus.com/us/Motherboards/PRIME-X470-PRO/HelpDesk_BIOS/

--
DE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Greg V]

On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  
wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has 
valid Length but zero Address: 0x/0x1 
(20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 12:59:59 -0500 (EST)
Daniel Eischen  wrote:

> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.

It s a bit legacy )
Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
does not use amdsmn.

On newer BIOS it swap CurTmpTjSel and CurTmp, and CurTmp show >90C.
I dont know why, @cem may know.

dev.amdtemp.0.htc.PslApicLoEn: 1
dev.amdtemp.0.htc.PslApicHiEn: 1
dev.amdtemp.0.htc.HtcActSts: 1
dev.amdtemp.0.htc.HtcAct: 1
dev.amdtemp.0.htc.HtcPstateLimit: 7
dev.amdtemp.0.htc.HtcSlewSel: 1
dev.amdtemp.0.htc.HtcLock: 1
dev.amdtemp.0.htc.HtcEn: 1
dev.amdtemp.0.htc.HtcHystLmt: 7.6C
dev.amdtemp.0.htc.HtcTmpLmt: 115.6C
dev.amdtemp.0.tts.core1.sensor1_offset: 0
dev.amdtemp.0.tts.core1.sensor0_offset: 0
dev.amdtemp.0.tts.core1.sensor1: -0.9C
dev.amdtemp.0.tts.core1.sensor0: -0.9C
dev.amdtemp.0.tts.core0.sensor1_offset: 0
dev.amdtemp.0.tts.core0.sensor0_offset: 0
dev.amdtemp.0.tts.core0.sensor1: -0.9C
dev.amdtemp.0.tts.core0.sensor0: -0.9C
dev.amdtemp.0.tts.thermtrip: 0
dev.amdtemp.0.tts.sense: 1
dev.amdtemp.0.tts.enable: 0
dev.amdtemp.0.tts.DiodeOffset: 13
dev.amdtemp.0.tts.TjOffset: 0
dev.amdtemp.0.rtc.sensor_offset: 0
dev.amdtemp.0.rtc.PerStepTimeUp: 15
dev.amdtemp.0.rtc.PerStepTimeDn: 15
dev.amdtemp.0.rtc.TmpMaxDiffUp: 3
dev.amdtemp.0.rtc.TmpSlewDnEn: 1
dev.amdtemp.0.rtc.CurTmpTjSel: 1.6C
dev.amdtemp.0.rtc.CurTmp: 50.6C
dev.amdtemp.0.%parent: hostb10
dev.amdtemp.0.%pnpinfo: 
dev.amdtemp.0.%location: 
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent: 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Daniel Eischen]

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid 
Length but zero Address: 0x/0x1 (20181031/tbfadt-796)

   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], AE_ALREADY_EXISTS 
(20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], AE_ALREADY_EXISTS 
(20181031/dsfield-803)

The amdtemp module loads fine (including the dependent amdsmn), but
doesn't report any temperature related sysctls.

   $ sysctl -a | grep temp
   cd0: Attempt to query device size failed: NOT READY, Medium not present - 
tray closed
   cd0: Attempt to query device size failed: NOT READY, Medium not present- 
tray closed
   net.inet6.ip6.use_tempaddr: 0
   net.inet6.ip6.temppltime: 86400
   net.inet6.ip6.tempvltime: 604800
   net.inet6.ip6.prefer_tempaddr: 0
   hw.usb.template: -1
   kstat.zfs.misc.arcstats.arc_tempreserve: 0
   kstat.zfs.misc.zcompstats.attempts: 135280

Here's the relevent CPU line from dmesg.

   CPU: AMD Ryzen 5 2400G with Radeon Vega Graphics (3593.34-MHz K8-class 
CPU)
 Origin="AuthenticAMD"  Id=0x810f10  Family=0x17  Model=0x11  Stepping=0
 
Features=0x178bfbff
 
Features2=0x7ed8320b
 AMD Features=0x2e500800
 AMD 
Features2=0x35c233ff
 Structured Extended 
Features=0x209c01a9
 XSAVE Features=0xf
 AMD Extended Feature Extensions ID EBX=0x1007
 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
 TSC: P-state invariant, performance statistics

The full dmesg, /usr/sbin/acpidump -dt, and apcica-tools acpudumps
(with and without -s) are here:

   https://people.freebsd.org/~deischen/2400g/dmesg.txt
   https://people.freebsd.org/~deischen/2400g/acpidump.txt
   https://people.freebsd.org/~deischen/2400g/acpica.acpidump.txt

Thanks

--
DE
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Harry Schmalzbauer]

Am 15.08.2018 um 10:43 schrieb Vladimir Zakharov:

Hello!

On Tue, Aug 14, 2018, Pete Wright wrote:

On 8/14/18 6:13 PM, Kyle Evans wrote:

On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:

i also attempted to boot using UEFI but the system hangs very early in the
boot process.  i have reverted to legacy mode for now so that i can work,
but am keen to test out any patches or do any other debugging that is
needed.

Hi Pete,

Where in the process does it hang with UEFI? I can't help much with
any of your other problems, but I am curious about this one. =)

sure thing - the last several lines are:

random: fast provider: "Intel Secure Key RNG"
kbd1 at kbdmux0
netmap: loaded module
nexus0

at this point it hangs.  let me know if you want me to try booting with
verbose output to dmesg or something.

I've updated from r337734 and got the same here with HP Probook 430 G2.
Setting efi.rt.disabled=1 in /boot/loader.conf fixed the problem for me.

# uname -a
FreeBSD vzakharov 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #24 r337829: Wed Aug 15 
06:33:54 MSK 2018
root@vzakharov:/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64



I can confirm efi.rt.disabled=1 in /boot/loader.conf fixes my problem 
too, which I posted in reply to Kyle's r337773 hint (non-bootable (UEFI, 
geli, ZFS) kernel on haswell [Was: Re: CURRENT from today throws lots of 
ACPI errors, lost HDMI detection])


Machine here is DH87MC+i3-4330 (LynxPoint/Series8+haswell)

-harry
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

non-bootable (UEFI, geli, ZFS) kernel on haswell [Was: Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection]

[Harry Schmalzbauer]

Am 15.08.2018 um 06:01 schrieb Kyle Evans:

On Tue, Aug 14, 2018 at 10:56 PM, Pete Wright  wrote:

On 8/14/18 8:45 PM, Kyle Evans wrote:

On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright  wrote:

On 8/14/18 6:13 PM, Kyle Evans wrote:

On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright 
wrote:

i also attempted to boot using UEFI but the system hangs very early in
the
boot process.  i have reverted to legacy mode for now so that i can
work,
but am keen to test out any patches or do any other debugging that is
needed.

Hi Pete,

Where in the process does it hang with UEFI? I can't help much with
any of your other problems, but I am curious about this one. =)

sure thing - the last several lines are:

random: fast provider: "Intel Secure Key RNG"
kbd1 at kbdmux0
netmap: loaded module
nexus0

at this point it hangs.  let me know if you want me to try booting with
verbose output to dmesg or something.


Are you running GENERIC, or custom config? Any modules loaded?



this is a GENERIC kernel using ZFS as well as GELI full disk encryption.


Good to know, thanks!


Hello,

me too here, kind of...
Machine resets after nexus0 – took my SLR with 1s exposure time to make 
sure there's no more GOP output available :-(
Haven't tried efi.rt.disabled=1 yet, since I had to spend some time to 
get the old kernel in place.

non-booting kernel inquestion is custom r337804.
Like Pete, I'm booting from a ZFS pool utilizing GOP, load_geli, zfs, 
aesni, nut my machine dosen't hang after "nexus0" but hard resets.
The modules loaded don't influence the problem, even with only "kernel" 
(which is MINIMAL_config + very view devices/filesystems added) loaded, 
the machine resets after "nexus0".


Will try efi.rt.disabled=1 tomorrow.
Anyone intending to update a haswell/UEFI machine (Intel DH87MC in my 
case, with INVPCID microcode updated BIOS) could run into simialr 
situation I guess, so please make sure to be prepared...


My first suspicion were side effects of r337715.  But this is just a 
wild guess, haven't bisected anything yet.


Thanks,

-harry

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[O. Hartmann]

On Tue, 14 Aug 2018 20:41:03 -0700
Pete Wright  wrote:

> On 8/14/18 6:13 PM, Kyle Evans wrote:
> > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:  
> >> i also attempted to boot using UEFI but the system hangs very early in the
> >> boot process.  i have reverted to legacy mode for now so that i can work,
> >> but am keen to test out any patches or do any other debugging that is
> >> needed.  
> > Hi Pete,
> >
> > Where in the process does it hang with UEFI? I can't help much with
> > any of your other problems, but I am curious about this one. =)  
> sure thing - the last several lines are:
> 
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> netmap: loaded module
> nexus0

Similar situation same here on a Lenovo ThinkPad E540, except that the netmpa
message occurs prior to "random: fast provider: "Intel Secure Key RNG"


> 
> at this point it hangs.  let me know if you want me to try booting with 
> verbose output to dmesg or something.
> 
> 
> cheers,
> -pete
> 
>

Other UEFI booting systems (oldish Asrock Z77-Pro4/Pro4-M) throw some infos
shortly after booting the kernel which look like the stuff I can see from the
UEFI loader very early - but it is to fast to catch with the naked eye. The
boxes reboot and spinning booting this way. 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Vladimir Zakharov]

Hello!

On Tue, Aug 14, 2018, Pete Wright wrote:
> 
> On 8/14/18 6:13 PM, Kyle Evans wrote:
> > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:
> > > i also attempted to boot using UEFI but the system hangs very early in the
> > > boot process.  i have reverted to legacy mode for now so that i can work,
> > > but am keen to test out any patches or do any other debugging that is
> > > needed.
> > Hi Pete,
> > 
> > Where in the process does it hang with UEFI? I can't help much with
> > any of your other problems, but I am curious about this one. =)
> sure thing - the last several lines are:
> 
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> netmap: loaded module
> nexus0
> 
> at this point it hangs.  let me know if you want me to try booting with
> verbose output to dmesg or something.

I've updated from r337734 and got the same here with HP Probook 430 G2.
Setting efi.rt.disabled=1 in /boot/loader.conf fixed the problem for me.

# uname -a
FreeBSD vzakharov 12.0-ALPHA1 FreeBSD 12.0-ALPHA1 #24 r337829: Wed Aug 15 
06:33:54 MSK 2018
root@vzakharov:/home/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[O. Hartmann]

On Tue, 14 Aug 2018 20:41:03 -0700
Pete Wright  wrote:

> On 8/14/18 6:13 PM, Kyle Evans wrote:
> > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:  
> >> i also attempted to boot using UEFI but the system hangs very early in the
> >> boot process.  i have reverted to legacy mode for now so that i can work,
> >> but am keen to test out any patches or do any other debugging that is
> >> needed.  
> > Hi Pete,
> >
> > Where in the process does it hang with UEFI? I can't help much with
> > any of your other problems, but I am curious about this one. =)  
> sure thing - the last several lines are:
> 
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> netmap: loaded module
> nexus0

Similar situation same here on a Lenovo ThinkPad E540, except that the netmpa
message occurs prior to "random: fast provider: "Intel Secure Key RNG"


> 
> at this point it hangs.  let me know if you want me to try booting with 
> verbose output to dmesg or something.
> 
> 
> cheers,
> -pete
> 
>

Other UEFI booting systems (oldish Asrock Z77-Pro4/Pro4-M) throw some infos
shortly after booting the kernel which look like the stuff I can see from the
UEFI loader very early - but it is to fast to catch with the naked eye. The
boxes reboot and spinning booting this way. 


Addon: this is with CURRENT r337832

Last known working version for me is: r337718

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Pete Wright]

On 8/14/18 9:06 PM, Pete Wright wrote:


On 8/14/18 9:01 PM, Kyle Evans wrote:



I'm curious if you've been bitten somehow by recently enabling EFIRT
in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
see where that gets you?


i did attempt to set that in loader.conf - and it progressed farther 
but

kernel panic'd when trying to bring up my iwn wireless interface.


Interesting... out of side curiosity, what does this panic look like?
Can you also try running a kernel >= r337773 with kib's patch from [1]
applied to make sure this the EFI part of this isn't already solved?


sure i can give that a spin.


i'm building an older version in an attempt to bisect this issue (i 
have a
skylake system running a checkout from monday without issues, so 
testing

that now).  if i am still running into problems i'll boot with
efi.rt.disabled=1 and will post the gdb panic string here.


Excellent.


so i have reverted back to this git hash:
90f37b39e4a

https://github.com/freebsd/freebsd/commit/90f37b39e4ad481d3e5a059123f7d68ac153f0c5 



and i can confirm that i am able to boot with EFI enabled, do not 
experience any issues bringing up my iwn interface and HDMI is 
recognized according to xrandr.  so that solves my immediate problem! 
:)  interestingly enough i still see the ACPI errors I reported 
earlier, but perhaps that is a red herring.


i'll go back to the tip of master and apply kib's patch and see how it 
goes.



ok great (thank's ccache for making buildkernel fast :) )

so after applying the patch from kib i have the same behavior as i'm 
seeing on git hash 90f37b39e4a.


i.e. boots fine with UEFI enabled, iwn interface comes up, HDMI output 
is detected by xrandr and interesting ACPI warning messages.


i'll dogfood this patch tomorrow when i get into the office and validate 
connecting my HDMI display works as expected and will report any other 
issues i bump into.


thanks for your help Kyle!  I didn't think to test kib's patch as i was 
assuming my issue was related to the ACPI errors, but this seems to get 
me back to where i need to be to work tomorrow so i'm good to go :)


-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Pete Wright]

On 8/14/18 9:01 PM, Kyle Evans wrote:



I'm curious if you've been bitten somehow by recently enabling EFIRT
in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
see where that gets you?


i did attempt to set that in loader.conf - and it progressed farther but
kernel panic'd when trying to bring up my iwn wireless interface.


Interesting... out of side curiosity, what does this panic look like?
Can you also try running a kernel >= r337773 with kib's patch from [1]
applied to make sure this the EFI part of this isn't already solved?


sure i can give that a spin.



i'm building an older version in an attempt to bisect this issue (i have a
skylake system running a checkout from monday without issues, so testing
that now).  if i am still running into problems i'll boot with
efi.rt.disabled=1 and will post the gdb panic string here.


Excellent.


so i have reverted back to this git hash:
90f37b39e4a

https://github.com/freebsd/freebsd/commit/90f37b39e4ad481d3e5a059123f7d68ac153f0c5

and i can confirm that i am able to boot with EFI enabled, do not 
experience any issues bringing up my iwn interface and HDMI is 
recognized according to xrandr.  so that solves my immediate problem! 
:)  interestingly enough i still see the ACPI errors I reported earlier, 
but perhaps that is a red herring.


i'll go back to the tip of master and apply kib's patch and see how it goes.

-p

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Kyle Evans]

On Tue, Aug 14, 2018 at 10:56 PM, Pete Wright  wrote:
>
> On 8/14/18 8:45 PM, Kyle Evans wrote:
>>
>> On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright  wrote:
>>>
>>> On 8/14/18 6:13 PM, Kyle Evans wrote:

 On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright 
 wrote:
>
> i also attempted to boot using UEFI but the system hangs very early in
> the
> boot process.  i have reverted to legacy mode for now so that i can
> work,
> but am keen to test out any patches or do any other debugging that is
> needed.

 Hi Pete,

 Where in the process does it hang with UEFI? I can't help much with
 any of your other problems, but I am curious about this one. =)
>>>
>>> sure thing - the last several lines are:
>>>
>>> random: fast provider: "Intel Secure Key RNG"
>>> kbd1 at kbdmux0
>>> netmap: loaded module
>>> nexus0
>>>
>>> at this point it hangs.  let me know if you want me to try booting with
>>> verbose output to dmesg or something.
>>>
>> Are you running GENERIC, or custom config? Any modules loaded?
>
>
>
> this is a GENERIC kernel using ZFS as well as GELI full disk encryption.
>

Good to know, thanks!

>
>>
>> I'm curious if you've been bitten somehow by recently enabling EFIRT
>> in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
>> see where that gets you?
>
>
> i did attempt to set that in loader.conf - and it progressed farther but
> kernel panic'd when trying to bring up my iwn wireless interface.
>

Interesting... out of side curiosity, what does this panic look like?
Can you also try running a kernel >= r337773 with kib's patch from [1]
applied to make sure this the EFI part of this isn't already solved?

>
> i'm building an older version in an attempt to bisect this issue (i have a
> skylake system running a checkout from monday without issues, so testing
> that now).  if i am still running into problems i'll boot with
> efi.rt.disabled=1 and will post the gdb panic string here.
>

Excellent.

> -pete
>

Thanks,

Kyle Evans

[1] https://lists.freebsd.org/pipermail/freebsd-current/2018-August/070660.html
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Pete Wright]

On 8/14/18 8:45 PM, Kyle Evans wrote:

On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright  wrote:

On 8/14/18 6:13 PM, Kyle Evans wrote:

On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:

i also attempted to boot using UEFI but the system hangs very early in
the
boot process.  i have reverted to legacy mode for now so that i can work,
but am keen to test out any patches or do any other debugging that is
needed.

Hi Pete,

Where in the process does it hang with UEFI? I can't help much with
any of your other problems, but I am curious about this one. =)

sure thing - the last several lines are:

random: fast provider: "Intel Secure Key RNG"
kbd1 at kbdmux0
netmap: loaded module
nexus0

at this point it hangs.  let me know if you want me to try booting with
verbose output to dmesg or something.


Are you running GENERIC, or custom config? Any modules loaded?



this is a GENERIC kernel using ZFS as well as GELI full disk encryption.




I'm curious if you've been bitten somehow by recently enabling EFIRT
in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
see where that gets you?


i did attempt to set that in loader.conf - and it progressed farther but 
kernel panic'd when trying to bring up my iwn wireless interface.



i'm building an older version in an attempt to bisect this issue (i have 
a skylake system running a checkout from monday without issues, so 
testing that now).  if i am still running into problems i'll boot with 
efi.rt.disabled=1 and will post the gdb panic string here.


-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Kyle Evans]

On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright  wrote:
>
> On 8/14/18 6:13 PM, Kyle Evans wrote:
>>
>> On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:
>>>
>>> i also attempted to boot using UEFI but the system hangs very early in
>>> the
>>> boot process.  i have reverted to legacy mode for now so that i can work,
>>> but am keen to test out any patches or do any other debugging that is
>>> needed.
>>
>> Hi Pete,
>>
>> Where in the process does it hang with UEFI? I can't help much with
>> any of your other problems, but I am curious about this one. =)
>
> sure thing - the last several lines are:
>
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> netmap: loaded module
> nexus0
>
> at this point it hangs.  let me know if you want me to try booting with
> verbose output to dmesg or something.
>

Are you running GENERIC, or custom config? Any modules loaded?

I'm curious if you've been bitten somehow by recently enabling EFIRT
in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and
see where that gets you?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Pete Wright]

On 8/14/18 6:13 PM, Kyle Evans wrote:

On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:

i also attempted to boot using UEFI but the system hangs very early in the
boot process.  i have reverted to legacy mode for now so that i can work,
but am keen to test out any patches or do any other debugging that is
needed.

Hi Pete,

Where in the process does it hang with UEFI? I can't help much with
any of your other problems, but I am curious about this one. =)

sure thing - the last several lines are:

random: fast provider: "Intel Secure Key RNG"
kbd1 at kbdmux0
netmap: loaded module
nexus0

at this point it hangs.  let me know if you want me to try booting with 
verbose output to dmesg or something.



cheers,
-pete


--

Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Kyle Evans]

On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:
> i also attempted to boot using UEFI but the system hangs very early in the
> boot process.  i have reverted to legacy mode for now so that i can work,
> but am keen to test out any patches or do any other debugging that is
> needed.

Hi Pete,

Where in the process does it hang with UEFI? I can't help much with
any of your other problems, but I am curious about this one. =)

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CURRENT from today throws lots of ACPI errors, lost HDMI detection

[Pete Wright]

howdy,
running code from today and having lots of issues.  when i boot the 
system (a kabylake laptop) using legacy mode in the BIOS i see lots of 
these errors are thrown in dmesg:


acpi0:  on motherboard
Firmware Error (ACPI): Failure creating 
[\134_SB.PCI0.XHC.RHUB.HS01._UPC], AE_ALREADY_EXISTS (20180810/dswload2-468)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20180810/psobject-372)

ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689)
Firmware Error (ACPI): Failure creating 
[\134_SB.PCI0.XHC.RHUB.HS01._PLD], AE_ALREADY_EXISTS (20180810/dswload2-468)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20180810/psobject-372)

ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689)
Firmware Error (ACPI): Failure creating 
[\134_SB.PCI0.XHC.RHUB.HS02._UPC], AE_ALREADY_EXISTS (20180810/dswload2-468)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20180810/psobject-372)

ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689)
Firmware Error (ACPI): Failure creating 
[\134_SB.PCI0.XHC.RHUB.HS02._PLD], AE_ALREADY_EXISTS (20180810/dswload2-468)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20180810/psobject-372)

ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689)
Firmware Error (ACPI): Failure creating 
[\134_SB.PCI0.XHC.RHUB.HS03._UPC], AE_ALREADY_EXISTS (20180810/dswload2-468)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20180810/psobject-372)

ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689)


there are lots more, i can post a pastebin link if needed.

i also attempted to boot using UEFI but the system hangs very early in 
the boot process.  i have reverted to legacy mode for now so that i can 
work, but am keen to test out any patches or do any other debugging that 
is needed.


thx!
-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

For those not on the bug, this is being followed up in PR 230290.

On Wed, Aug 1, 2018 at 10:27 PM, Johannes Lundberg  wrote:
>
>
> On Thu, Aug 2, 2018 at 06:20 Andriy Gapon  wrote:
>>
>> On 02/08/2018 01:17, Conrad Meyer wrote:
>> > I don't understand the concern.  There is only one listener to the
>> > event and it just invokes ReqSleepState, which is responsible for
>> > performing all suspend behavior.  The behavior is identical between
>> > lid close and acpiconf.
>>
>> Unless someone is adding a new listener for that event.
>
>
> Exactly my point.
>
>>
>> --
>> Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Ian Lepore]

On Thu, 2018-08-02 at 08:20 +0300, Andriy Gapon wrote:
> On 02/08/2018 01:17, Conrad Meyer wrote:
> > 
> > I don't understand the concern.  There is only one listener to the
> > event and it just invokes ReqSleepState, which is responsible for
> > performing all suspend behavior.  The behavior is identical between
> > lid close and acpiconf.
> Unless someone is adding a new listener for that event.
> 

Or if there is some listener in some proprietary or local module that's
not part of base freebsd. The ability to support modules that didn't
exist at the time the event was added is exactly the main benefit of a
loose-runtime-binding scheme such as event notifications.

-- Ian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Thu, Aug 2, 2018 at 06:20 Andriy Gapon  wrote:

> On 02/08/2018 01:17, Conrad Meyer wrote:
> > I don't understand the concern.  There is only one listener to the
> > event and it just invokes ReqSleepState, which is responsible for
> > performing all suspend behavior.  The behavior is identical between
> > lid close and acpiconf.
>
> Unless someone is adding a new listener for that event.
>

Exactly my point.


> --
> Andriy Gapon
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Andriy Gapon]

On 02/08/2018 01:17, Conrad Meyer wrote:
> I don't understand the concern.  There is only one listener to the
> event and it just invokes ReqSleepState, which is responsible for
> performing all suspend behavior.  The behavior is identical between
> lid close and acpiconf.

Unless someone is adding a new listener for that event.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

I don't understand the concern.  There is only one listener to the
event and it just invokes ReqSleepState, which is responsible for
performing all suspend behavior.  The behavior is identical between
lid close and acpiconf.

On Wed, Aug 1, 2018 at 3:00 PM, Johannes Lundberg  wrote:
>
>
> On Wed, Aug 1, 2018 at 22:55 Conrad Meyer  wrote:
>>
>> ReqSleepState is the routine that takes care of suspend, not the
>> eventhandler.  I'm not sure what difference the proposed change is
>> supposed to make.
>
>
> Listeners to acpi_sleep_event don’t get the event when suspending with
> acpiconf (but they do when suspending via lid or sleep button).
>
> I think one would expect the same behavior when suspending via command line
> or physical switch.
>
>
>>
>>
>> Best,
>> Conrad
>>
>> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg 
>> wrote:
>> >
>> >
>> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
>> >>
>> >> It seems deliberate, although the commit message does not call it out
>> >> and the event is perhaps poorly named.  The event currently indicates
>> >> that the lid was closed.  And the final registered eventhandler for
>> >> the event calls ReqSleepState.
>> >>
>> >> The ReqSleepState routine, as well as the userspace ioctl that
>> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
>> >> than invoking the acpi sleep event), were introduced together in
>> >> r170976.
>> >>
>> >
>> > Unless there's a way of calling suspend properly from the cli (zzz uses
>> > acpiconf...) maybe something like this makes more sense to get the same
>> > behavior on for example lid close as zzz or acpiconf -s 3? (untested)
>> >
>> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
>> > index c1bfd880c89..87b506d6bf5 100644
>> > --- a/sys/dev/acpica/acpi.c
>> > +++ b/sys/dev/acpica/acpi.c
>> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t
>> > addr,
>> > int flag, struct thread *t
>> >      case ACPIIO_REQSLPSTATE:
>> > state = *(int *)addr;
>> > if (state != ACPI_STATE_S5)
>> > -   return (acpi_ReqSleepState(sc, state));
>> > +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
>> > +   acpi_invoke_sleep_eventhandler, )) ? 0 :
>> > ENXIO;
>> > device_printf(sc->acpi_dev, "power off via acpi ioctl not
>> > supported\n");
>> > error = EOPNOTSUPP;
>> > break;
>> >
>> >
>> >>
>> >> Best,
>> >> Conrad
>> >>
>> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
>> >> wrote:
>> >> > Hi
>> >> >
>> >> > As the title says, callbacks registered with
>> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
>> >> > does not get called when calling acpiconf -s 3.
>> >> > They do however, when suspending with lid or sleep button.
>> >> >
>> >> > Is this deliberate or an oversight?
>> >> >
>> >> > Cheers
>> >> > ___
>> >> > freebsd-current@freebsd.org mailing list
>> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> >> > To unsubscribe, send any mail to
>> >> > "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

ReqSleepState is the routine that takes care of suspend, not the
eventhandler.  I'm not sure what difference the proposed change is
supposed to make.

Best,
Conrad

On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg  wrote:
>
>
> On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
>>
>> It seems deliberate, although the commit message does not call it out
>> and the event is perhaps poorly named.  The event currently indicates
>> that the lid was closed.  And the final registered eventhandler for
>> the event calls ReqSleepState.
>>
>> The ReqSleepState routine, as well as the userspace ioctl that
>> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
>> than invoking the acpi sleep event), were introduced together in
>> r170976.
>>
>
> Unless there's a way of calling suspend properly from the cli (zzz uses
> acpiconf...) maybe something like this makes more sense to get the same
> behavior on for example lid close as zzz or acpiconf -s 3? (untested)
>
> diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> index c1bfd880c89..87b506d6bf5 100644
> --- a/sys/dev/acpica/acpi.c
> +++ b/sys/dev/acpica/acpi.c
> @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr,
> int flag, struct thread *t
>  case ACPIIO_REQSLPSTATE:
> state = *(int *)addr;
> if (state != ACPI_STATE_S5)
> -   return (acpi_ReqSleepState(sc, state));
> +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
> +   acpi_invoke_sleep_eventhandler, )) ? 0 :
> ENXIO;
> device_printf(sc->acpi_dev, "power off via acpi ioctl not
> supported\n");
> error = EOPNOTSUPP;
> break;
>
>
>>
>> Best,
>> Conrad
>>
>> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
>> wrote:
>> > Hi
>> >
>> > As the title says, callbacks registered with
>> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
>> > does not get called when calling acpiconf -s 3.
>> > They do however, when suspending with lid or sleep button.
>> >
>> > Is this deliberate or an oversight?
>> >
>> > Cheers
>> > ___
>> > freebsd-current@freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to
>> > "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Wed, Aug 1, 2018 at 22:55 Conrad Meyer  wrote:

> ReqSleepState is the routine that takes care of suspend, not the
> eventhandler.  I'm not sure what difference the proposed change is
> supposed to make.


Listeners to acpi_sleep_event don’t get the event when suspending with
acpiconf (but they do when suspending via lid or sleep button).

I think one would expect the same behavior when suspending via command line
or physical switch.



>
> Best,
> Conrad
>
> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg 
> wrote:
> >
> >
> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
> >>
> >> It seems deliberate, although the commit message does not call it out
> >> and the event is perhaps poorly named.  The event currently indicates
> >> that the lid was closed.  And the final registered eventhandler for
> >> the event calls ReqSleepState.
> >>
> >> The ReqSleepState routine, as well as the userspace ioctl that
> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
> >> than invoking the acpi sleep event), were introduced together in
> >> r170976.
> >>
> >
> > Unless there's a way of calling suspend properly from the cli (zzz uses
> > acpiconf...) maybe something like this makes more sense to get the same
> > behavior on for example lid close as zzz or acpiconf -s 3? (untested)
> >
> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> > index c1bfd880c89..87b506d6bf5 100644
> > --- a/sys/dev/acpica/acpi.c
> > +++ b/sys/dev/acpica/acpi.c
> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t
> addr,
> > int flag, struct thread *t
> >  case ACPIIO_REQSLPSTATE:
> > state = *(int *)addr;
> > if (state != ACPI_STATE_S5)
> > -   return (acpi_ReqSleepState(sc, state));
> > +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
> > +   acpi_invoke_sleep_eventhandler, )) ? 0 :
> > ENXIO;
> > device_printf(sc->acpi_dev, "power off via acpi ioctl not
> > supported\n");
> > error = EOPNOTSUPP;
> > break;
> >
> >
> >>
> >> Best,
> >> Conrad
> >>
> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
> >> wrote:
> >> > Hi
> >> >
> >> > As the title says, callbacks registered with
> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
> >> > does not get called when calling acpiconf -s 3.
> >> > They do however, when suspending with lid or sleep button.
> >> >
> >> > Is this deliberate or an oversight?
> >> >
> >> > Cheers
> >> > ___
> >> > freebsd-current@freebsd.org mailing list
> >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> > To unsubscribe, send any mail to
> >> > "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:

> It seems deliberate, although the commit message does not call it out
> and the event is perhaps poorly named.  The event currently indicates
> that the lid was closed.  And the final registered eventhandler for
> the event calls ReqSleepState.
>
> The ReqSleepState routine, as well as the userspace ioctl that
> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
> than invoking the acpi sleep event), were introduced together in
> r170976.
>
>
Unless there's a way of calling suspend properly from the cli (zzz uses
acpiconf...) maybe something like this makes more sense to get the same
behavior on for example lid close as zzz or acpiconf -s 3? (untested)

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index c1bfd880c89..87b506d6bf5 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr,
int flag, struct thread *t
 case ACPIIO_REQSLPSTATE:
state = *(int *)addr;
if (state != ACPI_STATE_S5)
-   return (acpi_ReqSleepState(sc, state));
+   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
+   acpi_invoke_sleep_eventhandler, )) ? 0 :
ENXIO;
device_printf(sc->acpi_dev, "power off via acpi ioctl not
supported\n");
error = EOPNOTSUPP;
break;



> Best,
> Conrad
>
> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
> wrote:
> > Hi
> >
> > As the title says, callbacks registered with
> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
> > does not get called when calling acpiconf -s 3.
> > They do however, when suspending with lid or sleep button.
> >
> > Is this deliberate or an oversight?
> >
> > Cheers
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpiconf -s 3 does not call acpi sleep event handlers

[Conrad Meyer]

It seems deliberate, although the commit message does not call it out
and the event is perhaps poorly named.  The event currently indicates
that the lid was closed.  And the final registered eventhandler for
the event calls ReqSleepState.

The ReqSleepState routine, as well as the userspace ioctl that
'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
than invoking the acpi sleep event), were introduced together in
r170976.

Best,
Conrad

On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg  wrote:
> Hi
>
> As the title says, callbacks registered with
> EVENTHANDLER_REGISTER(acpi_sleep_event, 
> does not get called when calling acpiconf -s 3.
> They do however, when suspending with lid or sleep button.
>
> Is this deliberate or an oversight?
>
> Cheers
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

Hi

As the title says, callbacks registered with
EVENTHANDLER_REGISTER(acpi_sleep_event, 
does not get called when calling acpiconf -s 3.
They do however, when suspending with lid or sleep button.

Is this deliberate or an oversight?

Cheers
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND

[O. Hartmann]

Hello.

The target host is a

Fujitsu Esprimo Q956
Firmware V5.0.0.11 R1.26.0 for A3413-A1x
Date 05/25/2018
BIOS Revision 1.26

FreeBSD 11.2-RELEASE and 12-CURRENT (ISO Image from 9th July 2018, r336134) are
spamming the console with an annoying error:

Jul 13 10:00:32  kernel: Firmware Error (ACPI): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503) Jul 13 10:00:32
kernel: ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND
(20171214/psparse-677) Jul 13 10:00:32  kernel: Firmware Error (ACPI): Failure
looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503)

The error is repeated endless.

Can this be fixed?

Thanks in advance and kind regards,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ACPI is broken on CURRENT

[Yuri]

I couldn't make the S3 suspend to work at all.

Please see the bug report: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228654



Yuri


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New ACPI Errors

[Jung-uk Kim]

On 02/13/2018 17:34, Claude Buisson wrote:
> On 02/13/2018 22:49, Pete Wright wrote:
>> Hello,
>> I have started seeing a lot of these messages spam my system log:
>>
>> ACPI Error: No pointer back to namespace node in package
>> 0xf8000f79a080 (20180209/dsargs-472)
>> ACPI Error: Method parse/execution failed \134_SB.AC.ADJP,
>> AE_AML_INTERNAL (20180209/psparse-677)
>> ACPI Error: Method parse/execution failed \134_SB.AC._PSR,
>> AE_AML_INTERNAL (20180209/psparse-677)
>>
>> I noticed this starting from a CURRENT build i installed two weeks
>> ago, and still see it from a world/kernel i built last night.  two
>> questions:
>> 1) has anyone else noticed this?
>> 2) is this something to worry about?
>>
>> i can help debug the issue but am not sure where to start poking.
>>
>> thanks!
>> -pete
>>
> Here I have
> 
> ACPI Error: No pointer back to namespace node in package
> 0xf8000171f700 (20180209/dsargs-472)
> ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName
> unavailable] (20180209/dswexec-606)
> ACPI Error: Method parse/execution failed
> \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)
> 
> with svn 329142 on a Lenovo ThinkCentre M83
> ACPI APIC Table: 
> 
> Claude Buisson

This problem should be fixed now (r80).  Sorry for the delay.

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

Re: New ACPI Errors

[Pete Wright]

On 02/16/2018 13:54, Pete Wright wrote:



On 02/15/2018 13:37, Jung-uk Kim wrote:

On 02/13/2018 17:34, Claude Buisson wrote:

On 02/13/2018 22:49, Pete Wright wrote:

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP,
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR,
AE_AML_INTERNAL (20180209/psparse-677)

I noticed this starting from a CURRENT build i installed two weeks
ago, and still see it from a world/kernel i built last night.  two
questions:
1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete


Here I have

ACPI Error: No pointer back to namespace node in package
0xf8000171f700 (20180209/dsargs-472)
ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName
unavailable] (20180209/dswexec-606)
ACPI Error: Method parse/execution failed
\134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)

with svn 329142 on a Lenovo ThinkCentre M83
ACPI APIC Table: 

Claude Buisson

I believe you can silence the errors with the attached patch. Please
try it and let me know.

hrm still getting errors:

Feb 16 13:49:45 runner kernel: ACPI Error: No pointer back to 
namespace node in package 0xf80003c8c080 (20180209/dsargs-472)
Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution 
failed \_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677)
Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution 
failed \_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677)



here's my diff:
diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h 
b/sys/contrib/dev/acpica/include/platform/acfreebsd.h

index 905dffb7a40..df89399a369 100644
--- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h
+++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h
@@ -166,6 +166,7 @@

 #define ACPI_UINTPTR_T  uintptr_t

+#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS
 #define ACPI_USE_DO_WHILE_0
 #define ACPI_USE_LOCAL_CACHE
 #define ACPI_USE_NATIVE_DIVIDE




hi there - i was wondering if anyone has taken a look at this issue.  I 
am still seeing these ACPI errors on recent CURRENT systems:


ACPI Error: No pointer back to namespace node in package 
0xf803e71fff00 (20180313/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, 
AE_AML_INTERNAL (20180313/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR, 
AE_AML_INTERNAL (20180313/psparse-677)



I have two amd64 (skylake and kabylake) systems that are exhibiting this 
behavior and am more than happy to test patches or other things.


cheers!
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: X1 Carbon 6th gen. ACPI issues

[Kirill Ponomarev]

On 03/10, Kirill Ponomarev wrote:
> Hi,
> 
> it seems new Carbonss have some issues with S3 according to this Lenovo
> thread:
> https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/td-p/3998182
> 
> The same issues we have in CURRENT:
> hw.acpi.supported_sleep_state: S4 S5
> 
> If someone would like to analyze it and fix, I'm ready to help with
> access and testing.

In case if someone interested, there's a Linux workaround for this
issue:
https://delta-xi.net/#056

K.


signature.asc
Description: PGP signature

X1 Carbon 6th gen. ACPI issues

[Kirill Ponomarev]

Hi,

it seems new Carbonss have some issues with S3 according to this Lenovo
thread:
https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/td-p/3998182

The same issues we have in CURRENT:
hw.acpi.supported_sleep_state: S4 S5

If someone would like to analyze it and fix, I'm ready to help with
access and testing.

K.


signature.asc
Description: PGP signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Wed, Feb 21, 2018 at 8:55 AM, Warner Losh  wrote:
>
>
> On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans  wrote:
>>
>> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor 
>> wrote:
>> > Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>> >>
>> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
>> >> 
>> >> wrote:
>> >>>
>> >>> [... snip ...]
>> >>>
>> >>> Moreover, the "boot [kernel]" loader command does not work:
>> >>>
>> >>> OK ls /boot/kernel.old/kernel
>> >>>  /boot/kernel.old/kernel
>> >>> OK boot kernel.old
>> >>> Command failed
>> >>> OK boot /boot/kernel.old/kernel
>> >>> Command failed
>> >>> OK boot kernel
>> >>> Command failed
>> >>>
>> >>> On the other hand, just "boot" works.
>> >>>
>> >>
>> >> This part should work as expected as of r329674, so please give that a
>> >> shot. I'm still trying to see if I can reproduce your box drawing
>> >> problem.
>> >>
>> >> Thanks,
>> >>
>> >> Kyle Evans
>> >>
>> >
>> > Thanks Kyle.
>> >
>> > boot command works now. There is though a somewhat strangely formulated
>> > messages when trying to load an non-existent kernel:
>> >
>> > OK boot fake
>> > Failed to load kernel ’fake’
>> > Failed to load any kernel
>> > can’t load ’kernel’
>> >
>> > The two last lines are odd: Did the loader try to load a fallback kernel
>> > and
>> > failed? That would explain the ’kernel’ name in quotes, but I have such
>> > a
>> > kernel… Also, just nitpicking, but "can’t" should be capitalized.
>>
>> (CC'ing Rod, since he also commented on this)
>>
>> I'm only directly responsible for the first two messages. =) I've
>> removed the second one, though, since it was a carry-over from when it
>> would try to load the selected kernel and then some default kernel
>> that might be in your module_path.
>>
>> We can look at changing "can't load 'kernel'" to capitalize and remove
>> the contraction, but that's common loader stuff and should've also
>> been displayed for the same Forth scenario.
>>
>> > Then, I have just remembered why I was seeing a higher resolution menu
>> > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new
>> > loader is not implementing the inclusion of this file, because I can
>> > change
>> > the gop mode in the loader with 'gop set [0-3]'.
>> >
>>
>> Oy. This is actually a Forth file, so we can't really maintain all of
>> the functionality that would have been allowed there. Technically,
>> things like this should probably either appear in your loader.conf(5)
>> in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is
>> read, or we should provide some other means of running pure loader
>> command scripts at different points in the loader sequence. (CC
>> Warner, because he probably has thoughts about this latter idea)
>
>
> While loader.rc is FORTH, it's contrived FORTH designed to look like command
> line interaction. While some crazy people like me have actual forth in
> these, most do not, really (apart from the include /boot/XXX.4th lines, that
> is, which could be filtered).
>
> We have two choices here: Try to provide some level of compatibility shims,
> or provide a new way to say these things in Lua.
>
> In the original SoC code, loader.lua lived in /boot and looked to be
> something that people could modify. We likely need to do something similar.
> loader.lua right now has nothing but were in the forth world called
> 'include' and then very similar commands to the forth loader.rc. Perhaps the
> right answer is to move cli_execute out of /boot/lua/loader.lua, move that
> file up, and add the try-include functionality to try to include a
> loader.local.lua. Then we could tell people to move to the Lua syntax way of
> doing things. We'd have to hunt down all the hacks like this, but that
> wouldn't be terrible. Bonus points if we could convert the common ones
> either to lua code automatically, or to loader.conf variables.

We have something like this that I added yesterday in r329692, but
named a little bit differently ("local.lua", "local module"). Mostly
added because I've been using it to locally add test menu options and
writing some of the documentation for how to hook into our new lua
system to do things, and it was getting tiresome having to manually
revert those bits in loader.lua when I wanted to make changes to the
in-tree loader.lua.

We'd basically rename this to loader.local.lua to match more closely
to current convention, move "cli_execute" out to either core.lua or
maybe it and the boot commands are worthy of their own "cli" module,
then be happy.

> This specific example should have always been a loader.conf variable (and
> not an exec). While the gop command is useful, the loader should have, as
> part of it's forth sequence, had something that would set the GOP mode if
> the uefi_gop_mode loader.conf variable was set (I get why that wasn't done
> that way in the forth loader, insert rant of Fear of FORTH here). So we
> 

Re: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans  wrote:

> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor 
> wrote:
> > Le 20/02/2018 à 22:45, Kyle Evans a écrit :
> >>
> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <
> lis...@club.fr>
> >> wrote:
> >>>
> >>> [... snip ...]
> >>>
> >>> Moreover, the "boot [kernel]" loader command does not work:
> >>>
> >>> OK ls /boot/kernel.old/kernel
> >>>  /boot/kernel.old/kernel
> >>> OK boot kernel.old
> >>> Command failed
> >>> OK boot /boot/kernel.old/kernel
> >>> Command failed
> >>> OK boot kernel
> >>> Command failed
> >>>
> >>> On the other hand, just "boot" works.
> >>>
> >>
> >> This part should work as expected as of r329674, so please give that a
> >> shot. I'm still trying to see if I can reproduce your box drawing
> >> problem.
> >>
> >> Thanks,
> >>
> >> Kyle Evans
> >>
> >
> > Thanks Kyle.
> >
> > boot command works now. There is though a somewhat strangely formulated
> > messages when trying to load an non-existent kernel:
> >
> > OK boot fake
> > Failed to load kernel ’fake’
> > Failed to load any kernel
> > can’t load ’kernel’
> >
> > The two last lines are odd: Did the loader try to load a fallback kernel
> and
> > failed? That would explain the ’kernel’ name in quotes, but I have such a
> > kernel… Also, just nitpicking, but "can’t" should be capitalized.
>
> (CC'ing Rod, since he also commented on this)
>
> I'm only directly responsible for the first two messages. =) I've
> removed the second one, though, since it was a carry-over from when it
> would try to load the selected kernel and then some default kernel
> that might be in your module_path.
>
> We can look at changing "can't load 'kernel'" to capitalize and remove
> the contraction, but that's common loader stuff and should've also
> been displayed for the same Forth scenario.
>
> > Then, I have just remembered why I was seeing a higher resolution menu
> > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new
> > loader is not implementing the inclusion of this file, because I can
> change
> > the gop mode in the loader with 'gop set [0-3]'.
> >
>
> Oy. This is actually a Forth file, so we can't really maintain all of
> the functionality that would have been allowed there. Technically,
> things like this should probably either appear in your loader.conf(5)
> in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is
> read, or we should provide some other means of running pure loader
> command scripts at different points in the loader sequence. (CC
> Warner, because he probably has thoughts about this latter idea)
>

While loader.rc is FORTH, it's contrived FORTH designed to look like
command line interaction. While some crazy people like me have actual forth
in these, most do not, really (apart from the include /boot/XXX.4th lines,
that is, which could be filtered).

We have two choices here: Try to provide some level of compatibility shims,
or provide a new way to say these things in Lua.

In the original SoC code, loader.lua lived in /boot and looked to be
something that people could modify. We likely need to do something similar.
loader.lua right now has nothing but were in the forth world called
'include' and then very similar commands to the forth loader.rc. Perhaps
the right answer is to move cli_execute out of /boot/lua/loader.lua, move
that file up, and add the try-include functionality to try to include a
loader.local.lua. Then we could tell people to move to the Lua syntax way
of doing things. We'd have to hunt down all the hacks like this, but that
wouldn't be terrible. Bonus points if we could convert the common ones
either to lua code automatically, or to loader.conf variables.

This specific example should have always been a loader.conf variable (and
not an exec). While the gop command is useful, the loader should have, as
part of it's forth sequence, had something that would set the GOP mode if
the uefi_gop_mode loader.conf variable was set (I get why that wasn't done
that way in the forth loader, insert rant of Fear of FORTH here). So we
should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few
other things that are simple settings to make it easier for users to set
this stuff up and start to move away from the FoF kludges that we've
accumulated. A new loader.conf variable would also allow coexistence of the
two loaders, which will be further helped with some patches I have to the
build system coming soon.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Rodney W. Grimes]

> Le 20/02/2018 ? 22:45, Kyle Evans a ?crit?:
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ram?n Molina Menor  
> > wrote:
> >> [... snip ...]
> >>
> >> Moreover, the "boot [kernel]" loader command does not work:
> >>
> >> OK ls /boot/kernel.old/kernel
> >>  /boot/kernel.old/kernel
> >> OK boot kernel.old
> >> Command failed
> >> OK boot /boot/kernel.old/kernel
> >> Command failed
> >> OK boot kernel
> >> Command failed
> >>
> >> On the other hand, just "boot" works.
> >>
> > 
> > This part should work as expected as of r329674, so please give that a
> > shot. I'm still trying to see if I can reproduce your box drawing
> > problem.
> > 
> > Thanks,
> > 
> > Kyle Evans
> > 
> 
> Thanks Kyle.
> 
> boot command works now. There is though a somewhat strangely formulated 
> messages when trying to load an non-existent kernel:
> 
> OK boot fake
> Failed to load kernel ?fake?
> Failed to load any kernel
> can?t load ?kernel?
> 
> The two last lines are odd: Did the loader try to load a fallback kernel 
> and failed? That would explain the ?kernel? name in quotes, but I have 
> such a kernel? Also, just nitpicking, but "can?t" should be capitalized.

To be supper nt picky can't should also be spelled can not.

> Then, I have just remembered why I was seeing a higher resolution menu 
> before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new 
> loader is not implementing the inclusion of this file, because I can 
> change the gop mode in the loader with 'gop set [0-3]'.
> 
> This has thus nothing to do with the drawing lines, I guess.
> 
> Best regards.
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor  wrote:
> Le 20/02/2018 à 22:45, Kyle Evans a écrit :
>>
>> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor 
>> wrote:
>>>
>>> [... snip ...]
>>>
>>> Moreover, the "boot [kernel]" loader command does not work:
>>>
>>> OK ls /boot/kernel.old/kernel
>>>  /boot/kernel.old/kernel
>>> OK boot kernel.old
>>> Command failed
>>> OK boot /boot/kernel.old/kernel
>>> Command failed
>>> OK boot kernel
>>> Command failed
>>>
>>> On the other hand, just "boot" works.
>>>
>>
>> This part should work as expected as of r329674, so please give that a
>> shot. I'm still trying to see if I can reproduce your box drawing
>> problem.
>>
>> Thanks,
>>
>> Kyle Evans
>>
>
> Thanks Kyle.
>
> boot command works now. There is though a somewhat strangely formulated
> messages when trying to load an non-existent kernel:
>
> OK boot fake
> Failed to load kernel ’fake’
> Failed to load any kernel
> can’t load ’kernel’
>
> The two last lines are odd: Did the loader try to load a fallback kernel and
> failed? That would explain the ’kernel’ name in quotes, but I have such a
> kernel… Also, just nitpicking, but "can’t" should be capitalized.

(CC'ing Rod, since he also commented on this)

I'm only directly responsible for the first two messages. =) I've
removed the second one, though, since it was a carry-over from when it
would try to load the selected kernel and then some default kernel
that might be in your module_path.

We can look at changing "can't load 'kernel'" to capitalize and remove
the contraction, but that's common loader stuff and should've also
been displayed for the same Forth scenario.

> Then, I have just remembered why I was seeing a higher resolution menu
> before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new
> loader is not implementing the inclusion of this file, because I can change
> the gop mode in the loader with 'gop set [0-3]'.
>

Oy. This is actually a Forth file, so we can't really maintain all of
the functionality that would have been allowed there. Technically,
things like this should probably either appear in your loader.conf(5)
in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is
read, or we should provide some other means of running pure loader
command scripts at different points in the loader sequence. (CC
Warner, because he probably has thoughts about this latter idea)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 20/02/2018 à 22:45, Kyle Evans a écrit :

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:

[... snip ...]

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.



This part should work as expected as of r329674, so please give that a
shot. I'm still trying to see if I can reproduce your box drawing
problem.

Thanks,

Kyle Evans



Thanks Kyle.

boot command works now. There is though a somewhat strangely formulated 
messages when trying to load an non-existent kernel:


OK boot fake
Failed to load kernel ’fake’
Failed to load any kernel
can’t load ’kernel’

The two last lines are odd: Did the loader try to load a fallback kernel 
and failed? That would explain the ’kernel’ name in quotes, but I have 
such a kernel… Also, just nitpicking, but "can’t" should be capitalized.


Then, I have just remembered why I was seeing a higher resolution menu 
before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new 
loader is not implementing the inclusion of this file, because I can 
change the gop mode in the loader with 'gop set [0-3]'.


This has thus nothing to do with the drawing lines, I guess.

Best regards.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:
> [... snip ...]
>
> Moreover, the "boot [kernel]" loader command does not work:
>
> OK ls /boot/kernel.old/kernel
> /boot/kernel.old/kernel
> OK boot kernel.old
> Command failed
> OK boot /boot/kernel.old/kernel
> Command failed
> OK boot kernel
> Command failed
>
> On the other hand, just "boot" works.
>

This part should work as expected as of r329674, so please give that a
shot. I'm still trying to see if I can reproduce your box drawing
problem.

Thanks,

Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :> Hello!


On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.



Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...

In fact, I don’t think this has ever worked here… I’ve found a very old (July 
2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

Thanks.



Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.

I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U processor, 
4GB RAM). The only thing I can think of is that the ACPI of this model is not 
well supported, but the errors I have are related to thermal zones…:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with ccache 
and WITH_META_MODE, but this build process has been working nicely for months.

The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of things 
to slim down the memstick, but still, it has been stable till now:

juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This breaks settin

Re: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Feb 19, 2018 3:38 PM, "Kyle Evans"  wrote:

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh  wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco
to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script,
it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not
sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot
them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.


Forth has a framework for making all commands forth words. It leverages
that to run the intercept. We already have the intercept in place with a
stupidly simple policy. We totally can do something generic that would
solve this and maybe other problems. Let's chat online tomorrow about a
couple of possibilities we can choose from.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 4:32 PM, Warner Losh  wrote:
> 
> 
> 
>> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>> 
>> 
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>> 
>> I can indeed confirm this as fact.
>> 
>> Not able to help much because I am driving cross-country (San Francisco to 
>> Orlando) right now with the spouse and dog.
>> 
>> We get back March 3rd, but I will be checking-in from time to time for 
>> sporadic responses during downtime.
> 
> The command in loader.4th is defined as:
> 
> : boot
>   0= if ( interpreted ) get_arguments then
> 
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ; 
> 
> The thing to know here is when you see 'boot' as part of above script, it's 
> calling the 'boot' cli command, not itself recursively.
> 

What is actually going on is that when the “boot” function is compiled, the 
reference to “boot” inside it is to the already-existing word defined 
previously. Forth allows you to have multiply-defined names. The “boot” command 
inside the “boot” function is replaced with the address of previous boot during 
function compilation because the function is m not defined and given an address 
in the dictionary until it is completed (last line compiled).
— 
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

 gets sOn Mon, Feb 19, 2018 at 6:11 PM, Peter Lei <peter@ieee.org> wrote:
>
>
> On 2/19/18 5:48 PM, Kyle Evans wrote:
>>
>>
>> On Feb 19, 2018 5:44 PM, "Peter Lei" <peter@ieee.org
>> <mailto:peter@ieee.org>> wrote:
>>
>>
>>
>> On 2/19/18 2:21 PM, Kyle Evans wrote:
>> > Hello!
>> >
>> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
>> <lis...@club.fr <mailto:lis...@club.fr>> wrote:
>> >> I have done a full build of r329555 to test the new Lua boot loader.
>> >>
>> >> Both the new and the old kernels panic after being loaded with:
>> >>
>> >> panic: running without device atpic requires a local APIC
>> >>
>> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
>> a previous
>> >> message:
>> >>
>> 
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>> 
>> <https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html>
>> >>
>> >> OK show hint.acpi.0.disabled
>> >> 1
>> >>
>> >> Setting ACPI to On resolves the issue.
>> >
>> > As David noted, this should actually Just Work (TM) now. Can you break
>> > into a loader prompt with just the forth loader and tell me what "show
>> > hint.acpi.0.rsdp" looks like?
>>
>>
>> This doesn't appear to "just work out-of-the-box" yet when EFI booting
>> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
>>
>> Under EFI and lua loader, the following is set when breaking to prompt:
>> hint.acpi.0.disabled=1
>> Under forth loader, this is not present/set.
>>
>> In neither case is hint.acpi.0.rsdp present/set as that appears to get
>> set during the exec of the loaded kernel...
>>
>> I've worked around the issue by adding hint.acpi.0.disabled="0" to
>> loader.conf (or patching the amd64 efi loader code to explicitly clear
>> that hint).
>>
>>
>> [Apologies for broken quoting, currently mobile]
>>
>> What happens if you patch this line out?
>> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233
>
>
> Ah, right - yep, commenting out that line works.
>

This should be fixed as of r329614. hint.acpi.0.rsdp gets set upon
exec of the loaded kernel in the EFI world, then in i386 world it's
before lualoader comes into play. We should probably do as forth does
and disable ACPI stuff on !i386 (IIRC the option disappears
completely), but IIRC we haven't yet exposed TARGET/TARGET_ARCH to
lua.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 5:48 PM, Kyle Evans wrote:
> 
> 
> On Feb 19, 2018 5:44 PM, "Peter Lei" <peter@ieee.org
> <mailto:peter@ieee.org>> wrote:
> 
> 
> 
> On 2/19/18 2:21 PM, Kyle Evans wrote:
> > Hello!
> >
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
> <lis...@club.fr <mailto:lis...@club.fr>> wrote:
> >> I have done a full build of r329555 to test the new Lua boot loader.
> >>
> >> Both the new and the old kernels panic after being loaded with:
> >>
> >> panic: running without device atpic requires a local APIC
> >>
> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
> a previous
> >> message:
> >>
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
> 
> <https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html>
> >>
> >> OK show hint.acpi.0.disabled
> >> 1
> >>
> >> Setting ACPI to On resolves the issue.
> >
> > As David noted, this should actually Just Work (TM) now. Can you break
> > into a loader prompt with just the forth loader and tell me what "show
> > hint.acpi.0.rsdp" looks like?
> 
> 
> This doesn't appear to "just work out-of-the-box" yet when EFI booting
> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
> 
> Under EFI and lua loader, the following is set when breaking to prompt:
>     hint.acpi.0.disabled=1
> Under forth loader, this is not present/set.
> 
> In neither case is hint.acpi.0.rsdp present/set as that appears to get
> set during the exec of the loaded kernel...
> 
> I've worked around the issue by adding hint.acpi.0.disabled="0" to
> loader.conf (or patching the amd64 efi loader code to explicitly clear
> that hint).
> 
> 
> [Apologies for broken quoting, currently mobile]
> 
> What happens if you patch this line out?
> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233


Ah, right - yep, commenting out that line works.


> I'll have to go back and figure out what I was thinking here again. It
> made sense when I wrote it, maybe explicitly disabling ACPI if it's not
> immediately detected was the wrong move. =)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Feb 19, 2018 5:44 PM, "Peter Lei" <peter@ieee.org> wrote:



On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr>
wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/
2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
>
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).


[Apologies for broken quoting, currently mobile]

What happens if you patch this line out?
https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233

I'll have to go back and figure out what I was thinking here again. It made
sense when I wrote it, maybe explicitly disabling ACPI if it's not
immediately detected was the wrong move. =)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
> 
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> 
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
> 
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).



smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 4:32 PM, Warner Losh  wrote:
>
>
> On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:
>>
>>
>>
>> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
>> >
>> > It seems that the Forth loader might be doing something sneaky and
>> > replacing the standard common "boot" with a Forth boot that handles
>> > this a lot better. CC'ing dteske@ so they can confirm.
>>
>> I can indeed confirm this as fact.
>>
>> Not able to help much because I am driving cross-country (San Francisco to
>> Orlando) right now with the spouse and dog.
>>
>> We get back March 3rd, but I will be checking-in from time to time for
>> sporadic responses during downtime.
>
>
> The command in loader.4th is defined as:
>
> : boot
>   0= if ( interpreted ) get_arguments then
>
>   \ Unload only if a path was passed
>   dup if
> >r over r> swap
> c@ [char] - <> if
>   0 1 unload drop
> else
>   s" kernelname" getenv? if ( a kernel has been loaded )
> try-menu-unset
> bootmsg 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup if exit then
>   try-menu-unset
>   bootmsg 0 1 boot exit
> then
>   else
> s" kernelname" getenv? if ( a kernel has been loaded )
>   try-menu-unset
>   bootmsg 1 boot exit
> then
> load_kernel_and_modules
> ?dup if exit then
> try-menu-unset
> bootmsg 0 1 boot exit
>   then
>   load_kernel_and_modules
>   ?dup 0= if bootmsg 0 1 boot then
> ;
>
> The thing to know here is when you see 'boot' as part of above script, it's
> calling the 'boot' cli command, not itself recursively.
>
> I can help do more interpretation of the details if you need Kyle. Not sure
> how much to spell out, but the brief pseudo code is:
>
> If there were any arguments that didn't start with '-', unload.
>   otherwise if kernelname is in in the environment, run the 'menu-unset'
> forth word if it exists, print the boot message and boot.
>   Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
> it exists), print the boot message and boot with kernelname
> if all that fails, load the kernel and modules and if that works boot them.
>

Yeah, we have something like this on the lua side. Unfortunately, it's
going to wreck people's muscle memory- dropping to the loader prompt
and typing "boot [x]" will never work as expected because lua won't
recognize that as a function call due to spaces as delimiters.

We'd need some shim that takes "cmd [x]" and tries it as "cmd([x])"
(for some [x] that could be multiple space-delimited arguments) before
falling back to the originally typed "cmd [x]" if we want Lua to have
any chance to intercept it and adds its own salt and pepper like Forth
does.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Mon, Feb 19, 2018 at 2:57 PM, Devin Teske  wrote:

>
>
> > On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> >
> > It seems that the Forth loader might be doing something sneaky and
> > replacing the standard common "boot" with a Forth boot that handles
> > this a lot better. CC'ing dteske@ so they can confirm.
>
> I can indeed confirm this as fact.
>
> Not able to help much because I am driving cross-country (San Francisco to
> Orlando) right now with the spouse and dog.
>
> We get back March 3rd, but I will be checking-in from time to time for
> sporadic responses during downtime.
>

The command in loader.4th is defined as:

: boot
  0= if ( interpreted ) get_arguments then

  \ Unload only if a path was passed
  dup if
>r over r> swap
c@ [char] - <> if
  0 1 unload drop
else
  s" kernelname" getenv? if ( a kernel has been loaded )
try-menu-unset
bootmsg 1 boot exit
  then
  load_kernel_and_modules
  ?dup if exit then
  try-menu-unset
  bootmsg 0 1 boot exit
then
  else
s" kernelname" getenv? if ( a kernel has been loaded )
  try-menu-unset
  bootmsg 1 boot exit
then
load_kernel_and_modules
?dup if exit then
try-menu-unset
bootmsg 0 1 boot exit
  then
  load_kernel_and_modules
  ?dup 0= if bootmsg 0 1 boot then
;

The thing to know here is when you see 'boot' as part of above script, it's
calling the 'boot' cli command, not itself recursively.

I can help do more interpretation of the details if you need Kyle. Not sure
how much to spell out, but the brief pseudo code is:

If there were any arguments that didn't start with '-', unload.
  otherwise if kernelname is in in the environment, run the 'menu-unset'
forth word if it exists, print the boot message and boot.
  Otherwise load the kernel and modules, run the 'menu-unset' forth word
(if it exists), print the boot message and boot with kernelname
Otherwise load the kernel and modules, run the 'menu-unset' forth word (if
it exists), print the boot message and boot with kernelname
if all that fails, load the kernel and modules and if that works boot them.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.




Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?


OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...


In fact, I don’t think this has ever worked here… I’ve found a very old 
(July 2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.




There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.


Thanks.



Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.


I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U 
processor, 4GB RAM). The only thing I can think of is that the ACPI of 
this model is not well supported, but the errors I have are related to 
thermal zones…:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with 
ccache and WITH_META_MODE, but this build process has been working 
nicely for months.


The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of 
things to slim down the memstick, but still, it has been stable till now:


juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This bre

Re: ACPI panic on boot with new Lua loader and other minor issues

[Devin Teske]

> On Feb 19, 2018, at 2:21 PM, Kyle Evans  wrote:
> 
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.

I can indeed confirm this as fact.

Not able to help much because I am driving cross-country (San Francisco to 
Orlando) right now with the spouse and dog.

We get back March 3rd, but I will be checking-in from time to time for sporadic 
responses during downtime.
— 
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 3:37 PM, Warner Losh <i...@bsdimp.com> wrote:
>
>
> On Feb 19, 2018 1:23 PM, "Kyle Evans" <kev...@freebsd.org> wrote:
>
> Hello!
>
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr>
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
>> previous
>> message:
>>
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
>
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?
>
>> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
>> keyboard only becomes responsive at the loader stage.
>
> Hmm...
>
>> There is an error during this stage:
>>
>> Loading /boot/defaults/loader.conf
>> Failed to open config: ’/boot/loader.conf.local’
>
> David's diagnosis of this is right- this is more of an informational
> message that you don't need to worry about.
>
>> Moreover, the "boot [kernel]" loader command does not work:
>>
>> OK ls /boot/kernel.old/kernel
>> /boot/kernel.old/kernel
>> OK boot kernel.old
>> Command failed
>> OK boot /boot/kernel.old/kernel
>> Command failed
>> OK boot kernel
>> Command failed
>>
>> On the other hand, just "boot" works.
>
> It seems that the Forth loader might be doing something sneaky and
> replacing the standard common "boot" with a Forth boot that handles
> this a lot better. CC'ing dteske@ so they can confirm.
>
>
> Indeed, it does.
>
> Loader.4th defines boot. Search for ': boot' to see it.
>

I've created D14442 [1] to improve this situation a little bit. We
should also either:

1.) Provide a way for lua to register a function to handle a loader command, or
2.) Provide a way for lua/forth to tell the common boot what modules to load.

These both entail a good amount of work and quite a few places to
fail, but one of them needs to happen. =(

[1] https://reviews.freebsd.org/D14442
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 15:39, David Wolfskill a écrit :

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html


That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.


OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader:
the keyboard only becomes responsive at the loader stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)


Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
  /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


And the Lua loader permits kernel selection, as well (as the Forth
laoder has).


Finally, the double lines drawing a frame around the loader menu do not
work with the new loader and are replaced by ? characters in a box.


That has also been fixed for me (as of r329517).


Hope it helps,
Juan



Peace,
david


Thanks David. It’s strange I’m having issues resolved for you in commits 
older than the one I used here…


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Warner Losh]

On Feb 19, 2018 1:23 PM, "Kyle Evans" <kev...@freebsd.org> wrote:

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr>
wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous
> message:
> https://lists.freebsd.org/pipermail/freebsd-current/
2018-February/068497.html
>
> OK show hint.acpi.0.disabled
> 1
>
> Setting ACPI to On resolves the issue.

As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
> keyboard only becomes responsive at the loader stage.

Hmm...

> There is an error during this stage:
>
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

> Moreover, the "boot [kernel]" loader command does not work:
>
> OK ls /boot/kernel.old/kernel
> /boot/kernel.old/kernel
> OK boot kernel.old
> Command failed
> OK boot /boot/kernel.old/kernel
> Command failed
> OK boot kernel
> Command failed
>
> On the other hand, just "boot" works.

It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Indeed, it does.

Loader.4th defines boot. Search for ': boot' to see it.

Warner

> Finally, the double lines drawing a frame around the loader menu do not
work
> with the new loader and are replaced by ? characters in a box.

Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
>
> Both the new and the old kernels panic after being loaded with:
>
> panic: running without device atpic requires a local APIC
>
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
> message:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>
> OK show hint.acpi.0.disabled
> 1
>
> Setting ACPI to On resolves the issue.

As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

> Also, I can not stop boot2 to try to use the copy of the Forth loader: the
> keyboard only becomes responsive at the loader stage.

Hmm...

> There is an error during this stage:
>
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

> Moreover, the "boot [kernel]" loader command does not work:
>
> OK ls /boot/kernel.old/kernel
> /boot/kernel.old/kernel
> OK boot kernel.old
> Command failed
> OK boot /boot/kernel.old/kernel
> Command failed
> OK boot kernel
> Command failed
>
> On the other hand, just "boot" works.

It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.

> Finally, the double lines drawing a frame around the loader menu do not work
> with the new loader and are replaced by ? characters in a box.

Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI panic on boot with new Lua loader and other minor issues

[David Wolfskill]

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:
> I have done a full build of r329555 to test the new Lua boot loader.
> 
> Both the new and the old kernels panic after being loaded with:
> 
> panic: running without device atpic requires a local APIC
> 
> For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
> previous message:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.

> OK show hint.acpi.0.disabled
> 1
> 
> Setting ACPI to On resolves the issue.
> 
> Also, I can not stop boot2 to try to use the copy of the Forth loader: 
> the keyboard only becomes responsive at the loader stage.

> There is an error during this stage:
> 
> Loading /boot/defaults/loader.conf
> Failed to open config: ’/boot/loader.conf.local’

IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)

> Moreover, the "boot [kernel]" loader command does not work:
> 
> OK ls /boot/kernel.old/kernel
>  /boot/kernel.old/kernel
> OK boot kernel.old
> Command failed
> OK boot /boot/kernel.old/kernel
> Command failed
> OK boot kernel
> Command failed
> 
> On the other hand, just "boot" works.

And the Lua loader permits kernel selection, as well (as the Forth
laoder has).

> Finally, the double lines drawing a frame around the loader menu do not 
> work with the new loader and are replaced by ? characters in a box.

That has also been fixed for me (as of r329517).

> Hope it helps,
> Juan
> 

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed



I forgot that I tried starting with "unload", which seems to work, but 
does not correct the issue:


OK unload
OK boot kernel.old
Command failed
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
previous message:

https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader: 
the keyboard only becomes responsive at the loader stage.


There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
/boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.

Finally, the double lines drawing a frame around the loader menu do not 
work with the new loader and are replaced by ? characters in a box.


Hope it helps,
Juan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New ACPI Errors

[Pete Wright]

On 02/15/2018 13:37, Jung-uk Kim wrote:

On 02/13/2018 17:34, Claude Buisson wrote:

On 02/13/2018 22:49, Pete Wright wrote:

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP,
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR,
AE_AML_INTERNAL (20180209/psparse-677)

I noticed this starting from a CURRENT build i installed two weeks
ago, and still see it from a world/kernel i built last night.  two
questions:
1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete


Here I have

ACPI Error: No pointer back to namespace node in package
0xf8000171f700 (20180209/dsargs-472)
ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName
unavailable] (20180209/dswexec-606)
ACPI Error: Method parse/execution failed
\134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)

with svn 329142 on a Lenovo ThinkCentre M83
ACPI APIC Table: 

Claude Buisson

I believe you can silence the errors with the attached patch.  Please
try it and let me know.

hrm still getting errors:

Feb 16 13:49:45 runner kernel: ACPI Error: No pointer back to namespace 
node in package 0xf80003c8c080 (20180209/dsargs-472)
Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution failed 
\_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677)
Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution failed 
\_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677)



here's my diff:
diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h 
b/sys/contrib/dev/acpica/include/platform/acfreebsd.h

index 905dffb7a40..df89399a369 100644
--- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h
+++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h
@@ -166,6 +166,7 @@

 #define ACPI_UINTPTR_T  uintptr_t

+#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS
 #define ACPI_USE_DO_WHILE_0
 #define ACPI_USE_LOCAL_CACHE
 #define ACPI_USE_NATIVE_DIVIDE


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New ACPI Errors

[Jung-uk Kim]

On 02/13/2018 17:34, Claude Buisson wrote:
> On 02/13/2018 22:49, Pete Wright wrote:
>> Hello,
>> I have started seeing a lot of these messages spam my system log:
>>
>> ACPI Error: No pointer back to namespace node in package
>> 0xf8000f79a080 (20180209/dsargs-472)
>> ACPI Error: Method parse/execution failed \134_SB.AC.ADJP,
>> AE_AML_INTERNAL (20180209/psparse-677)
>> ACPI Error: Method parse/execution failed \134_SB.AC._PSR,
>> AE_AML_INTERNAL (20180209/psparse-677)
>>
>> I noticed this starting from a CURRENT build i installed two weeks
>> ago, and still see it from a world/kernel i built last night.  two
>> questions:
>> 1) has anyone else noticed this?
>> 2) is this something to worry about?
>>
>> i can help debug the issue but am not sure where to start poking.
>>
>> thanks!
>> -pete
>>
> Here I have
> 
> ACPI Error: No pointer back to namespace node in package
> 0xf8000171f700 (20180209/dsargs-472)
> ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName
> unavailable] (20180209/dswexec-606)
> ACPI Error: Method parse/execution failed
> \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)
> 
> with svn 329142 on a Lenovo ThinkCentre M83
> ACPI APIC Table: 
> 
> Claude Buisson

I believe you can silence the errors with the attached patch.  Please
try it and let me know.

Jung-uk Kim
Index: sys/contrib/dev/acpica/include/platform/acfreebsd.h
===
--- sys/contrib/dev/acpica/include/platform/acfreebsd.h	(revision 329340)
+++ sys/contrib/dev/acpica/include/platform/acfreebsd.h	(working copy)
@@ -166,6 +166,7 @@
 
 #define ACPI_UINTPTR_T  uintptr_t
 
+#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS
 #define ACPI_USE_DO_WHILE_0
 #define ACPI_USE_LOCAL_CACHE
 #define ACPI_USE_NATIVE_DIVIDE


signature.asc
Description: OpenPGP digital signature

Re: New ACPI Errors

[Claude Buisson]

On 02/13/2018 22:49, Pete Wright wrote:

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package 
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, 
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR, 
AE_AML_INTERNAL (20180209/psparse-677)


I noticed this starting from a CURRENT build i installed two weeks ago, 
and still see it from a world/kernel i built last night.  two questions:

1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete


Here I have

ACPI Error: No pointer back to namespace node in package 
0xf8000171f700 (20180209/dsargs-472)
ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName 
unavailable] (20180209/dswexec-606)
ACPI Error: Method parse/execution failed 
\134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)


with svn 329142 on a Lenovo ThinkCentre M83
ACPI APIC Table: 

Claude Buisson
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

New ACPI Errors

[Pete Wright]

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package 
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, 
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR, 
AE_AML_INTERNAL (20180209/psparse-677)


I noticed this starting from a CURRENT build i installed two weeks ago, 
and still see it from a world/kernel i built last night.  two questions:

1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ACPI Suspend/Resume on Lenovo 3000 G530 4151

[Frank Honolka]

Hiya,

Recently, I've installed FreeBSD 11.1 almost everything works fine. :D 
But when I'm bringing my Notebook Lenovo 3000 G530 4151 into S3 Suspend
I can't wake it up  anymore. I also can't connect per ssh to the
machine. I would like to know, how I can debug the machine in
suspend/resume modus?

Frank

P.S: By the way, I have the same issues with FreeBSD current.
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-RELEASE-p1 #3: Thu Jul 20 08:26:18 BST 2017
gandalf@lappi:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 
3.8.0)
VT(vga): resolution 640x480
info: [drm] Initialized drm 1.1.0 20060810
module_register: cannot register pci/ehci from kernel; already loaded from 
ehci.ko
Module pci/ehci failed to register: 17
module_register: cannot register pci/uhci from kernel; already loaded from 
uhci.ko
Module pci/uhci failed to register: 17
CPU: Intel(R) Celeron(R) CPU 900 @ 2.20GHz (2194.55-MHz K8-class CPU)
Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10
Features=0xafebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE>
Features2=0xc00e31d<SSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,XSAVE,OSXSAVE>
AMD Features=0x20100800<SYSCALL,NX,LM>
AMD Features2=0x1
TSC: P-state invariant, performance statistics
real memory = 1073741824 (1024 MB)
avail memory = 953561088 (909 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
random: unblocking device.
ioapic0  irqs 0-23 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x81035950, 0) error 19
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
Event timer "HPET3" frequency 14318180 Hz quality 440
cpu0:  on acpi0
atrtc0:  port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_ec0:  port 0x62,0x66 on acpi0
acpi_lid0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0x1800-0x1807 mem 
0xf400-0xf43f,0xd000-0xdfff irq 16 at device 2.0 on pci0
agp0:  on vgapci0
agp0: aperture size is 256M, detected 32764k stolen memory
acpi_video0:  on vgapci0
drmn0:  on vgapci0
iicbus0:  on iicbb0 addr 0xff
iic0:  on iicbus0
iic1:  on iicbus1
iicbus2:  on iicbb1 addr 0x0
iic2:  on iicbus2
iic3:  on iicbus3
iicbus4:  on iicbb2 addr 0x0
iic4:  on iicbus4
iic5:  on iicbus5
iicbus6:  on iicbb3 addr 0x0
iic6:  on iicbus6
iic7:  on iicbus7
iicbus8:  on iicbb4 addr 0x0
iic8:  on iicbus8
iic9:  on iicbus9
iicbus10:  on iicbb5 addr 0x0
iic10:  on iicbus10
iic11:  on iicbus11
info: [drm] MSI enabled 1 message(s)
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
drmn0: taking over the fictitious range 0xd000-0xe000
info: [drm] Connector LVDS-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.LVDS-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] Connector VGA-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.VGA-1
info: [drm] - kern.vt.fb.default_mode
info: [drm] Connector DP-1: get mode from tunables:
info: [drm] - kern.vt.fb.modes.DP-1
info: [drm] - kern.vt.fb.default_mode
fbd0 on drmn0
VT: Replacing driver "vga" with new "fb".
info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
vgapci0: Boot video device
vgapci1:  mem 0xf440-0xf44f at device 2.1 on 
pci0
uhci0:  port 0x1820-0x183f irq 16 at device 
26.0 on pci0
uhci0: LegSup = 0x3700
usbus0 on uhci0
uhci1:  port 0x1840-0x185f irq 21 at device 
26.1 on pci0
uhci1: LegSup = 0x2700
usbus1 on uhci1
uhci2:  port 0x1860-0x187f irq 20 at device 
26.2 on pci0
uhci2: LegSup = 0x2700
usbus2 on uhci2
ehci0:  mem 0xf4904800-0xf4904bff irq 
20 at device 26.7 on pci0
usbus3: EHCI version 1.0
usbus3 on ehci0
hdac0:  mem 0xf470-0xf4703fff irq 22 at device 
27.0 on pci0
pcib1:  irq 17 at device 28.0 

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Tue, May 2, 2017 at 11:28 AM, Sepherosa Ziehau <sepher...@gmail.com> wrote:
> On Tue, May 2, 2017 at 12:25 AM, John Baldwin <j...@freebsd.org> wrote:
>> On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
>>> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin <j...@freebsd.org> wrote:
>>> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>>> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin <j...@freebsd.org> wrote:
>>> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>>> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> 
>>> >> >> wrote:
>>> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>>> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>>> >> >> >> > Sent: Thursday, April 20, 2017 02:34
>>> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>>> >> >> >> > > change?
>>> >> >> >> > >
>>> >> >> >> > >  acpi_sysres_probe(device_t dev)
>>> >> >> >> > >  {
>>> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL 
>>> >> >> >> > > };
>>> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>>> >> >> >> > > "ACPI0004", NULL };
>>> >> >> >> > >
>>> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>>> >> >> >> > though we
>>> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
>>> >> >> >> > (since historically
>>> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
>>> >> >> >> > things like the
>>> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of 
>>> >> >> >> > ACPI0004 in the ACPI
>>> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>>> >> >> >> > particular, it
>>> >> >> >> > seems that 004 should only allow direct children to suballocate? 
>>> >> >> >> >  This
>>> >> >> >> > change might work, but it will allow more devices to allocate 
>>> >> >> >> > the ranges in
>>> >> >> >> >  _CRS than otherwise.
>>> >> >> >> >
>>> >> >> >> > Do you have an acpidump from a guest system that contains an 
>>> >> >> >> > ACPI0004
>>> >> >> >> > node that you can share?
>>> >> >> >> >
>>> >> >> >> > John Baldwin
>>> >> >> >>
>>> >> >> >> Hi John,
>>> >> >> >> Thanks for the help!
>>> >> >> >>
>>> >> >> >> Please see the attached file, which is got by
>>> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>>> >> >> >>
>>> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>>> >> >> >> "VMBus" (VMBS).
>>> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
>>> >> >> >> can't
>>> >> >> >> see the length of the MMIO range in the dumped asl code, it does 
>>> >> >> >> have
>>> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
>>> >> >> >>
>>> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>>> >> >> >> With the above one-line change, I can first find the child device
>>> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>>> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>>> >> >> >>
>>> >> >> >> If you think we shouldn't touch acpi_sysresource

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Tue, May 2, 2017 at 12:25 AM, John Baldwin <j...@freebsd.org> wrote:
> On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
>> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin <j...@freebsd.org> wrote:
>> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin <j...@freebsd.org> wrote:
>> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
>> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> >> >> > Sent: Thursday, April 20, 2017 02:34
>> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>> >> >> >> > > change?
>> >> >> >> > >
>> >> >> >> > >  acpi_sysres_probe(device_t dev)
>> >> >> >> > >  {
>> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>> >> >> >> > > "ACPI0004", NULL };
>> >> >> >> > >
>> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>> >> >> >> > though we
>> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
>> >> >> >> > (since historically
>> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
>> >> >> >> > things like the
>> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 
>> >> >> >> > in the ACPI
>> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> >> >> > particular, it
>> >> >> >> > seems that 004 should only allow direct children to suballocate?  
>> >> >> >> > This
>> >> >> >> > change might work, but it will allow more devices to allocate the 
>> >> >> >> > ranges in
>> >> >> >> >  _CRS than otherwise.
>> >> >> >> >
>> >> >> >> > Do you have an acpidump from a guest system that contains an 
>> >> >> >> > ACPI0004
>> >> >> >> > node that you can share?
>> >> >> >> >
>> >> >> >> > John Baldwin
>> >> >> >>
>> >> >> >> Hi John,
>> >> >> >> Thanks for the help!
>> >> >> >>
>> >> >> >> Please see the attached file, which is got by
>> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >> >> >>
>> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> >> >> "VMBus" (VMBS).
>> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
>> >> >> >> can't
>> >> >> >> see the length of the MMIO range in the dumped asl code, it does 
>> >> >> >> have
>> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
>> >> >> >>
>> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> >> >> With the above one-line change, I can first find the child device
>> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >> >> >>
>> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> >> >> driver as a child device of acpi0?
>> >> >> >
>> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
>> >> >> > device
>> >> >> > driver fo

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Sunday, April 30, 2017 09:02:30 AM Sepherosa Ziehau wrote:
> On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin <j...@freebsd.org> wrote:
> > On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> >> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin <j...@freebsd.org> wrote:
> >> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> >> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> >> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> >> >> > Sent: Thursday, April 20, 2017 02:34
> >> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
> >> >> >> > > change?
> >> >> >> > >
> >> >> >> > >  acpi_sysres_probe(device_t dev)
> >> >> >> > >  {
> >> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
> >> >> >> > > "ACPI0004", NULL };
> >> >> >> > >
> >> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
> >> >> >> > though we
> >> >> >> > in turn allow any child of acpi0 to suballocate those ranges 
> >> >> >> > (since historically
> >> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by 
> >> >> >> > things like the
> >> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 
> >> >> >> > in the ACPI
> >> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> >> >> > particular, it
> >> >> >> > seems that 004 should only allow direct children to suballocate?  
> >> >> >> > This
> >> >> >> > change might work, but it will allow more devices to allocate the 
> >> >> >> > ranges in
> >> >> >> >  _CRS than otherwise.
> >> >> >> >
> >> >> >> > Do you have an acpidump from a guest system that contains an 
> >> >> >> > ACPI0004
> >> >> >> > node that you can share?
> >> >> >> >
> >> >> >> > John Baldwin
> >> >> >>
> >> >> >> Hi John,
> >> >> >> Thanks for the help!
> >> >> >>
> >> >> >> Please see the attached file, which is got by
> >> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >> >> >>
> >> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> >> >> "VMBus" (VMBS).
> >> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we 
> >> >> >> can't
> >> >> >> see the length of the MMIO range in the dumped asl code, it does have
> >> >> >> a 512MB MMIO range [0xFE000, 0xF].
> >> >> >>
> >> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> >> >> With the above one-line change, I can first find the child device
> >> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >> >> >>
> >> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> >> >> driver as a child device of acpi0?
> >> >> >
> >> >> > Hmmm, so looking at this, the "right" thing is probably to have a 
> >> >> > device
> >> >> > driver for the ACPI0004 device that parses its _CRS and then allows 
> >> >> > its
> >> >> > child devices to sub-allocate resources from the ranges in _CRS.  
> >> >> > However,
> >> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> >> >> > we called the ACPI0004 dri

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Sat, Apr 29, 2017 at 12:01 AM, John Baldwin <j...@freebsd.org> wrote:
> On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
>> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin <j...@freebsd.org> wrote:
>> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
>> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> >> > Sent: Thursday, April 20, 2017 02:34
>> >> >> > > Can we add the support of "ACPI0004" with the below one-line 
>> >> >> > > change?
>> >> >> > >
>> >> >> > >  acpi_sysres_probe(device_t dev)
>> >> >> > >  {
>> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
>> >> >> > > "ACPI0004", NULL };
>> >> >> > >
>> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
>> >> >> > though we
>> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
>> >> >> > historically
>> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
>> >> >> > like the
>> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in 
>> >> >> > the ACPI
>> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> >> > particular, it
>> >> >> > seems that 004 should only allow direct children to suballocate?  
>> >> >> > This
>> >> >> > change might work, but it will allow more devices to allocate the 
>> >> >> > ranges in
>> >> >> >  _CRS than otherwise.
>> >> >> >
>> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004
>> >> >> > node that you can share?
>> >> >> >
>> >> >> > John Baldwin
>> >> >>
>> >> >> Hi John,
>> >> >> Thanks for the help!
>> >> >>
>> >> >> Please see the attached file, which is got by
>> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >> >>
>> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> >> "VMBus" (VMBS).
>> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> >> >> see the length of the MMIO range in the dumped asl code, it does have
>> >> >> a 512MB MMIO range [0xFE000, 0xF].
>> >> >>
>> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> >> With the above one-line change, I can first find the child device
>> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >> >>
>> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> >> driver as a child device of acpi0?
>> >> >
>> >> > Hmmm, so looking at this, the "right" thing is probably to have a device
>> >> > driver for the ACPI0004 device that parses its _CRS and then allows its
>> >> > child devices to sub-allocate resources from the ranges in _CRS.  
>> >> > However,
>> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
>> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
>> >> > device
>> >> > would need to create a child device for all of its child devices.  Right
>> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
>> >> > creates child devices anywhere in its namespace that have a valid _HID).
>> >> > You can find those duplicates and remove them during acpi_module0's 
>> >> > attach
>> >> > routine 

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Friday, April 28, 2017 05:38:32 PM Sepherosa Ziehau wrote:
> On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin <j...@freebsd.org> wrote:
> > On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> >> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> >> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> >> > Sent: Thursday, April 20, 2017 02:34
> >> >> > > Can we add the support of "ACPI0004" with the below one-line change?
> >> >> > >
> >> >> > >  acpi_sysres_probe(device_t dev)
> >> >> > >  {
> >> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", 
> >> >> > > "ACPI0004", NULL };
> >> >> > >
> >> >> > Hmm, so the role of C01 and C02 is to reserve system resources, 
> >> >> > though we
> >> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
> >> >> > historically
> >> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
> >> >> > like the
> >> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in 
> >> >> > the ACPI
> >> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> >> > particular, it
> >> >> > seems that 004 should only allow direct children to suballocate?  This
> >> >> > change might work, but it will allow more devices to allocate the 
> >> >> > ranges in
> >> >> >  _CRS than otherwise.
> >> >> >
> >> >> > Do you have an acpidump from a guest system that contains an ACPI0004
> >> >> > node that you can share?
> >> >> >
> >> >> > John Baldwin
> >> >>
> >> >> Hi John,
> >> >> Thanks for the help!
> >> >>
> >> >> Please see the attached file, which is got by
> >> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >> >>
> >> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> >> "VMBus" (VMBS).
> >> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> >> >> see the length of the MMIO range in the dumped asl code, it does have
> >> >> a 512MB MMIO range [0xFE000, 0xF].
> >> >>
> >> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> >> With the above one-line change, I can first find the child device
> >> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >> >>
> >> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> >> driver as a child device of acpi0?
> >> >
> >> > Hmmm, so looking at this, the "right" thing is probably to have a device
> >> > driver for the ACPI0004 device that parses its _CRS and then allows its
> >> > child devices to sub-allocate resources from the ranges in _CRS.  
> >> > However,
> >> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> >> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' 
> >> > device
> >> > would need to create a child device for all of its child devices.  Right
> >> > now acpi0 also creates devices for them which is somewhat messy (acpi0
> >> > creates child devices anywhere in its namespace that have a valid _HID).
> >> > You can find those duplicates and remove them during acpi_module0's 
> >> > attach
> >> > routine before creating its own child device_t devices.  (We associate
> >> > a device_t with each Handle when creating device_t's for ACPI handles
> >> > which is how you can find the old device that is a direct child of acpi0
> >> > so that it can be removed).
> >>
> >> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> >> hook up a new ac

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Thu, Apr 27, 2017 at 12:14 AM, John Baldwin <j...@freebsd.org> wrote:
> On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
>> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
>> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> >> > From: John Baldwin [mailto:j...@freebsd.org]
>> >> > Sent: Thursday, April 20, 2017 02:34
>> >> > > Can we add the support of "ACPI0004" with the below one-line change?
>> >> > >
>> >> > >  acpi_sysres_probe(device_t dev)
>> >> > >  {
>> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 
>> >> > > NULL };
>> >> > >
>> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though 
>> >> > we
>> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
>> >> > historically
>> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
>> >> > like the
>> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in 
>> >> > the ACPI
>> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
>> >> > particular, it
>> >> > seems that 004 should only allow direct children to suballocate?  This
>> >> > change might work, but it will allow more devices to allocate the 
>> >> > ranges in
>> >> >  _CRS than otherwise.
>> >> >
>> >> > Do you have an acpidump from a guest system that contains an ACPI0004
>> >> > node that you can share?
>> >> >
>> >> > John Baldwin
>> >>
>> >> Hi John,
>> >> Thanks for the help!
>> >>
>> >> Please see the attached file, which is got by
>> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>> >>
>> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> >> "VMBus" (VMBS).
>> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> >> see the length of the MMIO range in the dumped asl code, it does have
>> >> a 512MB MMIO range [0xFE000, 0xF].
>> >>
>> >> It looks FreeBSD can't detect ACPI0004 automatically.
>> >> With the above one-line change, I can first find the child device
>> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>> >>
>> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> >> we can add a new small driver for ACPI0004, just like we added VMBus
>> >> driver as a child device of acpi0?
>> >
>> > Hmmm, so looking at this, the "right" thing is probably to have a device
>> > driver for the ACPI0004 device that parses its _CRS and then allows its
>> > child devices to sub-allocate resources from the ranges in _CRS.  However,
>> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
>> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
>> > would need to create a child device for all of its child devices.  Right
>> > now acpi0 also creates devices for them which is somewhat messy (acpi0
>> > creates child devices anywhere in its namespace that have a valid _HID).
>> > You can find those duplicates and remove them during acpi_module0's attach
>> > routine before creating its own child device_t devices.  (We associate
>> > a device_t with each Handle when creating device_t's for ACPI handles
>> > which is how you can find the old device that is a direct child of acpi0
>> > so that it can be removed).
>>
>> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
>> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
>> we did to the hyper-v's pcib0.
>
> The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> should probably be doing is only creating device_t nodes for immediate
> children.  This would require an ACPI-aware isa0 for LPC devices below
> the ISA bus in the ACPI namespace.  We haven't done that in part because
> BIOS vendors are not always consistent in placing LPC devices unde

RE: Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

> From: John Baldwin
> Sent: Thursday, April 27, 2017 00:14
> On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> > On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> > > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > >> > From: John Baldwin [mailto:j...@freebsd.org]
> > >> > Sent: Thursday, April 20, 2017 02:34
> > >> > > Can we add the support of "ACPI0004" with the below one-line
> change?
> > >> > >
> > >> > >  acpi_sysres_probe(device_t dev)
> > >> > >  {
> > >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004",
> NULL };
> > >> > >
> > >> > Hmm, so the role of C01 and C02 is to reserve system resources,
> though we
> > >> > in turn allow any child of acpi0 to suballocate those ranges (since
> historically
> > >> > c01 and c02 tend to allocate I/O ranges that are then used by things
> like the
> > >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in
> the ACPI
> > >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> > >> > particular, it
> > >> > seems that 004 should only allow direct children to suballocate?  This
> > >> > change might work, but it will allow more devices to allocate the
> ranges in
> > >> >  _CRS than otherwise.
> > >> >
> > >> > Do you have an acpidump from a guest system that contains an
> ACPI0004
> > >> > node that you can share?
> > >> >
> > >> > John Baldwin
> > >>
> > >> Hi John,
> > >> Thanks for the help!
> > >>
> > >> Please see the attached file, which is got by
> > >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> > >>
> > >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> > >> "VMBus" (VMBS).
> > >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> > >> see the length of the MMIO range in the dumped asl code, it does have
> > >> a 512MB MMIO range [0xFE000, 0xF].
> > >>
> > >> It looks FreeBSD can't detect ACPI0004 automatically.
> > >> With the above one-line change, I can first find the child device
> > >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> > >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> > >>
> > >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> > >> we can add a new small driver for ACPI0004, just like we added VMBus
> > >> driver as a child device of acpi0?
> > >
> > > Hmmm, so looking at this, the "right" thing is probably to have a device
> > > driver for the ACPI0004 device that parses its _CRS and then allows its
> > > child devices to sub-allocate resources from the ranges in _CRS.  However,
> > > this would mean make VMBus be a child of the ACPI0004 device.
> Suppose
> > > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0'
> device
> > > would need to create a child device for all of its child devices.  Right
> > > now acpi0 also creates devices for them which is somewhat messy (acpi0
> > > creates child devices anywhere in its namespace that have a valid _HID).
> > > You can find those duplicates and remove them during acpi_module0's
> attach
> > > routine before creating its own child device_t devices.  (We associate
> > > a device_t with each Handle when creating device_t's for ACPI handles
> > > which is how you can find the old device that is a direct child of acpi0
> > > so that it can be removed).
> >
> > The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> > hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> > we did to the hyper-v's pcib0.
> 
> The acpi_pci driver used to do the remove/reassociate part.  What acpi0
> should probably be doing is only creating device_t nodes for immediate
> children.  This would require an ACPI-aware isa0 for LPC devices below
> the ISA bus in the ACPI namespace.  We haven't done that in part because
> BIOS vendors are not always consistent in placing LPC devices under an
> ISA bus.  However, you otherwi

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Wednesday, April 26, 2017 09:18:48 AM Sepherosa Ziehau wrote:
> On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> > On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> >> > From: John Baldwin [mailto:j...@freebsd.org]
> >> > Sent: Thursday, April 20, 2017 02:34
> >> > > Can we add the support of "ACPI0004" with the below one-line change?
> >> > >
> >> > >  acpi_sysres_probe(device_t dev)
> >> > >  {
> >> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> >> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 
> >> > > NULL };
> >> > >
> >> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
> >> > in turn allow any child of acpi0 to suballocate those ranges (since 
> >> > historically
> >> > c01 and c02 tend to allocate I/O ranges that are then used by things 
> >> > like the
> >> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the 
> >> > ACPI
> >> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In 
> >> > particular, it
> >> > seems that 004 should only allow direct children to suballocate?  This
> >> > change might work, but it will allow more devices to allocate the ranges 
> >> > in
> >> >  _CRS than otherwise.
> >> >
> >> > Do you have an acpidump from a guest system that contains an ACPI0004
> >> > node that you can share?
> >> >
> >> > John Baldwin
> >>
> >> Hi John,
> >> Thanks for the help!
> >>
> >> Please see the attached file, which is got by
> >> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> >>
> >> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> >> "VMBus" (VMBS).
> >> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> >> see the length of the MMIO range in the dumped asl code, it does have
> >> a 512MB MMIO range [0xFE000, 0xF].
> >>
> >> It looks FreeBSD can't detect ACPI0004 automatically.
> >> With the above one-line change, I can first find the child device
> >> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> >> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> >>
> >> If you think we shouldn't touch acpi_sysresource0 here, I guess
> >> we can add a new small driver for ACPI0004, just like we added VMBus
> >> driver as a child device of acpi0?
> >
> > Hmmm, so looking at this, the "right" thing is probably to have a device
> > driver for the ACPI0004 device that parses its _CRS and then allows its
> > child devices to sub-allocate resources from the ranges in _CRS.  However,
> > this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> > we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
> > would need to create a child device for all of its child devices.  Right
> > now acpi0 also creates devices for them which is somewhat messy (acpi0
> > creates child devices anywhere in its namespace that have a valid _HID).
> > You can find those duplicates and remove them during acpi_module0's attach
> > routine before creating its own child device_t devices.  (We associate
> > a device_t with each Handle when creating device_t's for ACPI handles
> > which is how you can find the old device that is a direct child of acpi0
> > so that it can be removed).
> 
> The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
> hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
> we did to the hyper-v's pcib0.

The acpi_pci driver used to do the remove/reassociate part.  What acpi0
should probably be doing is only creating device_t nodes for immediate
children.  This would require an ACPI-aware isa0 for LPC devices below
the ISA bus in the ACPI namespace.  We haven't done that in part because
BIOS vendors are not always consistent in placing LPC devices under an
ISA bus.  However, you otherwise have no good way to find your parent
ACPI0004 device.  You could perhaps find your ACPI handle, ask for its
parent handle, then ask for the device_t of that handle to find the
ACPI0004 device, but then you'd need to have all your bus_alloc_resource
calls go to that device, not your "real" parent of acpi0, which means
you can't use any of the standard bus_alloc_resource() methods like
bus_alloc_resource_any() but would have to manually use BUS_ALLOC_RESOURCE
with the ACPI0004 device as the explicit first argument.  It is primarily
the ability to let ACPI0004's driver transparently intercept all the
resource allocation so it can manage that is the reason for "VMBus"
to be a child of ACPI0004 rather than its sibling.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Add support for ACPI Module Device ACPI0004?

[Sepherosa Ziehau]

On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin <j...@freebsd.org> wrote:
> On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> > From: John Baldwin [mailto:j...@freebsd.org]
>> > Sent: Thursday, April 20, 2017 02:34
>> > > Can we add the support of "ACPI0004" with the below one-line change?
>> > >
>> > >  acpi_sysres_probe(device_t dev)
>> > >  {
>> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", 
>> > > NULL };
>> > >
>> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
>> > in turn allow any child of acpi0 to suballocate those ranges (since 
>> > historically
>> > c01 and c02 tend to allocate I/O ranges that are then used by things like 
>> > the
>> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the 
>> > ACPI
>> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, 
>> > it
>> > seems that 004 should only allow direct children to suballocate?  This
>> > change might work, but it will allow more devices to allocate the ranges in
>> >  _CRS than otherwise.
>> >
>> > Do you have an acpidump from a guest system that contains an ACPI0004
>> > node that you can share?
>> >
>> > John Baldwin
>>
>> Hi John,
>> Thanks for the help!
>>
>> Please see the attached file, which is got by
>> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>>
>> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> "VMBus" (VMBS).
>> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> see the length of the MMIO range in the dumped asl code, it does have
>> a 512MB MMIO range [0xFE000, 0xF].
>>
>> It looks FreeBSD can't detect ACPI0004 automatically.
>> With the above one-line change, I can first find the child device
>> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>>
>> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> we can add a new small driver for ACPI0004, just like we added VMBus
>> driver as a child device of acpi0?
>
> Hmmm, so looking at this, the "right" thing is probably to have a device
> driver for the ACPI0004 device that parses its _CRS and then allows its
> child devices to sub-allocate resources from the ranges in _CRS.  However,
> this would mean make VMBus be a child of the ACPI0004 device.  Suppose
> we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
> would need to create a child device for all of its child devices.  Right
> now acpi0 also creates devices for them which is somewhat messy (acpi0
> creates child devices anywhere in its namespace that have a valid _HID).
> You can find those duplicates and remove them during acpi_module0's attach
> routine before creating its own child device_t devices.  (We associate
> a device_t with each Handle when creating device_t's for ACPI handles
> which is how you can find the old device that is a direct child of acpi0
> so that it can be removed).

The remove/reassociate vmbus part seems kinda "messy" to me.  I'd just
hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
we did to the hyper-v's pcib0.

Thanks,
sephe

-- 
Tomorrow Will Never Die
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Thursday, April 20, 2017 02:34
> > > Can we add the support of "ACPI0004" with the below one-line change?
> > >
> > >  acpi_sysres_probe(device_t dev)
> > >  {
> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL 
> > > };
> > >
> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
> > in turn allow any child of acpi0 to suballocate those ranges (since 
> > historically
> > c01 and c02 tend to allocate I/O ranges that are then used by things like 
> > the
> > EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the 
> > ACPI
> > 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
> > seems that 004 should only allow direct children to suballocate?  This
> > change might work, but it will allow more devices to allocate the ranges in
> >  _CRS than otherwise.
> > 
> > Do you have an acpidump from a guest system that contains an ACPI0004
> > node that you can share?
> > 
> > John Baldwin
> 
> Hi John,
> Thanks for the help!
> 
> Please see the attached file, which is got by
> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
> 
> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> "VMBus" (VMBS). 
> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> see the length of the MMIO range in the dumped asl code, it does have
> a 512MB MMIO range [0xFE000, 0xF].
> 
> It looks FreeBSD can't detect ACPI0004 automatically.
> With the above one-line change, I can first find the child device 
> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
> 
> If you think we shouldn't touch acpi_sysresource0 here, I guess
> we can add a new small driver for ACPI0004, just like we added VMBus
> driver as a child device of acpi0?

Hmmm, so looking at this, the "right" thing is probably to have a device
driver for the ACPI0004 device that parses its _CRS and then allows its
child devices to sub-allocate resources from the ranges in _CRS.  However,
this would mean make VMBus be a child of the ACPI0004 device.  Suppose
we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
would need to create a child device for all of its child devices.  Right
now acpi0 also creates devices for them which is somewhat messy (acpi0
creates child devices anywhere in its namespace that have a valid _HID).
You can find those duplicates and remove them during acpi_module0's attach
routine before creating its own child device_t devices.  (We associate
a device_t with each Handle when creating device_t's for ACPI handles
which is how you can find the old device that is a direct child of acpi0
so that it can be removed).

Then when you are the "VMBus" device_t your parent is the ACPI0004 device
so you can easily talk to it to obtain resources (probably ACPI0004 can
just intercept bus_if.m resource methods to manage the resources).

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

> From: John Baldwin [mailto:j...@freebsd.org]
> Sent: Thursday, April 20, 2017 02:34
> > Can we add the support of "ACPI0004" with the below one-line change?
> >
> >  acpi_sysres_probe(device_t dev)
> >  {
> > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };
> >
> Hmm, so the role of C01 and C02 is to reserve system resources, though we
> in turn allow any child of acpi0 to suballocate those ranges (since 
> historically
> c01 and c02 tend to allocate I/O ranges that are then used by things like the
> EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the ACPI
> 6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
> seems that 004 should only allow direct children to suballocate?  This
> change might work, but it will allow more devices to allocate the ranges in
>  _CRS than otherwise.
> 
> Do you have an acpidump from a guest system that contains an ACPI0004
> node that you can share?
> 
> John Baldwin

Hi John,
Thanks for the help!

Please see the attached file, which is got by
"acpidump -dt | gzip -c9 > acpidump.dt.gz"

In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
"VMBus" (VMBS). 
It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
see the length of the MMIO range in the dumped asl code, it does have
a 512MB MMIO range [0xFE000, 0xF].

It looks FreeBSD can't detect ACPI0004 automatically.
With the above one-line change, I can first find the child device 
acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.

If you think we shouldn't touch acpi_sysresource0 here, I guess
we can add a new small driver for ACPI0004, just like we added VMBus
driver as a child device of acpi0?

-- Dexuan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Add support for ACPI Module Device ACPI0004?

[John Baldwin]

On Wednesday, April 19, 2017 12:26:51 PM Dexuan Cui wrote:
> The ACPI firmware of Hyper-V UEFI VM has a Module Device whose Hardware
> ID is "ACPI0004".  The module device has a _CRS object defining some MMIO
> ranges, which are needed when physical PCIe devices are passed through
> to the VM.
> 
> Currently it looks FreeBSD doesn't make use of the ACPI module device and
> hence the _CRS object can't be easily retrieved by Hyper-V VMBus driver.
> 
> Can we add the support of "ACPI0004" with the below one-line change?
> 
> Looking forward to your suggestion!
> 
> --- a/sys/dev/acpica/acpi_resource.c
> +++ b/sys/dev/acpica/acpi_resource.c
> @@ -653,7 +653,7 @@ MODULE_DEPEND(acpi_sysresource, acpi, 1, 1, 1);
>  static int
>  acpi_sysres_probe(device_t dev)
>  {
> -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };
> 
>  if (acpi_disabled("sysresource") ||
> ACPI_ID_PROBE(device_get_parent(dev), dev, sysres_ids) == NULL)

Hmm, so the role of C01 and C02 is to reserve system resources, though we
in turn allow any child of acpi0 to suballocate those ranges (since historically
c01 and c02 tend to allocate I/O ranges that are then used by things like the
EC, PS/2 keyboard controller, etc.).  From my reading of ACPI0004 in the ACPI
6.1 spec it's not quite clear that ACPI0004 is like that?  In particular, it
seems that 004 should only allow direct children to suballocate?  This change
might work, but it will allow more devices to allocate the ranges in _CRS
than otherwise.

Do you have an acpidump from a guest system that contains an ACPI0004 node
that you can share?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Add support for ACPI Module Device ACPI0004?

[Dexuan Cui]

The ACPI firmware of Hyper-V UEFI VM has a Module Device whose Hardware
ID is "ACPI0004".  The module device has a _CRS object defining some MMIO
ranges, which are needed when physical PCIe devices are passed through
to the VM.

Currently it looks FreeBSD doesn't make use of the ACPI module device and
hence the _CRS object can't be easily retrieved by Hyper-V VMBus driver.

Can we add the support of "ACPI0004" with the below one-line change?

Looking forward to your suggestion!

--- a/sys/dev/acpica/acpi_resource.c
+++ b/sys/dev/acpica/acpi_resource.c
@@ -653,7 +653,7 @@ MODULE_DEPEND(acpi_sysresource, acpi, 1, 1, 1);
 static int
 acpi_sysres_probe(device_t dev)
 {
-static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
+static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL };

 if (acpi_disabled("sysresource") ||
ACPI_ID_PROBE(device_get_parent(dev), dev, sysres_ids) == NULL)

Thanks,
-- Dexuan

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Alexandr Krivulya]

03.01.2017 20:21, Jung-uk Kim пишет:

On 01/03/2017 11:22, Hans Petter Selasky wrote:

On 01/03/17 16:26, Moore, Robert wrote:

Not sure I understand. The fix has been committed, and is part of
version 20161222.



Hi Robert,

 From what I can see that patches have been pushed to the following
branch, vendor-sys/acpica/20161222/, see:

https://svnweb.freebsd.org/changeset/base/310451

But not yet to "master" (12-current) ?

Is that correct?

My console has been filling up with messages like this:


ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
[OpcodeName unavailable] (20161117/dswexec-498)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC._Q50] (Node 0xf800047fce40),
AE_AML_OPERAND_TYPE (20161117/psparse-560)
acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE

over the holidays, so I assume that means the previous version of ACPI,
20161117 which the 20161222 version is supposed to fix.

I was AFK for two weeks.  I will merge ACPICA 20161222 to FreeBSD head
this week when I find some free time.




I don't know if my problem related to this topic, but a few weeks I see 
in KDE battery capacity -1%. acpiconf shows no battery:


root@thinkpad:/home/shurik # acpiconf -i0
Design capacity:0 mWh
Last full capacity: 0 mWh
Technology: primary (non-rechargeable)
Design voltage: 0 mV
Capacity (warn):0 mWh
Capacity (low): 0 mWh
Low/warn granularity:   0 mWh
Warn/full granularity:  0 mWh
Model number:
Serial number:
Type:
OEM info:
State:  not present
Present voltage:12611 mV

Just updated to r311492 and problem still present. There is no such 
problem on previous kernel r310241. And there is no more error messages:


Jan  6 09:22:39 thinkpad kernel: ACPI Error: Needed type [Reference], 
found [Processor] 0xf800055d5000 (20161117/exresop-111)
Jan  6 09:22:39 thinkpad kernel: ACPI Error: Method parse/execution 
failed [\PNOT] (Node 0xf80005595bc0), AE_AML_OPERAND_TYPE 
(20161117/psparse-560)
Jan  6 09:22:39 thinkpad kernel: ACPI Error: Method parse/execution 
failed [\_SB.PCI0.LPCB.EC0._REG] (Node 0xf8000558a040), 
AE_AML_OPERAND_TYPE (20161117/psparse-560)



--
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Edward Tomasz Napierala]

I've just updated, and the problem is gone.  Thanks!

On 1221T1520, Moore, Robert wrote:
> We have fixed this issue for the latest version of ACPICA that will happen 
> this week, probably 22 december.
> 
> 
> > -Original Message-
> > From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> > a...@freebsd.org] On Behalf Of Edward Tomasz Napierala
> > Sent: Wednesday, December 21, 2016 3:15 AM
> > To: O. Hartmann <ohartm...@walstatt.org>
> > Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> > Zakharov <zakharov...@gmail.com>
> > Subject: Re: ACPI Error on HP ProBook 430 G2
> > 
> > On 1220T1734, O. Hartmann wrote:
> > > Am Tue, 20 Dec 2016 18:09:20 +0300
> > > Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> > >
> > > > Hello!
> > > >
> > > > Some time ago new ACPI messages appeared on console and in
> > > > /var/log/messages. Like
> > > > these:
> > > >
> > > > ACPI Error: Needed type [Reference], found [Processor]
> > > > 0xf800043b8980
> > > > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While
> > > > resolving operands for [OpcodeName unavailable]
> > > > (20161117/dswexec-498) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04
> > failed:
> > > > AE_AML_OPERAND_TYPE
> > > >
> > > > I'm sure that there were no such messages earlier. Suspend/resume
> > > > works for me. But after disconnecting power line hw.acpi.acline
> > > > still equals to 1. And powerd/powerdxx do not adjust CPU frequency
> > anymore.
> > > >
> > > > System info:
> > > > $ uname -a
> > > > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M:
> > > > Tue Dec 20 16:42:21 MSK 2016
> > > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > > >
> > > > dmesg: http://pastebin.com/cYD8cR0b
> > > > hw.acpi: http://pastebin.com/Tht9B0FZ
> > > > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > > >
> > > >
> > > > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > > >
> > >
> > > I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook
> > > running most recent CURRENT ...
> > 
> > +1, I see the same on Thinkpad T420.
> > 
> > ___
> > freebsd-a...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Jung-uk Kim]

On 01/03/2017 11:22, Hans Petter Selasky wrote:
> On 01/03/17 16:26, Moore, Robert wrote:
>> Not sure I understand. The fix has been committed, and is part of
>> version 20161222.
>>
>>
> 
> Hi Robert,
> 
> From what I can see that patches have been pushed to the following
> branch, vendor-sys/acpica/20161222/, see:
> 
> https://svnweb.freebsd.org/changeset/base/310451
> 
> But not yet to "master" (12-current) ?
> 
> Is that correct?
> 
> My console has been filling up with messages like this:
> 
>> ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
>> [OpcodeName unavailable] (20161117/dswexec-498)
>> ACPI Error: Method parse/execution failed
>> [\134_SB.PCI0.LPCB.H_EC._Q50] (Node 0xf800047fce40),
>> AE_AML_OPERAND_TYPE (20161117/psparse-560)
>> acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE
> 
> over the holidays, so I assume that means the previous version of ACPI,
> 20161117 which the 20161222 version is supposed to fix.

I was AFK for two weeks.  I will merge ACPICA 20161222 to FreeBSD head
this week when I find some free time.

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

> -Original Message-
> From: Hans Petter Selasky [mailto:h...@selasky.org]
> Sent: Tuesday, January 3, 2017 8:23 AM
> To: Moore, Robert <robert.mo...@intel.com>; Edward Tomasz Napierala
> <tr...@freebsd.org>; O. Hartmann <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: Re: ACPI Error on HP ProBook 430 G2
> 
> On 01/03/17 16:26, Moore, Robert wrote:
> > Not sure I understand. The fix has been committed, and is part of
> version 20161222.
> >
> >
> 
> Hi Robert,
> 
>  From what I can see that patches have been pushed to the following
> branch, vendor-sys/acpica/20161222/, see:
> 
> https://svnweb.freebsd.org/changeset/base/310451
> 
> But not yet to "master" (12-current) ?
[Moore, Robert] 


Everything goes to master.


> 
> Is that correct?
> 
> My console has been filling up with messages like this:
> 
> > ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
> > [OpcodeName unavailable] (20161117/dswexec-498) ACPI Error: Method
> > parse/execution failed [\134_SB.PCI0.LPCB.H_EC._Q50] (Node
> > 0xf800047fce40), AE_AML_OPERAND_TYPE (20161117/psparse-560)
> > acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE
> 
> over the holidays, so I assume that means the previous version of ACPI,
> 20161117 which the 20161222 version is supposed to fix.
[Moore, Robert] 

Yes the messages above come from 20161117. Version is in the error messages.

> > 0xf800047fce40), AE_AML_OPERAND_TYPE (20161117/psparse-560)




> 
> --HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

Not sure I understand. The fix has been committed, and is part of version 
20161222.


> -Original Message-
> From: Hans Petter Selasky [mailto:h...@selasky.org]
> Sent: Monday, January 2, 2017 12:30 AM
> To: Moore, Robert <robert.mo...@intel.com>; Edward Tomasz Napierala
> <tr...@freebsd.org>; O. Hartmann <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: Re: ACPI Error on HP ProBook 430 G2
> 
> On 12/22/16 21:04, Moore, Robert wrote:
> > ACPICA version 20161222 happened today, with a fix for the problem
> below.
> >
> 
> +1
> 
> When will the fix be merged to -head ?
> 
> --HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Hans Petter Selasky]

On 01/03/17 16:26, Moore, Robert wrote:

Not sure I understand. The fix has been committed, and is part of version 
20161222.




Hi Robert,

From what I can see that patches have been pushed to the following 
branch, vendor-sys/acpica/20161222/, see:


https://svnweb.freebsd.org/changeset/base/310451

But not yet to "master" (12-current) ?

Is that correct?

My console has been filling up with messages like this:


ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName 
unavailable] (20161117/dswexec-498)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.H_EC._Q50] (Node 
0xf800047fce40), AE_AML_OPERAND_TYPE (20161117/psparse-560)
acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE


over the holidays, so I assume that means the previous version of ACPI, 
20161117 which the 20161222 version is supposed to fix.


--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ACPI Error on HP ProBook 430 G2

[Hans Petter Selasky]

On 12/22/16 21:04, Moore, Robert wrote:

ACPICA version 20161222 happened today, with a fix for the problem below.



+1

When will the fix be merged to -head ?

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

ACPICA version 20161222 happened today, with a fix for the problem below.


> -Original Message-
> From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> a...@freebsd.org] On Behalf Of Moore, Robert
> Sent: Wednesday, December 21, 2016 7:21 AM
> To: Edward Tomasz Napierala <tr...@freebsd.org>; O. Hartmann
> <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: RE: ACPI Error on HP ProBook 430 G2
> 
> We have fixed this issue for the latest version of ACPICA that will
> happen this week, probably 22 december.
> 
> 
> > -Original Message-
> > From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> > a...@freebsd.org] On Behalf Of Edward Tomasz Napierala
> > Sent: Wednesday, December 21, 2016 3:15 AM
> > To: O. Hartmann <ohartm...@walstatt.org>
> > Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> > Zakharov <zakharov...@gmail.com>
> > Subject: Re: ACPI Error on HP ProBook 430 G2
> >
> > On 1220T1734, O. Hartmann wrote:
> > > Am Tue, 20 Dec 2016 18:09:20 +0300
> > > Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> > >
> > > > Hello!
> > > >
> > > > Some time ago new ACPI messages appeared on console and in
> > > > /var/log/messages. Like
> > > > these:
> > > >
> > > > ACPI Error: Needed type [Reference], found [Processor]
> > > > 0xf800043b8980
> > > > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While
> > > > resolving operands for [OpcodeName unavailable]
> > > > (20161117/dswexec-498) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04
> > failed:
> > > > AE_AML_OPERAND_TYPE
> > > >
> > > > I'm sure that there were no such messages earlier. Suspend/resume
> > > > works for me. But after disconnecting power line hw.acpi.acline
> > > > still equals to 1. And powerd/powerdxx do not adjust CPU frequency
> > anymore.
> > > >
> > > > System info:
> > > > $ uname -a
> > > > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M:
> > > > Tue Dec 20 16:42:21 MSK 2016
> > > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > > >
> > > > dmesg: http://pastebin.com/cYD8cR0b
> > > > hw.acpi: http://pastebin.com/Tht9B0FZ
> > > > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > > >
> > > >
> > > > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > > >
> > >
> > > I see lots of ACPI errors also shortly on a Lenovo E540 UEFI
> > > notebook running most recent CURRENT ...
> >
> > +1, I see the same on Thinkpad T420.
> >
> > ___
> > freebsd-a...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-
> unsubscr...@freebsd.org"
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"