linux-mips
[Top] [All Lists]

RE: [MIPS] SB1: Build fix: delete initialization of flush_icache_page po

To: "Atsushi Nemoto" <anemo@mba.ocn.ne.jp>
Subject: RE: [MIPS] SB1: Build fix: delete initialization of flush_icache_page pointer.
From: "Manoj Ekbote" <manoje@broadcom.com>
Date: Tue, 26 Sep 2006 18:54:40 -0700
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, "Mark E Mason" <mark.e.mason@broadcom.com>
In-reply-to: <20060926.183946.49857108.nemoto@toshiba-tops.co.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AcbhT7ypS3Njh6HmQ7+E9jeQQjaFlAAhMObQ
Thread-topic: [MIPS] SB1: Build fix: delete initialization of flush_icache_page pointer.
Hi,

I tried the patch that you pointed to and UP kernel boots fine. Looks
like that was a icache and dcache coherency problem now that there is no
flush_icache_page implementation.

The SMP kernel still has trouble.Turning on the first printk in fault.c
makes it work..which is interesting.
I added a __sb1_flush_icache_range call with dcache invalidation..still
no help. I don't see a SIGSEGV message now.The kernel hangs with no
response to keystrokes and the soft lockup detect error shows up after
sometime.

Oh, inserting flush_icache_page caused the kernel to panic. I also see
that __flush_icache_page is not used anywhere. Any future use?

Thx.

>-----Original Message-----
>From: Atsushi Nemoto [mailto:anemo@mba.ocn.ne.jp] 
>Sent: Tuesday, September 26, 2006 2:40 AM
>To: Manoj Ekbote
>Cc: Mark E Mason; linux-mips@linux-mips.org; 
>ralf@linux-mips.org; ths@networkno.de
>Subject: Re: [MIPS] SB1: Build fix: delete initialization of 
>flush_icache_page pointer.
>
>On Mon, 25 Sep 2006 20:05:59 -0700, "Manoj Ekbote" 
><manoje@broadcom.com> wrote:
>> The latest tip still has problems with booting on Broadcom boards.
>> I turned on a couple of printk's in the page fault handler and I see 
>> the following messages:
>...
>> It looks like a cache corruption issue.  Did the removal of 
>> flush_icache_page cause this?
>
>Yes perhaps.  But flush_icache_page() itself is obsolete API 
>and should be gone (see Documentation/cachetlb.txt).  So there 
>should be fault in somewhere else.
>
>I think 
>
>http://www.linux-mips.org/archives/linux-mips/2006-08/msg00184.html
>
>is still needed, but it seems not enough.
>
>If reverting flush_icache_page() worked, then you can debug more.
>
>1. kill part of local_sb1_flush_icache_page().
>
>If killing __sb1_writeback_inv_dcache_phys_range() part was 
>OK, then it would be dcache issue, if killing 
>drop_mmu_context() part was OK, then it would be icache issue.
>
>2. kill calls of flush_icache_page().
>
>If is used in only 3 places.
>
>mm/fremap.c:    flush_icache_page(vma, page);
>mm/memory.c:    flush_icache_page(vma, page);
>mm/memory.c:            flush_icache_page(vma, new_page);
>
>Finding which lines are required might help further investigation.
>
>
>Another possible approach might be trying c-r4k.c instead of c-sb1.c.
>
>If you wanted to debug with latest git tree, note that 
>include/asm-mips/hazard.h in current lmo git tree seems 
>broken.  The fix was already posted to this ML so hopefully we 
>can see in git tree soon...
>
>---
>Atsushi Nemoto
>
>


<Prev in Thread] Current Thread [Next in Thread>