On 09/29/2010 04:50 AM, Greg KH wrote:
>
> Because the old ABI creates 129,000+ entries inside
> /sys/devices/system/memory with their associated links from
> /sys/devices/system/node/node*/ back to those directory entries.
>
> Thankfully things like rpm, hald, and other miscellaneous comman
Scott Wood wrote:
> On Tue, 28 Sep 2010 08:31:54 -0700
> "Ira W. Snyder" wrote:
>
>> On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hag...@gmail.com wrote:
>>> Alternatively, can somebody see a hint in the message that I don't know
>>> enough to pick out? At this point, my code is trying to memc
On Wed, Sep 29, 2010 at 10:32:34AM +0200, Avi Kivity wrote:
> On 09/29/2010 04:50 AM, Greg KH wrote:
>> >
>> > Because the old ABI creates 129,000+ entries inside
>> > /sys/devices/system/memory with their associated links from
>> > /sys/devices/system/node/node*/ back to those directory entrie
On Wed, Sep 29, 2010 at 14:37, Greg KH wrote:
> On Wed, Sep 29, 2010 at 10:32:34AM +0200, Avi Kivity wrote:
>> On 09/29/2010 04:50 AM, Greg KH wrote:
>>> >
>>> > Because the old ABI creates 129,000+ entries inside
>>> > /sys/devices/system/memory with their associated links from
>>> > /sys/dev
On Wed, 29 Sep 2010 00:20:54 +0100, Ben Dooks wrote:
> On Fri, Sep 24, 2010 at 04:14:53PM -0600, Grant Likely wrote:
> > Commit 959e85f7, "i2c: add OF-style registration and binding" caused a
> > module dependency loop where of_i2c.c calls functions in i2c-core, and
> > i2c-core calls of_i2c_regist
On Fri, 24 Sep 2010 16:15:18 -0600, Grant Likely wrote:
> Commit 959e85f7, "i2c: add OF-style registration and binding" caused a
> module dependency loop where of_i2c.c calls functions in i2c-core, and
> i2c-core calls of_i2c_register_devices() in of_i2c. This means that
> when i2c support is buil
On Tue, Sep 28, 2010 at 01:17:33PM -0500, Nathan Fontenot wrote:
> On 09/28/2010 07:38 AM, Robin Holt wrote:
> > I was tasked with looking at a slowdown in similar sized SGI machines
> > booting x86_64. Jack Steiner had already looked into the memory_dev_init.
> > I was looking at link_mem_section
On Mon, Sep 27, 2010 at 3:57 PM, Ira W. Snyder wrote:
> Now that the DMAEngine API has support for scatterlist to scatterlist
> copy, implement support for the STE DMA40 DMA controller.
>
> Cc: Linus Walleij
> Cc: Per Fridén
> Signed-off-by: Ira W. Snyder
> ---
> drivers/dma/ste_dma40.c | 17
> Scott Wood wrote:
> I also meet machine check exception if configure LAW improperly for PCI.
> (i.e.
> unmatched PCIe controller id.)
>
> From you log looks 0xexxx should be your PCI space. So you can check
> if that
> fall into appropriate LAW configuration. Maybe you can post your boot log
On Mon, Sep 27, 2010 at 3:57 PM, Ira W. Snyder wrote:
> Now that the generic DMAEngine API has support for scatterlist to
> scatterlist copying, this implementation of the DMA_SLAVE API is no
> longer necessary.
>
> In order to let device_control() continue to function, a stub
> device_prep_slave_
On Wed, Sep 29, 2010 at 02:52:16PM -0700, Dan Williams wrote:
> On Mon, Sep 27, 2010 at 3:57 PM, Ira W. Snyder wrote:
> > Now that the generic DMAEngine API has support for scatterlist to
> > scatterlist copying, this implementation of the DMA_SLAVE API is no
> > longer necessary.
> >
> > In order
Quoting Christoph Lameter :
On Thu, 23 Sep 2010, Christian Riesch wrote:
> > It implies clock tuning in userspace for a potential sub microsecond
> > accurate clock. The clock accuracy will be limited by user space
> > latencies and noise. You wont be able to discipline the system clock
> > acc
12 matches
Mail list logo
