Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Matthias Klose]

On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier  于2018年6月28日周四 上午4:06写道：
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>>  * Concern for ppc64el and s390x: we are dependent on sponsors for
>>hardware.
>>(Raised by DSA; carried over from stretch)
>>
>>  * Concern for armel and armhf: only secondary upstream support in GCC
>>(Raised by the GCC maintainer; carried over from stretch)

I don't think anybody objected about the status for armhf.  I didn't follow
armel issues too closely.

>>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>>
> 
> This is a misunderstanding as MIPS company had some unrest in recent half 
> year.
> Currently we are stable now, and the shape of gcc upstream is also good.

This is an optimistic view.  While currently not having any RC issues, we still
see mips* specific issues popping up more often than on other release 
architectures.

According to https://gcc.gnu.org/gcc-8/criteria.html there is no mips*-linux*
target listed as either primary or secondary platform. As far as I understand
the mips porters argue that this is covered by mipsisa64-elf, a bare metal
target.  I don't agree with this view, because

 - testing is missing on mips*-linux-* targets.  If you look at
   the gcc-testresults ML, you see only test reports submitted for
   the Debian GCC packages, nothing else.

 - A bare metal target is usually only built/used for C and C++. I
   doubt that other frontends are tested.

 - Configurations like libgcjit are not tested/used upstream, and not
   addressed. See #798710.

The Debian bug tracking for the MIPS port could be better, I usually need some
pings to the MIPS porters to get things forwarded or addressed.

To me it looks sometimes that Debian is used for testing by upstream, and for
that the mips architectures don't need to be release architectures.

Matthias

Re: Use SMP kernel for Alpha (udeb) builds

[Philippe Mathieu-Daudé]

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]fc00018f