New kernels

[xeno74]

Hi All,

I compiled the alpha2 of kernel 6.17 with the first PowerPC updates 6.17-1 yesterday.

Unfortunately Xorg doesn’t start anymore.

Error message:

Code: Select all

xf86OpenConsole: Switching VT failed.

I tested it with QEMU with virtio-gpu-pci and VGA,vgamem_mb=256 with some Linux distributions yesterday.

I reported this issue to the kernel developers yesterday.

Link: Switching VT failed

Please test the kernels,

Christian

[xeno74]

I bisected today.

1. Code: Select all

   git bisect start

2. Code: Select all

   git bisect good 038d61fd642278bab63ee8ef722c50d10ab01e8f

   (Good: Linux 6.16)

3. Code: Select all

   git bisect bad 260f6f4fda93c8485c8037865c941b42b9cba5d2

   (Bad: drm-next-2025-07-30 -- 2025-07-30 19:26:49 -0700)

Result:

Code: Select all

f1180ca37abe3d117e4a19be12142fe722612a7c is the first bad commit
commit f1180ca37abe3d117e4a19be12142fe722612a7c
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Wed Jun 11 12:02:53 2025 +0200

    tty: vt: use _IO() to define ioctl numbers

    _IO*() is the proper way of defining ioctl numbers. All these vt numbers
    were synthetically built up the same way the _IO() macro does.

    So instead of implicit hex numbers, use _IO() properly.

    To not change the pre-existing numbers, use only _IO() (and not _IOR()
    or _IOW()). The latter would change the numbers indeed.

    Objdump of vt_ioctl.o reveals no difference with this patch.

    Again, VT_GETCONSIZECSRPOS already uses _IOR(), so everything is paved
    for this patch.

    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Cc: Nicolas Pitre <[email protected]>
    Reviewed-by: Nicolas Pitre <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 include/uapi/linux/vt.h | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

I was able to revert the first bad commit.

Code: Select all

git revert f1180ca37abe3d117e4a19be12142fe722612a7c

Output:

Code: Select all

Revert "tty: vt: use _IO() to define ioctl numbers"

This reverts commit f1180ca37abe3d117e4a19be12142fe722612a7c.

After a new compiling, Xorg works again.

I created a patch for reverting the bad commit.

Code: Select all

diff -rupN a b > vt_ioctl.patch

vt_ioctl.patch:

Code: Select all

diff -rupN a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
--- a/include/uapi/linux/vt.h   2025-07-31 10:23:41.928121321 +0200
+++ b/include/uapi/linux/vt.h   2025-07-31 14:25:04.079827271 +0200
@@ -14,9 +14,9 @@
                /* Note: the ioctl VT_GETSTATE does not work for
                   consoles 16 and higher (since it returns a short) */

-/* 'V' to avoid collision with termios and kd */
+/* 0x56 is 'V', to avoid collision with termios and kd */

-#define VT_OPENQRY             _IO('V', 0x00)  /* find available vt */
+#define VT_OPENQRY     0x5600  /* find available vt */

 struct vt_mode {
        __u8 mode;              /* vt mode */
@@ -25,8 +25,8 @@ struct vt_mode {
        __s16 acqsig;           /* signal to raise on acquisition */
        __s16 frsig;            /* unused (set to 0) */
 };
-#define VT_GETMODE             _IO('V', 0x01)  /* get mode of active vt */
-#define VT_SETMODE             _IO('V', 0x02)  /* set mode of active vt */
+#define VT_GETMODE     0x5601  /* get mode of active vt */
+#define VT_SETMODE     0x5602  /* set mode of active vt */
 #define                VT_AUTO         0x00    /* auto vt switching */
 #define                VT_PROCESS      0x01    /* process controls switching */
 #define                VT_ACKACQ       0x02    /* acknowledge switch */
@@ -36,21 +36,21 @@ struct vt_stat {
        __u16 v_signal; /* signal to send */
        __u16 v_state;          /* vt bitmask */
 };
-#define VT_GETSTATE            _IO('V', 0x03)  /* get global vt state info */
-#define VT_SENDSIG             _IO('V', 0x04)  /* signal to send to bitmask of vts */
+#define VT_GETSTATE    0x5603  /* get global vt state info */
+#define VT_SENDSIG     0x5604  /* signal to send to bitmask of vts */

-#define VT_RELDISP             _IO('V', 0x05)  /* release display */
+#define VT_RELDISP     0x5605  /* release display */

-#define VT_ACTIVATE            _IO('V', 0x06)  /* make vt active */
-#define VT_WAITACTIVE          _IO('V', 0x07)  /* wait for vt active */
-#define VT_DISALLOCATE         _IO('V', 0x08)  /* free memory associated to vt */
+#define VT_ACTIVATE    0x5606  /* make vt active */
+#define VT_WAITACTIVE  0x5607  /* wait for vt active */
+#define VT_DISALLOCATE 0x5608  /* free memory associated to vt */

 struct vt_sizes {
        __u16 v_rows;           /* number of rows */
        __u16 v_cols;           /* number of columns */
        __u16 v_scrollsize;     /* number of lines of scrollback */
 };
-#define VT_RESIZE              _IO('V', 0x09)  /* set kernel's idea of screensize */
+#define VT_RESIZE      0x5609  /* set kernel's idea of screensize */

 struct vt_consize {
        __u16 v_rows;   /* number of rows */
@@ -60,10 +60,10 @@ struct vt_consize {
        __u16 v_vcol;   /* number of pixel columns on screen */
        __u16 v_ccol;   /* number of pixel columns per character */
 };
-#define VT_RESIZEX             _IO('V', 0x0A)  /* set kernel's idea of screensize + more */
-#define VT_LOCKSWITCH          _IO('V', 0x0B)  /* disallow vt switching */
-#define VT_UNLOCKSWITCH                _IO('V', 0x0C)  /* allow vt switching */
-#define VT_GETHIFONTMASK       _IO('V', 0x0D)  /* return hi font mask */
+#define VT_RESIZEX      0x560A  /* set kernel's idea of screensize + more */
+#define VT_LOCKSWITCH   0x560B  /* disallow vt switching */
+#define VT_UNLOCKSWITCH 0x560C  /* allow vt switching */
+#define VT_GETHIFONTMASK 0x560D  /* return hi font mask */

 struct vt_event {
        __u32 event;
@@ -77,14 +77,14 @@ struct vt_event {
        __u32 pad[4];           /* Padding for expansion */
 };

-#define VT_WAITEVENT           _IO('V', 0x0E)  /* Wait for an event */
+#define VT_WAITEVENT   0x560E  /* Wait for an event */

 struct vt_setactivate {
        __u32 console;
        struct vt_mode mode;
 };

-#define VT_SETACTIVATE         _IO('V', 0x0F)  /* Activate and set the mode of a console */
+#define VT_SETACTIVATE 0x560F  /* Activate and set the mode of a console */

 /* get console size and cursor position */
 struct vt_consizecsrpos {

[xeno74]

I reported this issue to the kernel developers today.

Link: Switching VT failed after commit tty: vt: use _IO() to define ioctl numbers

[xeno74]

Hi All,

Here is the alpha3 of kernel 6.17 with the first PowerPC updates for X1000 and e5500 machines (X5000/20, X5000/40, Mirari, and QEMU VMs).

Download and further information: github.com

Please test the kernels.

Thanks,
Christian

[xeno74]

Kernel 6.17 Alpha1 is working on my Mirari e5500 but Alpha3 is not. (did not test Alpha 2 )

Not working Alpha 3 log ..

Xorg not starting and Radeon driver from kernel not loaded so it seems...

;21;33m---[ en trace 000000000000000 ]---
[dr:.radeon_fbdev_river_fbdev_proe] *ERROR* faild to initializeframebuffer -22[0m
adeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton (ret=-22)
brd module loadedm
lop: module loadd
mpt3ss version 52.10.00.00 loaded
nve nvme0: pci fuction 0002:04:0.0
fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
scs host0: sata_fs
ta1: SATA max DMA/133 irq 68 pm-pol 0
;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
ata1: Signatue Update detectd @ 0 msecs
scsihost1: sata_fsl[0m
ta2: SATA max UMA/133 irq 69 lm-pol 0
nvme nvm0: 4/0/0 defaul/read/poll queus
nvme0n1: p1 p p3 p4 p5 p6 p7[0m
drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze framebuffer 22
fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/fman@40000/ethernet@e6000 failed
radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation (ret-22)
fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e

Many thanks for testing! I have the same issue on my X1000. Blank screen during the boot. The Radeon graphics framebuffer device doesn't work anymore.

I reported this issue to the kernel developers.

Link: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulaton

[xeno74]

Here is the modifed code from the DRM updates:

• radeon_fbdev.c
• radeon_drv.c
• radeon_display.c
• evergreen_cs.c

[Hypex]

Okay so I have some details to report.

Tested the final 6.16 and it's currently working fine on my Xenial system where it can stay.

Tested the new 6.17 alphas on a variety of systems like Fienix, Zesty and Mint and can confirm the findings. The a1 boots and works well. The a2 booted to a log in shell but was broke. I was able to log in but keyboard was corrupted. The a3 is incrementally worse and presents with a blank screen. I was able to log in from ttyS0 and grab a boot log. But it has obvious issues with graphics.

This is a crash dump from Mint:

Code: Select all

[drm] Initialized radeon 2.51.0 for 0000:01:00.0 on minor 0
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at drm_framebuffer_init+0x2c/0x34c
Modules linked in:
CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-a3-powerpc64-smp-g89748acdf226-d
irty #1 VOLUNTARY
Hardware name: pasemi,nemo PA6T 1x7.0-a3-powerpc64-smp-g89748acdf226-dirty)
MSR:  900000000202b032 <SF,HV,VEC,EE,FP,ME,IR,DR,RI>  CR: 24008480  XER: 00000000
IRQMASK: 0
GPR00: c000000000da9964 c0000000032d3350 c00000000214e700 c000000005d60008
GPR04: c0000000065b4900 c000000002060310 c0000000032d34a0 000000000000016d
GPR08: 0000000000000000 00000000000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 0000000000000000 c00000000207c260
GPR24: c000000005dc2868 0000000000000004 c0000000065b4900 c000000005dc2868
GPR28: c000000005d60000 c0000000032d35c0 c000000005d60008 c0000000065b4900
NIP 5cd60000
[c0000000032d3430] [c000000000eaf850] radeon_fbdev_driver_fbdev_probe+0x258/0x5d4
[c0000000032d3550] [c000000000d48558] __drm_fb_helper_initial_config_and_unlock+0x358/0x
6d0
[c0000000032d3630] [c000000000d4b094] drm_fbdev_client_hotplug+0xc8/0x144
[c0000000032d36c0] [c000000000d223c0] drm_client_register+0x84/0xe4
[c00d0rm_client_setup+0x104/0x138
[c0000000032d3830] [c000000000d6f860] radeon_pci_probe+0x1d8/0x248
[c0000000032d38c0] [c000000000c19328] pci_device_probe+0xcc/0x198
[c0000000032d3940] [c000000000ecc55c] really_probe+0x104/0x414
[c0000000032d39d0] [c000000000eccb20] driver_probe_device+0x58/0x178
[c0000000032d3a20] [c000000[00;21;33m[c0000000032d3ae0] [c000000000ecb158] bus_add_drive
r+0x26c/0x300
[c0000000032d3b70] [c000000000ece158] driver_register+0x8c/0x1c4
[c0000000032d3be0] [c000000000c18ad8] __pci_register_driver+0x68/0x7c
[c0000000032d3c00] [c00000000219e48c] radeon_module_init+0x6c/0xbc
[c0000000032d3c60] [c00000000000e6f8] do_one_initcall+0x60/0x2c8
r[om_kernel_user_thread+0x14/0x1c
---- interrupt: 0 at 0x0
Code: 4e800020 3c4c0145 38425334 7c0802a6 60000000 7d708026 fb81ffe0 91610008 f821ff51 e
9240000 7c291800 4182002c <0fe00000> 382100b0 3b80ffea 81610008
---[ end trace 0000000000000000 ]---
[drm:radeon_fbdev_driver_fbdev_probe] *ERROR* failed to initialize framebuffer -22

I've noticed that there can be overrun in serial logs. I don't know if it's kernel printing too much at once or the buffer in my USB serial adapter. Perhaps USB kernel debugging would be better but requires extra hardware.

[xeno74]

Hi All,

I released the alpha4 of kernel 6.17 for X1000 and e5500 machines (X5000/20, X5000/40, Mirari, and QEMU VMs) today.

Download and further information: github.com

If you have a Radeon graphics card then you don’t need to test it because of the issue with the initialization of Radeon framebuffer and setup emulation #15.

Thanks,
Christian

[xeno74]

Hi All,

Here is the alpha5 of kernel 6.17 for X1000 and e5500 machines (X5000/20, X5000/40, Mirari, and QEMU VMs).

I created kernels with and without the drm-next-2025-07-30 updates because of the issue with the Radeon graphics framebuffer device #15.

Download and further information: github.com

Please test both kernels.

Thanks,
Christian

[Hypex]

Okay so I've done some testing over the past couple of days.

Because I can be a rather sequential person I also tested the alpha 4. Both vmlinux-6.17 and vmlinux-6.17-2. As expected breaks on Radeon but could log in from serial and grab logs.

Next tested the alpha 5. Both vmlinux-6.17-1 and vmlinux-6.17-2. Dash-1 failed to load screen. Dash-2 works! So vmlinux-6.17-2 is functional.

I had to check I had the right versions. Because there was no vmlinux-6.17-1 in alpha 4 I got confused. I had a vmlinux-6.17-1 in alpha 5 and a vmlinux-6.17-2 in alpha 4. I didn't know what was going on! Then I checked all the files to see how it had ended up backwards.

So some notes about the alpha 5 archive. It lacks the expected 6.17 kernel files and only had dash-1 and dash-2 kernels. But it also lacks modules. So alpha 5 kernel can work but no modules are included. Is this intentional for the alpha 5 archive?