* [PATCH 5/5] Have ia64 use add_active_range() and free_area_init_nodes
From: Mel Gorman @ 2006-06-06 13:48 UTC (permalink / raw)
To: akpm
Cc: davej, tony.luck, linuxppc-dev, Mel Gorman, linux-kernel,
bob.picco, ak, linux-mm
In-Reply-To: <20060606134710.21419.48239.sendpatchset@skynet.skynet.ie>
Size zones and holes in an architecture independent manner for ia64.
arch/ia64/Kconfig | 3 ++
arch/ia64/mm/contig.c | 60 +++++-----------------------------------
arch/ia64/mm/discontig.c | 41 ++++-----------------------
arch/ia64/mm/init.c | 12 ++++++++
include/asm-ia64/meminit.h | 1
5 files changed, 30 insertions(+), 87 deletions(-)
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Bob Picco <bob.picco@hp.com>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/Kconfig linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/Kconfig
--- linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/Kconfig 2006-06-05 14:12:48.000000000 +0100
+++ linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/Kconfig 2006-06-05 14:17:47.000000000 +0100
@@ -353,6 +353,9 @@ config NODES_SHIFT
MAX_NUMNODES will be 2^(This value).
If in doubt, use the default.
+config ARCH_POPULATES_NODE_MAP
+ def_bool y
+
# VIRTUAL_MEM_MAP and FLAT_NODE_MEM_MAP are functionally equivalent.
# VIRTUAL_MEM_MAP has been retained for historical reasons.
config VIRTUAL_MEM_MAP
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/mm/contig.c linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/mm/contig.c
--- linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/mm/contig.c 2006-06-05 14:12:48.000000000 +0100
+++ linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/mm/contig.c 2006-06-05 14:17:47.000000000 +0100
@@ -26,10 +26,6 @@
#include <asm/sections.h>
#include <asm/mca.h>
-#ifdef CONFIG_VIRTUAL_MEM_MAP
-static unsigned long num_dma_physpages;
-#endif
-
/**
* show_mem - display a memory statistics summary
*
@@ -210,18 +206,6 @@ count_pages (u64 start, u64 end, void *a
return 0;
}
-#ifdef CONFIG_VIRTUAL_MEM_MAP
-static int
-count_dma_pages (u64 start, u64 end, void *arg)
-{
- unsigned long *count = arg;
-
- if (start < MAX_DMA_ADDRESS)
- *count += (min(end, MAX_DMA_ADDRESS) - start) >> PAGE_SHIFT;
- return 0;
-}
-#endif
-
/*
* Set up the page tables.
*/
@@ -230,47 +214,24 @@ void __init
paging_init (void)
{
unsigned long max_dma;
- unsigned long zones_size[MAX_NR_ZONES];
#ifdef CONFIG_VIRTUAL_MEM_MAP
- unsigned long zholes_size[MAX_NR_ZONES];
+ unsigned long nid = 0;
unsigned long max_gap;
#endif
- /* initialize mem_map[] */
-
- memset(zones_size, 0, sizeof(zones_size));
-
num_physpages = 0;
efi_memmap_walk(count_pages, &num_physpages);
max_dma = virt_to_phys((void *) MAX_DMA_ADDRESS) >> PAGE_SHIFT;
#ifdef CONFIG_VIRTUAL_MEM_MAP
- memset(zholes_size, 0, sizeof(zholes_size));
-
- num_dma_physpages = 0;
- efi_memmap_walk(count_dma_pages, &num_dma_physpages);
-
- if (max_low_pfn < max_dma) {
- zones_size[ZONE_DMA] = max_low_pfn;
- zholes_size[ZONE_DMA] = max_low_pfn - num_dma_physpages;
- } else {
- zones_size[ZONE_DMA] = max_dma;
- zholes_size[ZONE_DMA] = max_dma - num_dma_physpages;
- if (num_physpages > num_dma_physpages) {
- zones_size[ZONE_NORMAL] = max_low_pfn - max_dma;
- zholes_size[ZONE_NORMAL] =
- ((max_low_pfn - max_dma) -
- (num_physpages - num_dma_physpages));
- }
- }
-
max_gap = 0;
+ efi_memmap_walk(register_active_ranges, &nid);
efi_memmap_walk(find_largest_hole, (u64 *)&max_gap);
if (max_gap < LARGE_GAP) {
vmem_map = (struct page *) 0;
- free_area_init_node(0, NODE_DATA(0), zones_size, 0,
- zholes_size);
+ free_area_init_nodes(max_dma, max_dma,
+ max_low_pfn, max_low_pfn);
} else {
unsigned long map_size;
@@ -282,19 +243,14 @@ paging_init (void)
efi_memmap_walk(create_mem_map_page_table, NULL);
NODE_DATA(0)->node_mem_map = vmem_map;
- free_area_init_node(0, NODE_DATA(0), zones_size,
- 0, zholes_size);
+ free_area_init_nodes(max_dma, max_dma,
+ max_low_pfn, max_low_pfn);
printk("Virtual mem_map starts at 0x%p\n", mem_map);
}
#else /* !CONFIG_VIRTUAL_MEM_MAP */
- if (max_low_pfn < max_dma)
- zones_size[ZONE_DMA] = max_low_pfn;
- else {
- zones_size[ZONE_DMA] = max_dma;
- zones_size[ZONE_NORMAL] = max_low_pfn - max_dma;
- }
- free_area_init(zones_size);
+ add_active_range(0, 0, max_low_pfn);
+ free_area_init_nodes(max_dma, max_dma, max_low_pfn, max_low_pfn);
#endif /* !CONFIG_VIRTUAL_MEM_MAP */
zero_page_memmap_ptr = virt_to_page(ia64_imva(empty_zero_page));
}
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/mm/discontig.c linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/mm/discontig.c
--- linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/mm/discontig.c 2006-06-05 14:12:48.000000000 +0100
+++ linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/mm/discontig.c 2006-06-05 14:17:47.000000000 +0100
@@ -703,6 +703,7 @@ static __init int count_node_pages(unsig
{
unsigned long end = start + len;
+ add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
mem_data[node].num_physpages += len >> PAGE_SHIFT;
if (start <= __pa(MAX_DMA_ADDRESS))
mem_data[node].num_dma_physpages +=
@@ -727,9 +728,8 @@ static __init int count_node_pages(unsig
void __init paging_init(void)
{
unsigned long max_dma;
- unsigned long zones_size[MAX_NR_ZONES];
- unsigned long zholes_size[MAX_NR_ZONES];
unsigned long pfn_offset = 0;
+ unsigned long max_pfn = 0;
int node;
max_dma = virt_to_phys((void *) MAX_DMA_ADDRESS) >> PAGE_SHIFT;
@@ -746,47 +746,18 @@ void __init paging_init(void)
#endif
for_each_online_node(node) {
- memset(zones_size, 0, sizeof(zones_size));
- memset(zholes_size, 0, sizeof(zholes_size));
-
num_physpages += mem_data[node].num_physpages;
-
- if (mem_data[node].min_pfn >= max_dma) {
- /* All of this node's memory is above ZONE_DMA */
- zones_size[ZONE_NORMAL] = mem_data[node].max_pfn -
- mem_data[node].min_pfn;
- zholes_size[ZONE_NORMAL] = mem_data[node].max_pfn -
- mem_data[node].min_pfn -
- mem_data[node].num_physpages;
- } else if (mem_data[node].max_pfn < max_dma) {
- /* All of this node's memory is in ZONE_DMA */
- zones_size[ZONE_DMA] = mem_data[node].max_pfn -
- mem_data[node].min_pfn;
- zholes_size[ZONE_DMA] = mem_data[node].max_pfn -
- mem_data[node].min_pfn -
- mem_data[node].num_dma_physpages;
- } else {
- /* This node has memory in both zones */
- zones_size[ZONE_DMA] = max_dma -
- mem_data[node].min_pfn;
- zholes_size[ZONE_DMA] = zones_size[ZONE_DMA] -
- mem_data[node].num_dma_physpages;
- zones_size[ZONE_NORMAL] = mem_data[node].max_pfn -
- max_dma;
- zholes_size[ZONE_NORMAL] = zones_size[ZONE_NORMAL] -
- (mem_data[node].num_physpages -
- mem_data[node].num_dma_physpages);
- }
-
pfn_offset = mem_data[node].min_pfn;
#ifdef CONFIG_VIRTUAL_MEM_MAP
NODE_DATA(node)->node_mem_map = vmem_map + pfn_offset;
#endif
- free_area_init_node(node, NODE_DATA(node), zones_size,
- pfn_offset, zholes_size);
+ if (mem_data[node].max_pfn > max_pfn)
+ max_pfn = mem_data[node].max_pfn;
}
+ free_area_init_nodes(max_dma, max_dma, max_pfn, max_pfn);
+
zero_page_memmap_ptr = virt_to_page(ia64_imva(empty_zero_page));
}
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/mm/init.c linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/mm/init.c
--- linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/arch/ia64/mm/init.c 2006-06-05 14:12:48.000000000 +0100
+++ linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/arch/ia64/mm/init.c 2006-06-05 14:17:47.000000000 +0100
@@ -539,6 +539,18 @@ find_largest_hole (u64 start, u64 end, v
last_end = end;
return 0;
}
+
+int __init
+register_active_ranges(u64 start, u64 end, void *nid)
+{
+ BUG_ON(nid == NULL);
+ BUG_ON(*(unsigned long *)nid >= MAX_NUMNODES);
+
+ add_active_range(*(unsigned long *)nid,
+ __pa(start) >> PAGE_SHIFT,
+ __pa(end) >> PAGE_SHIFT);
+ return 0;
+}
#endif /* CONFIG_VIRTUAL_MEM_MAP */
static int __init
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/include/asm-ia64/meminit.h linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/include/asm-ia64/meminit.h
--- linux-2.6.17-rc5-mm3-104-x86_64_use_init_nodes/include/asm-ia64/meminit.h 2006-06-05 14:12:51.000000000 +0100
+++ linux-2.6.17-rc5-mm3-105-ia64_use_init_nodes/include/asm-ia64/meminit.h 2006-06-05 14:17:47.000000000 +0100
@@ -55,6 +55,7 @@ extern void efi_memmap_init(unsigned lon
extern unsigned long vmalloc_end;
extern struct page *vmem_map;
extern int find_largest_hole (u64 start, u64 end, void *arg);
+ extern int register_active_ranges (u64 start, u64 end, void *arg);
extern int create_mem_map_page_table (u64 start, u64 end, void *arg);
#endif
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/8] snd-aoa: add i2sbus
From: Takashi Iwai @ 2006-06-06 14:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <1149592647.5928.49.camel@johannes.berg>
At Tue, 06 Jun 2006 13:17:27 +0200,
Johannes Berg wrote:
>
> On Fri, 2006-06-02 at 16:23 +0200, Takashi Iwai wrote:
> > > + if (I2S_CLOCK_SPEED_18MHz % rate == 0) {
> > > + if ((I2S_CLOCK_SPEED_18MHz / rate) % mclk == 0) {
> >
> > Equivalent with "I2S_CLOCK_SPEED_18MHZ % (rate * mclk) == 0" ?
>
> Yeah, I guess, never really thought about that, just wrote it down the
> way I thought to do it :) That said, I think it's more readable if
> written that way, do you want me to change it regardless?
I found a single if is more readable (and good for compiler).
> > > + /* well, we really should support scatter/gather DMA */
> > > + /* FIXME FIXME FIXME: If this fails, we BUG() when the alsa layer
> > > + * later tries to allocate memory. Apparently we should be setting
> > > + * some device pointer for that ...
> > > + */
> > > + snd_pcm_lib_preallocate_pages_for_all(
> > > + dev->pcm, SNDRV_DMA_TYPE_DEV,
> > > + snd_dma_pci_data(macio_get_pci_dev(i2sdev->macio)),
> > > + 64 * 1024, 64 * 1024);
> >
> > Is the comment true? Yes, you have to set the device pointer via
> > snd_pcm_lib_preallocate*(). But it must be OK even if preallocate
> > fails.
>
> Hah, I don't know actually, I didn't know you set the pointer using this
> function, when I wrote the comment I just had forgotten the preallocate
> call!
> Does that mean that _preallocate_pages_for_all() has the side effect of
> setting the pointer? If so, imho that's pretty bad.
No, the only requirement is that you have to call snd_pcm_lib_malloc()
with proper type and assigned device pointer if you use
snd_pcm_lib_malloc() function. (If not called, you've got an error
when compiled with debug option.)
Takashi
^ permalink raw reply
* [PATCH 1/2] powerpc: implement pcibus_to_node and pcibus_to_cpumask
From: Christoph Hellwig @ 2006-06-06 14:09 UTC (permalink / raw)
To: linuxppc-dev
On 64bit powerpc we can find out what node a pci bus hangs off, so
implement the topology.h macros that export this information.
For 32bit this seems a little more difficult, but I don't know of 32bit
powerpc NUMA machines either, so let's leave it out for now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/include/asm-powerpc/topology.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/topology.h 2006-05-02 16:26:14.000000000 +0200
+++ linux-2.6/include/asm-powerpc/topology.h 2006-05-30 14:42:18.000000000 +0200
@@ -32,8 +32,13 @@
int of_node_to_nid(struct device_node *device);
+#ifdef CONFIG_PPC64
+#define pcibus_to_node(bus) (of_node_to_nid(bus->sysdata))
+#define pcibus_to_cpumask(bus) (node_to_cpumask(of_node_to_nid(bus->sysdata)))
+#else
#define pcibus_to_node(node) (-1)
#define pcibus_to_cpumask(bus) (cpu_online_map)
+#endif
/* sched_domains SD_NODE_INIT for PPC64 machines */
#define SD_NODE_INIT (struct sched_domain) { \
^ permalink raw reply
* [PATCH 2/2] powerpc: node-away dma allocations
From: Christoph Hellwig @ 2006-06-06 14:11 UTC (permalink / raw)
To: linuxppc-dev
Make sure dma_alloc_coherent allocates memory from the local node. This
is important on Cell where we avoid going through the slow cpu
interconnect.
Note: I could only test this patch on Cell, it should be verified on
some pseries machine by thos that have the hardware.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/powerpc/kernel/iommu.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/iommu.c 2006-04-25 15:53:07.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/iommu.c 2006-05-30 14:54:25.000000000 +0200
@@ -536,11 +536,12 @@
* 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, unsigned long mask, gfp_t flag)
+ dma_addr_t *dma_handle, unsigned long mask, gfp_t flag, int node)
{
void *ret = NULL;
dma_addr_t mapping;
unsigned int npages, order;
+ struct page *page;
size = PAGE_ALIGN(size);
npages = size >> PAGE_SHIFT;
@@ -560,9 +561,10 @@
return NULL;
/* Alloc enough pages (and possibly more) */
- ret = (void *)__get_free_pages(flag, order);
- if (!ret)
+ page = alloc_pages_node(flag, order, node);
+ if (!page)
return NULL;
+ ret = page_address(page);
memset(ret, 0, size);
/* Set up tces to cover the allocated range */
@@ -570,9 +572,9 @@
mask >> PAGE_SHIFT, order);
if (mapping == DMA_ERROR_CODE) {
free_pages((unsigned long)ret, order);
- ret = NULL;
- } else
- *dma_handle = mapping;
+ return NULL;
+ }
+ *dma_handle = mapping;
return ret;
}
Index: linux-2.6/arch/powerpc/kernel/pci_iommu.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/pci_iommu.c 2006-04-25 15:53:07.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/pci_iommu.c 2006-05-30 14:55:18.000000000 +0200
@@ -86,7 +86,8 @@
dma_addr_t *dma_handle, gfp_t flag)
{
return iommu_alloc_coherent(devnode_table(hwdev), size, dma_handle,
- device_to_mask(hwdev), flag);
+ device_to_mask(hwdev), flag,
+ pcibus_to_node(to_pci_dev(hwdev)->bus));
}
static void pci_iommu_free_coherent(struct device *hwdev, size_t size,
Index: linux-2.6/arch/powerpc/kernel/vio.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/vio.c 2006-04-25 15:53:07.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/vio.c 2006-05-30 14:54:38.000000000 +0200
@@ -229,7 +229,7 @@
dma_addr_t *dma_handle, gfp_t flag)
{
return iommu_alloc_coherent(to_vio_dev(dev)->iommu_table, size,
- dma_handle, ~0ul, flag);
+ dma_handle, ~0ul, flag, -1);
}
static void vio_free_coherent(struct device *dev, size_t size,
Index: linux-2.6/include/asm-powerpc/iommu.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/iommu.h 2006-04-25 15:53:07.000000000 +0200
+++ linux-2.6/include/asm-powerpc/iommu.h 2006-05-30 14:55:45.000000000 +0200
@@ -76,7 +76,8 @@
int nelems, enum dma_data_direction direction);
extern void *iommu_alloc_coherent(struct iommu_table *tbl, size_t size,
- dma_addr_t *dma_handle, unsigned long mask, gfp_t flag);
+ dma_addr_t *dma_handle, unsigned long mask,
+ gfp_t flag, int node);
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,
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
From: Alexandre Bounine @ 2006-06-06 14:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, Yang Xin-Xin-r48390
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Tuesday, June 06, 2006 6:17 AM
> To: Zang Roy-r61911
> Cc: Alexandre Bounine; Kumar Gala; linuxppc-dev list; Yang
> Xin-Xin-r48390; Paul Mackerras
> Subject: RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
>=20
>=20
> On Tue, 2006-06-06 at 17:43 +0800, Zang Roy-r61911 wrote:
>=20
> > Update Tsi108 implementation of MPIC.
> > Any comment?=20
> >=20
> > Integrate Tundra Semiconductor tsi108 host bridge interrupt=20
> controller=20
> > to mpic arch.
>=20
> Looks much better :) Still a few things...=20
>
Sounds good. We are moving in right direction :)
=20
> > + mpic =3D mpic_alloc(mpic_paddr,
> > + MPIC_PRIMARY | MPIC_BIG_ENDIAN |=20
> MPIC_WANTS_RESET |
> > + MPIC_SPV_EOI | MPIC_CASC_NOEOI |=20
> > + MPIC_MOD_ID(MPIC_ID_TSI108),
> > + 0, /* num_sources used */
> > + TSI108_IRQ_BASE,
> > + 0, /* num_sources used */
> > + NR_IRQS - 4 /* XXXX */,
> > + mpc7448_hpc2_pic_initsenses,
> > + sizeof(mpc7448_hpc2_pic_initsenses),=20
> "Tsi108_PIC");
>=20
> That's a hell lot of new flags... I'm not sure we need that many or a
> single TSI108 one that encloses all the new ones. Also, I'm=20
> not sure we
> need that model ID encoding thing. Let's do things simple, besides, I
> don't want to encourage HW folks into doing the same kind of=20
> contraption
> in the future
More details in comments below.
>(btw, tell the TSI folks for me that they had a BAD BAD
> BAD idea to muck around with the base design that way, especially
> changing the register map in incompatible ways for no good reason).
>=20
Done!
> > + /* Configure MPIC outputs to CPU0 */
> > + tsi108_write_reg(TSI108_MPIC_OFFSET + 0x30c, 0);
> > }
>=20
> It doesn't use the standard multiple processor outputs mecanism of
> MPIC ?
> =20
> > +static struct mpic_info mpic_infos[] =3D {
> > + [0] =3D { /* Original OpenPIC compatible MPIC */
> > + .greg_base =3D MPIC_GREG_BASE,
> > + .greg_frr0 =3D MPIC_GREG_FEATURE_0,
> > + .greg_config0 =3D MPIC_GREG_GLOBAL_CONF_0,
> > + .greg_vendor_id =3D MPIC_GREG_VENDOR_ID,
> > + .greg_ipi_vp0 =3D MPIC_GREG_IPI_VECTOR_PRI_0,
> > + .greg_ipi_stride =3D MPIC_GREG_IPI_STRIDE,
> > + .greg_spurious =3D MPIC_GREG_SPURIOUS,
> > + .greg_tfrr =3D MPIC_GREG_TIMER_FREQ,
> > +
>=20
> .../...
>=20
> It's a bit sad to have to go all the way to doing such tables, but I
> suspect it's probably the best way to handle it at this=20
> point.
> Send more
> nastygrams to the HW folks for me.
>=20
Done:)
> > mpic->num_sources =3D 0; /* so far */
> > mpic->senses =3D senses;
> > mpic->senses_count =3D senses_count;
> > + mpic->hw_set =3D &mpic_infos[MPIC_GET_MOD_ID(flags)];
>=20
> Well... the model ID thing might not be that a bad idea in=20
> the end :) I
> need to think about it. I might have to deal with yet another=20
> MPIC that
> has another regiser map (yeah yeah, TSI aren't the only ones=20
> to not get
> it)...=20
>
I'll tell this to HW guys as well :)=20
> .../...
>=20
> > @@ -963,7 +1043,7 @@ int mpic_get_one_irq(struct mpic *mpic,=20
> > {
> > u32 irq;
> > =20
> > - irq =3D mpic_cpu_read(MPIC_CPU_INTACK) & MPIC_VECPRI_VECTOR_MASK;
> > + irq =3D mpic_cpu_read(mpic->hw_set->cpu_intack) &=20
> mpic->hw_set->irq_vpr_vector;
> > #ifdef DEBUG_LOW
> > DBG("%s: get_one_irq(): %d\n", mpic->name, irq);
> > #endif
> > @@ -972,11 +1052,18 @@ #ifdef DEBUG_LOW
> > DBG("%s: cascading ...\n", mpic->name);
> > #endif
> > irq =3D mpic->cascade(regs, mpic->cascade_data);
> > - mpic_eoi(mpic);
> > +#ifdef DEBUG_LOW
> > + DBG("%s: cascaded irq: %d\n", mpic->name, irq);
> > +#endif
> > + if (!(mpic->flags & MPIC_CASC_NOEOI))
> > + mpic_eoi(mpic);
> > return irq;
> > }
>=20
> Can you tell me why you need the above ? (Why you aren't EOI'ing the
> cascade ?) Note that the cascade handling is going away from=20
> mpic anyway
> with the port to genirq that I'll publish later this week for=20
> 2.6.18 and
> it will almost be handled as a normal interrupt...
>=20
We have a level-signalled irq from the cascaded PCI interrupt =
controller. If I do EOI at=20
this time, level request will not have chance to be cleared (unless all =
PCI interrupts have
an SA_INTERRUPT flag) and result in recurring interrupts.=20
I chose to have an individual flag instead of checking model ID to avoid =
multiple checks within ISR (in case if we have more that one mpic =
version requiring this option). I also expect that it may be useful for =
any external level-signalling cascades connected to MPIC. =20
> > - if (unlikely(irq =3D=3D MPIC_VEC_SPURRIOUS))
> > + if (unlikely(irq =3D=3D MPIC_VEC_SPURRIOUS)) {
> > + if (mpic->flags & MPIC_SPV_EOI)
> > + mpic_eoi(mpic);
> > return -1;
> > + }
>=20
> I think the above thing could just test the model ID. It's=20
> unlikely that
> another implementation need the same "feature", so just test the model
> ID rather than adding a flag and if we ever have another=20
> model with the
> same "feature", then we'll go back to adding a flag :)
>=20
Motivation is the same as above - I just do not want to have multiple ID =
checks here. I agree that it is driven by mpic type (model ID) only. I =
can remove this one if you do not expect any
new "broken" MPICs on horizon. =20
> Cheers,
> Ben.
>=20
Thanks for your feedback,
Alex.
>=20
>=20
^ permalink raw reply
* Re: eth0: tx queue full
From: Steve Iribarne (GMail) @ 2006-06-06 14:45 UTC (permalink / raw)
To: salvatore cusenza; +Cc: linuxppc-embedded
In-Reply-To: <9252a64b0606060113v696adbb7ib43ad95836c0724b@mail.gmail.com>
On 6/6/06, salvatore cusenza <salvatore.cusenza@gmail.com> wrote:
>
> At runtime during the usual life of my board (MPC852 and linux-2.4.20 Denk's
> distribution)
> I have experienced the following crash:
>
>
> eth0: tx queue full!.
> eth0: tx queue full!.
> eth0: tx queue full!.
>
> Oops: kernel access of bad area, sig: 11
> NIP: C000D440 XER: 00000000 LR: C00BB040 SP: C0C9BC10 REGS: c0c9bb60 TRAP:
> 0300 Tainted: P
> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 00001F9D, DSISR: 000000E4
> TASK = c0c9a000[145] 'L5421' Last syscall: 4
> last math 00000000 last altivec 00000000
> GPR00: 00000000 C0C9BC10 C0C9A000 C0F56D70 00001F99 0000003C C0F56D6C
> 00000007
> GPR08: 00000001 0000003C 00000000 C0F56DB0 C0D83C3C 10071D28 00000000
> C3120000
> GPR16: C311CB04 C311C8D8 C311C754 C0170000 C3120000 C311CB30 00000001
> C0169DA0
> GPR24: F0000E00 00001F9D C0F58400 0000003C 00000040 C2080100 C0F58200
> C0F501B0
> Call backtrace:
> C00BAF8C C00BABC8 C0005848 C3119448 C31194C0 C31194F8 C00066F8
> C0011A48 C00BA8FC C00CADD8 C00C3F00 C0016B50 C00AFE4C C00B4B94
> C00B5EF4 C003571C C000457C 0FFD5E4C 0FEDB8DC 0FEDB284 1003B5B8
> 1003D558 1003A88C 0FED34A4 0FED32D0 0FFCFEE4 0FD5F590
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
> <0>Rebooting in 180 seconds..
>
>
> Could you suggest me something to investigate?
>
First thing I'd do is get my hands on ksymoops and look at the callstack.
Check out...
http://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/
>From my past experience, seems to me that I have had a similar oops
when the driver code that I have been debugging usually is stuck in a
loop at interrupt time and your missing interrupts.
Or better yet, your just plain crashing at interrupt time. It sounds
like this is pretty easy to reproduce so follow the readme on
ksymoops.
Hope that helps.
-stv
^ permalink raw reply
* PowerPC 8266 ADS-PCI(CPM8260) SCC (UART/Ethernet Mode) and SMC in UART mode
From: Aung Soe @ 2006-06-06 14:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
Dear All
I am working on PowerPC 8266 ADS-PCI board
with Montavista Linux with 2.4.20 Kernel to make SCC1, SMC 1& 2
in UART mode, SCC2, 3 & 4 in Ethernet mode, and FCC 2 in Fast
Ethernet Mode; all in NMSI and not TDM. The drivers provided with
2.4.20 Linux on Power PC were refered and reused.
http://lxr.linux.no/source/arch/ppc/8260_io/?v=2.4.20;a=ppc
When there are only 3 SCCs used in Ethernet mode and the last
SCC in UART mode then the system works well.
But when 2 more SMC are added to the UART serial driver, the SCC
Ethernet network driver is not working after all ports working for a while.
I will be appreciate to hear any pointers and hints.
Thanks in advance.
Sincerley
Aung
[-- Attachment #2: Type: text/html, Size: 1292 bytes --]
^ permalink raw reply
* Base address of executables - weirdness?
From: H. Peter Anvin @ 2006-06-06 15:42 UTC (permalink / raw)
To: linuxppc-dev
I'm trying to track down an odd issue with klibc on ppc32.
Until recently, binaries linked with ld defaulted to a base address of
0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of
reports -- and I've been able to confirm this on my FC5 system -- that
some versions of ld links at 0x01800000+SIZEOF_HEADERS. Needless to
say, this is more than a bit confusing, *especially* since "ld -verbose"
still reports:
PROVIDE (__executable_start = 0x10000000); . = 0x10000000 +
SIZEOF_HEADERS;
... at the top of the linker script.
I'm rather baffled. Has anyone else seen this, and/or have any other
explanation?
-hpa
^ permalink raw reply
* Intercept System call using Kernel module is 2.6 kernel
From: Meswani, Mitesh @ 2006-06-06 16:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <C26C730943E01145B4F89E37FE0A022002BBC7A2@itdsrvmail02.utep.edu>
[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]
Hello
I am attempting to run some user code with kernel space permission. I am using the ppc64 kernel version 2.6.16-rc4-3-ppc64 for IBM Power5 processors.
In this kernel module I am trying to implement a function that can be called from user space.
I have found through various posts that using unused system calls and replacing them temporarily can acheive this objective.
This is what I am doing, but its not working, please bear with the slightly long code that follows:
1) since the 2.6 kernel does not export sys_call_table, I grep it from the boot image
2) Next I write the kernel module as :
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/syscalls.h>
unsigned long **sctable;
void *org_func; /***** Copy of the original calls address ********/
asmlinkage int mitesh_func(void)
{
printk(KERN_ALERT "Executing mitesh_func...\n");
return 2;
}
int init_module(void)
{
unsigned long ptr;
unsigned long *p;
ptr = 0x23203404; /*** some hard coded addresses from grepping for sys_call_table *****/
p = (unsigned long *)ptr;
sctable = (unsigned long **)p;
printk("The address of the system call table is: 0x%x\n",&sctable[0]);
printk("The address of syscall #137 is: 0x%x\n",sctable[137]);
org_func = (void *) (sctable[137]); /**** Store the original sys call ****/
printk("Original func address 0x%x stored \n",org_func);
sctable[137] = (void *) mitesh_func; /**** replace with mitesh_func ****/
printk("The new sys call address is 0x%x and stored as : 0x%x\n",mitesh_func, sctable[137]);
return 0;
}
void cleanup_module(void)
{
sctable[137] = (void *) org_func;
printk("Upon module unload the sctable #137 address is :0x%x\n",sctable[137]);
printk("Module is unloaded!\n");
}
3) My user app looks like this:
#include <stdio.h>
#include <errno.h>
#include <asm-ppc64/unistd.h>
#define __NR_mitesh_func 137
_syscall0(int, mitesh_func);
void main()
{
int x=0;
x=mitesh_func();
printf("mitesh_func returned %d\n",x);
}
4) I verify from the system logs that when I insmod the kernel module I get all the print statements. I verified from the logs that the address of the sys_call_table is correctly passed and from /proc/kallsysms I can see that my function mitesh_func has been defined and has the address as indicated in the logs.
The problem is that when I execute my user app I expect to see two things:
a) I should see a message in the log "Executing mitesh_func..." and
b) A return value of 2
However I get an error value -1 returned.
Any help and ideas are highly appreciated.
Thank you in advance,
Mitesh
[-- Attachment #2: Type: text/html, Size: 5523 bytes --]
^ permalink raw reply
* Re: Intercept System call using Kernel module is 2.6 kernel
From: Jeff.Fellin @ 2006-06-06 17:02 UTC (permalink / raw)
To: mmeswani; +Cc: linuxppc-dev, linuxppc-dev-bounces+jeff.fellin=rflelect.com
"Meswani, Mitesh" <mmeswani@utep.edu>
Sent by: To: <linuxppc-dev@ozlabs.org>
linuxppc-dev-bounces+jeff.fellin=rflelect.com cc:
@ozlabs.org Subject: Intercept System call using Kernel module is
2.6 kernel
06/06/2006 12:25
>Hello
>I am attempting to run some user code with kernel space permission. I am
using the ppc64 kernel version >2.6.16-rc4-3-ppc64 for IBM Power5
processors.
>In this kernel module I am trying to implement a function that can be
called from user space.
>
>I have found through various posts that using unused system calls and
replacing them temporarily can acheive this >objective.
>
>This is what I am doing, but its not working, please bear with the
slightly long code that follows:
>
>1) since the 2.6 kernel does not export sys_call_table, I grep it from the
boot image
First sign what you are doing is not a good idea. There are better methods
of this
1) device driver interface with read/write/ioctl interface
2) procfs files from a module/driver
3) sysfs files from a module/driver
SNIP
>
>The problem is that when I execute my user app I expect to see two things:
>a) I should see a message in the log "Executing mitesh_func..." and
> b) A return value of 2
>However I get an error value -1 returned.
An indication of thinking of system calls vs other methods is wrong!.
>Any help and ideas are highly appreciated.
Don't add your own or hijack system calls
Thank you in advance,
Mitesh
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Collecting hypervisor call stats
From: Mike Kravetz @ 2006-06-06 16:46 UTC (permalink / raw)
To: Christopher Yeoh; +Cc: Chris Yeoh, Bryan Rosenburg, linuxppc-dev
In-Reply-To: <17534.30511.192632.558778@localhost.localdomain>
On Thu, Jun 01, 2006 at 03:12:15PM +1000, Christopher Yeoh wrote:
> Here's a patch we've used for collecting hcall counts and times.
Thanks for the patch/code Chris! I'm using this as a basis for something
that we may want to merge into the tree. Just a couple of questions.
Your 'wrappers' have the following general form:
> +long plpar_hcall(unsigned long opcode, unsigned long arg1,
> + unsigned long arg2, unsigned long arg3,
> + unsigned long arg4, unsigned long *out1,
> + unsigned long *out2, unsigned long *out3)
> +{
> + long retcode;
> + unsigned long t_entry;
> + int opcode_index;
> +
> + opcode_index = map_hcall_to_index(opcode);
> +
> + t_entry = mfspr(SPRN_PURR);
> + barrier();
> +
> + retcode = plpar_hcall_real(opcode, arg1, arg2, arg3, arg4,
> + out1, out2, out3);
> +
> + barrier();
> + get_cpu_var(hcall_type_count)[opcode_index]++;
> + put_cpu_var(hcall_type_count);
> + get_cpu_var(hcall_type_time)[opcode_index] += mfspr(SPRN_PURR) - t_entry;
> + put_cpu_var(hcall_type_time);
> +
> + return retcode;
> +};
Can you explain the need for barrier(s) before and after the call to the
real routine? It usually takes me a couple days of thought to figure out
exactly where these are needed. :)
The use of get_cpu_var/put_cpu_var result in disabling/enabling preemption.
I can understand why this would be desirable to assure the accuracy of the
statistics. But, I was wondering if the desired accuracy is worth the added
overhead. My thought was to make these as lightweight as possible and
sacrifice some accuracy if necessary. After all, no 'internal decisions' are
being made because of this data. It is simply exposed to user land.
Thoughts?
Thanks,
--
Mike
^ permalink raw reply
* Re: process starvation with 2.6 scheduler
From: Thiago Galesi @ 2006-06-06 17:09 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
In-Reply-To: <478F19F21671F04298A2116393EEC3D527421D@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
Did you try it with a _real_ CPU? My bet is that the timer interrupt
is overwhelming the CPU (even at 100Hz, 400kHz is too slow).
--
-
Thiago Galesi
^ permalink raw reply
* Re: Intercept System call using Kernel module is 2.6 kernel
From: Arnd Bergmann @ 2006-06-06 17:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Meswani, Mitesh
In-Reply-To: <C26C730943E01145B4F89E37FE0A022002BBC7A6@itdsrvmail02.utep.edu>
Am Tuesday 06 June 2006 18:25 schrieb Meswani, Mitesh:
> Any help and ideas are highly appreciated. =C2=A0
Tell your professor that the task you were given is=20
a) pointless, as you wouldn't use this kind of thing to
solve an actual problem other than bad OS design
homework.
b) not a correct approach regarding maintainability, since
you can't tell for an arbitrary kernel version if
the particular syscall you're abusing is now used for
something else.
As a replacement task, choose one or more of the following:
=2D implement a syscall by _recompiling_ the kernel and call
that from your user application.
=2D write a misc device driver that exposes a device to
do ioctl() on.
=2D create a file in each of sysfs, procfs and debugfs to
do your operation on, using read() and write().
=2D use a netlink socket for a two way communication with
a kernel module.
Arnd <><
^ permalink raw reply
* RE: Intercept System call using Kernel module is 2.6 kernel
From: Jenkins, Clive @ 2006-06-06 17:14 UTC (permalink / raw)
To: Meswani, Mitesh, linuxppc-dev
> x=3Dmitesh_func();=20
> printf("mitesh_func returned %d\n",x);
The first thing would be to change your user-space program
to print the error number from errno after your "system call".
x=3Dmitesh_func();=20
printf("mitesh_func returned %d, errno=3D%d\n",x,errno);
Or you can use perror() -- look it up.
Clive
=20
4) I verify from the system logs that when I insmod the kernel module I
get all the print statements. I verified from the logs that the address
of the sys_call_table is correctly passed and from /proc/kallsysms I can
see that my function mitesh_func has been defined and has the address as
indicated in the logs.=20
The problem is that when I execute my user app I expect to see two
things:=20
a) I should see a message in the log "Executing mitesh_func..." and=20
b) A return value of 2=20
However I get an error value -1 returned.=20
Any help and ideas are highly appreciated. =20
Thank you in advance,=20
Mitesh=20
^ permalink raw reply
* Re: Base address of executables - weirdness?
From: H. Peter Anvin @ 2006-06-06 18:21 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20060606173343.GE9294@austin.ibm.com>
Linas Vepstas wrote:
> On Tue, Jun 06, 2006 at 08:42:49AM -0700, H. Peter Anvin wrote:
>> I'm trying to track down an odd issue with klibc on ppc32.
>>
>> Until recently, binaries linked with ld defaulted to a base address of
>> 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of
>> reports -- and I've been able to confirm this on my FC5 system -- that
>> some versions of ld links at 0x01800000+SIZEOF_HEADERS. Needless to
>> say, this is more than a bit confusing, *especially* since "ld -verbose"
>> still reports:
>>
>> PROVIDE (__executable_start = 0x10000000); . = 0x10000000 +
>> SIZEOF_HEADERS;
>>
>> ... at the top of the linker script.
>>
>> I'm rather baffled. Has anyone else seen this, and/or have any other
>> explanation?
>
> Googling "0x01800000 linux ppc" brings up some interesting but old hits.
>
> However, I swear I saw someone suggest a patch last week that changed
> 0x10000000 to 0x01800000 somewhere, (vmlinux.lds ??) as a proposed cure
> for a bug. Sorry, I deleted it.
>
Well, it's worse than I previously surmised. I can't seem to find any combination of
options which work on both affected and unaffected binutils. This is a real mess.
-hpa
^ permalink raw reply
* Re: ppc85xx DMA
From: Naru Sundar @ 2006-06-06 18:55 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673026FD940@zch01exm40.ap.freescale.net>
On Tue, Jun 06, 2006 at 09:39:29AM +0800, Liu Dave-r63238 wrote:
> What is the DMA transfer mode? Is direct or chaining mode?
Direct mode. I fixed an error with my bit ordering for the configuration
registers, and now the transfer seems to complete, but I don't see any
actual data showing up in the destination register that I am writing to.
> Did you ioremap the DMA register space?
Yes, I can write the destination address manually. So I am thinking my addresses
are wrong.
For the source and dest address I used:
dma_map_single(NULL, ptr, len, DMA_TO_DEVICE)
(which effectively does a virt_to_bus on ppc and so should just return to me
the bus address used by the dma).
-naru
^ permalink raw reply
* RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
From: Alexandre Bounine @ 2006-06-06 18:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Zang Roy-r61911
Cc: linuxppc-dev list, Paul Mackerras, Yang Xin-Xin-r48390
I forgot to mention another argument in favor of adding separate =
MPIC_SPV_EOI and MPIC_CASC_NOEOI flags:
If we have MPIC with "broken" logic but standard register map we can use =
model ID =3D 0 for
the standard MPIC without creating additional data structure.
Regards,
Alex.
-----Original Message-----
From: Alexandre Bounine=20
Sent: Tuesday, June 06, 2006 10:46 AM
To: 'Benjamin Herrenschmidt'; Zang Roy-r61911
Cc: Kumar Gala; linuxppc-dev list; Yang Xin-Xin-r48390; Paul Mackerras
Subject: RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Tuesday, June 06, 2006 6:17 AM
> To: Zang Roy-r61911
> Cc: Alexandre Bounine; Kumar Gala; linuxppc-dev list; Yang
> Xin-Xin-r48390; Paul Mackerras
> Subject: RE: [PATCH/2.6.17-rc4 4/10]Powerpc: Add tsi108 pic support
>=20
>=20
> On Tue, 2006-06-06 at 17:43 +0800, Zang Roy-r61911 wrote:
>=20
> > Update Tsi108 implementation of MPIC.
> > Any comment?=20
> >=20
> > Integrate Tundra Semiconductor tsi108 host bridge interrupt=20
> controller=20
> > to mpic arch.
>=20
> Looks much better :) Still a few things...=20
>
Sounds good. We are moving in right direction :)
=20
> > + mpic =3D mpic_alloc(mpic_paddr,
> > + MPIC_PRIMARY | MPIC_BIG_ENDIAN |=20
> MPIC_WANTS_RESET |
> > + MPIC_SPV_EOI | MPIC_CASC_NOEOI |=20
> > + MPIC_MOD_ID(MPIC_ID_TSI108),
> > + 0, /* num_sources used */
> > + TSI108_IRQ_BASE,
> > + 0, /* num_sources used */
> > + NR_IRQS - 4 /* XXXX */,
> > + mpc7448_hpc2_pic_initsenses,
> > + sizeof(mpc7448_hpc2_pic_initsenses),=20
> "Tsi108_PIC");
>=20
> That's a hell lot of new flags... I'm not sure we need that many or a
> single TSI108 one that encloses all the new ones. Also, I'm=20
> not sure we
> need that model ID encoding thing. Let's do things simple, besides, I
> don't want to encourage HW folks into doing the same kind of=20
> contraption
> in the future
More details in comments below.
>(btw, tell the TSI folks for me that they had a BAD BAD
> BAD idea to muck around with the base design that way, especially
> changing the register map in incompatible ways for no good reason).
>=20
Done!
> > + /* Configure MPIC outputs to CPU0 */
> > + tsi108_write_reg(TSI108_MPIC_OFFSET + 0x30c, 0);
> > }
>=20
> It doesn't use the standard multiple processor outputs mecanism of
> MPIC ?
> =20
> > +static struct mpic_info mpic_infos[] =3D {
> > + [0] =3D { /* Original OpenPIC compatible MPIC */
> > + .greg_base =3D MPIC_GREG_BASE,
> > + .greg_frr0 =3D MPIC_GREG_FEATURE_0,
> > + .greg_config0 =3D MPIC_GREG_GLOBAL_CONF_0,
> > + .greg_vendor_id =3D MPIC_GREG_VENDOR_ID,
> > + .greg_ipi_vp0 =3D MPIC_GREG_IPI_VECTOR_PRI_0,
> > + .greg_ipi_stride =3D MPIC_GREG_IPI_STRIDE,
> > + .greg_spurious =3D MPIC_GREG_SPURIOUS,
> > + .greg_tfrr =3D MPIC_GREG_TIMER_FREQ,
> > +
>=20
> .../...
>=20
> It's a bit sad to have to go all the way to doing such tables, but I
> suspect it's probably the best way to handle it at this=20
> point.
> Send more
> nastygrams to the HW folks for me.
>=20
Done:)
> > mpic->num_sources =3D 0; /* so far */
> > mpic->senses =3D senses;
> > mpic->senses_count =3D senses_count;
> > + mpic->hw_set =3D &mpic_infos[MPIC_GET_MOD_ID(flags)];
>=20
> Well... the model ID thing might not be that a bad idea in=20
> the end :) I
> need to think about it. I might have to deal with yet another=20
> MPIC that
> has another regiser map (yeah yeah, TSI aren't the only ones=20
> to not get
> it)...=20
>
I'll tell this to HW guys as well :)=20
> .../...
>=20
> > @@ -963,7 +1043,7 @@ int mpic_get_one_irq(struct mpic *mpic,=20
> > {
> > u32 irq;
> > =20
> > - irq =3D mpic_cpu_read(MPIC_CPU_INTACK) & MPIC_VECPRI_VECTOR_MASK;
> > + irq =3D mpic_cpu_read(mpic->hw_set->cpu_intack) &=20
> mpic->hw_set->irq_vpr_vector;
> > #ifdef DEBUG_LOW
> > DBG("%s: get_one_irq(): %d\n", mpic->name, irq);
> > #endif
> > @@ -972,11 +1052,18 @@ #ifdef DEBUG_LOW
> > DBG("%s: cascading ...\n", mpic->name);
> > #endif
> > irq =3D mpic->cascade(regs, mpic->cascade_data);
> > - mpic_eoi(mpic);
> > +#ifdef DEBUG_LOW
> > + DBG("%s: cascaded irq: %d\n", mpic->name, irq);
> > +#endif
> > + if (!(mpic->flags & MPIC_CASC_NOEOI))
> > + mpic_eoi(mpic);
> > return irq;
> > }
>=20
> Can you tell me why you need the above ? (Why you aren't EOI'ing the
> cascade ?) Note that the cascade handling is going away from=20
> mpic anyway
> with the port to genirq that I'll publish later this week for=20
> 2.6.18 and
> it will almost be handled as a normal interrupt...
>=20
We have a level-signalled irq from the cascaded PCI interrupt =
controller. If I do EOI at=20
this time, level request will not have chance to be cleared (unless all =
PCI interrupts have
an SA_INTERRUPT flag) and result in recurring interrupts.=20
I chose to have an individual flag instead of checking model ID to avoid =
multiple checks within ISR (in case if we have more that one mpic =
version requiring this option). I also expect that it may be useful for =
any external level-signalling cascades connected to MPIC. =20
> > - if (unlikely(irq =3D=3D MPIC_VEC_SPURRIOUS))
> > + if (unlikely(irq =3D=3D MPIC_VEC_SPURRIOUS)) {
> > + if (mpic->flags & MPIC_SPV_EOI)
> > + mpic_eoi(mpic);
> > return -1;
> > + }
>=20
> I think the above thing could just test the model ID. It's=20
> unlikely that
> another implementation need the same "feature", so just test the model
> ID rather than adding a flag and if we ever have another=20
> model with the
> same "feature", then we'll go back to adding a flag :)
>=20
Motivation is the same as above - I just do not want to have multiple ID =
checks here. I agree that it is driven by mpic type (model ID) only. I =
can remove this one if you do not expect any
new "broken" MPICs on horizon. =20
> Cheers,
> Ben.
>=20
Thanks for your feedback,
Alex.
>=20
>=20
^ permalink raw reply
* Re: Base address of executables - weirdness?
From: Linas Vepstas @ 2006-06-06 17:33 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linuxppc-dev
In-Reply-To: <4485A279.4050403@zytor.com>
On Tue, Jun 06, 2006 at 08:42:49AM -0700, H. Peter Anvin wrote:
> I'm trying to track down an odd issue with klibc on ppc32.
>
> Until recently, binaries linked with ld defaulted to a base address of
> 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of
> reports -- and I've been able to confirm this on my FC5 system -- that
> some versions of ld links at 0x01800000+SIZEOF_HEADERS. Needless to
> say, this is more than a bit confusing, *especially* since "ld -verbose"
> still reports:
>
> PROVIDE (__executable_start = 0x10000000); . = 0x10000000 +
> SIZEOF_HEADERS;
>
> ... at the top of the linker script.
>
> I'm rather baffled. Has anyone else seen this, and/or have any other
> explanation?
Googling "0x01800000 linux ppc" brings up some interesting but old hits.
However, I swear I saw someone suggest a patch last week that changed
0x10000000 to 0x01800000 somewhere, (vmlinux.lds ??) as a proposed cure
for a bug. Sorry, I deleted it.
--linas
^ permalink raw reply
* 2.4 kernel scheduling (?) problems
From: Tobias Netzel @ 2006-06-06 18:29 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I'm new to this list - hoping you will help me with the 2.4 kernel,
although it's old now.
I'm improving hardware support for the NuBus PMacs. The NuBus Pmacs are
68k Macs with a PPC CPU and a different bus bridge/memory controller.
The NuBus PMac port is something like a hack to the PPC architecture
using some things from the PMac platform.
An open firmware device tree is emulated as far as needed. We use the
same PMU driver (although I hacked it a bit because we directly route
the PMU interrupts), ADB and RTC driver and the same functions to
calibrate the decrementer using the VIA timer.
The problem I got is that for example during SCSI transfers (I'm using
an old scanner) neither the X screen gets updated nor does the system
respond to any interrupts but the NMI.
Debugging messages through the serial port are still sent. So I have to
wait until the whole transfer is done. The kernel only receives
interrupts after a SCSI command has finished and before a new one is
sent. The data from the scanner is transfered in blocks of 32 kB.
The behaviour is similar when I do an performance test using "dd" or
"hdparm" on the IDE CD-ROM drive. Burning CDs using that IDE drive
works but causes the same problem as when scanning with the SCSI
scanner.
With the IDE hard disk I don't get this problem.
When I run "top" during those problem transfers the CPU utilization by
the system is higher than 95% ("top" hardly gets updated) - I doubt
that this is necessary as on the NuBus PMacs the PPC CPUs (and
especially the 217 MHz G3 with 512 kB L2 cache I'm using) should be
idle most of the time waiting for the slow 33 MHz system bus.
The strange thing is that the CPU misses all interrupts (except the
NMI) although interrupts aren't turned off in the CPU (otherwise the
PMU would shut us down and the NMI wouldn't work). I also tried to use
a timer to poll the interrupt controllers but the interrupt handling
routines also only find one pending interrupt in 10 seconds even when I
constantly move the mouse and hit keys.
At first I thought this was something caused by the hardware but in
MacOS 9 the SCSI driver doesn't block anything.
But is it possible that this is because of something like scheduling
problems of the kernel?
And if so might updating to the 2.6 kernel fix that issue?
Tobias
^ permalink raw reply
* Re: eth0: tx queue full
From: Wolfgang Denk @ 2006-06-06 20:53 UTC (permalink / raw)
To: salvatore cusenza; +Cc: linuxppc-embedded
In-Reply-To: <9252a64b0606060113v696adbb7ib43ad95836c0724b@mail.gmail.com>
In message <9252a64b0606060113v696adbb7ib43ad95836c0724b@mail.gmail.com> you wrote:
>
> At runtime during the usual life of my board (MPC852 and linux-2.4.20 Denk's
> distribution)
> I have experienced the following crash:
2.4.20 is at least 3.5 years old. Please use recent code.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Brain fried - Core dumped
^ permalink raw reply
* Re: Base address of executables - weirdness?
From: Andreas Schwab @ 2006-06-06 21:15 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linuxppc-dev
In-Reply-To: <4485A279.4050403@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Until recently, binaries linked with ld defaulted to a base address of
> 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of
> reports -- and I've been able to confirm this on my FC5 system -- that
> some versions of ld links at 0x01800000+SIZEOF_HEADERS.
You are probably using the wrong linker emulation. There are three
emulations enabled when building binutils for ppc-linux, but only the
elf32ppclinux emulation it the right one that uses 0x10000000 for the base
address.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: ppc85xx DMA
From: Naru Sundar @ 2006-06-06 21:16 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-embedded
In-Reply-To: <20060606185548.GB27078@fulcrummicro.com>
To clarify, I am definitely using the physical addresses. virt_to_bus and
virt_to_phys result in the same value. My transfer completes and I see
BCR go back to 0, but I can't manage to actually see any data difference
at the destination side.
The destination address is an ioremapped region that I pass through
virt_to_phys. The src is kmalloc'd memory that has GFP_DMA set.
On Tue, Jun 06, 2006 at 11:55:48AM -0700, Naru Sundar wrote:
> On Tue, Jun 06, 2006 at 09:39:29AM +0800, Liu Dave-r63238 wrote:
> > What is the DMA transfer mode? Is direct or chaining mode?
>
> Direct mode. I fixed an error with my bit ordering for the configuration
> registers, and now the transfer seems to complete, but I don't see any
> actual data showing up in the destination register that I am writing to.
>
> > Did you ioremap the DMA register space?
>
> Yes, I can write the destination address manually. So I am thinking my addresses
> are wrong.
>
> For the source and dest address I used:
>
> dma_map_single(NULL, ptr, len, DMA_TO_DEVICE)
>
> (which effectively does a virt_to_bus on ppc and so should just return to me
> the bus address used by the dma).
>
> -naru
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Base address of executables - weirdness?
From: H. Peter Anvin @ 2006-06-06 21:21 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jeirne56kn.fsf@sykes.suse.de>
Andreas Schwab wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> Until recently, binaries linked with ld defaulted to a base address of
>> 0x10000000+SIZEOF_HEADERS. However, recently I've gotten a couple of
>> reports -- and I've been able to confirm this on my FC5 system -- that
>> some versions of ld links at 0x01800000+SIZEOF_HEADERS.
>
> You are probably using the wrong linker emulation. There are three
> emulations enabled when building binutils for ppc-linux, but only the
> elf32ppclinux emulation it the right one that uses 0x10000000 for the base
> address.
>
Hm. Well, it's using the default one, but perhaps I should try to specify an explicit -m
option. Sure enough, that did the trick.
THANKS!
-hpa
^ permalink raw reply
* Re: ppc85xx DMA
From: Naru Sundar @ 2006-06-06 21:38 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-embedded
In-Reply-To: <20060606211610.GD27078@fulcrummicro.com>
Ah hah. I got it working.
Turns out using the ioremapped address was bad, I had to use the actual
nonremapped physical address.
Thanks for the info!
-naru
On Tue, Jun 06, 2006 at 02:16:10PM -0700, Naru Sundar wrote:
> To clarify, I am definitely using the physical addresses. virt_to_bus and
> virt_to_phys result in the same value. My transfer completes and I see
> BCR go back to 0, but I can't manage to actually see any data difference
> at the destination side.
>
> The destination address is an ioremapped region that I pass through
> virt_to_phys. The src is kmalloc'd memory that has GFP_DMA set.
>
> On Tue, Jun 06, 2006 at 11:55:48AM -0700, Naru Sundar wrote:
> > On Tue, Jun 06, 2006 at 09:39:29AM +0800, Liu Dave-r63238 wrote:
> > > What is the DMA transfer mode? Is direct or chaining mode?
> >
> > Direct mode. I fixed an error with my bit ordering for the configuration
> > registers, and now the transfer seems to complete, but I don't see any
> > actual data showing up in the destination register that I am writing to.
> >
> > > Did you ioremap the DMA register space?
> >
> > Yes, I can write the destination address manually. So I am thinking my addresses
> > are wrong.
> >
> > For the source and dest address I used:
> >
> > dma_map_single(NULL, ptr, len, DMA_TO_DEVICE)
> >
> > (which effectively does a virt_to_bus on ppc and so should just return to me
> > the bus address used by the dma).
> >
> > -naru
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 82xx CPM commands
From: Rune Torgersen @ 2006-06-06 22:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
Besause of some weird system hangs we have seen, I am wondering if the
CPM command register may need a lock around it.
In one of our drivers we can end up writing a CPM command every
millisecond on worst case during an error condition.
Sometimes during that error condition the whole CPU locks up. (or rather
it spins in an interrupt somewhere).
After looking at all the other places in the kernel the CPM command
register gets written, I am convinced that there does exists conditions
where we might accidentally write to the command register while some
other thread/irq is writing/waiting for command completion.
The code in all paces looks like:
cp->cp_cpcr =3D mk_cr_cmd(SOME COMMAND);
while (cp->cp_cpcr & CPM_CR_FLG);
I think we might need a lock around it.
local_irq_save() woild work, but would lock the whole CPU while the CPM
command completes (which can take 200 CPM clock cycles, avg 40 according
to maual)
Easiest way would probaby be to have a (inline) function that does the
lock/write/wait/unlock.
There is a couple of places that does a udelay between the write and the
wait.
^ 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