Hello,

I compiled the latest Git kernel today and unfortunately the boot issue 
still exists.

I was able to reduce the patch for reverting the changes. In this way we 
know the problematic code now.

vdso-v2.patch:

diff -rupN a/arch/powerpc/kernel/vdso32/vgettimeofday.c 
b/arch/powerpc/kernel/vdso32/vgettimeofday.c

--- a/arch/powerpc/kernel/vdso32/vgettimeofday.c    2020-12-19 

00:01:16.829846652 +0100

+++ b/arch/powerpc/kernel/vdso32/vgettimeofday.c    2020-12-19 

00:00:37.817369691 +0100

@@ -10,12 +10,6 @@ int __c_kernel_clock_gettime(clockid_t c
      return __cvdso_clock_gettime32_data(vd, clock, ts);
  }

-int __c_kernel_clock_gettime64(clockid_t clock, struct 

__kernel_timespec *ts,
-                   const struct vdso_data *vd)
-{
-    return __cvdso_clock_gettime_data(vd, clock, ts);
-}
-
  int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct 
timezone *tz,
                  const struct vdso_data *vd)
  {

----

With this patch, the uImage boots without any problems on my FSL P5040 
board and in a virtual e5500 QEMU machine. Please check the problematic 
code.

Thanks,
Christian



On 19 December 2020 at 01:33pm, Christian Zigotzky wrote:

On 19 December 2020 at 07:49am, Christophe Leroy wrote:

quoted

Le 18/12/2020 à 23:49, Christian Zigotzky a écrit :

quoted

On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
 >
 >
 > On Friday, December 18, 2020, Christian Zigotzky 
[off-list ref] wrote:
 >
 >     Hello,
 >
 >     I compiled the latest Git kernel with the new PowerPC updates 
5.11-1 [1] today. Unfortunately this kernel doesn't boot on my FSL 
P5040 board [2] and in a virtual e5500 QEMU machine [3].
 >
 >     I was able to revert the new PowerPC updates 5.11-1 [4] and 
after a new compiling, the kernel boots without any problems on my 
FSL P5040 board.
 >
 >     Please check the new PowerPC updates 5.11-1.
 >
 >
 > Can you bisect the bad commit?
 >
Hello Denis,

I have bisected [5] and d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e 
(powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32) [6] is 
the first bad commit.

I was able to revert this bad commit and after a new compiling, the 
kernel boots without any problems.

That's puzzling.

Can you describe the symptoms exactly ? What do you mean by "the 
kernel doesn't boot" ? Where and how does it stops booting ?

It stops during the disk initialisation.

quoted

This commit only adds a new VDSO call, for getting y2038 compliant 
time. At the time I implemented it there was no libc using it yet. Is 
your libc using it ?

I tested it with ubuntu MATE 16.04.7 LTS (32-bit userland + 64-bit 
kernel) and with Debian Sid (MintPPC and Fienix 32-bit userland + 
64-bit kernel) on my FSL P5040 board and in a virtual e5500 QEMU 
machine. How can I figure out if the libc use it?

quoted

Where can I find all the elements you are using to boot with QEMU ? 
Especially the file MintPPC32-X5000.img

Download: http://www.xenosoft.de/MintPPC32-X5000.tar.gz (md5sum: 
b31c1c1ca1fcf5d4cdf110c4bce11654) The password for both 'root' and 
'mintppc' is 'mintppc'.

QEMU command with KVM on my P5040 board: qemu-system-ppc64 -M ppce500 
-cpu e5500 -enable-kvm -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" 
-device virtio-vga -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -device 
usb-audio,bus=newusb.0 -smp 4

QEMU command without KVM on macOS Intel: qemu-system-ppc64 -M ppce500 
-cpu e5500 -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci 
-device usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1

quoted

Can you also share you kernel config

See attachment.

quoted

Thanks
Christophe

Thanks
Christian