* [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-13 2:05 UTC (permalink / raw)
To: linuxppc-dev
A devtree compiler (dtc) generated devtree blob is "relocatable" and
so does not contain a reserved_map entry for the blob itself.
This means that if passed to Linux, Linux will not get lmb_reserve()
the blob and it could be over.
The following patch will explicitly reserve the "blob" as it was
given to us and stops prom_init.c from creating a reserved mapping
for the blob.
NOTE: that the dtc must also not generate the blob reservation
entry. Should we try to detect this redundant entry? Should we bump
the DT version number?
Signed-off-by: <jimix@watson.ibm.com>
--
diff -r eb0990a251a9 arch/powerpc/kernel/prom.c
--- a/arch/powerpc/kernel/prom.c Thu Mar 30 22:05:40 2006 -0500
+++ b/arch/powerpc/kernel/prom.c Wed Apr 12 22:00:27 2006 -0400
@@ -1132,6 +1132,11 @@ static void __init early_reserve_mem(voi
reserve_map = (u64 *)(((unsigned long)initial_boot_params) +
initial_boot_params->off_mem_rsvmap);
+
+ /* before we do anything, lets reserve the dt blob */
+ lmb_reserve(__pa((unsigned long)initial_boot_params),
+ initial_boot_params->totalsize);
+
#ifdef CONFIG_PPC32
/*
* Handle the case where we might be booting from an old kexec
diff -r eb0990a251a9 arch/powerpc/kernel/prom_init.c
--- a/arch/powerpc/kernel/prom_init.c Thu Mar 30 22:05:40 2006 -0500
+++ b/arch/powerpc/kernel/prom_init.c Wed Apr 12 22:00:27 2006 -0400
@@ -1909,11 +1909,7 @@ static void __init flatten_device_tree(v
/* Version 16 is not backward compatible */
hdr->last_comp_version = 0x10;
- /* Reserve the whole thing and copy the reserve map in, we
- * also bump mem_reserve_cnt to cause further reservations to
- * fail since it's too late.
- */
- reserve_mem(RELOC(dt_header_start), hdr->totalsize);
+ /* Copy the reserve map in */
memcpy(rsvmap, RELOC(mem_reserve_map), sizeof(mem_reserve_map));
#ifdef DEBUG_PROM
@@ -1926,6 +1922,9 @@ static void __init flatten_device_tree(v
RELOC(mem_reserve_map)[i].size);
}
#endif
+ /* Bump mem_reserve_cnt to cause further reservations to fail
+ * since it's too late.
+ */
RELOC(mem_reserve_cnt) = MEM_RESERVE_MAP_SIZE;
prom_printf("Device tree strings 0x%x -> 0x%x\n",
^ permalink raw reply
* [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB
From: Olof Johansson @ 2006-04-13 2:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060413020559.GC24769@pb15.lixom.net>
Hi,
This goes with the previous dma_mask patch -- enable DART at 1GB due to
Airport Extreme cards needing it. Please consider for 2.6.17.
Thanks,
Olof
---
Turn on the DART already at 1GB. This is needed because of crippled
devices in some systems, i.e. Airport Extreme cards, only supporting
30-bit DMA addresses.
Otherwise, users with between 1 and 2GB of memory will need to manually
enable it with iommu=force, and that's no good.
Some simple performance tests show that there's a slight impact of
enabling DART, but it's in the 1-3% range (kernel build with disk I/O
as well as over NFS).
iommu=off can still be used for those who don't want to deal with the
overhead (and don't need it for any devices).
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6/arch/powerpc/sysdev/dart_iommu.c
===================================================================
--- 2.6.orig/arch/powerpc/sysdev/dart_iommu.c
+++ 2.6/arch/powerpc/sysdev/dart_iommu.c
@@ -329,10 +329,14 @@ void iommu_init_early_dart(void)
void __init alloc_dart_table(void)
{
- /* Only reserve DART space if machine has more than 2GB of RAM
+ /* Only reserve DART space if machine has more than 1GB of RAM
* or if requested with iommu=on on cmdline.
+ *
+ * 1GB of RAM is picked as limit because some default devices
+ * (i.e. Airport Extreme) have 30 bit address range limits.
*/
- if (lmb_end_of_DRAM() <= 0x80000000ull && !iommu_force_on)
+
+ if (lmb_end_of_DRAM() <= 0x40000000ull && !iommu_force_on)
return;
/* 512 pages (2MB) is max DART tablesize. */
^ permalink raw reply
* [PATCH] [1/2] POWERPC: IOMMU support for honoring dma_mask
From: Olof Johansson @ 2006-04-13 2:05 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Hi,
Paulus -- Ben mentioned being interested in this going into 2.6.17,
since the bcm43xx driver will need it to be usable on G5s with more than
1GB memory.
Built with iseries_defconfig and ppc64_defconfig, boot tested on pSeries
and G5, but I'm away from home so I haven't been able to install an
Airport card in the G5.
Since time is somewhat of essense (if 2.6.17 is still an option), I went
for the choice of sending now and follow up with a small bugfix later
in case something shows up, especially since quick regression tests seem
ok.
Thanks,
Olof
---
Some devices don't support full 32-bit DMA address space, which we currently
assume. Add the required mask-passing to the IOMMU allocators.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6/arch/powerpc/kernel/iommu.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/iommu.c
+++ 2.6/arch/powerpc/kernel/iommu.c
@@ -61,6 +61,7 @@ __setup("iommu=", setup_iommu);
static unsigned long iommu_range_alloc(struct iommu_table *tbl,
unsigned long npages,
unsigned long *handle,
+ unsigned long mask,
unsigned int align_order)
{
unsigned long n, end, i, start;
@@ -97,9 +98,21 @@ static unsigned long iommu_range_alloc(s
*/
if (start >= limit)
start = largealloc ? tbl->it_largehint : tbl->it_hint;
-
+
again:
+ if (limit + tbl->it_offset > mask) {
+ limit = mask - tbl->it_offset + 1;
+ /* If we're constrained on address range, first try
+ * at the masked hint to avoid O(n) search complexity,
+ * but on second pass, start at 0.
+ */
+ if ((start & mask) >= limit || pass > 0)
+ start = 0;
+ else
+ start &= mask;
+ }
+
n = find_next_zero_bit(tbl->it_map, limit, start);
/* Align allocation */
@@ -150,14 +163,14 @@ static unsigned long iommu_range_alloc(s
static dma_addr_t iommu_alloc(struct iommu_table *tbl, void *page,
unsigned int npages, enum dma_data_direction direction,
- unsigned int align_order)
+ unsigned long mask, unsigned int align_order)
{
unsigned long entry, flags;
dma_addr_t ret = DMA_ERROR_CODE;
-
+
spin_lock_irqsave(&(tbl->it_lock), flags);
- entry = iommu_range_alloc(tbl, npages, NULL, align_order);
+ entry = iommu_range_alloc(tbl, npages, NULL, mask, align_order);
if (unlikely(entry == DMA_ERROR_CODE)) {
spin_unlock_irqrestore(&(tbl->it_lock), flags);
@@ -236,7 +249,7 @@ static void iommu_free(struct iommu_tabl
int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
struct scatterlist *sglist, int nelems,
- enum dma_data_direction direction)
+ unsigned long mask, enum dma_data_direction direction)
{
dma_addr_t dma_next = 0, dma_addr;
unsigned long flags;
@@ -274,7 +287,7 @@ int iommu_map_sg(struct device *dev, str
vaddr = (unsigned long)page_address(s->page) + s->offset;
npages = PAGE_ALIGN(vaddr + slen) - (vaddr & PAGE_MASK);
npages >>= PAGE_SHIFT;
- entry = iommu_range_alloc(tbl, npages, &handle, 0);
+ entry = iommu_range_alloc(tbl, npages, &handle, mask >> PAGE_SHIFT, 0);
DBG(" - vaddr: %lx, size: %lx\n", vaddr, slen);
@@ -479,7 +492,8 @@ void iommu_free_table(struct device_node
* byte within the page as vaddr.
*/
dma_addr_t iommu_map_single(struct iommu_table *tbl, void *vaddr,
- size_t size, enum dma_data_direction direction)
+ size_t size, unsigned long mask,
+ enum dma_data_direction direction)
{
dma_addr_t dma_handle = DMA_ERROR_CODE;
unsigned long uaddr;
@@ -492,7 +506,8 @@ dma_addr_t iommu_map_single(struct iommu
npages >>= PAGE_SHIFT;
if (tbl) {
- dma_handle = iommu_alloc(tbl, vaddr, npages, direction, 0);
+ dma_handle = iommu_alloc(tbl, vaddr, npages, direction,
+ mask >> PAGE_SHIFT, 0);
if (dma_handle == DMA_ERROR_CODE) {
if (printk_ratelimit()) {
printk(KERN_INFO "iommu_alloc failed, "
@@ -521,7 +536,7 @@ void iommu_unmap_single(struct iommu_tab
* to the dma address (mapping) of the first page.
*/
void *iommu_alloc_coherent(struct iommu_table *tbl, size_t size,
- dma_addr_t *dma_handle, gfp_t flag)
+ dma_addr_t *dma_handle, unsigned long mask, gfp_t flag)
{
void *ret = NULL;
dma_addr_t mapping;
@@ -551,7 +566,8 @@ void *iommu_alloc_coherent(struct iommu_
memset(ret, 0, size);
/* Set up tces to cover the allocated range */
- mapping = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL, order);
+ mapping = iommu_alloc(tbl, ret, npages, DMA_BIDIRECTIONAL,
+ mask >> PAGE_SHIFT, order);
if (mapping == DMA_ERROR_CODE) {
free_pages((unsigned long)ret, order);
ret = NULL;
Index: 2.6/arch/powerpc/kernel/vio.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/vio.c
+++ 2.6/arch/powerpc/kernel/vio.c
@@ -202,7 +202,7 @@ static dma_addr_t vio_map_single(struct
size_t size, enum dma_data_direction direction)
{
return iommu_map_single(to_vio_dev(dev)->iommu_table, vaddr, size,
- direction);
+ ~0ul, direction);
}
static void vio_unmap_single(struct device *dev, dma_addr_t dma_handle,
@@ -216,7 +216,7 @@ static int vio_map_sg(struct device *dev
int nelems, enum dma_data_direction direction)
{
return iommu_map_sg(dev, to_vio_dev(dev)->iommu_table, sglist,
- nelems, direction);
+ nelems, ~0ul, direction);
}
static void vio_unmap_sg(struct device *dev, struct scatterlist *sglist,
@@ -229,7 +229,7 @@ static void *vio_alloc_coherent(struct d
dma_addr_t *dma_handle, gfp_t flag)
{
return iommu_alloc_coherent(to_vio_dev(dev)->iommu_table, size,
- dma_handle, flag);
+ dma_handle, ~0ul, flag);
}
static void vio_free_coherent(struct device *dev, size_t size,
Index: 2.6/include/asm-powerpc/iommu.h
===================================================================
--- 2.6.orig/include/asm-powerpc/iommu.h
+++ 2.6/include/asm-powerpc/iommu.h
@@ -70,17 +70,18 @@ extern void iommu_free_table(struct devi
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl);
extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
- struct scatterlist *sglist, int nelems,
+ struct scatterlist *sglist, int nelems, unsigned long mask,
enum dma_data_direction direction);
extern void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction);
extern void *iommu_alloc_coherent(struct iommu_table *tbl, size_t size,
- dma_addr_t *dma_handle, gfp_t flag);
+ dma_addr_t *dma_handle, unsigned long mask, gfp_t flag);
extern void iommu_free_coherent(struct iommu_table *tbl, size_t size,
void *vaddr, dma_addr_t dma_handle);
extern dma_addr_t iommu_map_single(struct iommu_table *tbl, void *vaddr,
- size_t size, enum dma_data_direction direction);
+ size_t size, unsigned long mask,
+ enum dma_data_direction direction);
extern void iommu_unmap_single(struct iommu_table *tbl, dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction);
Index: 2.6/arch/powerpc/kernel/pci_iommu.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/pci_iommu.c
+++ 2.6/arch/powerpc/kernel/pci_iommu.c
@@ -59,6 +59,25 @@ static inline struct iommu_table *devnod
}
+static inline unsigned long device_to_mask(struct device *hwdev)
+{
+ struct pci_dev *pdev;
+
+ if (!hwdev) {
+ pdev = ppc64_isabridge_dev;
+ if (!pdev) /* This is the best guess we can do */
+ return 0xfffffffful;
+ } else
+ pdev = to_pci_dev(hwdev);
+
+ if (pdev->dma_mask)
+ return pdev->dma_mask;
+
+ /* Assume devices without mask can take 32 bit addresses */
+ return 0xfffffffful;
+}
+
+
/* Allocates a contiguous real buffer and creates mappings over it.
* Returns the virtual address of the buffer and sets dma_handle
* to the dma address (mapping) of the first page.
@@ -67,7 +86,7 @@ static void *pci_iommu_alloc_coherent(st
dma_addr_t *dma_handle, gfp_t flag)
{
return iommu_alloc_coherent(devnode_table(hwdev), size, dma_handle,
- flag);
+ device_to_mask(hwdev), flag);
}
static void pci_iommu_free_coherent(struct device *hwdev, size_t size,
@@ -86,7 +105,7 @@ static dma_addr_t pci_iommu_map_single(s
size_t size, enum dma_data_direction direction)
{
return iommu_map_single(devnode_table(hwdev), vaddr, size,
- direction);
+ device_to_mask(hwdev), direction);
}
@@ -101,7 +120,7 @@ static int pci_iommu_map_sg(struct devic
int nelems, enum dma_data_direction direction)
{
return iommu_map_sg(pdev, devnode_table(pdev), sglist,
- nelems, direction);
+ nelems, device_to_mask(pdev), direction);
}
static void pci_iommu_unmap_sg(struct device *pdev, struct scatterlist *sglist,
@@ -113,7 +132,19 @@ static void pci_iommu_unmap_sg(struct de
/* We support DMA to/from any memory page via the iommu */
static int pci_iommu_dma_supported(struct device *dev, u64 mask)
{
- return 1;
+ struct iommu_table *tbl = devnode_table(dev);
+
+ if (!tbl || tbl->it_offset > mask) {
+ printk(KERN_INFO "Warning: IOMMU table offset too big for device mask\n");
+ if (tbl)
+ printk(KERN_INFO "mask: 0x%08lx, table offset: 0x%08lx\n",
+ mask, tbl->it_offset);
+ else
+ printk(KERN_INFO "mask: 0x%08lx, table unavailable\n",
+ mask);
+ return 0;
+ } else
+ return 1;
}
void pci_iommu_init(void)
^ permalink raw reply
* [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Olof Johansson @ 2006-04-13 2:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060413022809.GD24769@pb15.lixom.net>
On Wed, Apr 12, 2006 at 09:28:09PM -0500, Olof Johansson wrote:
> Hi,
>
> This goes with the previous dma_mask patch -- enable DART at 1GB due to
> Airport Extreme cards needing it. Please consider for 2.6.17.
Crap, I missed a quilt refresh. Here's the version that handles iommu=off
between 1GB and 2GB right.
---
Turn on the DART already at 1GB. This is needed because of crippled
devices in some systems, i.e. Airport Extreme cards, only supporting
30-bit DMA addresses.
Otherwise, users with between 1 and 2GB of memory will need to manually
enable it with iommu=force, and that's no good.
Some simple performance tests show that there's a slight impact of
enabling DART, but it's in the 1-3% range (kernel build with disk I/O
as well as over NFS).
iommu=off can still be used for those who don't want to deal with the
overhead (and don't need it for any devices).
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6/arch/powerpc/sysdev/dart_iommu.c
===================================================================
--- 2.6.orig/arch/powerpc/sysdev/dart_iommu.c
+++ 2.6/arch/powerpc/sysdev/dart_iommu.c
@@ -49,6 +49,7 @@
#include "dart.h"
+extern int iommu_is_off;
extern int iommu_force_on;
/* Physical base address and size of the DART table */
@@ -329,10 +330,17 @@ void iommu_init_early_dart(void)
void __init alloc_dart_table(void)
{
- /* Only reserve DART space if machine has more than 2GB of RAM
+ /* Only reserve DART space if machine has more than 1GB of RAM
* or if requested with iommu=on on cmdline.
+ *
+ * 1GB of RAM is picked as limit because some default devices
+ * (i.e. Airport Extreme) have 30 bit address range limits.
*/
- if (lmb_end_of_DRAM() <= 0x80000000ull && !iommu_force_on)
+
+ if (iommu_is_off)
+ return;
+
+ if (!iommu_force_on && lmb_end_of_DRAM() <= 0x40000000ull)
return;
/* 512 pages (2MB) is max DART tablesize. */
Index: 2.6/arch/powerpc/kernel/prom.c
===================================================================
--- 2.6.orig/arch/powerpc/kernel/prom.c
+++ 2.6/arch/powerpc/kernel/prom.c
@@ -62,7 +62,7 @@ static int __initdata dt_root_addr_cells
static int __initdata dt_root_size_cells;
#ifdef CONFIG_PPC64
-static int __initdata iommu_is_off;
+int __initdata iommu_is_off;
int __initdata iommu_force_on;
unsigned long tce_alloc_start, tce_alloc_end;
#endif
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-13 2:15 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <5148225C-AE27-4365-A1C2-40C46491AF0D@watson.ibm.com>
On Apr 12, 2006, at 10:05 PM, Jimi Xenidis wrote:
>
> NOTE: that the dtc must also not generate the blob reservation
> entry.
This reservation is only generated for "asm" dtc targets so it is
only that case that need to be changed.
> Should we try to detect this redundant entry? Should we bump
> the DT version number?
-JX
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-04-13 5:19 UTC (permalink / raw)
To: Rick Moleres; +Cc: Jeff Gibbons, linuxppc-embedded, Martin, Tim
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C021E5AAA@XCO-EXCHVS1.xlnx.xilinx.com>
On 4/12/06, Rick Moleres <rick.moleres@xilinx.com> wrote:
>
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
Hey cool! Yeah I just found it now. I haven't been following the
list very closely the last month or so. I'll try it out in short
order.
Thanks Rick!
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Paul Nasrat @ 2006-04-13 5:14 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Jon Loeliger, Paul Mackerras
In-Reply-To: <644FB6AC-3702-41D0-A9E2-6FDEC52B819D@freescale.com>
On Wed, 2006-04-12 at 18:19 -0500, Andy Fleming wrote:
> On Mar 28, 2006, at 10:55, Paul Nasrat wrote:
>
> > On Tue, 2006-03-28 at 20:14 +0400, Vitaly Bordug wrote:
> >> + - address : List of bytes representing the ethernet address of
> >> + this controller
> >
> > Umm should we not use local-mac-address and mac-address (and
> > address-bits) as in section 3.7.4 in 1275-1994?
>
>
> So no one chimed in on this. Clearly, 1275 states that it's supposed
> to be local-mac-address or mac-address. We use "address". But I'm
> pretty sure we copied our ethernet node from somewhere else, so which
> one should it be?
Well I'm biased and say we shouldn't reinvent the wheel with dtc if we
don't need to. I've sent Jon a patch to start validating this for dtc
and am waiting feedback before I add additional device_types. So we
should have local-mac-address be preassiged hwaddr and mac-address last
used. For some setups this would be the same persistently, but I can
envisage some non OF setups populating mac-address from the card.
Paul
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Michael Neuling @ 2006-04-13 5:36 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <9B2C87C5-0B69-46E7-B48B-9CDB882836B2@watson.ibm.com>
Hey Jimi,
> > NOTE: that the dtc must also not generate the blob reservation
> > entry.
>
> This reservation is only generated for "asm" dtc targets so it is
> only that case that need to be changed.
The user space kexec tools create a reserve map entry for the blob as
well.
Mikey
^ permalink raw reply
* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Muli Ben-Yehuda @ 2006-04-13 6:40 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20060413025233.GE24769@pb15.lixom.net>
On Wed, Apr 12, 2006 at 09:52:33PM -0500, Olof Johansson wrote:
> iommu=off can still be used for those who don't want to deal with the
> overhead (and don't need it for any devices).
I've been pondering walking the PCI bus before deciding to enable an
IOMMU and checking each device's DMA mask. Is this something that you
considered and rejected, or just something no one got around to doing?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* Re: Freescale 8272ADS configuration
From: Alex Zeffertt @ 2006-04-13 8:36 UTC (permalink / raw)
To: Carlos Munoz; +Cc: linuxppc-embedded
In-Reply-To: <443DA7D9.8090606@kenati.com>
Carlos,
You need to load u-boot using the following BDI2000 config file:
ftp://ftp.denx.de/pub/BDI2000/MPC8260ADS.cfg
u-boot itself needs to be configured with
make MPC8272ADS_config
before it is built.
The kernel needs to be configured with
make ads8272_config && make oldconfig
before it is built.
And most importantly you should read the user manual on
http://www.denx.de/wiki/DULG/Manual
It's a bit 8xx centric but most of it applies to the 82xx as well.
Alex
On Wed, 12 Apr 2006 18:22:33 -0700
Carlos Munoz <carlos@kenati.com> wrote:
> Hi all,
>
> I have a new Freescale 8272ADS board that I need to load uboot and
> linux on. I have read all the documentation that came with the board
> but unfortunately it doesn't explain how to bring up the board from
> scratch. Does anyone know what I need to do to load uboot and linux
> on this board ?
>
> Thanks,
>
>
> Carlos
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Mel Gorman @ 2006-04-13 9:52 UTC (permalink / raw)
To: davej, tony.luck, linuxppc-dev, linux-kernel, bob.picco, ak,
linux-mm
In-Reply-To: <20060412232036.18862.84118.sendpatchset@skynet>
On (13/04/06 00:20), Mel Gorman didst pronounce:
> This is V2 of the patchset. They have been boot tested on x86, ppc64
> and x86_64 but I still need to do a double check that zones are the
> same size before and after the patch on all arches. IA64 passed a
> basic compile-test. a driver program that fed in the values generated
> by IA64 to add_active_range(), zone_present_pages_in_node() and
> zone_absent_pages_in_node() seemed to generate expected values.
I didn't look at the test program output carefully enough! There was a
double counting of some holes because of a missing "if" - obvious in the
morning. Fix is this (applies on top of the debugging patch)
diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-zonesizing-v6/mm/mem_init.c linux-2.6.17-rc1-zonesizing-v7/mm/mem_init.c
--- linux-2.6.17-rc1-zonesizing-v6/mm/mem_init.c 2006-04-13 10:30:50.000000000 +0100
+++ linux-2.6.17-rc1-zonesizing-v7/mm/mem_init.c 2006-04-13 10:37:11.000000000 +0100
@@ -761,9 +761,11 @@ unsigned long __init zone_absent_pages_i
}
/* Update the hole size cound and move on */
- hole_pages += start_pfn - prev_end_pfn;
- printk("Hole found index %d: %lu -> %lu\n",
- i, prev_end_pfn, start_pfn);
+ if (start_pfn > arch_zone_lowest_possible_pfn[zone_type]) {
+ hole_pages += start_pfn - prev_end_pfn;
+ printk("Hole found index %d: %lu -> %lu\n",
+ i, prev_end_pfn, start_pfn);
+ }
prev_end_pfn = early_node_map[i].end_pfn;
}
^ permalink raw reply
* 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Benjamin Herrenschmidt @ 2006-04-13 10:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc
In-Reply-To: <17463.9759.442768.685153@cargo.ozlabs.ibm.com>
(For those who haven't followed the beginning, current git locks up at
boot on most recent powermacs. It was tracked down to a weird problem
with the idle code. My latest experiments seem to show something dodgy
with MSR_POW). Help from Freescale folks would be appreciated.
On Sat, 2006-04-08 at 12:55 +1000, Paul Mackerras wrote:
> This patch fixes it for me on my powerbook (1.5GHz albook). The issue
> seems to be that the cpu objects to HID0_NAP being cleared in HID0.
> If I have this code power_save_6xx_restore, it hangs:
>
> _GLOBAL(power_save_6xx_restore)
> mfspr r11,SPRN_HID0
> rlwinm r11,r11,0,10,8 /* Clear NAP */
> mtspr SPRN_HID0,r11
> b transfer_to_handler_cont
>
> If I take out that rlwinm, it boots. Bizaare.
If you do that, you cause the transfer_to_handler to always call
power_save_6xx_restore even when not coming back from idle.
I did a bit more tracking and it's very strange.... At first, I
discovered that adding a printk after the call to power_save fixed it. I
did all sort of tests and if my memory serves me well, a simple mb()
there will fix it too. In fact, what I noticed is that if I do
if (mfmsr() & MSR_POW)
printk("GACK !\n");
After calling ppc_md.power_save() and before local_irq_enable(), it does
trigger ! But with an mb() just before, it doesn't. In fact, you don't
need an mb()... all you need is another mfmsr(). Thus a dummy msmsr()
"fixes" the stale MSR_POW in there.
That is very dodgy. Looks like we get a stale MSR_POW upon return from
the exception that interrupted sleep, causing the next
local_irq_enable() to block forever.
The next question is how does it get there... my idea at first was that
we get MSR_POW in SRR1 in that exception and put it back in with rfi
(and the CPU gets it that way instead of ignoring it). Sounds like a
lovely explanation if we also add that a sync or an mfmsr "clears" this
weird condition. However, I added clearing of MSR_POW in r9 in
EXCEPTION_PROLOG_2() and it didn't fix it (but maybe I did something
wrong, I was tired).
I can't see right now why your hack to the restore code seems to fix it
as well... it should only cause us to do dodgy things on every exception
return path.
I have to go to bed now, maybe somebody will have found more useful data
by the time I wakeup ;) In the meantime, adding an mfmsr at the end of
idle_6xx might do the trick. Paul, we should check if MSR_POW is
supposed to be mirrored in SRR1... if it is, we can simplify/optimize
the code in transfer_to_handler to not load HID0 all the time. Also, we
should merge some of your other cleanups of the restore from idle in all
cases.
Ben.
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Mel Gorman @ 2006-04-13 10:24 UTC (permalink / raw)
To: Andi Kleen
Cc: davej, tony.luck, linuxppc-dev, Linux Kernel Mailing List,
bob.picco, Linux Memory Management List
In-Reply-To: <200604130257.00203.ak@suse.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5427 bytes --]
On Thu, 13 Apr 2006, Andi Kleen wrote:
> On Thursday 13 April 2006 02:22, Mel Gorman wrote:
>
>> I experimented with the idea of all architectures sharing the struct
>> node_active_region rather than storing the information twice. It got very
>> messy, particularly for x86 because it needs to store more than nid,
>> start_pfn and end_pfn for a range of page frames (see node_memory_chunk_s
>> in arch/i386/kernel/srat.c). Worse, some architecture-specific code
>> remembers the ranges of active memory as addresses and others as pfn's. In
>> the end, I was not too worried about having the information in two places,
>> because the active ranges are kept in __initdata and gets freed.
>
> The problem is not memory consumption but complexity of code/data structures.
The architecture-independent code is simpler than i386's SRAT messing,
about the same complexity as ppcs dealings with LMB (in fact, much of the
code is lifted from ppc) and comparable in complexity to what IA64 does.
For x86_64, there is less architecture-specific code that has to be
understood.
> Keeping information in two places is usually a good cue that something
> is wrong. This code is also fragile and hard to test.
>
At minimum, it requires a boot test - not that massive a burden. For the
active, a look at the value of the zones before and after the patches.
To test architectures that register PFNs in unexpected ways that I don't
have a test machine for (like IA64), I wrote the attached test program. It
was a simply case of
1. Few #defines to pretend it's compiled in-kernel
2. Cut and paste from the architecture-independent code in mem_init.c to
the driver program
3. Pass in sample input from main() and see what pops out
It caught a number of simple bugs (including one this morning) without
having to even boot a machine. The same type of testing is hard with the
architecture specific code. This is sample output of the driver program
handing PFN ranges supplied by IA64;
mel@joshua:~/tmp$ gcc driver_test.c -o driver_test && ./driver_test | grep
-v "active with no"
Stage 1: Registering active ranges
add_active_range(0, 0, 4096): New
add_active_range(0, 0, 131072): Merging forward
add_active_range(0, 0, 131072): Merging backwards
add_active_range(0, 393216, 523264): New
add_active_range(0, 393216, 523264): Merging backwards
add_active_range(0, 393216, 524288): Merging forward
add_active_range(0, 393216, 524288): Merging backwards
Stage 2: Calculating zone sizes and holes
Hole found zone 1 index 1: 131072 -> 393216
Stage 3: Dumping zone sizes and holes
zone_size[0][0] = 131020 zone_holes[0][0] = 0
zone_size[0][1] = 393268 zone_holes[0][1] = 262144
Stage 4: Printing present pages
On node 0, 262144 pages
zone 0 present_pages = 131020
zone 1 present_pages = 131124
So, testing is not that hard.
How is the code fragile? Even *if* it is fragile, it only has to be fixed
once to benefit any architecture using the code path.
>> I'll admit that for x86_64, the entire code path for initialisation (i.e.
>> architecture specific and architecture independent paths) is now more
>> complex. The architecture independent code needed to be able to handle
>> every variety of node layout which is overkill for x86_64. Nevertheless,
>> without size_zones(), I thought the architecture-specific code for x86_64
>> memory initialisation was a bit easier to read. With
>> architecture-independent zone size and hole calculation, you only have to
>> understand the relevant code once, not once for each architecture.
>
>
> I think i386 SRAT NUMA should be just removed at some point - it never
> worked all that well and is quite complicated.
Assuming you mean the code, are these patches not a readable replacement?
> That leaves IA64, x86-64
> and ppc64. I suspect keeping the code there near their low level
> data structures is better.
>
For PPC64, the architecture-independent representation *is* the only copy
(which is why 128 arch-specific LOC were deleted for ppc including a
stryct init_node_data array of nids, start_pfns and end_pfns). IA64's low
level representation uses addresses, not pfns, so having only one copy
would be a very invasive patch which is not a good idea without a test
box.
In many cases, the low-level representation between architectures is
similar. The representation I use is the common elements all the
architectures need - nid, start_pfn, end_pfn.
>>> I have my doubts that is really a improvement over the old state.
>>>
>>
>> For x86_64 in isolation or the entire set of patches?
>
> For x86-64/i386. I haven't read the other architectures.
>
ok.
>>> I think it would be better if you just defined some simple "library functions"
>>> that can be called from the architecture specific code instead of adding
>>> all this new high level code.
>>>
>>
>> What sort of library functions would you recommend? x86_64 uses
>> add_active_range() and free_area_init_nodes() from this patchset which
>> seemed fairly straight-forward.
>
> e.g. a generic size_zones(). Possibly some others.
>
For a generic size_zones(), one would need an architecture independent way
to pass in active page frame ranges and what node they are on. So we end
up with code very similar to what I've posted.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
[-- Attachment #2: driver_test.c --]
[-- Type: TEXT/x-csrc, Size: 9413 bytes --]
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define ZONE_DMA 0
#define ZONE_NORMAL 1
#define printk(x, args...) printf(x, ## args)
#define BUG(x) do { printf("BUG AT %d\n", __LINE__); } while (0)
#define BUG_ON(x) do { if (x) BUG(); } while (0)
#define __init
#define __initdata
#define KERN_WARNING
#define KERN_ERR
#define MAX_NR_NODES 32
#define MAX_NR_ZONES 5
struct node_active_region {
unsigned long start_pfn;
unsigned long end_pfn;
int nid;
};
#define MAX_ACTIVE_REGIONS (MAX_NR_NODES * MAX_NR_ZONES)
struct node_active_region __initdata early_node_map[MAX_ACTIVE_REGIONS];
unsigned long __initdata arch_zone_lowest_possible_pfn[MAX_NR_ZONES];
unsigned long __initdata arch_zone_highest_possible_pfn[MAX_NR_ZONES];
static int __init first_active_region_index_in_nid(int nid)
{
int i;
for (i = 0; early_node_map[i].end_pfn; i++) {
if (early_node_map[i].nid == nid)
return i;
}
return MAX_ACTIVE_REGIONS;
}
static int __init next_active_region_index_in_nid(unsigned int index, int nid)
{
for (index = index + 1; early_node_map[index].end_pfn; index++) {
if (early_node_map[index].nid == nid)
return index;
}
return MAX_ACTIVE_REGIONS;
}
#ifndef CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
int __init early_pfn_to_nid(unsigned long pfn)
{
int i;
for (i = 0; early_node_map[i].end_pfn; i++) {
unsigned long start_pfn = early_node_map[i].start_pfn;
unsigned long end_pfn = early_node_map[i].end_pfn;
if ((start_pfn <= pfn) && (pfn < end_pfn))
return early_node_map[i].nid;
}
return -1;
}
#endif
#define for_each_active_range_index_in_nid(i, nid) \
for (i = first_active_region_index_in_nid(nid); \
i != MAX_ACTIVE_REGIONS; \
i = next_active_region_index_in_nid(i, nid))
void __init get_pfn_range_for_nid(unsigned int nid,
unsigned long *start_pfn, unsigned long *end_pfn)
{
unsigned int i;
*start_pfn = -1UL;
*end_pfn = 0;
for_each_active_range_index_in_nid(i, nid) {
if (early_node_map[i].start_pfn < *start_pfn)
*start_pfn = early_node_map[i].start_pfn;
if (early_node_map[i].end_pfn > *end_pfn)
*end_pfn = early_node_map[i].end_pfn;
}
if (*start_pfn == -1UL) {
printk(KERN_WARNING "Node %u active with no memory\n", nid);
*start_pfn = 0;
}
}
unsigned long __init zone_present_pages_in_node(int nid,
unsigned long zone_type,
unsigned long *ignored)
{
unsigned long node_start_pfn, node_end_pfn;
unsigned long zone_start_pfn, zone_end_pfn;
/* Get the start and end of the node and zone */
get_pfn_range_for_nid(nid, &node_start_pfn, &node_end_pfn);
zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type];
zone_end_pfn = arch_zone_highest_possible_pfn[zone_type];
/* Check that this node has pages within the zone's required range */
if (zone_end_pfn < node_start_pfn || zone_start_pfn > node_end_pfn)
return 0;
/* Move the zone boundaries inside the node if necessary */
if (zone_end_pfn > node_end_pfn)
zone_end_pfn = node_end_pfn;
if (zone_start_pfn < node_start_pfn)
zone_start_pfn = node_start_pfn;
/* Return the spanned pages */
return zone_end_pfn - zone_start_pfn;
}
unsigned long __init zone_absent_pages_in_node(int nid,
unsigned long zone_type,
unsigned long *ignored)
{
int i = 0;
unsigned long prev_end_pfn = 0, hole_pages = 0;
unsigned long start_pfn;
/* Find the end_pfn of the first active range of pfns in the node */
i = first_active_region_index_in_nid(nid);
prev_end_pfn = early_node_map[i].start_pfn;
/* Find all holes for the zone within the node */
for (; i != MAX_ACTIVE_REGIONS;
i = next_active_region_index_in_nid(i, nid)) {
/* No need to continue if prev_end_pfn is outside the zone */
if (prev_end_pfn >= arch_zone_highest_possible_pfn[zone_type])
break;
/* Make sure the end of the zone is not within the hole */
start_pfn = early_node_map[i].start_pfn;
if (start_pfn > arch_zone_highest_possible_pfn[zone_type])
start_pfn = arch_zone_highest_possible_pfn[zone_type];
if (prev_end_pfn > start_pfn) {
printk("prev_end > start_pfn : %lu > %lu\n",
prev_end_pfn,
start_pfn);
BUG();
}
/* Update the hole size cound and move on */
if (start_pfn > arch_zone_lowest_possible_pfn[zone_type]) {
hole_pages += start_pfn - prev_end_pfn;
printk("Hole found zone %lu index %d: %lu -> %lu\n",
zone_type, i, prev_end_pfn, start_pfn);
}
prev_end_pfn = early_node_map[i].end_pfn;
}
return hole_pages;
}
void __init add_active_range(unsigned int nid, unsigned long start_pfn,
unsigned long end_pfn)
{
unsigned int i;
printk("add_active_range(%d, %lu, %lu): ",
nid, start_pfn, end_pfn);
/* Merge with existing active regions if possible */
for (i = 0; early_node_map[i].end_pfn; i++) {
if (early_node_map[i].nid != nid)
continue;
/* Merge forward if suitable */
if (start_pfn <= early_node_map[i].end_pfn &&
end_pfn > early_node_map[i].end_pfn) {
printk("Merging forward\n");
early_node_map[i].end_pfn = end_pfn;
return;
}
/* Merge backward if suitable */
if (start_pfn < early_node_map[i].end_pfn &&
end_pfn >= early_node_map[i].start_pfn) {
printk("Merging backwards\n");
early_node_map[i].start_pfn = start_pfn;
return;
}
}
/*
* Leave last entry NULL so we dont iterate off the end (we use
* entry.end_pfn to terminate the walk).
*/
if (i >= MAX_ACTIVE_REGIONS - 1) {
printk(KERN_ERR "WARNING: too many memory regions in "
"numa code, truncating\n");
return;
}
printk("New\n");
early_node_map[i].nid = nid;
early_node_map[i].start_pfn = start_pfn;
early_node_map[i].end_pfn = end_pfn;
}
unsigned long __init find_min_pfn(void)
{
int i;
unsigned long min_pfn = -1UL;
for (i = 0; early_node_map[i].end_pfn; i++) {
if (early_node_map[i].start_pfn < min_pfn)
min_pfn = early_node_map[i].start_pfn;
}
return min_pfn;
}
/* Find the lowest pfn in a node. This depends on a sorted early_node_map */
unsigned long __init find_start_pfn_for_node(unsigned long nid)
{
int i;
/* Assuming a sorted map, the first range found has the starting pfn */
for_each_active_range_index_in_nid(i, nid) {
return early_node_map[i].start_pfn;
}
/* nid does not exist in early_node_map */
printk(KERN_WARNING "Could not find start_pfn for node %lu\n", nid);
return 0;
}
int main()
{
unsigned long zone_size[MAX_NR_NODES][MAX_NR_ZONES];
unsigned long zone_holes[MAX_NR_NODES][MAX_NR_ZONES];
unsigned long node_present[MAX_NR_NODES];
unsigned long start_pfn, end_pfn;
int i, j;
/* init */
memset(early_node_map, 0, sizeof(early_node_map));
memset(zone_size, 0, sizeof(zone_size));
memset(zone_holes, 0, sizeof(zone_holes));
memset(node_present, 0, sizeof(node_present));
printk("Stage 1: Registering active ranges\n");
/* Test Case: IA64 flatmem with VIRT_MEM_MAP=y */
/*
add_active_range(0, 1024, 130688);
add_active_range(0, 130984, 131020);
add_active_range(0, 393216, 524164);
add_active_range(0, 524192, 524269);
*/
/* Test Case: IA64 generic kernel */
add_active_range(0, 0, 4096);
add_active_range(0, 0, 131072);
add_active_range(0, 0, 131072);
add_active_range(0, 393216, 523264);
add_active_range(0, 393216, 523264);
add_active_range(0, 393216, 524288);
add_active_range(0, 393216, 524288);
/* Test Case: Simple PPC64 LMB */
/*
add_active_range(0, 0, 100);
add_active_range(0, 100, 200);
add_active_range(0, 200, 300);
add_active_range(1, 1000, 2000);
add_active_range(1, 500, 1000);
*/
/* Test Case: PPC64 with interleving nodes and holes*/
/*
add_active_range(0, 0, 100);
add_active_range(0, 200, 300);
add_active_range(1, 100, 200);
add_active_range(0, 500, 1000);
*/
/* IA64 zone pfn ranges */
arch_zone_lowest_possible_pfn[ZONE_DMA] = 0;
arch_zone_highest_possible_pfn[ZONE_DMA] = 131020;
arch_zone_lowest_possible_pfn[ZONE_NORMAL] = arch_zone_highest_possible_pfn[ZONE_DMA];
arch_zone_highest_possible_pfn[ZONE_NORMAL] = 800000;
/* PPC64 zone pfn ranges */
/*
arch_zone_lowest_possible_pfn[ZONE_DMA] = 0;
arch_zone_highest_possible_pfn[ZONE_DMA] = 131020;
*/
printf("\nStage 2: Calculating zone sizes and holes\n");
for (i = 0; i < MAX_NR_NODES; i++) {
for (j = 0; j < MAX_NR_ZONES; j++) {
zone_size[i][j] = zone_present_pages_in_node(i, j, NULL);
zone_holes[i][j] = zone_absent_pages_in_node(i, j, NULL);
node_present[i] += zone_size[i][j];
node_present[i] -= zone_holes[i][j];
}
}
printf("\nStage 3: Dumping zone sizes and holes\n");
for (i = 0; i < MAX_NR_NODES; i++) {
if (!node_present[i])
continue;
for (j = 0; j < MAX_NR_ZONES; j++) {
if (!zone_size[i][j])
continue;
printf("zone_size[%d][%d] = %8lu zone_holes[%d][%d] = %8lu\n",
i, j, zone_size[i][j], i, j, zone_holes[i][j]);
}
}
printf("\nStage 4: Printing present pages\n");
for (i = 0; i < MAX_NR_NODES; i++) {
if (!node_present[i])
continue;
printf("On node %d, %lu pages\n", i, node_present[i]);
for (j = 0; j < MAX_NR_ZONES; j++) {
if (!zone_size[i][j])
continue;
printf(" zone %d present_pages = %lu\n", j,
zone_size[i][j] - zone_holes[i][j]);
}
}
}
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-13 10:37 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <20060413053614.2648467DE3@ozlabs.org>
On Apr 13, 2006, at 1:36 AM, Michael Neuling wrote:
> Hey Jimi,
>
>>> NOTE: that the dtc must also not generate the blob reservation
>>> entry.
>>
>> This reservation is only generated for "asm" dtc targets so it is
>> only that case that need to be changed.
>
> The user space kexec tools create a reserve map entry for the blob as
> well.
good point, but I thought the kexec tools used dtc, no?
looking passed my own world I see:
- bootx: creates a reservation entry
- iSeries: not reserving the blob at all
-JX
^ permalink raw reply
* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Benjamin Herrenschmidt @ 2006-04-13 10:45 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Olof Johansson, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20060413064027.GH10412@granada.merseine.nu>
On Thu, 2006-04-13 at 09:40 +0300, Muli Ben-Yehuda wrote:
> On Wed, Apr 12, 2006 at 09:52:33PM -0500, Olof Johansson wrote:
>
> > iommu=off can still be used for those who don't want to deal with the
> > overhead (and don't need it for any devices).
>
> I've been pondering walking the PCI bus before deciding to enable an
> IOMMU and checking each device's DMA mask. Is this something that you
> considered and rejected, or just something no one got around to doing?
It would do the trick for airport cards in G5s.. a little bit of OF
walking to find the card.
It won't help with cardbus broadcom's but then, there is currently no G5
with a cardbus adaptor that I know of :) It's possible I suppose to get
a pci<->cardbus adapter but I suppose in that case, we can ignore it ...
Ben.
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Mel Gorman @ 2006-04-13 10:51 UTC (permalink / raw)
To: Yasunori Goto
Cc: davej, tony.luck, Linux Memory Management List, ak, bob.picco,
Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20060413191700.1146.Y-GOTO@jp.fujitsu.com>
On Thu, 13 Apr 2006, Yasunori Goto wrote:
> Ah, my willing patch is here. :-).
> My system, which is Tiger4 with my numa emulation,
> can boot up by this patch.
>
Most excellent! Thanks for testing.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Michael Ellerman @ 2006-04-13 11:07 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <C67D530F-2629-4D6B-986B-0FC7CFE525BF@watson.ibm.com>
On Thu, 2006-04-13 at 06:37 -0400, Jimi Xenidis wrote:
> On Apr 13, 2006, at 1:36 AM, Michael Neuling wrote:
>
> > Hey Jimi,
> >
> >>> NOTE: that the dtc must also not generate the blob reservation
> >>> entry.
> >>
> >> This reservation is only generated for "asm" dtc targets so it is
> >> only that case that need to be changed.
> >
> > The user space kexec tools create a reserve map entry for the blob as
> > well.
> good point, but I thought the kexec tools used dtc, no?
No, but they should.
> looking passed my own world I see:
> - iSeries: not reserving the blob at all
That sounds right. I think having the kernel do it is definitely the
right option.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
^ permalink raw reply
* Re: freescale lite 5200 board and kernel 2.6
From: Domenico Andreoli @ 2006-04-13 10:23 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: massimo.vanetti, linuxppc-embedded
In-Reply-To: <443D7F78.30402@246tNt.com>
On Thu, Apr 13, 2006 at 12:30:16AM +0200, Sylvain Munaut wrote:
> Domenico Andreoli wrote:
> >
> > sometimes kernel prints "eth0: config: auto-negotiation on, 100HDX,
> > 10HDX.", the eth0 is up and everything works.
> >
> > most of the times "eth0: config: auto-negotiation off, No speed/duplex
> > selected?." is instead printed and eth0 seems to not exist.
> >
> > i tend to exclude hw problems, older kernel 2.4.x always succeed in
> > using eth0.
> >
> > is there any way to force eth0 auto-negotiation?
> >
> When it doesn't work, did it detect the phy correctly ?
> Somewhere in the boot sequence it should print something about a LXT971
> being found at some address.
no, it does not, it uses GENERIC. when PHY is detected as LXT971,
network works.
actually this is unrelated with previous runs of kernel 2.4 (as i
stated in some previous post). sometimes PHY is detected correctly,
sometimes is not.
thank you
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Yasunori Goto @ 2006-04-13 10:32 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060413095207.GA4047@skynet.ie>
Ah, my willing patch is here. :-).
My system, which is Tiger4 with my numa emulation,
can boot up by this patch.
Thanks.
> On (13/04/06 00:20), Mel Gorman didst pronounce:
> > This is V2 of the patchset. They have been boot tested on x86, ppc64
> > and x86_64 but I still need to do a double check that zones are the
> > same size before and after the patch on all arches. IA64 passed a
> > basic compile-test. a driver program that fed in the values generated
> > by IA64 to add_active_range(), zone_present_pages_in_node() and
> > zone_absent_pages_in_node() seemed to generate expected values.
>
> I didn't look at the test program output carefully enough! There was a
> double counting of some holes because of a missing "if" - obvious in the
> morning. Fix is this (applies on top of the debugging patch)
>
> diff -rup -X /usr/src/patchset-0.5/bin//dontdiff linux-2.6.17-rc1-zonesizing-v6/mm/mem_init.c linux-2.6.17-rc1-zonesizing-v7/mm/mem_init.c
> --- linux-2.6.17-rc1-zonesizing-v6/mm/mem_init.c 2006-04-13 10:30:50.000000000 +0100
> +++ linux-2.6.17-rc1-zonesizing-v7/mm/mem_init.c 2006-04-13 10:37:11.000000000 +0100
> @@ -761,9 +761,11 @@ unsigned long __init zone_absent_pages_i
> }
>
> /* Update the hole size cound and move on */
> - hole_pages += start_pfn - prev_end_pfn;
> - printk("Hole found index %d: %lu -> %lu\n",
> - i, prev_end_pfn, start_pfn);
> + if (start_pfn > arch_zone_lowest_possible_pfn[zone_type]) {
> + hole_pages += start_pfn - prev_end_pfn;
> + printk("Hole found index %d: %lu -> %lu\n",
> + i, prev_end_pfn, start_pfn);
> + }
> prev_end_pfn = early_node_map[i].end_pfn;
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Yasunori Goto
^ permalink raw reply
* [patch] cell: correctly detect systemsim host
From: Christian Krafft @ 2006-04-13 11:41 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev
Systemsim uses a different compatible property in the device tree.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
---
Index: linux/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux.orig/arch/powerpc/platforms/cell/setup.c
+++ linux/arch/powerpc/platforms/cell/setup.c
@@ -222,10 +222,13 @@ static int __init cell_probe(void)
* more appropriate detection logic
*/
unsigned long root = of_get_flat_dt_root();
- if (!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
- return 0;
+ if (of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
+ return 1;
- return 1;
+ if (of_flat_dt_is_compatible(root, "IBM,CPBW-SystemSim"))
+ return 1;
+
+ return 0;
}
/*
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch] cell: correctly detect systemsim host
From: Arnd Bergmann @ 2006-04-13 11:44 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Christian Krafft, linuxppc-dev
In-Reply-To: <443E38FE.2050304@de.ibm.com>
On Thursday 13 April 2006 13:41, Christian Krafft wrote:
> Systemsim uses a different compatible property in the device tree.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Thanks.
I'm wondering if we should have that upstream, since some
more patches are currently required to run on systemsim
anyway. For now, I'll keep it in my tree.
Arnd <><
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Jimi Xenidis @ 2006-04-13 13:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <1144926434.7777.5.camel@localhost.localdomain>
Actually, is this even an issue? can the LMB handle repeated
reservations?
-JX
On Apr 13, 2006, at 7:07 AM, Michael Ellerman wrote:
> On Thu, 2006-04-13 at 06:37 -0400, Jimi Xenidis wrote:
>> On Apr 13, 2006, at 1:36 AM, Michael Neuling wrote:
>>
>>> Hey Jimi,
>>>
>>>>> NOTE: that the dtc must also not generate the blob reservation
>>>>> entry.
>>>>
>>>> This reservation is only generated for "asm" dtc targets so it is
>>>> only that case that need to be changed.
>>>
>>> The user space kexec tools create a reserve map entry for the
>>> blob as
>>> well.
>> good point, but I thought the kexec tools used dtc, no?
>
> No, but they should.
>
>> looking passed my own world I see:
>> - iSeries: not reserving the blob at all
>
> That sounds right. I think having the kernel do it is definitely the
> right option.
>
> cheers
>
> --
> Michael Ellerman
> IBM OzLabs
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
>
^ permalink raw reply
* Re: [patch][rfc]flattened device tree: Passing a dtb (blob) to Linux.
From: Michael Ellerman @ 2006-04-13 14:34 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <2A70CBD7-4A52-4599-8BEF-6AC633F62C83@watson.ibm.com>
On Thu, 2006-04-13 at 09:19 -0400, Jimi Xenidis wrote:
> Actually, is this even an issue? can the LMB handle repeated
> reservations?
It can, but we were thinking about adding code to check and warn if
reservations overlap, because it usually indicates a bug. Although
that's probably ok in this case, as long as dtc gets fixed eventually.
Another option would be to not warn for identical reservations.
cheers
> On Apr 13, 2006, at 7:07 AM, Michael Ellerman wrote:
>
> > On Thu, 2006-04-13 at 06:37 -0400, Jimi Xenidis wrote:
> >> On Apr 13, 2006, at 1:36 AM, Michael Neuling wrote:
> >>
> >>> Hey Jimi,
> >>>
> >>>>> NOTE: that the dtc must also not generate the blob reservation
> >>>>> entry.
> >>>>
> >>>> This reservation is only generated for "asm" dtc targets so it is
> >>>> only that case that need to be changed.
> >>>
> >>> The user space kexec tools create a reserve map entry for the
> >>> blob as
> >>> well.
> >> good point, but I thought the kexec tools used dtc, no?
> >
> > No, but they should.
> >
> >> looking passed my own world I see:
> >> - iSeries: not reserving the blob at all
> >
> > That sounds right. I think having the kernel do it is definitely the
> > right option.
> >
> > cheers
> >
> > --
> > Michael Ellerman
> > IBM OzLabs
> >
> > wwweb: http://michael.ellerman.id.au
> > phone: +61 2 6212 1183 (tie line 70 21183)
> >
> > We do not inherit the earth from our ancestors,
> > we borrow it from our children. - S.M.A.R.T Person
> >
>
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
^ permalink raw reply
* RE: NAND and JFFS2 supports in Linux 2.4
From: Laurent Lagrange @ 2006-04-13 14:49 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1144790375.3659.3.camel@yoda.jdub.homelinux.org>
Hello
> -----Message d'origine-----
> De : Josh Boyer
> > Linux 2.4.18 or 2.4.25 do not support this device,
> Those are entire too old.
Except for some customers which must maintain kernels during many years :-)
> > Linux 2.4.31 seems supporting this device but JFFS2 is not adapted,
> NAND + JFFS2 + 2.4 is not a supported combination.
That's the problem i am facing with.
> > Linux 2.4.32 does not support this device anymore.
> Odd. Do you have a diff from .31 to .32?
Not a diff but
1) in Linux 2.4.32, I have the following files :
Config.in diskonchip.c nand_bbt.c rtc_from4.c tx4925ndfmc.c
Makefile edb7312.c nand_ecc.c s3c2410.c tx4938ndfmc.c
Makefile.common h1910.c nand_ids.c sharpsl.c*
au1550nd.c nand.c nandsim.c spia.c
autcpu12.c nand_base.c ppchameleonevb.c toto.c
$Id: nand_ids.c,v 1.12 2005/02/16 09:33:27 gleixner Exp $
2) in Linux 2.4.32, I just have the following files :
autcpu12.c edb7312.c nand.c nand_ids.c
Config.in Makefile nand_ecc.c spia.c
with a very old nand_ids.c.
$Id: nand_ids.c,v 1.1 2002/12/02 22:06:04 gleixner Exp $
> > On www.linux-mtd.infradead.org, it seems that Linux 2.4 is no more
supported.
> Well, 2.4 is supported but no new features go in that tree. Including
> NAND support in JFFS2. If there is a bug in the 2.4 code that is
> present in MTD/JFFS2 it can certainly still be fixed.
OK
> > Any help would be welcome
> You might try your luck with patching the latest 2.4 kernel with MTD
> CVS. But be warned that quite a few things have changed, so
> you'd have to essentially backport.
> And keep in mind that it's not supported.
Yes, I saw that many things have changed and are not be easily backported.
I checked the MTD CVS. All that I found are in the Linux kernel 2.4.31 or
2.6.x.
> -----Message d'origine-----
> De : Jaap-Jan Boor
> Take a look at the 2.4 http://www.denx.de kernel, it has NAND
> and jffs2 support.
Thanks but, I retreived the same files than in the other kernels.
Thanks again for your ideas
I will see what I can do
Bye
Laurent
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL CPM2 device tree node documentation
From: Jon Loeliger @ 2006-04-13 15:15 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1144905296.29397.40.camel@enki.eridu>
So, like, the other day Paul Nasrat mumbled:
>
> Well I'm biased and say we shouldn't reinvent the wheel with dtc if we
> don't need to. I've sent Jon a patch to start validating this for dtc
> and am waiting feedback before I add additional device_types.
What other device_types do you want to check?
> So we
> should have local-mac-address be preassiged hwaddr and mac-address last
> used. For some setups this would be the same persistently, but I can
> envisage some non OF setups populating mac-address from the card.
I'm sitting at a conference right now. I'll slate
some time for looking into it early next week.
jdl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox