On Wed, Sep 26, 2018 at 11:42:24PM +0200, Helge Deller wrote: > On 26.09.2018 23:24, Guenter Roeck wrote: > > On Wed, Sep 26, 2018 at 10:25:22PM +0200, Helge Deller wrote: > >> On 26.09.2018 21:32, Guenter Roeck wrote: > >>> 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 tried my -for-next on top of c307aaf3eb47 too -> no issues. > >> > > > > Did you try a non-SMP configuration ? > > Uni-processor qemu virtual machine with SMP-enabled Linux kernel works. Yes, I can confirm that. A multi-processor virtual machine runs very slow, but that really looks like a qemu issue to me. > But I haven't tried running a non-SMP Linux kernel itself yet (I can try earliest tomorrow). > That is what fails for me. Please let me know how it goes. Thanks, Guenter
