Hi Folks !
Is there any specific reason why you chose 1T (40 bit) as the location
of the 64-bit DMA window ?
It happens that most current radeon adapters cannot DMA there, they have
a 40-bit DMA limit. I seem to be getting things to work fine using a
39-bit window, but I suppose that might collid
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Fedora 19 seems to be using it ... among others.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxp
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Another question...
>
> Do you guys happen to have a patch to emulate fsqrt in the kernel ?
>
> Fedora 19 seems to be using it ... among others.
You mean this one
arch/powerpc/math-emu/fsqrt.c ?
Yes.
On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Seems this is already emulated:
arch/powerpc/math-emu/fsqrt.c
You can enable CONFIG_MATH_EMULATION to try.
Tiejun
___
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
>
> Hi Folks !
>
> Is there any specific reason why you chose 1T (40 bit) as the location of
> the 64-bit DMA window ?
>
> It happens that most current radeon adapters cannot DMA there, they have
> a
On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
> On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
> > Another question...
> >
> > Do you guys happen to have a patch to emulate fsqrt in the kernel ?
>
> Seems this is already emulated:
>
> arch/powerpc/math-emu/fsqrt.c
>
> You can enab
On Fri, 2013-06-07 at 07:45 +, Zang Roy-R61911 wrote:
>
> > -Original Message-
> > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> > Another question...
> >
> > Do you guys happen to have a patch to emulate fsqrt in the kernel ?
> >
> > Fedora 19 seems to be using it
On Fri, 2013-06-07 at 07:58 +, Zang Roy-R61911 wrote:
>
> > -Original Message-
> > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> >
> > Hi Folks !
> >
> > Is there any specific reason why you chose 1T (40 bit) as the location of
> > the 64-bit DMA window ?
> >
> >
On Fri, 2013-06-07 at 18:53 +1000, Benjamin Herrenschmidt wrote:
> +
> +static double crackpot_sqrt(double val)
> +{
> +int i;
> +float x, y;
> +const float f = 1.5F;
> +
> +x = val * 0.5F;
> +y = val;
> +i = * ( int * ) &y;
> +i = 0x5f3759df - ( i >> 1 );
> +y
On 06/07/2013 04:53 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
Another question...
Do you guys happen to have a patch to emulate fsqrt in the kernel ?
Seems this is already emulated:
arch/powe
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
>
> On Fri, 2013-06-07 at 07:58 +, Zang Roy-R61911 wrote:
> >
> > > -Original Message-
> > > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> > >
> > > Hi Folks !
> > >
> > >
The MSR TM controls are in the top 32 bits of the MSR hence on 32 bit signals,
we stick the top half of the MSR in the checkpointed signal context so that the
user can access it.
Unfortunately, we don't currently write anything to the checkpointed signal
context when coming in a from a non transac
Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit signal
without SIGINFO (non RT) inside a transaction, on signal return we don't
restore the signal frame correctly.
This checks if the signal frame being restoring is an active transaction, and
if so, it copies the additional
Currently we clear out the MSR TM bits on signal return assuming that the
signal should never return to an active transaction.
This is bogus as the user may do this. It's most likely the transaction will
be doomed due to a treclaim but that's a problem for the HW not the kernel.
This removes the
Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active. Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.
The current
Currently we only restore signals which are transactionally suspended but it's
possible that the transaction can be restored even when it's active. Most
likely this will result in a transactional rollback by the hardware as the
transaction will have been doomed by an earlier treclaim.
The current
> > +
> > +static double crackpot_sqrt(double val)
> > +{
> > +int i;
> > +float x, y;
> > +const float f = 1.5F;
> > +
> > +x = val * 0.5F;
> > +y = val;
> > +i = * ( int * ) &y;
> > +i = 0x5f3759df - ( i >> 1 );
> > +y = * ( float * ) &i;
> > +y = y * ( f
On Friday, June 07, 2013 10:48:21 AM Viresh Kumar wrote:
> On 31 May 2013 16:20, Viresh Kumar wrote:
> > On 20 May 2013 10:10, Viresh Kumar wrote:
> >> On 13 May 2013 11:34, Viresh Kumar wrote:
> >>> On 22 April 2013 12:19, Viresh Kumar wrote:
> On 9 April 2013 14:05, Viresh Kumar wrote:
On Fri, 2013-06-07 at 17:02 +0800, tiejun.chen wrote:
> On 06/07/2013 04:53 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-06-07 at 15:46 +0800, tiejun.chen wrote:
> >> On 06/07/2013 03:41 PM, Benjamin Herrenschmidt wrote:
> >>> Another question...
> >>>
> >>> Do you guys happen to have a patch
On Fri, 2013-06-07 at 09:44 +, Zang Roy-R61911 wrote:
>
> > -Original Message-
> > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> >
> > On Fri, 2013-06-07 at 07:58 +, Zang Roy-R61911 wrote:
> > >
> > > > -Original Message-
> > > > From: Benjamin Herrensch
Benjamin Herrenschmidt wrote:
PHY reset timed out
PHY reset timed out
PHY reset timed out
PHY reset timed out
This usually means that your RCW does not match your dip switch settings.
--
Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozl
On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote:
> > For those interested, this is the Quake3 sqrt from Carmack ...
> there's
> > plenty of literature about it one or two google clicks away :-)
>
> I guess that is a rough enough approximation for graphics.
>
> However it will be miscompiled
On Jun 7, 2013, at 7:14 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote:
>>> For those interested, this is the Quake3 sqrt from Carmack ...
>> there's
>>> plenty of literature about it one or two google clicks away :-)
>>
>> I guess that is a rough enoug
From: Sukadev Bhattiprolu
Date: Wed, 8 May 2013 22:59:29 -0700
Subject: [PATCH 1/2] perf/Power7: Save dcache_src fields in sample record.
Power7 saves the "perf-event vector" information in the mmcra register.
Included in this event vector is a "data-cache source" field which
identifies where in
>From 9f1a8a16e0ef36447e343d1cd4797c2b6a81225f Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Fri, 7 Jun 2013 13:26:31 -0700
Subject: [PATCH 2/2] perf: Add support for the mem_xlvl field.
A follow-on patch to adding perf_mem_data_src support for Power7.
At this point, this is only touc
On 06/07/2013 05:01:28 PM, Scott Wood wrote:
On 06/07/2013 07:09:20 AM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 09:44 +, Zang Roy-R61911 wrote:
>
> > -Original Message-
> > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> >
> > On Fri, 2013-06-07 at 07:58
On Fri, 2013-06-07 at 17:02 -0500, Scott Wood wrote:
> O
> > I thought the device tree was for describing the hardware, rather
> > than configuration? :-)
A bit of both really. See things like /chosen etc...
Also to what extent a MAC address is HW vs. configuration ? :-)
The HW configuration f
On 06/07/2013 05:09:54 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 17:02 -0500, Scott Wood wrote:
> O
> > I thought the device tree was for describing the hardware, rather
> > than configuration? :-)
A bit of both really. See things like /chosen etc...
Also to what extent a MAC addr
On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
> > You also need to account for other on-chip MMIOs no ? Or do you never
> > intend to let PCI devices hit them ?
>
> I don't think we normally need that (other than MSIs, which have a
> special window under 4G)... The question is whether it
On Fri, 2013-06-07 at 14:19 -0500, Kumar Gala wrote:
> > I don't personally have the bandwidth to do a clean implementation (that
> > handles FP exceptions, NaNs, FPSCR, etc...) but I believe it would be
> > valuable if somebody else did (hint hint hint :-) since without this,
> > Fedora ppc64 is b
On Sat, 2013-06-08 at 09:23 +1000, Benjamin Herrenschmidt wrote:
> Ok, thinking out loud... looks like we might be able to just use existing
> math-emu for that. From what I can tell, all it needs (other than enabling
> the config option), is a call to flush_fp_to_thread(current);
>
> While talki
On 06/07/2013 05:39:53 PM, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
> > You also need to account for other on-chip MMIOs no ? Or do you
never
> > intend to let PCI devices hit them ?
>
> I don't think we normally need that (other than MSIs, which have
On Sat, 2013-06-08 at 09:25 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2013-06-08 at 09:23 +1000, Benjamin Herrenschmidt wrote:
> > Ok, thinking out loud... looks like we might be able to just use existing
> > math-emu for that. From what I can tell, all it needs (other than enabling
> > the c
On Fri, 2013-06-07 at 18:29 -0500, Scott Wood wrote:
> I just meant that a PCIe device targeting something other than RAM,
> CCSR (it's not just MSIs that are mapped through the special window),
> or another PCIe is a rather unusual case -- not something that you'd
> see by just plugging in
On 06/06/2013 09:00:20 PM, Kevin Hao wrote:
As you can see, the only difference between these two logs is the
io resource address and all the mem and bus address are still the
same.
Hmm... The thing that originally motivated the picking of an arbitrary
primary was virtio being assigned a BAR
On Fri, 2013-06-07 at 17:20 -0700, Dan Malek wrote:
> The purpose for that "minimal code" was the signal handlers were
> hand-coded assembly that always did the FPU load/store regardless of
> compiler flags. Over time, it became convenient to emulate a few
> others, even with user space math emul
On Fri, 2013-06-07 at 18:13 -0700, Dan Malek wrote:
> Hi Ben.
>
> On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt
> wrote:
>
> > The question is whether this is still relevant ?
>
> The only answer I could provide is that it's dependent upon the
> libraries and how the distributions are buil
37 matches
Mail list logo
