public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Guillaume Autran <gautran@mrv•com>
To: linux-ppc-embedded <linuxppc-embedded@ozlabs•org>
Cc: "Smith, Craig" <craig.d.smith@siemens•com>
Subject: Re: Linux 2.6.x on 8xx status
Date: Mon, 21 Mar 2005 16:45:21 -0500	[thread overview]
Message-ID: <423F4071.1000001@mrv.com> (raw)
In-Reply-To: <20050210170859.GB20153@logos.cnet>

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

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
======================================= 


[-- Attachment #2: Type: text/html, Size: 2953 bytes --]

  reply	other threads:[~2005-03-21 21:45 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-21 11:59 Linux 2.6.x on 8xx status Smith, Craig
2004-09-21 11:53 ` Pantelis Antoniou
2004-09-21 16:54   ` Dan Malek
2004-09-21 17:03 ` Dan Malek
2004-09-22 11:09   ` Sam Song
2004-10-15 15:49   ` Marcelo Tosatti
2004-10-16  2:13     ` Marcelo Tosatti
2004-10-16  9:08       ` Sam Song
2004-10-18  5:59         ` Pantelis Antoniou
2004-10-18  6:22           ` Sam Song
2004-10-18  3:10     ` Dan Malek
2005-02-10 15:04   ` Marcelo Tosatti
2005-02-10 19:26     ` Dan Malek
2005-02-10 17:06       ` Marcelo Tosatti
2005-02-10 17:08         ` Marcelo Tosatti
2005-03-21 21:45           ` Guillaume Autran [this message]
2005-03-21 21:53             ` Robert P. J. Day
2005-03-22 13:04             ` Marcelo Tosatti
2005-03-22 20:57               ` Dan Malek
2005-03-22 17:58                 ` Marcelo Tosatti
2005-03-22 22:53                   ` Dan Malek
2005-03-23 10:25                     ` Marcelo Tosatti
2005-03-23 16:12                       ` Dan Malek
2005-03-23 16:05                         ` Marcelo Tosatti
2005-03-24 14:05                           ` Pantelis Antoniou
2005-03-23 14:06                   ` Guillaume Autran
2005-02-11  3:42         ` Dan Malek
2005-02-21 21:12       ` Armin Schindler
2005-02-21 23:45         ` Guillaume Autran
2005-02-15  9:39     ` Reading of RTC robin
  -- strict thread matches above, loose matches on Subject: below --
2005-02-22 11:20 Linux 2.6.x on 8xx status Joakim Tjernlund
2004-10-25 15:00 Sam Song
2004-09-17 13:57 Smith, Craig
2004-09-17 13:50 ` Pantelis Antoniou
     [not found] <20040916201505.E723B2BDB2@ozlabs.org>
2004-09-17 10:06 ` Song Sam
2004-09-17  9:55   ` Pantelis Antoniou
2004-09-18 20:11     ` Song Sam
2004-09-20  6:02       ` Pantelis Antoniou
2004-09-20 11:47         ` Song Sam
2004-09-20 17:49     ` Tom Rini
2004-09-20 18:02       ` Robert P. J. Day
2004-09-20 18:17         ` Tom Rini
2004-09-21  1:38       ` Song Sam
2004-09-21  6:12         ` Pantelis Antoniou
2004-09-21 10:35           ` Song Sam
2004-09-21 10:41             ` Pantelis Antoniou
2004-10-15 15:47               ` Marcelo Tosatti
2004-09-16 18:56 Smith, Craig
2004-09-16 20:07 ` Dan Malek
2004-09-17  5:43   ` Pantelis Antoniou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=423F4071.1000001@mrv.com \
    --to=gautran@mrv$(echo .)com \
    --cc=craig.d.smith@siemens$(echo .)com \
    --cc=linuxppc-embedded@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox