Re: Use SMP kernel for Alpha (udeb) builds
On 12/13/18 09:08, Michael Cree wrote: On Sun, Dec 09, 2018 at 08:21:11AM +1300, Michael Cree wrote: On Sun, Dec 09, 2018 at 07:54:52AM +1300, Michael Cree wrote: On Sat, Dec 08, 2018 at 12:01:23PM +1300, Michael Cree wrote: On Fri, Dec 07, 2018 at 10:39:58PM +0100, Frank Scheiner wrote: On 12/7/18 22:06, Michael Cree wrote: On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: As per [1] and our recent discussions the generic 4.x kernels seem to no longer work on Alpha machines which also renders any installer images using the generic 4.x kernels non-working. Bisection leads to: dca496451bddea9aa87b7510dc2eb413d1a19dfd is the first bad commit Actually I am not so sure about that. It appears that sometimes a bad kernel can boot which might have lead me astray. That commit after failing once (assuming I did not make a mistake in the bisection) is now booting... It would appear that I accidently marked one step in the bisection incorrectly but I have now identified the problem commit and it makes a lot more sense. The first bad commit is commit b38d08f3181c5025a7ce84646494cc4748492a3b Author: Tejun Heo Date: Tue Sep 2 14:46:02 2014 -0400 percpu: restructure locking The commit prior to that one boots reliably but this one fails to boot a generic kernel. I'll report it to the linux kernel mail list. That's great! Thanks for getting things forward. Cheers, Frank
Re: Use SMP kernel for Alpha (udeb) builds
On Sun, Dec 09, 2018 at 08:21:11AM +1300, Michael Cree wrote: > On Sun, Dec 09, 2018 at 07:54:52AM +1300, Michael Cree wrote: > > On Sat, Dec 08, 2018 at 12:01:23PM +1300, Michael Cree wrote: > > > On Fri, Dec 07, 2018 at 10:39:58PM +0100, Frank Scheiner wrote: > > > > On 12/7/18 22:06, Michael Cree wrote: > > > > > On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: > > > > > > As per [1] and our recent discussions the generic 4.x kernels seem > > > > > > to no > > > > > > longer work on Alpha machines which also renders any installer > > > > > > images using > > > > > > the generic 4.x kernels non-working. > > > > Bisection leads to: > > > > dca496451bddea9aa87b7510dc2eb413d1a19dfd is the first bad commit > > Actually I am not so sure about that. It appears that sometimes a > bad kernel can boot which might have lead me astray. That commit > after failing once (assuming I did not make a mistake in the > bisection) is now booting... It would appear that I accidently marked one step in the bisection incorrectly but I have now identified the problem commit and it makes a lot more sense. The first bad commit is commit b38d08f3181c5025a7ce84646494cc4748492a3b Author: Tejun Heo Date: Tue Sep 2 14:46:02 2014 -0400 percpu: restructure locking The commit prior to that one boots reliably but this one fails to boot a generic kernel. I'll report it to the linux kernel mail list. Cheers, Michael.
Re: Use SMP kernel for Alpha (udeb) builds
Hi Bob, Michael, On 12/8/18 21:03, Bob Tracy wrote: On Sat, Dec 08, 2018 at 07:41:15PM +0100, Frank Scheiner wrote: On 12/8/18 15:05, Bob Tracy wrote: So can we assume `CONFIG_ALPHA_GENERIC=y` also activates `CONFIG_ALPHA_LEGACY_START_ADDRESS`? I wouldn't assume so, particularly for the Gentoo kernel source tree to whatever extent it differs from the kernel.org source tree. What the dependency is saying is, you can't have the legacy start address config option force-enabled unless you're building a generic kernel. Thanks for the clarification. Otherwise, the (alpha) processor-specific config options presumably dictate whether the legacy start address is used. This is, I think, why Gentoo includes a generic+lsa kernel and a generic+nolsa kernel in their install image. Not helpful for our problem, but say, does the generic+nolsa kernel also boot on your PWS? I'd actually expect it to work. Because if that lsa is really only needed for older bootloaders (as mentioned on [1]), using a nolsa kernel on an older Alpha with a current bootloader shouldn't be a problem. [1]: https://cateee.net/lkddb/web-lkddb/ALPHA_LEGACY_START_ADDRESS.html But then I don't understand why Gentoo "today" still needs two different kernels. Just to be clear, Gentoo's generic kernel *does* have SMP configured, and *with* the legacy start address enabled should boot just fine on your PWS as it does on mine. Yes, I expect that, too. But if SMP support really has a play in our problem, than the Gentoo kernels (being both SMP capable) cannot provide "new" information for our problem. BTW, the patches applied by Gentoo for a slightly newer kernel (4.14.72) are available on [2]. [2]: https://dev.gentoo.org/~mpagano/genpatches/patches-4.14-72.html The kernel version is 4.14(.65). I was missing the time yesterday, so tested the Debian generic kernel on my ES45 today. it behaves like the DS25, i.e. it seems to hang after aboot starts the kernel: As I'm still missing a "MMJ to whatever" adapter I "copied" this from a glass console: ``` [...] bootstrap code read in base = 2fc000, image_start = 0, image_bytes = 90b86c(9484396) initializing HWRPB at 2000 initializing page table at initializing machine state setting affinity to the primary CPU jumping to bootstrap code aboot: Linux/Alpha SRM bootloader version 1.0_pre20040408 aboot: switching to OSF/1 PALcode version 1.92 aboot: loading initrd (4874860 bytes/9522 blocks) at 0xfc00ffb46000 aboot: starting kernel network with arguments root=/dev/nfs ip=:eth0:dhcp console=tty1 net.ifnames=0 biosdevname=0 ``` Another thing to note: Pushing (and releasing) the halt button on the ES45's OCP has no effect afterwards (I haven't yet checked that on my DS25). Doing the same when the Debian SMP kernel has started and the OS is running returns me immediately to the SRM prompt. So this mechanism seems to be broken by loading the Debian generic kernel. Cheers, Frank
Re: Use SMP kernel for Alpha (udeb) builds
Hi Philippe, On 12/9/18 19:12, Philippe Mathieu-Daudé wrote: FYI I've added few tests to QEMU to avoid regressions, one is booting the DP264 machine (not yet merged, the specific test is here:) Wow, didn't knew Alpha emulation is already that good with QEMU! https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg03082.html I tested a recent Debian SMP kernel and got: alpha-softmmu/qemu-system-alpha \ -kernel vmlinuz-4.18.0-3-alpha-generic \ This is the non-SMP kernel, but I assume you meant that actually. -append console=srm -initrd initrd.gz \ -nographic -net nic -net user -d mmu,unimp \ -drive file=debian-503-alpha-businesscard.iso,if=ide,media=cdrom PCI: 00:00:0 class 0300 id 1013:00b8 PCI: region 0: 1000 PCI: region 1: 1200 PCI: 00:01:0 class 0200 id 8086:100e PCI: region 0: 1202 PCI: region 1: c000 PCI: 00:02:0 class 0101 id 1095:0646 PCI: region 0: c040 PCI: region 1: c048 PCI: region 3: c04c [0.00] Linux version 4.18.0-3-alpha-generic (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-30)) #1 Debian 4.18.20-2 (2018-11-23) [0.00] bootconsole [srm0] enabled [0.00] Booting GENERIC on Tsunami variation Clipper using machine vector Clipper from SRM [...] [0.003906] [ cut here ] [0.004882] WARNING: CPU: 0 PID: 0 at /build/linux-kQe68U/linux-4.18.20/init/main.c:650 start_kernel+0x4dc/0x754 [0.004882] Interrupts were enabled early [0.004882] Modules linked in: [0.005859] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-3-alpha-generic #1 Debian 4.18.20-2 [0.006835]fc00018f3dc8 fc000216ee70 fc000103597c fc0001898ddc [0.007812]fc00010359f4 fc00018ce1b0 fc0002171704 fc000216ee70 [0.007812]fc000216ee70 028a fc0001898ddc [0.007812]fc0001898ddc fc000173e371 fc00018f3e88 [0.008789]fc18 fc000216ee70 0001 [0.008789]fc00018acab8 0001 [0.008789] Trace: [0.009765] [] __warn+0x15c/0x180 [0.009765] [] warn_slowpath_fmt+0x54/0x70 [0.009765] [] _stext+0x1c/0x20 [0.009765] [] _stext+0x0/0x20 [0.010742] [0.010742] ---[ end trace c85a0517f87d04be ]--- [...] [2.127928] ledtrig-cpu: registered to indicate activity on CPUs [2.131834] NET: Registered protocol family 10 [2.264647] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 [...] Maybe the warning at init/main.c:650 is useful for your real hw? Maybe Michael and Bob can make something out of this. But a problem is, that we actually don't get that far on real hardware with the non-SMP kernel. All machines I tested so far either (1) fall back to SRM or (2) seem to hang (DS25/ES45 and most likely other Titan based systems) after aboot starts the kernel. Cheers, Frank P.S. BTW, that Avocado stuff looks interesting. I wonder if that could also be used to verify (Linux kernel) bootups on real hardware. That would definitely ease up testing new kernel versions.
Re: Use SMP kernel for Alpha (udeb) builds
Hi Frank, On 12/4/18 5:38 PM, Frank Scheiner wrote: > Dear all, > > As per [1] and our recent discussions the generic 4.x kernels seem to no > longer work on Alpha machines which also renders any installer images > using the generic 4.x kernels non-working. > > [1]: https://lists.debian.org/debian-alpha/2017/03/msg7.html > > Confirmed on: > * AlphaStation 200 (w/EV4 x 1) > * AlphaStation 255 (w/EV45 x 1) > * Personal Workstation 500au (w/EV56 x 1) > * AlphaServer DS20E (w/EV67 x 2) > > Also expected on: > * AXPpci33 (w/LCA4 x 1) > * AlphaStation 500 (w/EV56 x 1) > * AlphaServer DS25 (w/EV68CB x 2) > * AlphaServer ES45 (w/EV68CB x 4) > > The following two patches should switch the used kernels to the SMP > version. As: > > (1) I don't exactly know how to build images using multiple kernels > (i.e. what happens if $TEMP_KERNEL has multiple kernel names in it, > which seems to be supported according to [2], will the image creation in > e.g. [3] than run multiple times automatically?) and I don't want to > break things, > > [2]: > https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/dir#L79 > > > [3]: > https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/alpha/netboot.cfg > > > (2) I can't find a similar example for another architecture and > > (3) the images with the generic kernels are non-working anyhow, > > ...I just omitted the generic ones for now. > > This is sort of a workaround and does not fix the actual problem which > is yet unknown, but I believe getting working installer images is more > important at the moment. With working installer images more people could > get involved and maybe sometime in the future someone has enough time > and effort to invest in fixing the actual problem. > > ## Patches ## > > 1. > https://salsa.debian.org/frank-scheiner-guest/linux/commit/865cacfd7722b346629082ab3094b6ad93964095 > > > 2. > https://salsa.debian.org/frank-scheiner-guest/debian-installer/commit/7269679bec8bae997ef5ed7619e9f8df2e184134 > > > I think both patches are already enough to produce the needed alpha-smp > udebs and will allow to produce working installer images (e.g. netboot > images might work instantly and could be an alternative way for Bob to > reinstall his PWS). > > What do you think? Is there anything obvious missing? FYI I've added few tests to QEMU to avoid regressions, one is booting the DP264 machine (not yet merged, the specific test is here:) https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg03082.html I tested a recent Debian SMP kernel and got: alpha-softmmu/qemu-system-alpha \ -kernel vmlinuz-4.18.0-3-alpha-generic \ -append console=srm -initrd initrd.gz \ -nographic -net nic -net user -d mmu,unimp \ -drive file=debian-503-alpha-businesscard.iso,if=ide,media=cdrom PCI: 00:00:0 class 0300 id 1013:00b8 PCI: region 0: 1000 PCI: region 1: 1200 PCI: 00:01:0 class 0200 id 8086:100e PCI: region 0: 1202 PCI: region 1: c000 PCI: 00:02:0 class 0101 id 1095:0646 PCI: region 0: c040 PCI: region 1: c048 PCI: region 3: c04c [0.00] Linux version 4.18.0-3-alpha-generic (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-30)) #1 Debian 4.18.20-2 (2018-11-23) [0.00] bootconsole [srm0] enabled [0.00] Booting GENERIC on Tsunami variation Clipper using machine vector Clipper from SRM [0.00] Major Options: MAGIC_SYSRQ [0.00] Command line: console=srm [0.00] memcluster 0, usage 1, start0, end 14 [0.00] memcluster 1, usage 0, start 14, end16384 [0.00] freeing pages 14:2048 [0.00] freeing pages 4332:16384 [0.00] reserving pages 4332:4333 [0.00] Initial ramdisk at: 0x(ptrval) (5079886 bytes) [0.00] Built 1 zonelists, mobility grouping on. Total pages: 16256 [0.00] Kernel command line: console=srm [0.00] Dentry cache hash table entries: 16384 (order: 4, 131072 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 65536 bytes) [0.00] Sorting __ex_table... [0.00] Memory: 106304K/131072K available (6642K kernel code, 8709K rwdata, 2080K rodata, 352K init, 393K bss, 24768K reserved, 0K cma-reserved) [0.00] random: get_random_u64 called from __kmem_cache_create+0x5c/0x620 with crng_init=0 [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS: 32784 [0.00] clocksource: qemu: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.003906] [ cut here ] [0.004882] WARNING: CPU: 0 PID: 0 at /build/linux-kQe68U/linux-4.18.20/init/main.c:650 start_kernel+0x4dc/0x754 [0.004882] Interrupts were enabled early [0.004882] Modules linked in: [0.005859] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-3-alpha-generic #1 Debian 4.18.20-2 [0.006835]
Re: Use SMP kernel for Alpha (udeb) builds
On Sat, Dec 08, 2018 at 07:41:15PM +0100, Frank Scheiner wrote: > On 12/8/18 15:05, Bob Tracy wrote: > > From the "image.squashfs" file on the Gentoo "install-alpha-minimal" > > image, attached is "etc/kernels/kernel-config-alpha-4.14.65-gentoo" > > which appears to correspond to the "nolsa" kernel variant. To your > > question about whether SMP is configured, most definitely "yes" with > > CONFIG_NR_CPUS=32. > > Thanks for checking. This seems to be definitely a SMP capable kernel, as > `CONFIG_SMP=y` is also set. > > About the `CONFIG_ALPHA_LEGACY_START_ADDRESS`, [1] mentions this is actually > needed for older boot loaders only which hardcoded the kernel start address. > And the Gentoo config shows it as inactive: `# > CONFIG_ALPHA_LEGACY_START_ADDRESS is not set` > > [1]: https://cateee.net/lkddb/web-lkddb/ALPHA_LEGACY_START_ADDRESS.html > > But interesting, [1] also says, that this option depends on > CONFIG_ALPHA_GENERIC, which is actually set (`CONFIG_ALPHA_GENERIC=y`) in > the Gentoo config. > > So can we assume `CONFIG_ALPHA_GENERIC=y` also activates > `CONFIG_ALPHA_LEGACY_START_ADDRESS`? I wouldn't assume so, particularly for the Gentoo kernel source tree to whatever extent it differs from the kernel.org source tree. What the dependency is saying is, you can't have the legacy start address config option force-enabled unless you're building a generic kernel. Otherwise, the (alpha) processor-specific config options presumably dictate whether the legacy start address is used. This is, I think, why Gentoo includes a generic+lsa kernel and a generic+nolsa kernel in their install image. BUT, in your defense, it's possible an unpatched kernel.org source tree might be doing (or might have done -- this could have been patched upstream) exactly as you suggest. I haven't investigated this, because I've never used the alpha generic kernel except for the initial installation on a system. Just to be clear, Gentoo's generic kernel *does* have SMP configured, and *with* the legacy start address enabled should boot just fine on your PWS as it does on mine. The kernel version is 4.14(.65). --Bob
Re: Use SMP kernel for Alpha (udeb) builds
On Sun, Dec 09, 2018 at 07:54:52AM +1300, Michael Cree wrote: > On Sat, Dec 08, 2018 at 12:01:23PM +1300, Michael Cree wrote: > > On Fri, Dec 07, 2018 at 10:39:58PM +0100, Frank Scheiner wrote: > > > On 12/7/18 22:06, Michael Cree wrote: > > > > On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: > > > > > As per [1] and our recent discussions the generic 4.x kernels seem to > > > > > no > > > > > longer work on Alpha machines which also renders any installer images > > > > > using > > > > > the generic 4.x kernels non-working. > > > > > > > > Yes, that was noted some time ago. A generic kernel does not boot > > > > since about 3.13. > > > > > > Must be after 3.16 because a Debian 3.16 generic kernel still worked on my > > > PWS 500au back in 2017 or even earlier. > > > > Confirmed. 3.16 generic boots but 3.18 generic does not on XP1000. > > > > The reason I did not bisect at the time is that there were build errors > > in the kernel about 3.17 and 3.18 but I think I now know how to work > > around those so shall proceed to bisect. > > Bisection leads to: > > dca496451bddea9aa87b7510dc2eb413d1a19dfd is the first bad commit Actually I am not so sure about that. It appears that sometimes a bad kernel can boot which might have lead me astray. That commit after failing once (assuming I did not make a mistake in the bisection) is now booting... Cheers, Michael.
Re: Use SMP kernel for Alpha (udeb) builds
On Sat, Dec 08, 2018 at 12:01:23PM +1300, Michael Cree wrote: > On Fri, Dec 07, 2018 at 10:39:58PM +0100, Frank Scheiner wrote: > > On 12/7/18 22:06, Michael Cree wrote: > > > On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: > > > > As per [1] and our recent discussions the generic 4.x kernels seem to no > > > > longer work on Alpha machines which also renders any installer images > > > > using > > > > the generic 4.x kernels non-working. > > > > > > Yes, that was noted some time ago. A generic kernel does not boot > > > since about 3.13. > > > > Must be after 3.16 because a Debian 3.16 generic kernel still worked on my > > PWS 500au back in 2017 or even earlier. > > Confirmed. 3.16 generic boots but 3.18 generic does not on XP1000. > > The reason I did not bisect at the time is that there were build errors > in the kernel about 3.17 and 3.18 but I think I now know how to work > around those so shall proceed to bisect. Bisection leads to: dca496451bddea9aa87b7510dc2eb413d1a19dfd is the first bad commit commit dca496451bddea9aa87b7510dc2eb413d1a19dfd Author: Tejun Heo Date: Tue Sep 2 14:46:01 2014 -0400 percpu: move common parts out of pcpu_[de]populate_chunk() I have no idea why that commit is a problem... Cheers, Michael.
Re: Use SMP kernel for Alpha (udeb) builds
On 12/8/18 15:05, Bob Tracy wrote: On Sat, Dec 08, 2018 at 11:15:21AM +0100, Frank Scheiner wrote: Is this Gentoo generic installer kernel SMP capable? I believe these Gentoo kernels have the config included in the kernel image, so available as `/proc/config.gz` during runtime, I think. From the "image.squashfs" file on the Gentoo "install-alpha-minimal" image, attached is "etc/kernels/kernel-config-alpha-4.14.65-gentoo" which appears to correspond to the "nolsa" kernel variant. To your question about whether SMP is configured, most definitely "yes" with CONFIG_NR_CPUS=32. Thanks for checking. This seems to be definitely a SMP capable kernel, as `CONFIG_SMP=y` is also set. About the `CONFIG_ALPHA_LEGACY_START_ADDRESS`, [1] mentions this is actually needed for older boot loaders only which hardcoded the kernel start address. And the Gentoo config shows it as inactive: `# CONFIG_ALPHA_LEGACY_START_ADDRESS is not set` [1]: https://cateee.net/lkddb/web-lkddb/ALPHA_LEGACY_START_ADDRESS.html But interesting, [1] also says, that this option depends on CONFIG_ALPHA_GENERIC, which is actually set (`CONFIG_ALPHA_GENERIC=y`) in the Gentoo config. So can we assume `CONFIG_ALPHA_GENERIC=y` also activates `CONFIG_ALPHA_LEGACY_START_ADDRESS`? If yes this could correspond to the behaviour of the generic Debian kernel on my DS25. I just tested a `netabootwrap`ped `4.18.0-2-alpha-generic` and after aboot emits the "starting kernel [...]" message nothing happens: ``` >>>boot (boot ega0.0.0.5.2 -flags root=/dev/nfs ip=:enP2p2s5:dhcp console=ttyS0,9600n8) Trying BOOTP boot. Broadcasting BOOTP Request... Received BOOTP Packet File Name is: /AC100259 local inet address: 172.16.2.89 remote inet address: 172.16.0.2 TFTP Read File Name: /AC100259 netmask = 255.255.0.0 Server is on same subnet as client. block number= 0 port_number= 35092 . bootstrap code read in base = 39c000, image_start = 0, image_bytes = 90b86c(9484396) initializing HWRPB at 2000 initializing page table at initializing machine state setting affinity to the primary CPU jumping to bootstrap code aboot: Linux/Alpha SRM bootloader version 1.0_pre20040408 aboot: switching to OSF/1 PALcode version 1.92 aboot: loading initrd (4874860 bytes/9522 blocks) at 0xfc00ffb46000 aboot: starting kernel network with arguments root=/dev/nfs ip=:enP2p2s5:dhcp console=ttyS0,9600n8 ``` And as [1] says, the SRM firmware of Titan machines is bigger than on older Alpha machines, so the kernel start address for the generic kernel might have ended somewhere inside the SRM. I'll check that with my ES45, too. The same kernel leads to: ``` CPU 0 booting (boot ewa0.0.0.3.0 -flags root=/dev/nfs ip=dhcp console=tty1 console=ttyS0,9600n8) Trying BOOTP boot. Broadcasting BOOTP Request... .Received BOOTP Packet File Name is: /AC10020F local inet address: 172.16.2.15 remote inet address: 172.16.0.2 TFTP Read File Name: /AC10020F netmask = 255.255.0.0 Server is on same subnet as client. . bootstrap code read in base = 1e6000, image_start = 0, image_bytes = 90b86c initializing HWRPB at 2000 initializing page table at 1d8000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code aboot: Linux/Alpha SRM bootloader version 1.0_pre20040408 aboot: switching to OSF/1 PALcode version 1.22 aboot: loading initrd (4874860 bytes/9522 blocks) at 0xfc0023b56000 aboot: starting kernel network with arguments root=/dev/nfs ip=dhcp console=tty1 console=ttyS0,9600n8 halted CPU 0 halt code = 6 double error halt PC = fc000107f868 boot failure ``` ...on my PWS 500au. I hence assume, the SRM is small enough on this machine, so the kernel start address doesn't end up in the SRM. The SMP kernel boots without an issue on both machines. But strange, the kernel configuration files for both `4.18.0-2-alpha-generic` and `4.18.0-2-alpha-smp` contain: ``` # grep -n CONFIG_ALPHA_GENERIC config-4.18.0-2-alpha-generic config-4.18.0-2-alpha-smp config-4.18.0-2-alpha-generic:288:CONFIG_ALPHA_GENERIC=y config-4.18.0-2-alpha-smp:296:CONFIG_ALPHA_GENERIC=y ``` So shouldn't this setting then not also imply `CONFIG_ALPHA_LEGACY_START_ADDRESS` active for both kernels (so also for the SMP kernel)? But maybe some other active/inactive option in the SMP kernel remedies the dependent `CONFIG_ALPHA_LEGACY_START_ADDRESS`. A unified diff between both configurations is attached. Oh btw, the generic config also has "CONFIG_BROKEN_ON_SMP=y" but I am not sure what this means. [2] mentions this is sort of attached to drivers unsafe on SMPs. But then I'd actually expect that setting to be active for the SMP config. [2]:
Re: Use SMP kernel for Alpha (udeb) builds
On Sat, Dec 08, 2018 at 11:15:21AM +0100, Frank Scheiner wrote: > Is this Gentoo generic installer kernel SMP capable? I believe these Gentoo > kernels have the config included in the kernel image, so available as > `/proc/config.gz` during runtime, I think. >From the "image.squashfs" file on the Gentoo "install-alpha-minimal" image, attached is "etc/kernels/kernel-config-alpha-4.14.65-gentoo" which appears to correspond to the "nolsa" kernel variant. To your question about whether SMP is configured, most definitely "yes" with CONFIG_NR_CPUS=32. --Bob # # Automatically generated file; DO NOT EDIT. # Linux/alpha 4.14.65-gentoo Kernel Configuration # # # Gentoo Linux # CONFIG_GENTOO_LINUX=y CONFIG_GENTOO_LINUX_UDEV=y CONFIG_GENTOO_LINUX_PORTAGE=y # # Support for init systems, system and service managers # CONFIG_GENTOO_LINUX_INIT_SCRIPT=y # CONFIG_GENTOO_LINUX_INIT_SYSTEMD is not set CONFIG_ALPHA=y CONFIG_64BIT=y CONFIG_MMU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PGTABLE_LEVELS=3 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_AUTO_IRQ_AFFINITY=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_CLOCKEVENTS=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_CGROUPS=y # CONFIG_MEMCG is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUP_PIDS is not set # CONFIG_CGROUP_RDMA is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CPUSETS is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_SOCK_CGROUP_DATA is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y # CONFIG_EXPERT is not set CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_POSIX_TIMERS=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set CONFIG_KALLSYMS_BASE_RELATIVE=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_FUTEX_PI=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_USERFAULTFD is not set CONFIG_PCI_QUIRKS=y CONFIG_MEMBARRIER=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # CONFIG_PC104 is not set # # Kernel Performance Events And Counters # # CONFIG_PERF_EVENTS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set CONFIG_SLAB_MERGE_DEFAULT=y # CONFIG_SLAB_FREELIST_RANDOM is not set # CONFIG_SYSTEM_DATA_VERIFICATION is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_64BIT_ALIGNED_ACCESS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y # CONFIG_CC_STACKPROTECTOR is not set CONFIG_THIN_ARCHIVES=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_RELA=y # CONFIG_HAVE_ARCH_HASH is not set CONFIG_ISA_BUS_API=y CONFIG_ODD_RT_SIGACTION=y CONFIG_OLD_SIGSUSPEND=y CONFIG_CPU_NO_EFFICIENT_FFS=y # CONFIG_HAVE_ARCH_VMAP_STACK is not set # CONFIG_ARCH_OPTIONAL_KERNEL_RWX is not set # CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT is not set
Re: Use SMP kernel for Alpha (udeb) builds
On 12/8/18 06:58, Bob Tracy wrote: On Sat, Dec 08, 2018 at 10:06:25AM +1300, Michael Cree wrote: On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: As per [1] and our recent discussions the generic 4.x kernels seem to no longer work on Alpha machines which also renders any installer images using the generic 4.x kernels non-working. Yes, that was noted some time ago. A generic kernel does not boot since about 3.13. I can't remember why I never attempted bisecting this back when it was first noted to be a problem, maybe because it didn't affect me because I normally run my own spun kernels. Ditto on this end. I figure a first pass at the problem would be to compare our respective kernel configs against the generic one, just to get a reading on what code *may* be involved. I can provide my Miata config for a 4.14 kernel (and that's about all I can do until I'm back up and running) if that would be helpful. Another data point to consider would be the kernel config for the current (as of the end of November) Gentoo "install-alpha-minimal" image, which works on Miata at least (modulo the missing Qlogic firmware issue). The associated kernel is "4.14.65-gentoo", and two variants are present on the image -- a "generic" one, and one without a "legacy start address". The "aboot.conf" file has the following comment: # Some later alphas need a special kernel without legacy start address, most # notably the DS15A and DS25 workstations as well as the ES45, ES47 and GS # series of servers. The Miata boots fine with the "generic" kernel, and panics when I try the "nolsa" kernel. Is this Gentoo generic installer kernel SMP capable? I believe these Gentoo kernels have the config included in the kernel image, so available as `/proc/config.gz` during runtime, I think. Bottom line: I think the way forward will be easier from a Debian perspective if the Debian installer for alpha includes a >= 4.14 kernel, because the 4.8 and 4.9 kernels are known to have issues anyway. An upgrade would also put alpha closer to being in-sync with the "testing" distro on Intel/AMD platforms. I think the kernel version used on the installers will be the same version that's available as `linux-image-[...].deb` at the time of creation, as kernel-wedge creates the udebs from the `linux-image-[...].deb` IIUIC. Cheers, Frank
Re: Use SMP kernel for Alpha (udeb) builds
On Sat, Dec 08, 2018 at 10:06:25AM +1300, Michael Cree wrote: > On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: > > As per [1] and our recent discussions the generic 4.x kernels seem to no > > longer work on Alpha machines which also renders any installer images using > > the generic 4.x kernels non-working. > > Yes, that was noted some time ago. A generic kernel does not boot > since about 3.13. I can't remember why I never attempted bisecting > this back when it was first noted to be a problem, maybe because it > didn't affect me because I normally run my own spun kernels. Ditto on this end. I figure a first pass at the problem would be to compare our respective kernel configs against the generic one, just to get a reading on what code *may* be involved. I can provide my Miata config for a 4.14 kernel (and that's about all I can do until I'm back up and running) if that would be helpful. Another data point to consider would be the kernel config for the current (as of the end of November) Gentoo "install-alpha-minimal" image, which works on Miata at least (modulo the missing Qlogic firmware issue). The associated kernel is "4.14.65-gentoo", and two variants are present on the image -- a "generic" one, and one without a "legacy start address". The "aboot.conf" file has the following comment: # Some later alphas need a special kernel without legacy start address, most # notably the DS15A and DS25 workstations as well as the ES45, ES47 and GS # series of servers. The Miata boots fine with the "generic" kernel, and panics when I try the "nolsa" kernel. Bottom line: I think the way forward will be easier from a Debian perspective if the Debian installer for alpha includes a >= 4.14 kernel, because the 4.8 and 4.9 kernels are known to have issues anyway. An upgrade would also put alpha closer to being in-sync with the "testing" distro on Intel/AMD platforms. --Bob
Re: Use SMP kernel for Alpha (udeb) builds
On Fri, Dec 07, 2018 at 10:39:58PM +0100, Frank Scheiner wrote: > On 12/7/18 22:06, Michael Cree wrote: > > On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: > > > As per [1] and our recent discussions the generic 4.x kernels seem to no > > > longer work on Alpha machines which also renders any installer images > > > using > > > the generic 4.x kernels non-working. > > > > Yes, that was noted some time ago. A generic kernel does not boot > > since about 3.13. > > Must be after 3.16 because a Debian 3.16 generic kernel still worked on my > PWS 500au back in 2017 or even earlier. Confirmed. 3.16 generic boots but 3.18 generic does not on XP1000. The reason I did not bisect at the time is that there were build errors in the kernel about 3.17 and 3.18 but I think I now know how to work around those so shall proceed to bisect. Cheers, Michael.
Re: Use SMP kernel for Alpha (udeb) builds
On 12/7/18 22:06, Michael Cree wrote: On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: As per [1] and our recent discussions the generic 4.x kernels seem to no longer work on Alpha machines which also renders any installer images using the generic 4.x kernels non-working. Yes, that was noted some time ago. A generic kernel does not boot since about 3.13. Must be after 3.16 because a Debian 3.16 generic kernel still worked on my PWS 500au back in 2017 or even earlier. I can't remember why I never attempted bisecting this back when it was first noted to be a problem, maybe because it didn't affect me because I normally run my own spun kernels. Yes, you mentioned that it doesn't affect non-generic kernels, e.g. kernels built for specific hardware like DP264. Confirmed on: * AlphaStation 200 (w/EV4 x 1) * AlphaStation 255 (w/EV45 x 1) * Personal Workstation 500au (w/EV56 x 1) * AlphaServer DS20E (w/EV67 x 2) Also on XP1000 so I would presume on any DP264 based machine. Also expected on: * AlphaServer ES45 (w/EV68CB x 4) Actually no. I seem to recall that the generic kernel does boot on ES45 (Titan). Interesting, maybe I should also give that a try on my DS25. I can check that at some point when the buildds are not busy. If you want to avoid a reboot on the buildd machine, I can have a look with my ES45 on Sunday. Cheers, Frank
Re: Use SMP kernel for Alpha (udeb) builds
On Tue, Dec 04, 2018 at 05:38:51PM +0100, Frank Scheiner wrote: > As per [1] and our recent discussions the generic 4.x kernels seem to no > longer work on Alpha machines which also renders any installer images using > the generic 4.x kernels non-working. Yes, that was noted some time ago. A generic kernel does not boot since about 3.13. I can't remember why I never attempted bisecting this back when it was first noted to be a problem, maybe because it didn't affect me because I normally run my own spun kernels. > Confirmed on: > * AlphaStation 200 (w/EV4 x 1) > * AlphaStation 255 (w/EV45 x 1) > * Personal Workstation 500au (w/EV56 x 1) > * AlphaServer DS20E (w/EV67 x 2) Also on XP1000 so I would presume on any DP264 based machine. > Also expected on: > * AlphaServer ES45 (w/EV68CB x 4) Actually no. I seem to recall that the generic kernel does boot on ES45 (Titan). I can check that at some point when the buildds are not busy. I might have a look again to see if we can bisect this problem... Cheers Michael.
Re: Use SMP kernel for Alpha (udeb) builds
On 12/5/18 07:33, Bob Tracy wrote: Can you open PRs so that these changes can get merged? I will then build new images. Sure, created them now: * First part: https://salsa.debian.org/kernel-team/linux/merge_requests/79 * Second part: https://salsa.debian.org/installer-team/debian-installer/merge_requests/6 @all: Unfortunately both patches weren't included in the latest (maintainer?) commits/releases - not that I expected that ;-). I keep rebasing them (due to constant changes to `debian/changelog`) but would it help if people (with influence :-)) upvote these patches with that "thumbs up" buttons? Much appreciated, gentlemen. Wish I could do more than offer my system up as a test platform, but so it goes... I'll be happy to help with determining the "actual problem which is yet unknown" with the alpha generic kernel, once my system is back up and running :-). Hey, if someone knows how to use `kernel-wedge` manually, we could build a netboot image right away, assuming that `kernel-wedge` can use the existing linux-image-[...]-alpha-smp package to build the needed udebs. That would not require a rebuild of the linux-image-[...]-alpha-smp package and save us a lot of time. Cheers, Frank
Re: Use SMP kernel for Alpha (udeb) builds
On Tue, Dec 04, 2018 at 07:37:13PM +0100, Frank Scheiner wrote: > On 12/4/18 17:45, John Paul Adrian Glaubitz wrote: > > > ## Patches ## > > > > > > 1. > > > https://salsa.debian.org/frank-scheiner-guest/linux/commit/865cacfd7722b346629082ab3094b6ad93964095 > > > > > > 2. > > > https://salsa.debian.org/frank-scheiner-guest/debian-installer/commit/7269679bec8bae997ef5ed7619e9f8df2e184134 > > > > > > I think both patches are already enough to produce the needed alpha-smp > > > udebs and will allow to produce working installer images (e.g. netboot > > > images might work instantly and could be an alternative way for Bob to > > > reinstall his PWS). > > > > > > What do you think? Is there anything obvious missing? > > > > Can you open PRs so that these changes can get merged? I will then build > > new images. > > Sure, created them now: > > * First part: https://salsa.debian.org/kernel-team/linux/merge_requests/79 > > * Second part: > https://salsa.debian.org/installer-team/debian-installer/merge_requests/6 Much appreciated, gentlemen. Wish I could do more than offer my system up as a test platform, but so it goes... I'll be happy to help with determining the "actual problem which is yet unknown" with the alpha generic kernel, once my system is back up and running :-). --Bob
Re: Use SMP kernel for Alpha (udeb) builds
Hi Adrian, On 12/4/18 17:45, John Paul Adrian Glaubitz wrote: ## Patches ## 1. https://salsa.debian.org/frank-scheiner-guest/linux/commit/865cacfd7722b346629082ab3094b6ad93964095 2. https://salsa.debian.org/frank-scheiner-guest/debian-installer/commit/7269679bec8bae997ef5ed7619e9f8df2e184134 I think both patches are already enough to produce the needed alpha-smp udebs and will allow to produce working installer images (e.g. netboot images might work instantly and could be an alternative way for Bob to reinstall his PWS). What do you think? Is there anything obvious missing? Can you open PRs so that these changes can get merged? I will then build new images. Sure, created them now: * First part: https://salsa.debian.org/kernel-team/linux/merge_requests/79 * Second part: https://salsa.debian.org/installer-team/debian-installer/merge_requests/6 Cheers, Frank
Re: Use SMP kernel for Alpha (udeb) builds
Hi Frank! On 12/4/18 5:38 PM, Frank Scheiner wrote: > As per [1] and our recent discussions the generic 4.x kernels seem to no > longer work on Alpha machines which also renders any installer images using > the generic 4.x kernels non-working. > > [1]: https://lists.debian.org/debian-alpha/2017/03/msg7.html > > Confirmed on: > * AlphaStation 200 (w/EV4 x 1) > * AlphaStation 255 (w/EV45 x 1) > * Personal Workstation 500au (w/EV56 x 1) > * AlphaServer DS20E (w/EV67 x 2) > > Also expected on: > * AXPpci33 (w/LCA4 x 1) > * AlphaStation 500 (w/EV56 x 1) > * AlphaServer DS25 (w/EV68CB x 2) > * AlphaServer ES45 (w/EV68CB x 4) Wow, thanks for the very extensive testing. > This is sort of a workaround and does not fix the actual problem which is yet > unknown, but I believe getting working installer images is more important at > the moment. With working installer images more people could get involved and > maybe sometime in the future someone has enough time and effort to invest in > fixing the actual problem. I agree. > ## Patches ## > > 1. > https://salsa.debian.org/frank-scheiner-guest/linux/commit/865cacfd7722b346629082ab3094b6ad93964095 > > 2. > https://salsa.debian.org/frank-scheiner-guest/debian-installer/commit/7269679bec8bae997ef5ed7619e9f8df2e184134 > > I think both patches are already enough to produce the needed alpha-smp udebs > and will allow to produce working installer images (e.g. netboot images might > work instantly and could be an alternative way for Bob to reinstall his PWS). > > What do you think? Is there anything obvious missing? Can you open PRs so that these changes can get merged? I will then build new images. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Use SMP kernel for Alpha (udeb) builds
Dear all, As per [1] and our recent discussions the generic 4.x kernels seem to no longer work on Alpha machines which also renders any installer images using the generic 4.x kernels non-working. [1]: https://lists.debian.org/debian-alpha/2017/03/msg7.html Confirmed on: * AlphaStation 200 (w/EV4 x 1) * AlphaStation 255 (w/EV45 x 1) * Personal Workstation 500au (w/EV56 x 1) * AlphaServer DS20E (w/EV67 x 2) Also expected on: * AXPpci33 (w/LCA4 x 1) * AlphaStation 500 (w/EV56 x 1) * AlphaServer DS25 (w/EV68CB x 2) * AlphaServer ES45 (w/EV68CB x 4) The following two patches should switch the used kernels to the SMP version. As: (1) I don't exactly know how to build images using multiple kernels (i.e. what happens if $TEMP_KERNEL has multiple kernel names in it, which seems to be supported according to [2], will the image creation in e.g. [3] than run multiple times automatically?) and I don't want to break things, [2]: https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/dir#L79 [3]: https://salsa.debian.org/installer-team/debian-installer/blob/master/build/config/alpha/netboot.cfg (2) I can't find a similar example for another architecture and (3) the images with the generic kernels are non-working anyhow, ...I just omitted the generic ones for now. This is sort of a workaround and does not fix the actual problem which is yet unknown, but I believe getting working installer images is more important at the moment. With working installer images more people could get involved and maybe sometime in the future someone has enough time and effort to invest in fixing the actual problem. ## Patches ## 1. https://salsa.debian.org/frank-scheiner-guest/linux/commit/865cacfd7722b346629082ab3094b6ad93964095 2. https://salsa.debian.org/frank-scheiner-guest/debian-installer/commit/7269679bec8bae997ef5ed7619e9f8df2e184134 I think both patches are already enough to produce the needed alpha-smp udebs and will allow to produce working installer images (e.g. netboot images might work instantly and could be an alternative way for Bob to reinstall his PWS). What do you think? Is there anything obvious missing? Cheers, Frank
