memory problems on Fiasco porting
adam at os.inf.tu-dresden.de
Thu Feb 26 19:37:49 CET 2009
On Thu Feb 26, 2009 at 01:27:24 +0800, Tsai, Tung-Chieh wrote:
> On Fri, Feb 20, 2009 at 5:41 AM, Adam Lackorzynski
> <adam at os.inf.tu-dresden.de> wrote:
> > This is the point where interrupts are enabled and also the points where
> > it's likely that the first timer hits. The cache_enabled constant just
> > influences the cp15-c1 value so maybe you should also disable the
> > flushing functions, maybe there's something strange? Another
> > simplification is also not to do any range based flushing but alsways
> > flush everything. When you mean stuck is it because of a fault or is it
> > looping or something else? Do you look at the system with some external
> > debugger?
> I use `stuck' to describe that it would falling into a infinite loop. I use
> ARM AXD debugger to debug.
Ok, and where? Any prominent place?
> I set cache_enabled to false, using empty cache flush/clean function,
> and change Config::scheduler_granularity to 100UL, make the timer
> interrupt less frequently, then it could pass the "Calibrating timer
> loop... ",
> leaveingThread::init_workload() normally. ( Without changing
> Config::scheduler_granularity , it wouldn't pass) But wouldn't show any
> thing further.It seems because sigma0 wouldn't work. I try to enter jdb
> after leaving init_workload() , jdb shows that the status of sigma0 is
> `cancel,dead' and boot_task is `poll,ipc_progr,snd_progr' :
> (0.00) jdb: t2
> thread: 2.00 <00040000> prio: 10 mcp: 00 mode: Con
> state: 300 cancel,dead
> wait for: *.** polling: rcv descr:
> lcked by: ---.-- timeout :
> cpu time: 900.000 µ timeslice: 200/1000 µs
> pager : 0.00 cap: ---.-- utcb: f0bfb000
> preemptr: 0.00 not monitored ready lnk: ---.-- ---.--
> prsent lnk: 4.00 0.00
> PC=ffffffd8 USP=300707d0
> It seems sigma0 has problem on PC, but the value of Kip::k()->sigma0_ip
> is correct.
The pc looks like it already did something. The last page should be the
syscall page. Did it go through Thread::user_invoke and tried to enter
user-mode? What's the pc of roottask?
In the initial boot-prompt you should also enabled page fault logging
(P*) to see if any (unusual) happened (with T). And maybe also IPC
logging (I* and IR+).
> Besides, I found that I didn't enable ROM protection(R bit in CP15_c1, bit 9)
> , because if I adding it to Cpu::Cp15_c1_generic to enable it, an RDI
> warning will be raised on AXD and uart wouldn't give any output from
> fiasco kernel. In Page_table::init(Page_table*), it write the domain access
> permission to 0x0001. In original situation, for example, in integratorcp,
> d1 ~ d15 will become read only, but in my situation, since R bit is unable to
> enable, d1 to d15 will become `No acess' . I guess this cause my problem,
> but not very sure.
Looking at the table in the manual this only affects kernel-only ro
pages which there should not be any. d0 is the only one used so the
other should not play a role. Also on integratorcp d1-d15 should be 0,
i.e. no access. I think you mean in the AP bits in the page table.
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers