Date: Tue, 29 Jun 2010 13:04:32 -0700 From: Neel Natu <neelnatu@gmail.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-mips@freebsd.org Subject: Re: Merging 64 bit changes to -HEAD Message-ID: <AANLkTikIMYAfntzNC60L7ZXZm2lCavtDhxCsmyiRrfw0@mail.gmail.com> In-Reply-To: <20100629.112421.25793712605171655.imp@bsdimp.com> References: <AANLkTint7Hyf79EH29OLsIfreQRd7dQMdvX9wRq4v_yG@mail.gmail.com> <C6D73C96-3640-4502-A9D7-B3597E37E80A@gmail.com> <AANLkTilQIqF4FCfgLdVcKdcsAUVjCmr89Lu0TEXUFdYN@mail.gmail.com> <20100629.112421.25793712605171655.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Tue, Jun 29, 2010 at 10:24 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <AANLkTilQIqF4FCfgLdVcKdcsAUVjCmr89Lu0TEXUFdYN@mail.gmail.com=
>
> =A0 =A0 =A0 =A0 =A0 =A0"Jayachandran C." <c.jayachandran@gmail.com> write=
s:
> : On Tue, Jun 29, 2010 at 2:28 AM, Luiz Otavio O Souza <lists.br@gmail.co=
m> wrote:
> : >> Thanks for the the update. Looks like pmap_map for kernel is failing=
,
> : >> may be the new tlb_update code causes this. =A0Can you apply the
> : >> attached patch and see if the problem still persists, it replaces th=
e
> : >> new tlb_update code with the older version.
> : >>
> : >> Obviously not a fix, but if we can narrow it down to this function,
> : >> fixing will be easier.
> : >>
> : >> JC.
> : >> <try.diff>
> : >
> : > JC,
> : >
> : > This fix the problem ! Thanks ! Now, at least, you know where to look=
:)
> :
> : The new tlb_update does not seem to update the tlb entry if the tlbp
> : fails. =A0Here's a patch that should make the new function behave like
> : the older one. =A0The patch is in attached file 'tlb-update.diff'.
> :
> : If that does not work, I'm not sure what the issue is. =A0You could als=
o
> : try try the nop-change.diff attached. It tries to switch the ssnop
> : used for delay in the new code with 'nop' which was used by the old
> : code.
>
> ssnop is a mips32r2/mips64r2 addition. =A0We likely need to get smarter
> about the nop stuff, based on the CPU we configure. =A0I can't recall if
> the Atheros is misp32 or mips32r2. =A0IIRC, the idt RC32434 is mips32,
> as is the adm5120...
>
It seems that ssnop should be identical to nop on non-superscalar processor=
s.
Here is the snippet from vol2 of the mips64 architecture manual.
<snip>
Format:
MIPS32
SSNOP
Purpose:
Break superscalar issue on a superscalar processor.
Description:
SSNOP is the assembly idiom used to denote superscalar no operation.
The actual instruction is interpreted by the
hardware as SLL r0, r0, 1.
This instruction alters the instruction issue behavior on a
superscalar processor by forcing the SSNOP instruction to
single-issue. The processor must then end the current instruction
issue between the instruction previous to the SSNOP
and the SSNOP. The SSNOP then issues alone in the next issue slot.
On a single-issue processor, this instruction is a NOP that takes an issue =
slot.
</snip>
It may lead to less efficient code on multiple issue processors but
replacing a nop with an ssnop should be always be safe, right?
best
Neel
> Warner
> _______________________________________________
> freebsd-mips@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikIMYAfntzNC60L7ZXZm2lCavtDhxCsmyiRrfw0>