Re: [parisc] A500 boot crash with 44786880df196a4200c178945c4d41675faf9fb7

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

 



On Wed, 2018-10-24 at 17:56 +0200, Helge Deller wrote:
> On 24.10.2018 17:45, Helge Deller wrote:
> > On 24.10.2018 17:03, John David Anglin wrote:
> > > On 2018-10-24 7:59 AM, John David Anglin wrote:
> > > > The fault occured executing this instruction "stw r31,0(r25)".
> > > > Register r31 contains the following
> > > > instruction "pdtlb,l r0(sr1,r3)".  This indicates the fault
> > > > occurred during alternative patching.
> > > > 
> > > > I suspect all kernel TLB entries need to be flushed prior to
> > > > alternative patching to ensure that kernel
> > > > pages are writeable.
> > > 
> > > Looks like this is a problem with set_kernel_text_rw().  Maybe
> > > this causes problems:
> > > 
> > > int __flush_tlb_range(unsigned long sid, unsigned long start,
> > >                       unsigned long end)
> > > {
> > >         unsigned long flags;
> > > 
> > >         if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) &&
> > >             end - start >= parisc_tlb_flush_threshold) {
> > >                 flush_tlb_all();
> > >                 return 1;
> > >         }
> > > 
> > > I believe that we need to disable this optimization until the
> > > parisc_tlb_flush_threshold is
> > > calculated.  I think this crash is related to the occasional
> > > crash in parisc_setup_cache_timing().
> > > 
> > > Maybe change in cache.c the initial define for
> > > parisc_tlb_flush_threshold:
> > > static unsigned long parisc_tlb_flush_threshold __read_mostly =
> > > ~0UL;
> > 
> > If it would run into flush_tlb_all(), then I'd expect that all TLBs
> > have been flushed and
> > we wouldn't see an issue.
> > Maybe the info in the cache_info struct, which is used in the
> > assembly of flush_tlb_all_local(),
> > hasn't been initialized yet and such the whole cache hasn't been
> > flushed?
> 
> Nope, cache_info has already been initialized then...
> Nevertheless, flush_tlb_all_local() should have fully flushed the
> TLB...

I don't think it does what you think: you're expecting it to flush the
TLB entries associated with the kernel.  What it seems to do, in my
reading, is flush the TLB entries associated with the user space id,
which won't touch the kernel tlbs.

James




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

  Powered by Linux