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:
Le 18/12/2020 à 23:49, Christian Zigotzky a écrit :
On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
>
>
> On Friday, December 18, 2020, Christian Zigotzky
<chzigot...@xenosoft.de> 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.
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?
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
Can you also share you kernel config
See attachment.
Thanks
Christophe
Thanks
Christian
