Re: [PATCH] parisc: Remove PTE load and fault check from L2_ptep macro

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
> 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.
> Can you try to come up with some more info for what I should look at?
> 
> Linux version 4.19.0-rc5-32bit+ (deller@ls3530) (gcc version 7.2.1 20170915 (Red Hat Cross 7.2.1-1) (GCC)) #733 SMP Wed Sep 26 18:13:01 CEST 2018
> CPU0: thread -1, cpu 0, socket 0
...
> smp: Bringing up secondary CPUs ...
> smp: Brought up 1 node, 1 CPU

Key difference:

Your configuration has SMP enabled. Mine (using "defconfig") doesn't.
The difference is default_defconfig vs. generic-32bit_defconfig.

I'll add smp tests to my test suite.

Guenter



[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux