New Debian Kernel Packages

New Debian Kernel Packages

[John David Anglin]

The following kernel packages are now in the parisc-linux.org archive:

-rw-r--r--   1 deller   ftpadmin 19931220 Jul 29 22:01 linux- 
image-3.10-1-parisc-smp_3.10.3-1_hppa.deb
-rw-r--r--   1 deller   ftpadmin 21374850 Jul 29 22:01 linux- 
image-3.10-1-parisc64-smp_3.10.3-1_hppa.deb
-rw-r--r--   1 deller   ftpadmin 20766562 Jul 29 22:01 linux- 
image-3.10-1-parisc64_3.10.3-1_hppa.deb
-rw-r--r--   1 deller   ftpadmin 19290152 Jul 29 22:01 linux- 
image-3.10-1-parisc_3.10.3-1_hppa.deb

Dave
--
John David Anglin	dave.anglin@bell.net

Re: New Debian Kernel Packages

[Helge Deller]

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.

Helge

Re: New Debian Kernel Packages

[John David Anglin]

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.  Unfortunately, the only fix so  
far is to not use flush_cache_all()
in flush_cache_mm() and flush_cache_range(), and this really slows  
things down running GCC
testsuite.  It doesn't seem to hurt much for other stuff.

My thought that this might be a timing issue didn't work.  I tried  
masking all external interrupts except for
IPI on all processors first, but it didn't help.  It may be this can  
be narrowed somewhat.  I suspect that we
have an inconsistent cache state during fork.

I think if this issue is fixed, c8000's will be worth a bit more than  
100 Euros...

Dave
--
John David Anglin	dave.anglin@bell.net

Re: New Debian Kernel Packages

[James Bottomley]

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.

James

Re: New Debian Kernel Packages

[John David Anglin]

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.


That thought had occurred to me.  It's also possible that it doesn't  
work
properly with the L3 added in the PA8800/PA8900 systems.

What seems to work is flushing all the user mappings.

I should note that I have also seen corruption of space register %sr1
(added checks in the routines that use pa_memcpy).  I think the only
way that can happen is kernel stack corruption.  Probably, this is also
caused by flush_cache_all.  I know this issue has been around for
a long time.

I'll look at the flush code again.

Dave
--
John David Anglin	dave.anglin@bell.net

Re: New Debian Kernel Packages

[John David Anglin]

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, 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.

Dave
--
John David Anglin	dave.anglin@bell.net

Re: New Debian Kernel Packages

[James Bottomley]

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