From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailman.xyplex.com (mailman.xyplex.com [140.179.176.116]) by ozlabs.org (Postfix) with ESMTP id D60D867A7F for ; Tue, 22 Mar 2005 08:45:09 +1100 (EST) Message-ID: <423F4071.1000001@mrv.com> Date: Mon, 21 Mar 2005 16:45:21 -0500 From: Guillaume Autran MIME-Version: 1.0 To: linux-ppc-embedded References: <28F2CE72-0BF0-11D9-97DC-003065F9B7DC@embeddededge.com> <20050210150437.GA19134@logos.cnet> <20050210170658.GA20153@logos.cnet> <20050210170859.GB20153@logos.cnet> In-Reply-To: <20050210170859.GB20153@logos.cnet> Content-Type: multipart/alternative; boundary="------------000805080702080102080705" Cc: "Smith, Craig" Subject: Re: Linux 2.6.x on 8xx status List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------000805080702080102080705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Was there any progress made about this issue or is it still pending ? I'm running 2.6.11 and still see the problem... Regards, Guillaume. Marcelo Tosatti wrote: >On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote: > > >>On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote: >> >> >>>On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote: >>> >>> >>> >>>>Does anyone have a clue of what is/can be wrong with the TLB entry for >>>>the >>>>address being flushed at __flush_dcache_icache()? >>>> >>>> >>>Not sure. The problem is that the __flush_dcache_icache is passed a >>>user space virtual address that doesn't look like it is mapped for >>>writing >>>or something. I don't know, as an ooops isn't sufficient to debug the >>>problem. >>>You have to catch it here and track down the current state of the TLB >>>and >>>the page tables. Of course, when I do this everything looks OK, >>> >>> >>How do you do track down the current TLB state? With a BDI? >> >> >> >>>so what I've been trying to do is catch the TLBmiss reload that actually causes >>>this >>>to happen to see what it really tried to load into the tlb. >>> >>> >>Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to your >>analysis ?? >> >> > >So this assumption which you have made sometime ago is wrong, given that now you >know TLB entry is not stale ? > >"The symptom is we appear to have a stale TLB entry, >so at least one of the callouts from the generic VM >code isn't doing the right thing for us. I'm still >puzzled as to why it doesn't affect other PPC processor." > >_______________________________________________ >Linuxppc-embedded mailing list >Linuxppc-embedded@ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > -- ======================================= Guillaume Autran Senior Software Engineer MRV Communications, Inc. Tel: (978) 952-4932 office E-mail: gautran@mrv.com ======================================= --------------000805080702080102080705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Was there any progress made about this issue or is it still pending ? I'm running 2.6.11 and still see the problem...

Regards,
Guillaume.



Marcelo Tosatti wrote:
On Thu, Feb 10, 2005 at 03:06:58PM -0200, Marcelo Tosatti wrote:
  
On Thu, Feb 10, 2005 at 02:26:52PM -0500, Dan Malek wrote:
    
On Feb 10, 2005, at 10:04 AM, Marcelo Tosatti wrote:

      
Does anyone have a clue of what is/can be wrong with the TLB entry for 
the
address being flushed at __flush_dcache_icache()?
        
Not sure.  The problem is that the __flush_dcache_icache is passed a
user space virtual address that doesn't look like it is mapped for 
writing
or something.  I don't know, as an ooops isn't sufficient to debug the 
problem.
You have to catch it here and track down the current state of the TLB 
and
the page tables.  Of course, when I do this everything looks OK, 
      
How do you do track down the current TLB state? With a BDI? 

    
so what I've been trying to do is catch the TLBmiss reload that actually causes 
this
to happen to see what it really tried to load into the tlb.
      
Shouldnt it be loading the TLB entry which "seem to be OK" accordingly to your
analysis ?? 
    

So this assumption which you have made sometime ago is wrong, given that now you 
know TLB entry is not stale ?

"The symptom is we appear to have a stale TLB entry,
so at least one of the callouts from the generic VM
code isn't doing the right thing for us.  I'm still
puzzled as to why it doesn't affect other PPC processor." 

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

  

-- 
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
======================================= 
--------------000805080702080102080705--