Re: Boot regression in Linux 6.1 gone for Montecito in 6.3
Hi all, i have rx2620 sitting in shelf for some time. Where can i get working iso to try? Last time i booted 3.2.0 kernel. Gatis Frank Scheiner (šajā datumā: sestd., 2023. g. 20. maijs 21:20) rakstīja: > Dear all, > > I today noticed that a new Debian kernel is available from [1]. Thanks > to whoever built that one - most likely Adrian. > > [1]: > > http://ftp.ports.debian.org/debian-ports/pool-ia64/main/l/linux/linux-image-6.3.0-0-mckinley_6.3.2-1~exp1_ia64.deb > > I currently have the rx2620 and the rx2800-i2 at home and gave it a test > on them, and... > > ...it is working more or less flawlessly on both systems. The boot > regression at where the initramfs is extracted is gone for the rx2620. > > @Pedro: > Maybe you give this kernel a try on your rx2660 to see if it is working > for that one, too. It will take me until next week to test it on my > Montvale driven systems and the rx4640 with Madisons. > > There is a reproducible issue for the rx2800-i2, though, happening just > after the first occurance of a message from the igb driver for the four > built-in PCI-e NICs (longer log on [2]). I cut the intertwined USB > messages here: > > ``` > [ 37.566439] [ cut here ] > [ 37.571640] WARNING: CPU: 7 PID: 155 at kernel/irq/msi.c:196 > msi_domain_free_descs+0x240/0x280 > [ 37.582425] GSI 19 (level, low) -> CPU 7 (0x0700) vector 75 > [ 37.583481] Modules linked in: igb(+) uhci_hcd(+) ehci_pci ehci_hcd > i2c_algo_bit usbcore ptp pps_core i2c_core usb_common > [ 37.603864] CPU: 7 PID: 155 Comm: (udev-worker) Not tainted > 6.3.0-0-mckinley #1 Debian 6.3.2-1~exp1 > [ 37.622180] Hardware name: hp Integrity rx2800 i2, BIOS 01.93 09/12/2012 > [ 37.622180] > [ 37.622180] Call Trace: > [ 37.640068] [] show_stack.part.0+0x30/0x60 > [ 37.640068] sp=e0084649fa70 > bsp=e00846499c18 > [ 37.652236] [] show_stack+0x90/0xc0 > [ 37.652236] sp=e0084649fa70 > bsp=e00846499be0 > [ 37.696069] [] dump_stack_lvl+0xf0/0x160 > [ 37.696069] sp=e0084649fc40 > bsp=e00846499b70 > [ 37.720069] [] dump_stack+0x30/0x60 > [ 37.720069] sp=e0084649fc40 > bsp=e00846499b18 > [ 37.720069] [] __warn+0x160/0x200 > [ 37.720069] sp=e0084649fc40 > bsp=e00846499ad0 > [ 37.748236] [] warn_slowpath_fmt+0x300/0x360 > [ 37.748236] sp=e0084649fc40 > bsp=e00846499a58 > [ 37.776069] [] msi_domain_free_descs+0x240/0x280 > [ 37.776069] sp=e0084649fc70 > bsp=e00846499a18 > [ 37.800069] [] > msi_domain_free_msi_descs_range+0x50/0x80 > [ 37.800069] sp=e0084649fc80 > bsp=e008464999d8 > [ 37.826759] [] pci_msi_teardown_msi_irqs+0x90/0xe0 > [ 37.826759] sp=e0084649fc90 > bsp=e008464999b8 > [ 37.850941] [] pci_free_msi_irqs+0x30/0xa0 > [ 37.850941] sp=e0084649fc90 > bsp=e0084640 > [ 37.874941] [] pci_disable_msix+0xb0/0xe0 > [ 37.874941] sp=e0084649fc90 > bsp=e00846499968 > [ 37.898941] [] > igb_reset_interrupt_capability+0x230/0x260 [igb] > [ 37.898941] sp=e0084649fc90 > bsp=e00846499928 > [ 37.920068] [] igb_probe+0x970/0x3380 [igb] > [ 37.920068] sp=e0084649fc90 > bsp=e00846499858 > [ 37.950180] [] local_pci_probe+0x90/0x140 > [ 37.950180] sp=e0084649fca0 > bsp=e00846499818 > [ 37.974181] [] pci_device_probe+0x190/0x520 > [ 37.974181] sp=e0084649fca0 > bsp=e008464997c0 > [ 37.998180] [] really_probe+0x260/0xb20 > [ 37.998180] sp=e0084649fcc0 > bsp=e00846499770 > [ 38.024068] [] __driver_probe_device+0x290/0x420 > [ 38.024068] sp=e0084649fcc0 > bsp=e00846499730 > [ 38.024068] [] driver_probe_device+0x50/0x160 > [ 38.024068] sp=e0084649fcc0 > bsp=e008464996e8 > [ 38.052236] [] __driver_attach+0x380/0x4c0 > [ 38.052236] sp=e0084649fcc0 > bsp=e008464996b0 > [ 38.052236] [] bus_for_each_dev+0x100/0x1c0 > [ 38.052236] sp=e0084649fcc0 > bsp=e00846499668 > [ 38.086181] [] driver_attach+0x40/0x60 > [ 38.086181] sp=e0084649fcd0 > bsp=e00846499648 > [ 38.110180] [] bus_add_driver+0x230/0x520 > [ 38.110180] sp=e0084649fcd0 > bsp=e00846499600 > [ 38.134180] [] driver_register+0x100/0x360 > [ 38.134180] sp=e0084649fcd0
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 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 > 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 > --- > 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
Re: Moving ia64 to Debian Ports?
I have one ia64 server installed for building. But also have little experience with autobuild / buildd / etc. g On 2014.02.09. 19:59, Émeric MASCHINO wrote: Hi, Now that Debian has killed ia64, I'm wondering if we could maintain ia64 alive on Debian Ports [1]? It would be really sad to let 14 years of work vanish to trash, don't you think so? I'm however not familiar with Debian infrastructure, so don't know exactly what needs to be done to have ia64 accepted in Debian Ports. Does anybody have any pointer or guidance instruction? Émeric [1] http://www.ports.debian.org -- To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f94013.6010...@pie-dabas.net
