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
