On Wed, Sep 26, 2018 at 06:36:08PM +0200, Helge Deller wrote: > On 26.09.2018 15:29, Guenter Roeck wrote: > > On 09/26/2018 05:09 AM, John David Anglin wrote: > >> On 2018-09-25 11:21 PM, Guenter Roeck wrote: > >>> This patch causes my parisc qemu tests to fail. > >>> Unfortunately I don't have any useful log output; the failure > >>> is silent. Reverting the patch fixes the problem. > >> Can you be more specific on how to run these tests? > > > > Sorry. Please see > > > > https://github.com/groeck/linux-build-test/tree/master/rootfs/parisc > > > > My tests enable a number of device and debug options on top of defconfig. > > Those are not necessary, though. The problem can be reproduced with defconfig. > > > > With the initrd available from there, and with an image built using 'defconfig', > > run > > > > qemu-system-hppa \ > > -kernel vmlinux -no-reboot \ > > -initrd rootfs.cpio.gz \ > > -append 'rdinit=/sbin/init console=ttyS0,115200' \ > > -nographic -monitor null > > > > I tested with qemu 2.12 and 3.0. Using "arch/parisc/boot/bzImage" as kernel > > image does not make a difference. > > > > Note: The initrd auto-reboots. To avoid that, add "noreboot" as additional > > command line option. > > You didn't mention which kernel version you were using. Sorry. The patch is only available in -next, so I somehow thought it was obvious that I referred to -next. Mainline as of v4.19-rc5-143-gc307aaf3eb47 is fine. However, I do observe the problem in mainline after applying this patch on top of c307aaf3eb47. I also see the problem with your for-next branch. > I did some testing with your rootfs & initrd, based on upstream git kernel > with the latest patches from my for-next tree: > https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=for-next > > I did tested with my own 32-bit config and the 32bit-default-config. > > Overall I couldn't reproduce any issues. Interesting. > Can you try to come up with some more info for what I should look at? > All I can say is that it doesn't boot for me if this patch is applied. > By the way, this patch is now running on all physical debian-buildd servers (64bit kernel) > without any issues so far. > I guess qemu is at fault, but I have no idea why. I also tried qemu mainline, but it does not make a difference for me. Do you by any chance know the command line necessary to make earlycon work ? Maybe that would help. Looking into debug output from qemu, I see that start_firmware calls some external function. In the working image, execution returns to start_firmware. In the non-working image, it never returns but stops execution. Here is the key difference: Working: ---------------- IN: 0x0000000000175744: extrw,u r8,9,10,r1 0x0000000000175748: depw r0,31,12,r25 0x000000000017574c: copy r0,r16 0x0000000000175750: ldw,s r1(r25),r25 0x0000000000175754: bb,>=,n r25,1f,0x1757cc ---------------- IN: 0x0000000000175758: depw r0,31,4,r25 0x000000000017575c: copy r25,r9 0x0000000000175760: depw,z r9,23,24,r25 0x0000000000175764: extrw,u r8,19,10,r1 0x0000000000175768: depw r0,31,12,r25 0x000000000017576c: shladd r1,2,r25,r25 0x0000000000175770: ldw r0(r25),r16 <<-- not executed in broken case 0x0000000000175774: bb,>=,n r16,16,0x1757cc <<-- not executed in broken case ---------------- IN: 0x0000000000175778: ldi 100,r9 0x000000000017577c: or r9,r16,r1 0x0000000000175780: and,<> r9,r16,r0 0x0000000000175784: stw r1,0(r25) 0x0000000000175788: depw,z r24,30,15,r17 0x000000000017578c: depw r16,8,7,r17 0x0000000000175790: extrw,u,= r16,24,1,r0 0x0000000000175794: depwi 1,12,1,r17 0x0000000000175798: extrw,u,= r16,20,1,r0 0x000000000017579c: depwi 7,11,3,r17 0x00000000001757a0: extrw,u,= r16,28,1,r0 0x00000000001757a4: depwi 0,11,2,r17 0x00000000001757a8: depwi 0,31,12,r16 0x00000000001757ac: extrw,u r16,24,25,r16 0x00000000001757b0: mfsp sr1,r9 0x00000000001757b4: mtsp r24,sr1 0x00000000001757b8: idtlba r16,(sr1,r8) 0x00000000001757bc: idtlbp r17,(sr1,r8) 0x00000000001757c0: mtsp r9,sr1 0x00000000001757c4: rfi,r ---------------- IN: start_parisc 0x0000000010107694: copy r3,r1 0x0000000010107698: stw rp,-14(sp) ... Broken: ---------------- IN: 0x0000000000175744: extrw,u r8,9,10,r1 0x0000000000175748: depw r0,31,12,r25 0x000000000017574c: copy r0,r16 0x0000000000175750: ldw,s r1(r25),r25 0x0000000000175754: bb,>=,n r25,1f,0x1757c4 <<-- shightly different jump target ---------------- IN: 0x0000000000175758: depw r0,31,4,r25 0x000000000017575c: copy r25,r9 0x0000000000175760: depw,z r9,23,24,r25 0x0000000000175764: extrw,u r8,19,10,r1 0x0000000000175768: depw r0,31,12,r25 0x000000000017576c: shladd r1,2,r25,r25 <<-- two instructions missing 0x0000000000175770: ldi 100,r9 0x0000000000175774: or r9,r16,r1 0x0000000000175778: and,<> r9,r16,r0 0x000000000017577c: stw r1,0(r25) 0x0000000000175780: depw,z r24,30,15,r17 0x0000000000175784: depw r16,8,7,r17 0x0000000000175788: extrw,u,= r16,24,1,r0 0x000000000017578c: depwi 1,12,1,r17 0x0000000000175790: extrw,u,= r16,20,1,r0 0x0000000000175794: depwi 7,11,3,r17 0x0000000000175798: extrw,u,= r16,28,1,r0 0x000000000017579c: depwi 0,11,2,r17 0x00000000001757a0: depwi 0,31,12,r16 0x00000000001757a4: extrw,u r16,24,25,r16 0x00000000001757a8: mfsp sr1,r9 0x00000000001757ac: mtsp r24,sr1 0x00000000001757b0: idtlba r16,(sr1,r8) 0x00000000001757b4: idtlbp r17,(sr1,r8) 0x00000000001757b8: mtsp r9,sr1 0x00000000001757bc: rfi,r <<-- should return to start_parisc ---------------- IN: 0x00000000001738e0: b,l 0x1754bc,r0 0x00000000001738e4: ldi 7,r8 ... ---------------- IN: 0x00000000001755e8: mtctl r0,pcsq 0x00000000001755ec: mtctl r0,pcsq 0x00000000001755f0: mtctl r1,ipsw 0x00000000001755f4: ldil L%10175000,r1 0x00000000001755f8: ldo 610(r1),r1 0x00000000001755fc: mtctl r1,pcoq 0x0000000000175600: ldo 4(r1),r1 0x0000000000175604: mtctl r1,pcoq 0x0000000000175608: rfi,r <<-- hangs here The differences seem to be in line with the patch. No idea how to proceed. Please let me know if there is anything else I can do. Thanks, Guenter
