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/msg00007.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)
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 inthe 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?
## 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.
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
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 :-).
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.
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:
* AlphaServer ES45 (w/EV68CB x 4)
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.
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.
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.
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.
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.
(boot ega0.0.0.5.2 -flags root=/dev/nfs ip=:::::enP2p2s5:dhcp console=ttyS0,9600n8)boot
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.
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`?
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
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/msg00007.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: 10000000
PCI: region 1: 12000000
PCI: 00:01:0 class 0200 id 8086:100e
PCI: region 0: 12020000
PCI: region 1: 0000c000
PCI: 00:02:0 class 0101 id 1095:0646
PCI: region 0: 0000c040
PCI: region 1: 0000c048
PCI: region 3: 0000c04c
[ 0.000000] Linux version 4.18.0-3-alpha-generic (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-30))
#1 Debian 4.18.20-2 (2018-11-23)
[ 0.000000] bootconsole [srm0] enabled
[ 0.000000] 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] fffffc00018f3dc8 fffffc000216ee70 fffffc000103597c fffffc0001898ddc
[ 0.007812] fffffc00010359f4 fffffc00018ce1b0 fffffc0002171704 fffffc000216ee70
[ 0.007812] fffffc000216ee70 0000000000000000 000000000000028a fffffc0001898ddc
[ 0.007812] fffffc0001898ddc 0000000000000000 fffffc000173e371 fffffc00018f3e88
[ 0.008789] fffffc0000000018 fffffc000216ee70 0000000000000000 0000000000000001
[ 0.008789] fffffc00018acab8 0000000000000001 0000000000000000 0000000000000000
[ 0.008789] Trace:
[ 0.009765] [<fffffc000103597c>] __warn+0x15c/0x180
[ 0.009765] [<fffffc00010359f4>] warn_slowpath_fmt+0x54/0x70
[ 0.009765] [<fffffc000101001c>] _stext+0x1c/0x20
[ 0.009765] [<fffffc0001010000>] _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?
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.
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.
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).
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...
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 <tj@kernel.org>
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 415 |
Nodes: | 16 (2 / 14) |
Uptime: | 144:36:00 |
Calls: | 8,706 |
Calls today: | 10 |
Files: | 13,266 |
Messages: | 5,950,078 |