-----Original Message----- From: Arm-dev [mailto:arm-dev-bounces@centos.org] On Behalf Of Jeremiah Rothschild Sent: Saturday, January 27, 2018 3:18 AM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] Kernel problems on APM X-Gene
On Fri, Jan 26, 2018 at 10:07:03PM +0700, Phong Vo wrote:
Jeremy,
Edit the grub command line and remove both or one of console= or earlycon= below
console=ttyS0,115200 earlycon=uart8250,mmio32,0x1c020000
to see if proceeds any further.
Wow, removing "console=" worked! Can you please explain?
The UARTSerialBus macro in Tianocore is used to define the characteristics of a slave device attached to the UART bus. It should be put in Resource template of a different Device node rather than the UART controller node. With a rather recent commit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ ?id=e361d1f85855ded967bd4803e8293445a6ce301a
the visible of UARTSerialBus forces ACPI subsystem to think that the UART controller node is a slave device node thus fails to open the console device.
-Phong
-----Original Message----- From: Arm-dev [mailto:arm-dev-bounces@centos.org] On Behalf Of Jeremiah Rothschild Sent: Friday, January 26, 2018 5:04 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] Kernel problems on APM X-Gene
On Fri, Jan 26, 2018 at 04:48:24PM +0700, Phong Vo wrote:
Jeremy,
Hi Phong. Thanks for the reply! Also, thank you for the tools & instructions to flash the Tianocore. That process worked great. :)
Is this on which board?
Gigabyte MP30-AR0 (uart0).
Unless you provide a log file, it is difficult to tell,
Understood. I have attached boot.log to this message. After this point, it freezes/hangs.
but latest CentOS 7.4 (kernel 4.11) boots fine on X-Gene platforms.
I am not sure how you built kernel, but this is what you can check. To boot X-Gene using acpi, you need to enable CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y. CentOS (RPM) default configuration should already have this enabled.
Interesting. It is enabled in the failing kernel:
[root@hammer ~]# grep CONFIG_ARM64_ACPI_PARKING_PROTOCOL /boot/config-4.11.0-45.el7.aarch64 CONFIG_ARM64_ACPI_PARKING_PROTOCOL=y
but it is not enabled in the working kernel that Gordan built for me:
[root@hammer ~]# grep CONFIG_ARM64_ACPI_PARKING_PROTOCOL /boot/config-4.9.60-1.el7.centos.aarch64 [root@hammer ]#
-Phong
+-----Original Message----- +From: Arm-dev [mailto:arm-dev-bounces@centos.org] On Behalf Of +Jeremiah Rothschild +Sent: Friday, January 26, 2018 4:35 PM +To: Conversations around CentOS on ARM hardware +Subject: Re: [Arm-dev] Kernel problems on APM X-Gene
+On Sat, Nov 04, 2017 at 05:37:54PM +0000, Gordan Bobic wrote: +> Apologies for taking so long to return to this thread, it took +> way longer than expected to get to the machine and get it up and +> running +again.
+Thanks for the update & apologies as well on my delayed follow-up.
+Last time I wrote the mailing list about my kernel problems, I was +told (by jperrin@centos.org) that my system was not in a supported +state because I was daisy-chaining Tianocore EFI via U-Boot. I was +directed to flash the Tianocore firmware and remove U-Boot from
the
equation.
+Although I was skeptical of this answer, I finally was able to do
this.
+Unfortunately, however, this does not change behavior. I still +cannot successfully boot into any kernels beyond 4.5 unless I use
'acpi=off'.
+I am, interestingly enough, able to run the 4.9.60 kernel that you +supplied.
+So:
+(1) My experience leads me to believe that it is still a +possibility that a kernel related bug exists.
+(2) I am confused as to why your kernel worked. I built kernel-
alt-
+4.11.0-22.el7a from source and it fails like the others. Were
there
+any special steps you took in building the rpm's you supplied me?
+(3) Is it true that you are able to boot into the (> 4.5) distro- +supplied kernels? Or have you only tried/succeeded with your
custom
+builds?
+Thanks again!
+j
+> I also just updated the build to the latest 4.9.60. +> +> Here is a download link to both binaries and src.rpm (download +> the kernel tarball from kernel.org manually to build from
src.rpm):
+> http://ftp.redsleeve.org/pub/misc/kernel/aarch64/RPMS/ +> http://ftp.redsleeve.org/pub/misc/kernel/aarch64/SRPMS/ +> +> To recap - I am also running with Tianocore EFI chain-loaded
from
+> u-boot, and mainling 4.9.x boots just fine on it. +> +> No need for disabling ACPI on the kernel command line, no need
to
+> run EFI firmware as a 1st stage boot loader, it just works. +> Do feel free to try it - if that works for you but the distro +> supplied 4.5.x kernel doesn't, it seems reasonably conclusive +> that it is the CentOS kernel that is broken for this board. +> +> I'd also be interested in learning whether you have any luck +> getting PCIe cards to work with it without problems - I haven't +> tried it since upgrading to 4.9.x, but certainly on 4.4.x +> mainline the machine used to reliably lock up as soon as the +> driver for the
PCIe card loads.
+> +> Gordan +> +> +> On Fri, Sep 22, 2017 at 12:06 PM, Jeremiah Rothschild +> jeremiah@franz.com +> wrote: +> +> > On Fri, Sep 22, 2017 at 11:59:00AM +0100, Gordan Bobic wrote: +> > > On Fri, Sep 22, 2017 at 11:54 AM, Jeremiah Rothschild < +> > jeremiah@franz.com> +> > > wrote: +> > > +> > > > On Fri, Sep 22, 2017 at 11:39:19AM +0100, Gordan Bobic
wrote:
+> > > > > If you are interested, I'm more than happy to share my +> > > > > src.rpm for +> > 4.9.x, +> > > > > but won't be able to get to it before tomorrow morning
as
+> > > > > the +> > machine was +> > > > > recently mothballed. +> > > > +> > > > Thanks. I actually need to test with as new of a version
as
+> > > > I can +> > because I +> > > > have been experiencing an occasional "page allocation
failure"
+> > > > kernel panic. +> > > > No idea if/when that was fixed but I figure the newest +> > > > version is my +> > best +> > > > hope. +> > > > +> > > +> > > I've been on my own 4.9.x more or less since I got the +> > > machine, it was in +> > > 24/7 use, and I never experienced that issue. So it may be +> > > worth a cross-check with the kernel that I'm running to see +> > > whether the fault follows your machine or whether it is +> > > kernel
dependent.
+> > +> > You're right. It would be a good extra data point. Feel free
to
+> > mail me directly once you're sorted and I'll gladly check out +> > your 4.9 +build. +> > Thanks +> > again! +> > +> > +> > +> > > _______________________________________________ +> > > Arm-dev mailing list +> > > Arm-dev@centos.org +> > > https://lists.centos.org/mailman/listinfo/arm-dev +> > +> > _______________________________________________ +> > Arm-dev mailing list +> > Arm-dev@centos.org +> > https://lists.centos.org/mailman/listinfo/arm-dev +> >
+> _______________________________________________ +> Arm-dev mailing list +> Arm-dev@centos.org +> https://lists.centos.org/mailman/listinfo/arm-dev
+_______________________________________________ +Arm-dev mailing list +Arm-dev@centos.org +https://lists.centos.org/mailman/listinfo/arm-dev _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev