[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2, mckinley, rx2620)



Well, problem is then likely with iLO card or serial console.
Indeed, I'm daily using a zx6000 workstation for years, being with
Debian for more than a decade, now with Gentoo since Debian has killed
the plug on ia64 in 2013.
I have no problem booting/using it locally (GNOME 3.24 desktop
environment) with kernels 4.9.76 and 4.12.12. Kernels were compiled
either with GCC 4.5.4 (because of a nasty error with GDB that
sometimes segfaults when kernels i compiled with GCC > 4.5) or 6.2.0.

2018-02-14 1:41 GMT+01:00 Pedro Miguel Teixeira <pmsjt@texair.net>:
>
>
> Hi Jason.
>
>
>
> That was close – I was really about to send the zx6000 onto the tech
> recycle.
>
>
>
> The following is all I get coming out from the console (Serial A, since the
> zx6000 does not have a management card / iLO). After the initrd line shows,
> a good 5 seconds pass. Then the front panel becomes all red and the cryptic
> modem-style sounds come out. I’ve wondered about the health of both my ELILO
> and Kernel, but my rx2660 boots fine with the exact the same two.
>
>
>
>
>
> EFI Boot Manager ver 1.10 [14.61]  Firmware ver 2.31 [4411]
>
>
>
> Loading device drivers
>
>
>
> Loading.: Auxiliary Floating Point Driver
>
> Load of Auxiliary Floating Point Driver failed: Not Found
>
> EFI Boot Manager ver 1.10 [14.61]  Firmware ver 2.31 [4411]
>
>
>
> Please select a boot option
>
>
>
>     Windows Boot Manager
>
>     Debian
>
>     EFI Shell [Built-in]
>
>     Removable Media
>
>     Boot Option Maintenance Menu
>
>     System Configuration Menu
>
>
>
>
>
>     Use ^ and v to change option(s). Use Enter to select an option
>
> Loading.: Debian
>
> Starting: Debian
>
> ELILO v3.14 for EFI/IA-64
>
> ..
>
> Uncompressing Linux... done
>
> Loading file \EFI\debian\initrd.img...done
>
>
>
>
>
>
>
>
>
> _____
> Pedro
>
>
>
> From: Jason Duerstock
> Sent: Friday, February 9, 2018 04:01
> To: Pedro Miguel Teixeira
> Cc: Gatis Visnevskis; Ivan Zakharyaschev; debian-ia64; glebfm@altlinux.org
>
>
> Subject: Re: Bug#711135: Re: compiling a bootable kernel for ia64 (itanium2,
> mckinley, rx2620)
>
>
>
> Hi Pedro,
>
> Can you file a separate bug for this, and include a boot log?
>
> Thanks,
>
> Jason
>
>
> On Fri, Feb 9, 2018 at 6:24 AM, Pedro Miguel Teixeira <pmsjt@texair.net>
> wrote:
>>
>>
>> The latest kernel available from Debian does work fine on my Montvale
>> rx2660. However, I cannot boot my McKinley zx6000 with it. It will MCA
>> really early in the boot process.
>>
>>
>>
>> Linux b777 3.2.0-4-mckinley #1 SMP Debian 3.2.78-1 ia64 GNU/Linux
>>
>>
>>
>>
>>
>> _____
>> Pedro
>>
>>
>>
>> From: Gatis Visnevskis
>> Sent: Friday, February 9, 2018 03:13
>> To: Ivan Zakharyaschev
>> Cc: Jason Duerstock; debian-ia64; glebfm@altlinux.org
>> Subject: Re: Bug#711135: Re: compiling a bootable kernel for ia64
>> (itanium2,
>> mckinley, rx2620)
>>
>>
>>
>> Hi all
>>
>> I got working 3.2.0 kernel after some work. Without recompilation.
>> HP rx4640. That was 2 years ago. Server switched off for cost saving :(
>>
>> Started to install toolchain for compilation, but not finished.
>> Internal disks were too small, some 36 gb i think.
>>
>> It seems that i have to boot my server, and try again, as there is some
>> light in end of tunnel. I was hoping to get LXC working on ia64 some
>> day.
>>
>> Gasha
>>
>> On Fri, 9 Feb 2018 11:33:16 +0300 (MSK)
>> Ivan Zakharyaschev <imz@altlinux.org> wrote:
>>
>>> Hi,
>>>
>>> On Wed, 7 Feb 2018, Ivan Zakharyaschev wrote:
>>>
>>> > On Sun, 4 Feb 2018, Jason Duerstock wrote:
>>> >
>>> >>  Does the kernel from here work for you?:
>>> >>
>>> >>  https://people.debian.org/~jrtc27/wheezy-backports-ia64/
>>> >>
>>> >>  Specifically
>>> >>
>>> >>
>>> >> https://people.debian.org/~jrtc27/wheezy-backports-ia64/linux-image-3.16.0-0.bpo.4-mckinley_3.16.39-1+deb8u1~bpo70+1+gcc4.4_ia64.deb
>>> >
>>> > (As I've already said, this kernel works for our machine.)
>>> >
>>> > How to reproduce this build? Have you published the corresponding
>>> > rules?
>>> >
>>> > I tried:
>>> >
>>> > $ apt-get source linux-image-3.16.0-0.bpo.4-mckinley
>>> > $ cd linux-3.16.39/
>>> > $ sed -e 's/gcc-4.6/gcc-4.4/g' debian/config/ia64/defines -i
>>> > $ debuild -b -us -uc
>>> > $ debuild -j2 -b -us -uc
>>> > ...
>>> >   Kernel: vmlinux.gz is ready
>>> > ERROR: "numa_slit" [drivers/block/nvme.ko] undefined!
>>> > make[6]: *** [__modpost] Error 1
>>>
>>> BTW, has anyone been working on adapting the newest kernel package
>>> for ia64? (buildd simply reports that there are no rules for ia64.)
>>>
>>> As for building 3.16 myself (reproducing Jason's build), I've found
>>> an obvious fix for the above build problem at
>>>
>>>
>>> https://kernel.opensuse.org/cgit/kernel-source/commit/patches.arch/ia64-export-numa_slit.patch?h=packaging&id=bbf39ca510248f9f9cbfc3c65e8514df929a3094
>>> :
>>>
>>> $ cd debian/patches/
>>> $ mkdir bugfix/ia64
>>> $ wget
>>>
>>>
>>> 'https://kernel.opensuse.org/cgit/kernel-source/plain/patches.arch/ia64-export-numa_slit.patch?h=packaging&id=bbf39ca510248f9f9cbfc3c65e8514df929a3094'
>>> -O bugfix/ia64/ia64-export-numa_slit.patch
>>> $ cat bugfix/ia64/ia64-export-numa_slit.patch
>>> From: Hannes Reinecke <hare@suse.de>
>>> Date: Wed, 14 Jan 2015 15:01:30 +0100
>>> Subject: [PATCH] ia64: export numa_slit()
>>> Patch-Mainline: not yet
>>> References: bnc#913030,FATE#317455
>>>
>>> nvme triggers a build error with 'numa_slit' being undefined.
>>>
>>> Signed-off-by: Hannes Reinecke <hare@suse.de>
>>> ---
>>>   arch/ia64/mm/numa.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/ia64/mm/numa.c b/arch/ia64/mm/numa.c
>>> index 88f4eeb..23a914c 100644
>>> --- a/arch/ia64/mm/numa.c
>>> +++ b/arch/ia64/mm/numa.c
>>> @@ -35,6 +35,7 @@ struct node_cpuid_s node_cpuid[NR_CPUS] =
>>>    * proportional to the memory access latency ratios.
>>>    */
>>>   u8 numa_slit[MAX_NUMNODES * MAX_NUMNODES];
>>> +EXPORT_SYMBOL(numa_slit);
>>>
>>>   /* Identify which cnode a physical address resides on */
>>>   int
>>
>>
>
>


Reply to: