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

[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

[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

[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

[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

[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

[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

[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

[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;