Re: New Debian Kernel Packages

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2013-08-14 at 19:43 -0400, John David Anglin wrote:
> On 1-Aug-13, at 6:52 PM, James Bottomley wrote:
> 
> > On Thu, 2013-08-01 at 18:39 -0400, John David Anglin wrote:
> >> On 1-Aug-13, at 6:20 PM, Helge Deller wrote:
> >>
> >>> Hi Dave,
> >>>
> >>> On 07/30/2013 12:46 AM, John David Anglin wrote:
> >>>> The following kernel packages are now in the parisc-linux.org
> >>>> archive:
> >>>>
> >>>> linux-image-3.10-1-parisc-smp_3.10.3-1_hppa.deb
> >>>> linux-image-3.10-1-parisc64-smp_3.10.3-1_hppa.deb
> >>>> linux-image-3.10-1-parisc64_3.10.3-1_hppa.deb
> >>>> linux-image-3.10-1-parisc_3.10.3-1_hppa.deb
> >>>
> >>> That's fantastic!
> >>> This brings us one big step further to being able to build a real
> >>> debian-unstable-installer boot CD.
> >>>
> >>> I'm still hoping the C8000 patches I pushed for inclusion into 3.11
> >>> will then
> >>> show up in stable 3.10 series soon as well. If that happens we will
> >>> have a kernel
> >>> which should boot on all machines - including the c8000.
> >>
> >>
> >> I have bootstrap tested the linux-image-3.10-1-parisc64-
> >> smp_3.10.3-1_hppa.deb package.  We'll
> >> have to see if 3.10 will be the Debian choice for the next release.
> >>
> >> As I mentioned in private, I have found that flush_cache_all() is the
> >> principal problem causing random
> >> segmentation faults on SMP systems.
> >
> > That would tend to indicate the architectural flush code is wrong: it
> > isn't flushing all as it should be.
> 
> 
> After looking at this, I think there is an irq problem.  It looks like  
> we loose IPI
> interrupts on occasion,

I don't really think this can be the case.  Our flushes are all done via
the generic function on_each_cpu() with wait set to true.  If we were
losing IPIs, this would cause the wait to wait forever and you should
see a system hang (or at least one CPU spinning in cpu_relax while it
waits).  on_each_cpu() uses a list to process and store invocations, so
even two simultaneous calls to the flush functions should be strictly
sequenced on each cpu.

>  or there is a sequencing issue in processing  
> them.
> In particular, it would be bad if we simultaneously tried to purge  
> both theTLB
> and cache at the same time.  However, this isn't the whole answer.

I can't really see how: the architectural TLB flush will, of course,
purge TLBs in the tmpalias region, but they'll just refill on the next
access for a flush, so I could see simultaneous TLB flush and cache
flush slowing each other down, but I can't see a problem arising, unless
I've missed something?

James