|To:||Ralf Baechle <firstname.lastname@example.org>|
|Subject:||Re: [PATCH] MIPS: Kernel hangs occasionally during boot.|
|From:||"Gleb O. Raiko" <email@example.com>|
|Date:||Wed, 09 Nov 2011 15:26:32 +0400|
|Cc:||Al Cooper <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org|
|References:||<y> <email@example.com> <20111108175532.GA15493@linux-mips.org> <4EBA2E65.firstname.lastname@example.org> <20111109103432.GA27378@linux-mips.org>|
|User-agent:||Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1|
On 09.11.2011 14:34, Ralf Baechle wrote:
In fact, current back_to_back_hazard is more than enough for cpus I deal with. I guess, required time to wait equals number of stages between EX (or RD) and WB stages for modern cpus, because CP0 CAUSE is updated during WB nowadays.Hmm... Looking at the R4000 manual which generall has the longest pipeline hazards, mtc0 gets executed at stage 7, interrupts get sampled at stage 3 meaning there is a (7 - 3 - 1) = 3 cycles hazard. Does that one statisfy your constraints? Or are additional cycles needed for a hazard that's generated outside of the CPU's pipeline?
I suspect, the time required to update internal counter logic for original r4k might be bigger though. At least old code waited 12 cycles (4*irq_disable_hazard which is 3 for r4k). Perhaps, we should keep this code and insert the same amount of nops for old cpus at least.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH] MIPS: Kernel hangs occasionally during boot., Ralf Baechle|
|Next by Date:||Re: [PATCH v2 10/11] MIPS: BCM63XX: add external irq support for non 6348 CPUs., Jonas Gorski|
|Previous by Thread:||Re: [PATCH] MIPS: Kernel hangs occasionally during boot., Ralf Baechle|
|Next by Thread:||built-in command line vs. bootloader-supplied, Ricard Wanderlof|
|Indexes:||[Date] [Thread] [Top] [All Lists]|