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 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.
But I haven't tried running a non-SMP Linux kernel itself yet (I can try earliest tomorrow).

Helge



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

  Powered by Linux