Bug 251171 - [aarch64] panic: boot Huawei taishan
Summary: [aarch64] panic: boot Huawei taishan
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-arm (Nobody)
URL: https://reviews.freebsd.org/D27238
Keywords: panic
Depends on:
Blocks:
 
Reported: 2020-11-16 00:20 UTC by Andrey Fesenko
Modified: 2020-12-03 00:04 UTC (History)
3 users (show)

See Also:


Attachments
loader_horror.png (718.36 KB, image/png)
2020-11-16 00:20 UTC, Andrey Fesenko
no flags Details
acpi dump linux (486.29 KB, text/plain)
2020-11-16 09:32 UTC, Andrey Fesenko
no flags Details
huawei dmesg cdrom only boot (78.77 KB, text/plain)
2020-11-19 18:30 UTC, Andrey Fesenko
no flags Details
pciconf (12.39 KB, text/plain)
2020-11-19 18:31 UTC, Andrey Fesenko
no flags Details
MegaRAID-SAS3408 (2.24 KB, text/plain)
2020-12-03 00:01 UTC, Andrey Fesenko
no flags Details
zpool create error (1.31 KB, text/plain)
2020-12-03 00:03 UTC, Andrey Fesenko
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Fesenko 2020-11-16 00:20:14 UTC
Created attachment 219717 [details]
loader_horror.png

Hello.

We have Kunpeng 920, Huawei Taishan 2280 V2 for test.
Boot fail see loader_horror.png, loader menu have artefacts ASCII code and not work keyboard

 Index: sys/arm64/arm64/machdep.c
 ===================================================================
 --- sys/arm64/arm64/machdep.c   (revision 367627)
 +++ sys/arm64/arm64/machdep.c   (working copy)
 @@ -1059,6 +1059,8 @@
                }
                freeenv(env);

 +               arm64_bus_method = ARM64_BUS_ACPI;
 +
                /* If we set the bus method it is valid */
                if (arm64_bus_method != ARM64_BUS_NONE)
                        return (true);
 @@ -1071,6 +1073,8 @@
                        arm64_bus_method = ARM64_BUS_ACPI;
        }

 +       arm64_bus_method = ARM64_BUS_ACPI;
 +
        /*
         * If no option was set the default is valid, otherwise we are
         * setting one to get cninit() working, then calling panic to tell

After this patch, and disable loadre_logo=NO

boot escape work, loader have more progress but huawei_acpi_error.png

 generic_timer0: <ARM Generic Timer> irq 70,71,72 on acpi0

Any help wanted
Comment 2 Andrey Fesenko 2020-11-16 09:32:35 UTC
Created attachment 219726 [details]
acpi dump linux
Comment 3 Andrew Turner freebsd_committer 2020-11-16 09:59:29 UTC
We don't detect ACPI as there is no Serial Port Console Redirection (SPCR) table. It might be better to just check if there there are any ACPI tables. The SPCR check was to ensure there was some sort of console, however recent devices may just send the console to a display making this check less useful.

There is a second issue where we only check for the GICv3, where this has a GICv4. The same driver should work with both, so the check could be updated to also allow the latter.
Comment 4 Andrey Fesenko 2020-11-17 21:35:30 UTC
Fall back to use the GICR address from the distributor struct https://reviews.freebsd.org/D27247
Comment 5 commit-hook freebsd_committer 2020-11-19 09:27:40 UTC
A commit references this bug:

Author: andrew
Date: Thu Nov 19 09:26:51 UTC 2020
New revision: 367841
URL: https://svnweb.freebsd.org/changeset/base/367841

Log:
  Fall back to use the GICR address from the generic interrupt struct

  When there is no ACPI redistributor sub-table in the MADT we need to
  fall back to use the GICR base address from the GIC CPU interface
  structure.

  Handle this fallback when adding memory to the device and when counting
  the number of redistributors.

  PR:		251171
  Reported by:	Andrey Fesenko <f0andrey_gmail.com>
  Sponsored by:	Innovate UK
  Differential Revision:	https://reviews.freebsd.org/D27247

Changes:
  head/sys/arm64/arm64/gic_v3_acpi.c
Comment 6 Andrey Fesenko 2020-11-19 18:30:32 UTC
Created attachment 219818 [details]
huawei dmesg cdrom only boot

after r367841
path https://dpaste.com/3RVB8SBV9
commented https://github.com/freebsd/freebsd/blob/master/sys/dev/pci/pci_host_generic_acpi.c#L204

system success boot with cd, but requere not active jbod and MegaRAID Tri-Mode SAS3408 (if activate and load mrsas)

> mountroot: waiting for device /dev/iso9660/13_0_CURRENT_AARCH64_CD...
> Mounting from cd9660:/dev/iso9660/13_0_CURRENT_AARCH64_CD failed with error 19.

https://dpaste.com/BB3V4LHYS
Comment 7 Andrey Fesenko 2020-11-19 18:31:14 UTC
Created attachment 219819 [details]
pciconf
Comment 8 Andrey Fesenko 2020-12-02 23:59:31 UTC
After commit https://reviews.freebsd.org/D27274 https://svnweb.freebsd.org/base?view=revision&revision=368156

Boot not require any patch, but need disable boot menu and load mrsas.ko if use MegaRAID SAS3408.

Sorry, the test period is over and the test platform is no longer available.
Comment 9 Andrey Fesenko 2020-12-03 00:01:47 UTC
Created attachment 220198 [details]
MegaRAID-SAS3408

partial boot log MegaRAID SAS3408 with mrsas.ko
Comment 10 Andrey Fesenko 2020-12-03 00:03:44 UTC
Created attachment 220199 [details]
zpool create error

UFS succes work, zpool create not work

> (da9:mrsas0:1:9:0): Ecannot zero first 4096 bytes of '/dev/da9p1': Input/output error