Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-09 Thread Mark Kettenis
> From: Peter Nicolai Mathias Hansteen 
> Date: Sat, 8 May 2021 13:15:10 +0200
> 
> > 7. mai 2021 kl. 23:28 skrev Mark Kettenis :
> >> 
> >> Yeah, nothing changed.
> > 
> > That said, can you try the attached diff?  Again I'm curious if
> > halt -p works with this or not.
> 
> Yes, of course, excellent!
> 
> And a few minutes later, I can report that with that patch applied,
> halt -p works as expected.
> 
> So I would be very pleased to see this go in.

It's in now.  Cheers!



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-08 Thread Peter Nicolai Mathias Hansteen


> 7. mai 2021 kl. 23:28 skrev Mark Kettenis :
>> 
>> Yeah, nothing changed.
> 
> That said, can you try the attached diff?  Again I'm curious if
> halt -p works with this or not.

Yes, of course, excellent!

And a few minutes later, I can report that with that patch applied, halt -p 
works as expected.

So I would be very pleased to see this go in.

Thanks so much for taking the time to look into this!

All the best,
Peter

—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP


Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-07 Thread Mark Kettenis
> Date: Fri, 7 May 2021 21:04:19 +0200 (CEST)
> From: Mark Kettenis 
> 
> > Date: Fri, 7 May 2021 10:24:19 +0200
> > From: "Peter N. M. Hansteen" 
> > 
> > On Thu, May 06, 2021 at 05:00:47PM +0200, Peter N. M. Hansteen wrote:
> > > Hi Mark,
> > > 
> > > On Thu, May 06, 2021 at 04:30:00PM +0200, Mark Kettenis wrote:
> > > > > 
> > > > > Are there other tests I could usefully perform for this one?
> > > > 
> > > > Not sure.  The BIOS on this machine is kinda broken.  It adbertises
> > > > itself as "hardware reduced" ACPI (something usually seen on arm64
> > > > machines) and claims to support S4 and S5 (hibernate and poweroff) but
> > > > doesn't actually implement the registers to do so.  So the machine
> > > > doesn't actually power off.
> > > > 
> > > > Does the BIOS screen on this machine provide a way to enable S3 mode?
> > > > If so it might be worth trying.
> > > 
> > > It doesn't, unfortunately. But I was thinking I would contact ASUS anyway
> > > to see if an updated BIOS is available. So I stole most of that to input
> > > in their support site's form.
> > > 
> > > Now I'll be looking forward to their response :)
> > 
> > They responded almost immediately, so this morning I downloaded and 
> > installed a
> > newer version BIOS (version 307 replacing version 302), and after a 
> > sysupgrade
> > the boot went pretty much like the earlier attempts:
> > 
> > https://www.bsdly.net/~peter/20210507_095128.jpg 
> > https://www.bsdly.net/~peter/20210507_095143.jpg 
> > https://www.bsdly.net/~peter/20210507_095157.jpg
> > 
> > and after repeating the boot -c and so forth steps for completeness I 
> > rebuilt
> > a kernel with a patched acpi.c, new sendbug -P output follows attached.
> > 
> > Unfortunately the new BIOS does not offer any new options of the kind we
> > were looking for.
> 
> Yeah, nothing changed.

