Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
Itaru
On 10/10/2017 01:30 AM, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
This is usually down to firmware issues, but we don't test every possible hardware/firmware variation to validate.
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
We'll likely match what RH does for their aarch64/arm64 support.
Hi Jim, all,
Red Hat says BIOS T43 is a production release at the moment, we're on the same version, so I exclude that for now.
Upstream kernel, v4.13 configured in using config-4.5.0.25.el7.aarch64 boots on the same HW. Have you touched the config when changing the kernel onto 4.11?
I think still, if you don't mind sharing the exact HW used for the CentOS 7 Altarch validations, would be greatly helpful to narrow down this issue.
Itaru
On 10/11/17 1:41 AM, Jim Perrin wrote:
On 10/10/2017 01:30 AM, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
This is usually down to firmware issues, but we don't test every possible hardware/firmware variation to validate.
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
We'll likely match what RH does for their aarch64/arm64 support.
On 10/10/2017 03:49 PM, Itaru Kitayama wrote:
Hi Jim, all,
Red Hat says BIOS T43 is a production release at the moment, we're on the same version, so I exclude that for now.
Upstream kernel, v4.13 configured in using config-4.5.0.25.el7.aarch64 boots on the same HW. Have you touched the config when changing the kernel onto 4.11?
Yes, the config changed between 4.5 and 4.11. You can see the config here -> https://git.centos.org/blob/sig-altarch!kernel.git/sig-altarch7-aarch64/SOUR...
It is the upstream (RedHat provided) config with no modifications.
I think still, if you don't mind sharing the exact HW used for the CentOS 7 Altarch validations, would be greatly helpful to narrow down this issue.
Unfortunately I cannot. Much of the hardware is provided under NDA.
Itaru
On 10/11/17 1:41 AM, Jim Perrin wrote:
On 10/10/2017 01:30 AM, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
This is usually down to firmware issues, but we don't test every possible hardware/firmware variation to validate.
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
We'll likely match what RH does for their aarch64/arm64 support.
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On Tue, Oct 10, 2017 at 05:30:39PM +0900, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
This sounds a lot like what I experienced. Try booting with the added kernel paramter 'acpi=off'. Maybe that will get you further.
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
Itaru _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
We have T47 available for that platform. What BMC f/w are you using? Regards Tony. Avantek Computer
Regards, Tony Avantek Computer Ltd | St Peter’s Road | ARNESBY | LE8 5WJ t: +44 (0)330 300 3000 web: https://www.avantek.co.uk webstore: https://www.avantek.co.uk/store ARM SERVER NEWS: http://www.arm.com/innovation/products/avantek-2-u-server.php ________________________________ From: Arm-dev arm-dev-bounces@centos.org on behalf of Jeremiah Rothschild jeremiah@franz.com Sent: Tuesday, October 10, 2017 6:20:38 PM To: Conversations around CentOS on ARM hardware Subject: Re: [Arm-dev] kernel 4.11.0-22.el7.2.aarch64 does not boot on ThunderX
On Tue, Oct 10, 2017 at 05:30:39PM +0900, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
This sounds a lot like what I experienced. Try booting with the added kernel paramter 'acpi=off'. Maybe that will get you further.
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
Itaru _______________________________________________ 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
Hi Itaru,
On Tue, Oct 10, 2017 at 05:30:39PM +0900, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
Could you please try to run kernel with earlycon option? Append kernel command line with something like "earlycon=pl011,0x87e024000000" and check kernel output. This could give us some hint of what is going on there.
WBR, Vadim
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
Itaru _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Vadim,
At this moment, I don't need to try to this specific latest CentOS kernel as I said in previous replied to Jim, v4.13 boots on the HW, but thanks for your suggestion. I've been booting up the HW with slightly at different address like below:
earlycon=pl011,0x87e025000000
this give me lots of boot messages.
Itaru
On 2017/10/11 23:28, Vadim Lomovtsev wrote:
Hi Itaru,
On Tue, Oct 10, 2017 at 05:30:39PM +0900, Itaru Kitayama wrote:
Hi,
In our attempt upgrading from 4.5.0-25.el7.aarch64 to the 4.11-based kernel we see the latter does not boot on ThunderX.
Here's the HW details:
http://b2b.gigabyte.com/ARM-Server/R150-T62-rev-100#support-manual
The BIOS release is T43. (According Red Hat, they've been testing fine their 1 socket GIGABYTE server with their RHEL 7 kernels.)
I am wondering what ThunderX platform CentOS has been using for testing, and the list happens to have the above HW.
The boot process seems to be stuck as soon as system prints our EFI stub messages. No messages from the kernel.
Could you please try to run kernel with earlycon option? Append kernel command line with something like "earlycon=pl011,0x87e024000000" and check kernel output. This could give us some hint of what is going on there.
WBR, Vadim
Is the CentOS Alt architecture group going to release a 4.12 or .13 kernel soon?
Itaru _______________________________________________ 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
On 10/12/2017 12:29 AM, Itaru Kitayama wrote:
Vadim,
At this moment, I don't need to try to this specific latest CentOS kernel as I said in previous replied to Jim, v4.13 boots on the HW, but thanks for your suggestion. I've been booting up the HW with slightly at different address like below:
earlycon=pl011,0x87e025000000
this give me lots of boot messages.
Can you provide those messages? (btw if you have a correctly working firmware, simply saying "earlycon" will setup earlycon automatically)
Usually the lack of any output is caused by something failing prior to the serial console being setup correctly. That specific Gigabyte platform has various firmware releases, of which you should be running the latest version to have the necessary ACPI tables.
A quick note, on ACPI. Disabling ACPI is not an optional thing. If you turn it off, you will have a non-standard, completely untested, broken, non-functional machine. Nobody tests any of the kernel sources with ACPI disabled. In the future it won't be possible to disable it. Just say no to turning off ACPI.
Jon.
Jon, all,
Our ThunderX system at this moment has a system NIC issue that's it's not fully linked up at boot time, but only by re-plugging the fibre cable manually. So given it's been up and operational, while I don't have no issue providing it, I am not able to honor your request.
I was also about to ask this ACPI question to Jim as to whether the CentOS community support it or not. Thanks for the clarifications and heads up.
Itaru
On 10/13/17 10:56 AM, Jon Masters wrote:
On 10/12/2017 12:29 AM, Itaru Kitayama wrote:
Vadim,
At this moment, I don't need to try to this specific latest CentOS kernel as I said in previous replied to Jim, v4.13 boots on the HW, but thanks for your suggestion. I've been booting up the HW with slightly at different address like below:
earlycon=pl011,0x87e025000000
this give me lots of boot messages.
Can you provide those messages? (btw if you have a correctly working firmware, simply saying "earlycon" will setup earlycon automatically)
Usually the lack of any output is caused by something failing prior to the serial console being setup correctly. That specific Gigabyte platform has various firmware releases, of which you should be running the latest version to have the necessary ACPI tables.
A quick note, on ACPI. Disabling ACPI is not an optional thing. If you turn it off, you will have a non-standard, completely untested, broken, non-functional machine. Nobody tests any of the kernel sources with ACPI disabled. In the future it won't be possible to disable it. Just say no to turning off ACPI.
Jon. _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
-
Itaru Kitayama -
Jeremiah Rothschild -
Jim Perrin -
Jon Masters -
Tony Lees - Avantek -
Vadim Lomovtsev