Really?
The current dma_addr_t is:
#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif
typedef u64 dma64_addr_t;
-EBRAINFAI ... either I wasn't looking when we changed it or I just
forgot :-) We -used-, I'm pretty
On Sat, 2010-10-02 at 21:15 -0600, Grant Likely wrote:
But I won't merge this through my tree unless Ben asks me to.
Being careful heh ? :-)
I'll take care of these.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Hi all,
My problem is kernel crash under full line rate random packet length
ip network traffic.
I'am using default unmodified kernel and default SMP kernel
configuration, MPC8572DS development board and also using a hardware
packet generator.
My test is ip forwarding between eth0 and eth1, and
On 09/29/2010 02:37 PM, Greg KH wrote:
Thankfully things like rpm, hald, and other miscellaneous commands scan
that information.
Really? Why? Why would rpm care about this? hald is dead now so we
don't need to worry about that anymore,
That's not what compatiblity means.
On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
* Nathan Fontenot nf...@austin.ibm.com [2010-10-01 13:35:54]:
Define a version of memory_block_size_bytes() for powerpc/pseries such that
a memory block spans an entire lmb.
I hope I am not missing anything obvious, but why
On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
* Nathan Fontenot nf...@austin.ibm.com [2010-10-01 13:35:54]:
Define a version of memory_block_size_bytes() for powerpc/pseries such
that
a memory block spans an
* Dave Hansen d...@linux.vnet.ibm.com [2010-10-03 11:11:01]:
On Sun, 2010-10-03 at 13:07 -0500, Robin Holt wrote:
On Sun, Oct 03, 2010 at 11:25:00PM +0530, Balbir Singh wrote:
* Nathan Fontenot nf...@austin.ibm.com [2010-10-01 13:35:54]:
Define a version of memory_block_size_bytes()
On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote:
I suppose another option is to to use the kernel profiling option I
always see but have never used. Is that a viable option to figure out
what is happening
On the prom boot path, with the firmware supposed to
be managing the MMU, there is a case where:
1. Linux changes some BAT registers.
2. Bits 0x0070 are/become set in the MSR.
3. Linux takes an MMU fault.
4. The firmware handles it.
AFAIK, you can't expect the firmware to leave the