That said, can you try the attached diff?  Again I'm curious if
halt -p works with this or not.


Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.397
diff -u -p -r1.397 acpi.c
--- dev/acpi/acpi.c 15 Mar 2021 22:44:57 -  1.397
+++ dev/acpi/acpi.c 7 May 2021 21:27:30 -
@@ -1436,7 +1436,8 @@ acpi_read_pmreg(struct acpi_softc *sc, i
 * For Hardware-reduced ACPI we also emulate PM1A_STS using
 * SLEEP_STATUS_REG.
 */
-   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS) {
+   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS &&
+   sc->sc_fadt->sleep_status_reg.register_bit_width > 0) {
uint8_t value;
 
KASSERT(offset == 0);
@@ -1514,7 +1515,8 @@ acpi_write_pmreg(struct acpi_softc *sc, 
 * For Hardware-reduced ACPI we also emulate PM1A_STS using
 * SLEEP_STATUS_REG.
 */
-   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS) {
+   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS &&
+   sc->sc_fadt->sleep_status_reg.register_bit_width > 0) {
uint8_t value = (regval >> 8);
 
KASSERT(offset == 0);
@@ -1530,7 +1532,8 @@ acpi_write_pmreg(struct acpi_softc *sc, 
 * For Hardware-reduced ACPI we also emulate PM1A_CNT using
 * SLEEP_CONTROL_REG.
 */
-   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_CNT) {
+   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_CNT &&
+   sc->sc_fadt->sleep_control_reg.register_bit_width > 0) {
uint8_t value = (regval >> 8);
 
KASSERT(offset == 0);
@@ -1608,10 +1611,6 @@ acpi_map_pmregs(struct acpi_softc *sc)
bus_size_t size, access;
const char *name;
int reg;
-
-   /* Registers don't exist on Hardware-reduced ACPI. */
-   if (sc->sc_hw_reduced)
-   return;
 
for (reg = 0; reg < ACPIREG_MAXREG; reg++) {
size = 0;



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-07 Thread Mark Kettenis
> Date: Fri, 7 May 2021 10:24:19 +0200
> From: "Peter N. M. Hansteen" 
> 
> On Thu, May 06, 2021 at 05:00:47PM +0200, Peter N. M. Hansteen wrote:
> > Hi Mark,
> > 
> > On Thu, May 06, 2021 at 04:30:00PM +0200, Mark Kettenis wrote:
> > > > 
> > > > Are there other tests I could usefully perform for this one?
> > > 
> > > Not sure.  The BIOS on this machine is kinda broken.  It adbertises
> > > itself as "hardware reduced" ACPI (something usually seen on arm64
> > > machines) and claims to support S4 and S5 (hibernate and poweroff) but
> > > doesn't actually implement the registers to do so.  So the machine
> > > doesn't actually power off.
> > > 
> > > Does the BIOS screen on this machine provide a way to enable S3 mode?
> > > If so it might be worth trying.
> > 
> > It doesn't, unfortunately. But I was thinking I would contact ASUS anyway
> > to see if an updated BIOS is available. So I stole most of that to input
> > in their support site's form.
> > 
> > Now I'll be looking forward to their response :)
> 
> They responded almost immediately, so this morning I downloaded and installed 
> a
> newer version BIOS (version 307 replacing version 302), and after a sysupgrade
> the boot went pretty much like the earlier attempts:
> 
> https://www.bsdly.net/~peter/20210507_095128.jpg 
> https://www.bsdly.net/~peter/20210507_095143.jpg 
> https://www.bsdly.net/~peter/20210507_095157.jpg
> 
> and after repeating the boot -c and so forth steps for completeness I rebuilt
> a kernel with a patched acpi.c, new sendbug -P output follows attached.
> 
> Unfortunately the new BIOS does not offer any new options of the kind we
> were looking for.

Yeah, nothing changed.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-06 Thread Peter N. M. Hansteen
Hi Mark,

On Thu, May 06, 2021 at 04:30:00PM +0200, Mark Kettenis wrote:
> > 
> > Are there other tests I could usefully perform for this one?
> 
> Not sure.  The BIOS on this machine is kinda broken.  It adbertises
> itself as "hardware reduced" ACPI (something usually seen on arm64
> machines) and claims to support S4 and S5 (hibernate and poweroff) but
> doesn't actually implement the registers to do so.  So the machine
> doesn't actually power off.
> 
> Does the BIOS screen on this machine provide a way to enable S3 mode?
> If so it might be worth trying.

It doesn't, unfortunately. But I was thinking I would contact ASUS anyway
to see if an updated BIOS is available. So I stole most of that to input
in their support site's form.

Now I'll be looking forward to their response :)

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-06 Thread Peter N. M. Hansteen
Hi Mark,

Are there other tests I could usefully perform for this one?

All the best,
Peter


-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-06 Thread Mark Kettenis
> Date: Thu, 6 May 2021 16:17:51 +0200
> From: "Peter N. M. Hansteen" 
> 
> Hi Mark,
> 
> Are there other tests I could usefully perform for this one?

Not sure.  The BIOS on this machine is kinda broken.  It adbertises
itself as "hardware reduced" ACPI (something usually seen on arm64
machines) and claims to support S4 and S5 (hibernate and poweroff) but
doesn't actually implement the registers to do so.  So the machine
doesn't actually power off.

Does the BIOS screen on this machine provide a way to enable S3 mode?
If so it might be worth trying.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-04 Thread Mark Kettenis
> Date: Mon, 3 May 2021 23:06:58 +0200
> From: "Peter N. M. Hansteen" 
> Cc: bugs@openbsd.org
> Content-Type: multipart/mixed; boundary="xA/hR9rv41MU9mZo"
> Content-Disposition: inline
> 
> 
> [1:text/plain Hide]
> 
> Hi Mark,
> 
> On Mon, May 03, 2021 at 07:00:44PM +0200, Mark Kettenis wrote:
> > Hi Peter,
> > 
> > Here is a small diff.  Two questions:
> > 
> > 1. Does the machine powerdown if you do halt -p with this diff?
> > 
> > 2. Does the diff fix the crashes?
> 
> With the diff applied, the machine booted fine, but halt -p produced
> another crash, as illustrated by

How about the diff below?

Same questions as above.


Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.397
diff -u -p -r1.397 acpi.c
--- dev/acpi/acpi.c 15 Mar 2021 22:44:57 -  1.397
+++ dev/acpi/acpi.c 4 May 2021 19:12:08 -
@@ -1436,7 +1436,8 @@ acpi_read_pmreg(struct acpi_softc *sc, i
 * For Hardware-reduced ACPI we also emulate PM1A_STS using
 * SLEEP_STATUS_REG.
 */
-   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS) {
+   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS &&
+   sc->sc_fadt->sleep_status_reg.register_bit_width > 0) {
uint8_t value;
 
KASSERT(offset == 0);
@@ -1514,7 +1515,8 @@ acpi_write_pmreg(struct acpi_softc *sc, 
 * For Hardware-reduced ACPI we also emulate PM1A_STS using
 * SLEEP_STATUS_REG.
 */
-   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS) {
+   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_STS &&
+   sc->sc_fadt->sleep_status_reg.register_bit_width > 0) {
uint8_t value = (regval >> 8);
 
KASSERT(offset == 0);
@@ -1530,7 +1532,8 @@ acpi_write_pmreg(struct acpi_softc *sc, 
 * For Hardware-reduced ACPI we also emulate PM1A_CNT using
 * SLEEP_CONTROL_REG.
 */
-   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_CNT) {
+   if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_CNT &&
+   sc->sc_fadt->sleep_control_reg.register_bit_width > 0) {
uint8_t value = (regval >> 8);
 
KASSERT(offset == 0);



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-03 Thread Peter N. M. Hansteen
Further info (screen shots) - today during a lengthy rsync it seemed the
screen saver kicked in but X crashed right after and then this sequence 
happened:

https://www.bsdly.net/~peter/20210503_164555.jpg
https://www.bsdly.net/~peter/20210503_164607.jpg
https://www.bsdly.net/~peter/20210503_164616.jpg
https://www.bsdly.net/~peter/20210503_164624.jpg
https://www.bsdly.net/~peter/20210503_165327.jpg
https://www.bsdly.net/~peter/20210503_165335.jpg

still running with a disable acpicpu* kernel, FWIW

All the best,
Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install

2021-05-03 Thread Mark Kettenis
Hi Peter,

Here is a small diff.  Two questions:

1. Does the machine powerdown if you do halt -p with this diff?

2. Does the diff fix the crashes?

Thanks,

Mark


Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.397
diff -u -p -r1.397 acpi.c
--- dev/acpi/acpi.c 15 Mar 2021 22:44:57 -  1.397
+++ dev/acpi/acpi.c 3 May 2021 17:00:09 -
@@ -262,6 +262,9 @@ acpi_gasio(struct acpi_softc *sc, int io
dnprintf(50, "gasio: %.2x 0x%.8llx %s\n",
iospace, address, (iodir == ACPI_IOWRITE) ? "write" : "read");
 
+   if (len == 0)
+   return 0;
+
KASSERT((len % access_size) == 0);
 
pb = (uint8_t *)buffer;



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-05-02 Thread Peter Nicolai Mathias Hansteen


> 2. mai 2021 kl. 19:54 skrev Mark Kettenis :
> 
> 
> Can you file a proper sendbug report for this machine?
> 
> 
I just did a sendbug. It went by really fast so I hope it actually contains the 
required information.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP


Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-05-02 Thread Bryan Steele
On Sun, May 02, 2021 at 04:02:17PM -0400, Bryan Steele wrote:
> On Sun, May 02, 2021 at 09:51:13PM +0200, Peter Nicolai Mathias Hansteen 
> wrote:
> > 
> > 
> > > 2. mai 2021 kl. 19:54 skrev Mark Kettenis :
> > > 
> > > 
> > > Can you file a proper sendbug report for this machine?
> > > 
> > > 
> > I just did a sendbug. It went by really fast so I hope it actually contains 
> > the required information.
> > 
> > All the best,
> > Peter
> 
> It is much better to generate the report using sendbug -E, fill out the
> template and send the report from a system that has mail configured.
> 
> -Bryan.

Sorry, sendbug -P



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-05-02 Thread Mark Kettenis
> Date: Sun, 2 May 2021 13:05:49 +0200
> From: "Peter N. M. Hansteen" 
> 
> On Sat, May 01, 2021 at 07:58:20PM +0200, Peter N. M. Hansteen wrote:
> > On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> > > 
> > > Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
> > 
> > Doing the boot -c and disable acpicpu* did enable the thing to boot, so
> > for now it's running with a config -e'd kernel.
> > 
> > The next hurdle is that the iwm interface is recognized but
> > 
> > iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, 
> > msi
> > iwm0: Failed to wake up the nic
> > 
> > I find a few instances of this message in Linux forums but I'm not entirely 
> > sure
> > how to apply any of that to my setup here.
> > 
> > The thing has now had a sysupgrade and I've run fw_update (the thing now 
> > connects via 
> > wired, ure).
> > 
> > dmesg attached and at https://www.bsdly.net/~peter/dmesg.zelda
> 
> I left the thing running a rscync of my home directory from the old one, and 
> this
> morning I found it had crashed (apparently the kernel reordering had not 
> worked,
> perhaps not a surprise), this time with "kernel: integer divide fault trap, 
> code=0"
> 
> trace and ps in the following pictures:
> 
> https://www.bsdly.net/~peter/20210502_111412.jpg 
> https://www.bsdly.net/~peter/20210502_111425.jpg 
> https://www.bsdly.net/~peter/20210502_111436.jpg 
> https://www.bsdly.net/~peter/20210502_111444.jpg 
> https://www.bsdly.net/~peter/20210502_111459.jpg 
> https://www.bsdly.net/~peter/20210502_111508.jpg
> 
> I'll likely try with jsg's patch again later today but any other
> input would be much appreciated.

Can you file a proper sendbug report for this machine?



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-05-02 Thread Peter N. M. Hansteen
On Sat, May 01, 2021 at 07:58:20PM +0200, Peter N. M. Hansteen wrote:
> On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> > 
> > Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
> 
> Doing the boot -c and disable acpicpu* did enable the thing to boot, so
> for now it's running with a config -e'd kernel.
> 
> The next hurdle is that the iwm interface is recognized but
> 
> iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
> iwm0: Failed to wake up the nic
> 
> I find a few instances of this message in Linux forums but I'm not entirely 
> sure
> how to apply any of that to my setup here.
> 
> The thing has now had a sysupgrade and I've run fw_update (the thing now 
> connects via 
> wired, ure).
> 
> dmesg attached and at https://www.bsdly.net/~peter/dmesg.zelda

I left the thing running a rscync of my home directory from the old one, and 
this
morning I found it had crashed (apparently the kernel reordering had not worked,
perhaps not a surprise), this time with "kernel: integer divide fault trap, 
code=0"

trace and ps in the following pictures:

https://www.bsdly.net/~peter/20210502_111412.jpg 
https://www.bsdly.net/~peter/20210502_111425.jpg 
https://www.bsdly.net/~peter/20210502_111436.jpg 
https://www.bsdly.net/~peter/20210502_111444.jpg 
https://www.bsdly.net/~peter/20210502_111459.jpg 
https://www.bsdly.net/~peter/20210502_111508.jpg

I'll likely try with jsg's patch again later today but any other input would be 
much
appreciated.

All the best
Peter 

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-05-01 Thread Peter N. M. Hansteen
On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> 
> Or perhaps boot -c and disable acpicpu* if that doesn't break anything.

Doing the boot -c and disable acpicpu* did enable the thing to boot, so
for now it's running with a config -e'd kernel.

The next hurdle is that the iwm interface is recognized but

iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 8265" rev 0x78, msi
iwm0: Failed to wake up the nic

I find a few instances of this message in Linux forums but I'm not entirely sure
how to apply any of that to my setup here.

The thing has now had a sysupgrade and I've run fw_update (the thing now 
connects via 
wired, ure).

dmesg attached and at https://www.bsdly.net/~peter/dmesg.zelda

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-04-30 Thread Peter N. M. Hansteen
On Fri, Apr 30, 2021 at 12:00:05PM +1000, Jonathan Gray wrote:
> 
> If you can build a kernel on another machine try
> 
> Index: sys/dev/acpi/acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.397
> diff -u -p -r1.397 acpi.c
> --- sys/dev/acpi/acpi.c   15 Mar 2021 22:44:57 -  1.397
> +++ sys/dev/acpi/acpi.c   30 Apr 2021 01:57:00 -
> @@ -262,6 +262,11 @@ acpi_gasio(struct acpi_softc *sc, int io
>   dnprintf(50, "gasio: %.2x 0x%.8llx %s\n",
>   iospace, address, (iodir == ACPI_IOWRITE) ? "write" : "read");
>  
> + if (access_size == 0) {
> + printf("%s: invalid size 0\n", DEVNAME(sc));
> + return -1;
> + }
> +
>   KASSERT((len % access_size) == 0);
>  
>   pb = (uint8_t *)buffer;

I'm building with that now on the older machine. I wonder, is this change
small and non-intrusive enough that we could hope it makes it into an amd64
snapshot soon?

(I fully appreciate why developers want faster machines :))

- Peter


-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-04-30 Thread Jonathan Gray
On Fri, Apr 30, 2021 at 01:51:11PM +0200, Peter N. M. Hansteen wrote:
> On Fri, Apr 30, 2021 at 12:00:05PM +1000, Jonathan Gray wrote:
> > 
> > If you can build a kernel on another machine try
> > 
> > Index: sys/dev/acpi/acpi.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> > retrieving revision 1.397
> > diff -u -p -r1.397 acpi.c
> > --- sys/dev/acpi/acpi.c 15 Mar 2021 22:44:57 -  1.397
> > +++ sys/dev/acpi/acpi.c 30 Apr 2021 01:57:00 -
> > @@ -262,6 +262,11 @@ acpi_gasio(struct acpi_softc *sc, int io
> > dnprintf(50, "gasio: %.2x 0x%.8llx %s\n",
> > iospace, address, (iodir == ACPI_IOWRITE) ? "write" : "read");
> >  
> > +   if (access_size == 0) {
> > +   printf("%s: invalid size 0\n", DEVNAME(sc));
> > +   return -1;
> > +   }
> > +
> > KASSERT((len % access_size) == 0);
> >  
> > pb = (uint8_t *)buffer;
> 
> I'm building with that now on the older machine. I wonder, is this change
> small and non-intrusive enough that we could hope it makes it into an amd64
> snapshot soon?
> 
> (I fully appreciate why developers want faster machines :))
> 
> - Peter

If you can boot bsd.rd you should be able to mount / and fetch a kernel
over http without having to build a snapshot.

Or perhaps boot -c and disable acpicpu* if that doesn't break anything.



Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

2021-04-29 Thread Jonathan Gray
On Thu, Apr 29, 2021 at 10:27:49PM +0200, Peter Nicolai Mathias Hansteen wrote:
> I just spent the evening trying to work around an odd error that happens 
> after an apparently straightforward install on a new laptop.
> 
> The most useful info I can offer is that the install proceeds with no 
> complaints, but on first boot this happens:
> 
> 
> 
> 
> Followed by
> 
> 
> 
> This is a modern laptop so things such as serial consoles are not easily 
> available.
> 
> How do I go about supplying useful information here? I tried but failed to 
> collect useful things such as dmesg (trying to write to the install USB only 
> corrupts and so forth).
> 
> The store’s return policy is friendly enough that I can have this one lying 
> around at least a few days (actually 60 but I suspect the lady of the house 
> will not be quite as accommodating)
> 
> All the best,
> Peter
> 
> PS in case the attachments do not survive the pics are also up at 
> https://www.bsdly.net/~peter/20210429_190606.jpg 
>  and 
> https://www.bsdly.net/~peter/20210429_190645.jpg 
> 
> 

acpicpu0 at acpi0kernel: integer divide fault trap, code=0
Stopped at acpi_gasio+0x36: idivl %r8d,%eax
acpi_gasio(x,1,0,0.0.0) at acpi_gasio+0x36
acpi_write_pmreg(x,2,0,3,x,3) at acpi_write_pmreg+0xba
acpi_write_pmreg(x,10,0,3,x,x) at acpi_write_pmreg+0x18f
acpicpu_attach(...) at acpicpu_attach+0x1c3

acpi_gasio+0x36 is /usr/src/sys/dev/acpi/acpi.c line 265

acpi_gasio(struct acpi_softc *sc, int iodir, int iospace, uint64_t address,
int access_size, int len, void *buffer)
..
KASSERT((len % access_size) == 0);

acpi_write_pmreg+0xba is /usr/src/sys/dev/acpi/acpi.c line 1541

/*
 * For Hardware-reduced ACPI we also emulate PM1A_CNT using
 * SLEEP_CONTROL_REG.
 */
if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_CNT) {
uint8_t value = (regval >> 8);

KASSERT(offset == 0);
acpi_gasio(sc, ACPI_IOWRITE,
sc->sc_fadt->sleep_control_reg.address_space_id,
sc->sc_fadt->sleep_control_reg.address,
sc->sc_fadt->sleep_control_reg.register_bit_width / 8,
sc->sc_fadt->sleep_control_reg.access_size, );
return;
}

If you can build a kernel on another machine try

Index: sys/dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.397
diff -u -p -r1.397 acpi.c
--- sys/dev/acpi/acpi.c 15 Mar 2021 22:44:57 -  1.397
+++ sys/dev/acpi/acpi.c 30 Apr 2021 01:57:00 -
@@ -262,6 +262,11 @@ acpi_gasio(struct acpi_softc *sc, int io
dnprintf(50, "gasio: %.2x 0x%.8llx %s\n",
iospace, address, (iodir == ACPI_IOWRITE) ? "write" : "read");
 
+   if (access_size == 0) {
+   printf("%s: invalid size 0\n", DEVNAME(sc));
+   return -1;
+   }
+
KASSERT((len % access_size) == 0);
 
pb = (uint8_t *)buffer;