* RE: Ethernet Jumbo Frames
From: Darcy Watkins @ 2008-04-02 21:32 UTC (permalink / raw)
To: LinuxPPC-Embedded
In-Reply-To: <20080402211552.729E82B007F@mail93-dub.bigfish.com>
Thanks for the comments...
I have hacked the IBM EMAC driver (Xenomai-2.3.0 Real Time Linux
2.6.19.2) and got jumbo frames to pass back and forth between two such
embedded boards. Checked it using ping, iperf and httpd / wget file
transfer with md5sum check.
Still have to clean things up a bit and do some more tests before I can
share it as a patch.
Regards,
Darcy
-----Original Message-----
Sure, it can be done. The Xilinx 10/100 Ethernet drivers have jumbo
frame support in MontaVista/WindRiver Linux. As long as both ends are
talking jumbo frames, works just fine.
-Rick
-----Original Message-----
We've done it for our 2.4 based kernel that runs on a Freescale MPC8270.
10/100/1000 doesn't really make any difference. For us the trick was to
support receving jumbo frames in multiple RX BufDescriptors (because our
MPC8270 FCC eth driver pre-allocates 2k buffers per RX BD).
For transmitting hardly any changes were necessary.
From linux (driver) standpoint there should be no problems,
the question is whether your ethernet MAC (IBM EMAC) properly supports
it.
hth,
N. van Bolhuis.
^ permalink raw reply
* RE: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Stephen Neuendorffer @ 2008-04-02 21:39 UTC (permalink / raw)
To: John Linn, Grant Likely, sshtylyov; +Cc: linuxppc-dev
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C05FC4762@XCO-EXCHVS1.xlnx.xilinx.com>
I don't think big-endian has the same context as reg-shift/reg-offset.
The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If
we were talking about a 32 bit device, then I'd probably agree with you,
but in this case, the reg-shift (and to some extent) reg-offset have
been used before and probably make more sense, I think.
Steve
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]
> Sent: Wednesday, April 02, 2008 1:20 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org; grant.likely@secretlab.ca
> Subject: Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for
Xilinx uart 16550.
>=20
> Hello.
>=20
> John Linn wrote:
>=20
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based addressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
>=20
> > This code updates the of_serial driver to handle the reg-offset
> > and reg-shift properties to enable this core to be used.
>=20
> > Signed-off-by: John Linn <john.linn@xilinx.com>
>=20
> > diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-
> of.txt
> > index 87f4d84..af112d9 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -2539,6 +2539,17 @@ platforms are moved over to use the
flattened-device-tree model.
> > differ between different families. May be
> > 'virtex2p', 'virtex4', or 'virtex5'.
> >
> > + iv) Xilinx Uart 16550
> > +
> > + Xilinx UART 16550 devices are very similar to the NS16550
such that they
> > + use the ns16550 binding with properties to specify register
spacing and
> > + an offset from the base address.
> > +
> > + Requred properties:
> > + - clock-frequency : Frequency of the clock input
> > + - reg-offset : A value of 3 is required
>=20
> I'm proposing you to use the already existing "big-endian"
property ISO
> "reg-offset" (used in the nodes describing OpenPIC, for example).
>=20
> WBR, Sergei
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Yinghai Lu @ 2008-04-02 21:57 UTC (permalink / raw)
To: Badari Pulavarty
Cc: lkml, Kamalesh Babulal, linuxppc-dev, Andrew Morton, Balbir Singh
In-Reply-To: <1207164127.30407.36.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > >>
> > > >> [ 0.000000] ------------[ cut here ]------------
> > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [ 0.000000] Modules linked in:
> > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [ 0.000000] Call Trace:
> > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > >> [ 0.000000] Instruction dump:
> > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > > >>
> > > >
> > > > int __meminit vmemmap_populate(struct page *start_page,
> > > > unsigned long nr_pages, int node)
> > > > {
> > > > unsigned long mode_rw;
> > > > unsigned long start = (unsigned long)start_page;
> > > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > > >
> > > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > > >
> > > > /* Align to the page size of the linear mapping. */
> > > > start = _ALIGN_DOWN(start, page_size);
> > > >
> > > > for (; start < end; start += page_size) {
> > > > int mapped;
> > > > void *p;
> > > >
> > > > if (vmemmap_populated(start, page_size))
> > > > continue;
> > > >
> > > > p = vmemmap_alloc_block(page_size, node);
> > > > if (!p)
> > > > return -ENOMEM;
> > > >
> > > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > > start, p, __pa(p));
> > > >
> > > > mapped = htab_bolt_mapping(start, start + page_size,
> > > > __pa(p), mode_rw, mmu_linear_psize,
> > > > mmu_kernel_ssize);
> > > > =====> BUG_ON(mapped < 0);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > > in git-powerpc...
> > >
> > > One of the machines is the Power5 and another is PowerMac G5, on which the
> > > same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
>
> Okay. Found it.
>
> Root cause is:
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
>
will send you patch workaround it...
YH
^ permalink raw reply
* [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-02 22:25 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Badari Pulavarty,
Balbir Singh
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
on powerpc,
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > >>
> > > >> [ 0.000000] ------------[ cut here ]------------
> > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [ 0.000000] Modules linked in:
> > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [ 0.000000] Call Trace:
> > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > >> [ 0.000000] Instruction dump:
> > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
so try to allocate usemap at first altogether.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
diff --git a/mm/sparse.c b/mm/sparse.c
index d3cb085..782ebe5 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -294,7 +294,7 @@ void __init sparse_init(void)
unsigned long pnum;
struct page *map;
unsigned long *usemap;
- struct page **section_map;
+ unsigned long **usemap_map;
int size;
int node;
@@ -305,27 +305,31 @@ void __init sparse_init(void)
* make next 2M slip to one more 2M later.
* then in big system, the memmory will have a lot hole...
* here try to allocate 2M pages continously.
+ *
+ * powerpc hope to sparse_init_one_section right after each
+ * sparse_early_mem_map_alloc, so allocate usemap_map
+ * at first.
*/
- size = sizeof(struct page *) * NR_MEM_SECTIONS;
- section_map = alloc_bootmem(size);
- if (!section_map)
- panic("can not allocate section_map\n");
+ size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
+ usemap_map = alloc_bootmem(size);
+ if (!usemap_map)
+ panic("can not allocate usemap_map\n");
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
- section_map[pnum] = sparse_early_mem_map_alloc(pnum);
+ usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
}
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
- map = section_map[pnum];
+ map = sparse_early_mem_map_alloc(pnum);
if (!map)
continue;
- usemap = sparse_early_usemap_alloc(pnum);
+ usemap = usemap_map[pnum];
if (!usemap)
continue;
@@ -333,7 +337,7 @@ void __init sparse_init(void)
usemap);
}
- free_bootmem(__pa(section_map), size);
+ free_bootmem(__pa(usemap_map), size);
}
#ifdef CONFIG_MEMORY_HOTPLUG
^ permalink raw reply related
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Yinghai Lu @ 2008-04-02 22:24 UTC (permalink / raw)
To: Badari Pulavarty
Cc: lkml, Kamalesh Babulal, linuxppc-dev, Andrew Morton, Balbir Singh
In-Reply-To: <1207164127.30407.36.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > >>
> > > >> [ 0.000000] ------------[ cut here ]------------
> > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [ 0.000000] Modules linked in:
> > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [ 0.000000] Call Trace:
> > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > >> [ 0.000000] Instruction dump:
> > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > > >>
> > > >
> > > > int __meminit vmemmap_populate(struct page *start_page,
> > > > unsigned long nr_pages, int node)
> > > > {
> > > > unsigned long mode_rw;
> > > > unsigned long start = (unsigned long)start_page;
> > > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > > >
> > > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > > >
> > > > /* Align to the page size of the linear mapping. */
> > > > start = _ALIGN_DOWN(start, page_size);
> > > >
> > > > for (; start < end; start += page_size) {
> > > > int mapped;
> > > > void *p;
> > > >
> > > > if (vmemmap_populated(start, page_size))
> > > > continue;
> > > >
> > > > p = vmemmap_alloc_block(page_size, node);
> > > > if (!p)
> > > > return -ENOMEM;
> > > >
> > > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > > start, p, __pa(p));
> > > >
> > > > mapped = htab_bolt_mapping(start, start + page_size,
> > > > __pa(p), mode_rw, mmu_linear_psize,
> > > > mmu_kernel_ssize);
> > > > =====> BUG_ON(mapped < 0);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > > in git-powerpc...
> > >
> > > One of the machines is the Power5 and another is PowerMac G5, on which the
> > > same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
>
> Okay. Found it.
>
> Root cause is:
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
>
http://lkml.org/lkml/2008/4/2/592
Thanks
YH
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Badari Pulavarty @ 2008-04-02 23:51 UTC (permalink / raw)
To: yhlu.kernel
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
Ingo Molnar, Balbir Singh
In-Reply-To: <200804021525.48799.yhlu.kernel@gmail.com>
On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> so try to allocate usemap at first altogether.
>
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -294,7 +294,7 @@ void __init sparse_init(void)
> unsigned long pnum;
> struct page *map;
> unsigned long *usemap;
> - struct page **section_map;
> + unsigned long **usemap_map;
> int size;
> int node;
>
> @@ -305,27 +305,31 @@ void __init sparse_init(void)
> * make next 2M slip to one more 2M later.
> * then in big system, the memmory will have a lot hole...
> * here try to allocate 2M pages continously.
Comments are x86-64 specific. On ppc its 16MB chunks :(
> + *
> + * powerpc hope to sparse_init_one_section right after each
> + * sparse_early_mem_map_alloc, so allocate usemap_map
> + * at first.
> */
> - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> - section_map = alloc_bootmem(size);
> - if (!section_map)
> - panic("can not allocate section_map\n");
> + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> + usemap_map = alloc_bootmem(size);
> + if (!usemap_map)
> + panic("can not allocate usemap_map\n");
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
> - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> }
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
>
> - map = section_map[pnum];
> + map = sparse_early_mem_map_alloc(pnum);
> if (!map)
> continue;
>
> - usemap = sparse_early_usemap_alloc(pnum);
> + usemap = usemap_map[pnum];
> if (!usemap)
> continue;
You may want to move this check before doing sparse_early_mem_map_alloc
(). We are also not handling errors properly (freeing up the unused
map or usemap) if we "continue". I know the original code is this way,
but you touched it last :)
>
> @@ -333,7 +337,7 @@ void __init sparse_init(void)
> usemap);
> }
>
> - free_bootmem(__pa(section_map), size);
> + free_bootmem(__pa(usemap_map), size);
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
Tested and boots my machine fine.
Acked-by: Badari Pulavarty <pbadari@us.ibm.com>
Thanks,
Badari
^ permalink raw reply
* RE: Access physical memory via mmap() on ppc440epx.
From: Leonid @ 2008-04-02 22:50 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <406A31B117F2734987636D6CCC93EE3C025292E2@ehost011-3.exch011.intermedia.net>
Hi, Josh:
I have resolved my kernel driver problem, it was my own bug, didn't have
anything to do with memory remapping itself. Your suggestion to move to
ioremap64() did resolve problem completely.
I still need investigate mmap() crash. Apparently switch to mmap64()
didn't help, but it could be some another bug, I'll double check.
Thanks,
Leonid.=20
-----Original Message-----
From: linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+leonid=3Da-k-a.net@ozlabs.org] On =
Behalf
Of Leonid
Sent: Tuesday, April 01, 2008 9:30 PM
To: Josh Boyer
Cc: linuxppc-embedded@ozlabs.org
Subject: RE: Access physical memory via mmap() on ppc440epx.
Hi, Josh:
Thank you for your suggestion. Somehow it didn't work with mmap (may be,
my mistake, I'll double check), however it partially helped me with my
another problem.
I have kernel driver where I need read/write some HW device, connected
on address 0xea000000, chip select 4. This chip select configured
properly, here are EBC registers:
440EPx>rd ebc0_b4cr
ebc0_b4cr: 0xea01a000 -368992256
440EPx>rd ebc0_b4ap
ebc0_b4ap: 0x03037000 50556928
>From u-boot I can read/write this address with no problem (I use md/mw
commands).
In my driver I tried to ioremap() this address and any attempt to access
led to crash, same as with mmap().
When, following your suggestion, I used address 0x1ea00000 and
ioremap64(), crashes disappeared!
I even can write, but when I read data back I see least significant byte
of each 16 bits word only (bus is configured 16 bits width).=20
What can it be?
Thanks,
Leonid.=20
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@gmail.com]
Sent: Tuesday, April 01, 2008 6:44 PM
To: Leonid
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Access physical memory via mmap() on ppc440epx.
On Tue, 2008-04-01 at 14:12 -0700, Leonid wrote:
> Hi:
>=20
> I am trying to read from NOR flash, located on address 0xfc000000, on
my
It's at 0x1fc000000 IIRC.
> TLB entries look strange though. That what it was on u-boot stage:
>=20
> 440EPx>tlb 0 10
> IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
> 0 : 00 40000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
> 2 : 00 c0000000 256MB V0 -> 1_c0000000 U:0000 -I-G- XWRXWR
> 3 : 00 f0000000 256MB V0 -> 1_f0000000 U:0000 WI-G- XWRXWR
See. Virtual is 0xf0000000, physical is 0x1f0000000.
> On Linux stage it looks rather different:
I don't even see your entry in here. Likely because the TLB is small
and it's gone by the time you do the dump
> Probably under MMU it should look this way? How to use mmap() then?
Try mmap64 on the real physical address and see if that helps.
josh
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Andrew Morton @ 2008-04-02 22:52 UTC (permalink / raw)
To: yhlu.kernel
Cc: Balbir, Kamalesh, kernel list, Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Singh
In-Reply-To: <200804021525.48799.yhlu.kernel@gmail.com>
On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> on powerpc,
>
> On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> >
> > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > > Andrew Morton wrote:
> > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > > >
> > > > >> Hi Andrew,
> > > > >>
> > > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > > >>
> > > > >> [ 0.000000] ------------[ cut here ]------------
> > > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > > >> [ 0.000000] Modules linked in:
> > > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > > >> [ 0.000000] Call Trace:
> > > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > > >> [ 0.000000] Instruction dump:
> > > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >
> > mm-make-mem_map-allocation-continuous.patch
> > and its friends in -mm.
> >
> > You have to call sparse_init_one_section() on each pmap and usemap
> > as we allocate - since valid_section() depends on it (which is needed
> > by vmemmap_populate() to check if the section is populated or not).
> > On ppc, we need to call htab_bolted_mapping() on each section and
> > we need to skip existing sections.
> >
> > These patches tried to group all allocations together and then later
> > calls sparse_init_one_section() - which is not good :(
>
> so try to allocate usemap at first altogether.
I have to turn all the above crud into a proper changelog. I'd prefer that
you do it.
Unless this patch should be folded into another one, in which case it
doesn't matter.
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
We shouldn't merge this patch on its own because then that will leave a
non-bisectable region in the powerpc history.
So which patch is this patch fixing? Lexically it applies to
mm-allocate-section_map-for-sparse_init.patch (and its updates). But is
that where it logically lies?
^ permalink raw reply
* [PATCH] [POWERPC] Fix a mm compile error
From: Emil Medve @ 2008-04-02 23:05 UTC (permalink / raw)
To: paulus, linuxppc-dev, linuxppc-embedded; +Cc: Emil Medve
arch/powerpc/mm/init_32.c:102: error: conflicting types for '__initial_memory_limit_addr'
arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of '__initial_memory_limit_addr' was here
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
arch/powerpc/mm/init_32.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 555bb7e..63c5e3d 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM;
* address of the limit of what is accessible with initial MMU setup -
* 256MB usually, but only 16MB on 601.
*/
-unsigned long __initial_memory_limit_addr = 0x10000000;
+phys_addr_t __initial_memory_limit_addr = 0x10000000;
/*
* Check for command-line options that affect what MMU_init will do.
--
1.5.4.GIT
^ permalink raw reply related
* [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 23:22 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift properties to enable this core to be used.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
V3 has fixes suggested by Grant. They were incorporated and tested.
Documentation/powerpc/booting-without-of.txt | 10 ++++++++++
drivers/serial/of_serial.c | 14 +++++++++++++-
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 87f4d84..4066ec8 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
+ iv) Xilinx Uart 16550
+
+ Xilinx UART 16550 devices are very similar to the NS16550 but with
+ different register spacing and an offset from the base address.
+
+ Requred properties:
+ - clock-frequency : Frequency of the clock input
+ - reg-offset : A value of 3 is required
+ - reg-shift : A value of 2 is required
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..73c47a5 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -31,7 +31,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
struct resource resource;
struct device_node *np = ofdev->node;
const unsigned int *clk, *spd;
- int ret;
+ const u32 *prop;
+ int ret, prop_size;
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
@@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
spin_lock_init(&port->lock);
port->mapbase = resource.start;
+
+ /* Check for shifted address mapping */
+ prop = of_get_property(np, "reg-offset", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ port->mapbase += *prop;
+
+ /* Check for registers offset within the devices address range */
+ prop = of_get_property(np, "reg-shift", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ port->regshift = *prop;
+
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
port->type = type;
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Arnd Bergmann @ 2008-04-02 23:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, John Linn
In-Reply-To: <fa686aa40804021046n1bc0626ay6a3f9f2a251331ef@mail.gmail.com>
On Wednesday 02 April 2008, Grant Likely wrote:
> On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> > From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> >
> > =A0The of_serial driver queries the current-speed property and attempts
> > =A0to use it to register the custom_divisor property of the uart_port.
> > =A0However, if current-speed is not set, then this code will dereference
> > =A0a bad pointer. =A0The fix is to only set custom_divisor when a
> > =A0current-speed property appears in the device tree.
> >
> > =A0Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > =A0Signed-off-by: John Linn <john.linn@xilinx.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Arnd Bergmann @ 2008-04-02 23:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
In-Reply-To: <20080402232213.5D87515B8067@mail37-sin.bigfish.com>
On Thursday 03 April 2008, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
I may not be the best driver maintainer, but please keep the illusion
alive for me and Cc me on patches to drivers I wrote ;-)
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..4066ec8 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 but with
> + different register spacing and an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
Since it is not really compatible with ns16550, shouldn't you at least specify
a different "compatible" property? That way, the driver won't do incorrect
accesses when you try to use an old driver with a device tree that specifies
one of these.
> @@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
>
> spin_lock_init(&port->lock);
> port->mapbase = resource.start;
> +
> + /* Check for shifted address mapping */
> + prop = of_get_property(np, "reg-offset", &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + port->mapbase += *prop;
> +
> + /* Check for registers offset within the devices address range */
> + prop = of_get_property(np, "reg-shift", &prop_size);
> + if (prop && (prop_size == sizeof(u32)))
> + port->regshift = *prop;
> +
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
This part looks good to me.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: David Gibson @ 2008-04-03 0:02 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.C835D1CF8088@mail12-sin.bigfish.com>
On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
> ---
> arch/powerpc/boot/ns16550.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
Uh... how does the behaviour of reg-offset differ from just bumping
the address in "reg"?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: John Bonesio @ 2008-04-03 0:31 UTC (permalink / raw)
To: Johann Baudy; +Cc: linuxppc-embedded, John Linn, git
In-Reply-To: <7e0dd21a0804020020s66a091ferfbbf4142adcd84ae@mail.gmail.com>
The change with the extra parenthesis (in the patch starting with line 133)=
seems unecessary. I looked at the XLlDma_mBdWrite macro and it appeared to=
have the correct use of parethesis in the implementation.
So, assuming there's nothing subtle that I missed, it's not needed. However=
, it does no harm either.
The rest of the patch seems fine.
=2D John
On Wednesday 02 April 2008 00:20, Johann Baudy wrote:
> I've solved this checksum offloading issue with this below patch.
> It may help, if you need performance. It certainly needs review but it wo=
rks
> on my side.
>=20
> --- xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c.orig 2008-03-=
21
> 09:11:43.000000000 +0100
> +++ xilinxgit/drivers/net/xilinx_lltemac/xlltemac_main.c 2008-03-21
> 09:24:23.000000000 +0100
> @@ -133,7 +133,7 @@
> (XLlDma_mBdRead((BdPtr), XLLDMA_BD_STSCTRL_USR0_OFFSET)) &
> 0xFFFFFFFE )
>=20
> #define BdCsumSetup(BdPtr, Start, Insert) \
> - XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 |
> (Insert))
> + XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
> (Insert))
>=20
> /* Used for debugging */
> #define BdCsumInsert(BdPtr) \
> @@ -1540,7 +1541,7 @@ static int xenet_DmaSend_internal(struct
> /*
> * if tx checksum offloading is enabled, when the ethernet stack
> * wants us to perform the checksum in hardware,
> - * skb->ip_summed is CHECKSUM_COMPLETE. Otherwise skb->ip_summed is
> + * skb->ip_summed is CHECKSUM_PARTIAL. Otherwise skb->ip_summed is
> * CHECKSUM_NONE, meaning the checksum is already done, or
> * CHECKSUM_UNNECESSARY, meaning checksumming is turned off (e.g.
> * loopback interface)
> @@ -1565,9 +1566,11 @@ static int xenet_DmaSend_internal(struct
> * skb_transport_header(skb) points to the beginning of the ip header
> *
> */
> - if (skb->ip_summed =3D=3D CHECKSUM_COMPLETE) {
> + if (skb->ip_summed =3D=3D CHECKSUM_PARTIAL) {
> +
> + unsigned int csum_start_off =3D skb_transport_offset(skb);
> + unsigned int csum_index_off =3D csum_start_off + skb->csum_offse=
t;
>=20
> - unsigned char *raw =3D skb_transport_header(skb);
> #if 0
> {
> unsigned int csum =3D _xenet_tx_csum(skb);
> @@ -1578,9 +1581,8 @@ static int xenet_DmaSend_internal(struct
> }
> #else
> BdCsumEnable(bd_ptr);
> - BdCsumSetup(bd_ptr, raw - skb->data,
> - (raw - skb->data) + skb->csum);
> -
> + BdCsumSetup(bd_ptr, csum_start_off,
> + csum_index_off);
> #endif
> lp->tx_hw_csums++;
> }
> @@ -3277,7 +3279,7 @@ static int __devinit xtenet_of_probe(str
> struct resource *r_irq =3D &r_irq_struct; /* Interrupt resources =
*/
> struct resource *r_mem =3D &r_mem_struct; /* IO mem resources */
> struct xlltemac_platform_data *pdata =3D &pdata_struct;
> - void *mac_address;
> + const void *mac_address;
> int rc =3D 0;
> const phandle *llink_connected_handle;
> struct device_node *llink_connected_node;
>=20
>=20
> On Mon, Mar 31, 2008 at 11:10 AM, Magnus Hjorth <mh@omnisys.se> wrote:
>=20
> > Deactivating checksum offloading helped a lot! I still have some packet
> > loss and not the best performance (TFTP transfer about 100 kbyte/s) but=
at
> > least it works.
> >
> > Thanks!
> >
> > //Magnus
> >
> > > -----Original Message-----
> > > From: rza1 [mailto:rza1@so-logic.net]
> > > Sent: den 31 mars 2008 11:14
> > > To: Magnus Hjorth
> > > Cc: John Linn; git; linuxppc-embedded@ozlabs.org
> > > Subject: Re: Xilinx LLTEMAC driver issues
> > >
> > > Hi Magnus,
> > >
> > > 1.
> > > I am using nearly the same versions then you and got the same problems
> > > too ;-).
> > > I think there are some problems with the checksum offloading.
> > > Try to sniff the some packages (e.g. wireshark)...
> > > For me ICMP (ping) worked but udp and tcp not (because off a wrong
> > > checksum in the transport layer).
> > > A quick solution is to just deactivate checksum offloading.
> > >
> > > 2.
> > > I remember some problems with Virtex-4 presamples too.
> > > There where problems with the hard-temac wrapper. You had to use 1.00=
=2Ea
> > > and not b version.
> > > But I don't have these problems with the EDK 9.2sp2/ISE9.2sp3 anymore.
> > >
> > > all the best,
> > > Robert
> > >
> > > Magnus Hjorth wrote:
> > > > Hi John,
> > > >
> > > > Thanks for the very fast reply! Right now I'm not at work so I don't
> > > > have the board or EDK here to test anything.
> > > >
> > > > I'm using checksum offload, but I don't know if DRE is enabled or n=
ot.
> > I
> > > > can't recall seeing any setting to enable/disable DRE..
> > > >
> > > > A few things that crossed my mind:
> > > >
> > > > Last year I did a design with EDK 8.2, back then there was an issue
> > with
> > > > the ML403 boards having an old revision of the FPGA which wasn't
> > > > compatible with some versions of the IP core. There are no such
> > version
> > > > issues with the xps_ll_temac?
> > > >
> > > > I don't think that I had phy-addr set in the DTS file. Will test th=
at
> > on
> > > > Monday.
> > > >
> > > > Best regards,
> > > > Magnus
> > > >
> > > >
> > > > On Sat, 2008-03-29 at 07:58 -0600, John Linn wrote:
> > > >
> > > >> Hi Magnus,
> > > >>
> > > >> Sorry to hear you're having problems with it.
> > > >>
> > > >> I am doing testing on an ML405 which is the same board but with a
> > bigger
> > > FPGA, but with ppc arch and I don't see this issue. I have done limit=
ed
> > testing
> > > with powerpc arch and the LL TEMAC, but I didn't see this issue there
> > either.
> > > Powerpc arch is definitely less mature in my experience than the ppc
> > arch. I'll
> > > do a quick test with my powerpc arch and make sure again I'm not seei=
ng
> > it.
> > > >>
> > > >> My kernel is from the Xilinx Git tree, but there have been a number
> > of
> > > changes we have pushed out so I don't know how long ago you pulled fr=
om
> > the Git
> > > tree.
> > > >>
> > > >> My EDK project is 10.1 so it's a little newer. I am using LL TEMAC
> > 1.01a so
> > > it's a little newer. I reviewed the change log for the LL TEMAC and
> > don't see
> > > any big problems that were fixed in the newer versions, more new
> > features. I'll
> > > check with some others here to see if I missed something there.
> > > >>
> > > >> I am using DMA also, but no DRE or checksum offload. You didn't s=
ay
> > anything
> > > about those. I'm going to insert my mhs file that describes my system=
to
> > let you
> > > compare your system configuration. It's not clear to me yet if you ha=
ve
> > a h/w or
> > > s/w problem.
> > > >>
> > > >> I'll also insert some of my device tree with the LL TEMAC so you c=
an
> > compare
> > > (ignore 16550 stuff as we are still working on that).
> > > >>
> > > >> Since you can't ping reliably I would probably focus on that since
> > it's
> > > simpler than the other issues you're seeing.
> > > >>
> > > >> Thanks,
> > > >> John
> > > >>
> > > >>
> > > >>
> > > >> #
> > >
> > #######################################################################=
#######
> > > >> # Created by Base System Builder Wizard for Xilinx EDK 10.1.1 Build
> > > EDK_K_SP1.1
> > > >> # Thu Feb 14 14:11:12 2008
> > > >> # Target Board: Xilinx Virtex 4 ML405 Evaluation Platform Rev 1
> > > >> # Family: virtex4
> > > >> # Device: xc4vfx20
> > > >> # Package: ff672
> > > >> # Speed Grade: -10
> > > >> # Processor: ppc405_0
> > > >> # Processor clock frequency: 300.00 MHz
> > > >> # Bus clock frequency: 100.00 MHz
> > > >> # On Chip Memory : 8 KB
> > > >> # Total Off Chip Memory : 128 MB
> > > >> # - DDR_SDRAM =3D 128 MB
> > > >> #
> > >
> > #######################################################################=
#######
> > > >> PARAMETER VERSION =3D 2.1.0
> > > >>
> > > >>
> > > >> PORT fpga_0_RS232_Uart_sin_pin =3D fpga_0_RS232_Uart_sin, DIR =3D=
I
> > > >> PORT fpga_0_RS232_Uart_sout_pin =3D fpga_0_RS232_Uart_sout, DIR =
=3D O
> > > >> PORT fpga_0_LEDs_4Bit_GPIO_IO_pin =3D fpga_0_LEDs_4Bit_GPIO_IO, D=
IR =3D
> > IO, VEC
> > > =3D [0:3]
> > > >> PORT fpga_0_IIC_EEPROM_Scl_pin =3D fpga_0_IIC_EEPROM_Scl, DIR =3D=
IO
> > > >> PORT fpga_0_IIC_EEPROM_Sda_pin =3D fpga_0_IIC_EEPROM_Sda, DIR =3D=
IO
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CLK_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_CLK, DIR =3D I
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPA_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_MPA, DIR =3D O, VEC =3D [6:1]
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPD_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_MPD, DIR =3D IO, VEC =3D [15:0]
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_CEN_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_CEN, DIR =3D O
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_OEN_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_OEN, DIR =3D O
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_WEN_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_WEN, DIR =3D O
> > > >> PORT fpga_0_SysACE_CompactFlash_SysACE_MPIRQ_pin =3D
> > > fpga_0_SysACE_CompactFlash_SysACE_MPIRQ, DIR =3D I
> > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_pin =3D fpga_0_DDR_SDRAM_DDR_Clk, D=
IR =3D
> > O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_Clk_n_pin =3D fpga_0_DDR_SDRAM_DDR_Clk_=
n,
> > DIR =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_Addr_pin =3D fpga_0_DDR_SDRAM_DDR_Addr,=
DIR
> > =3D O, VEC
> > > =3D [12:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_BankAddr_pin =3D
> > fpga_0_DDR_SDRAM_DDR_BankAddr, DIR
> > > =3D O, VEC =3D [1:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_CAS_n_pin =3D fpga_0_DDR_SDRAM_DDR_CAS_=
n,
> > DIR =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_CE_pin =3D fpga_0_DDR_SDRAM_DDR_CE, DIR=
=3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_CS_n_pin =3D fpga_0_DDR_SDRAM_DDR_CS_n,=
DIR
> > =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_RAS_n_pin =3D fpga_0_DDR_SDRAM_DDR_RAS_=
n,
> > DIR =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_WE_n_pin =3D fpga_0_DDR_SDRAM_DDR_WE_n,=
DIR
> > =3D O
> > > >> PORT fpga_0_DDR_SDRAM_DDR_DM_pin =3D fpga_0_DDR_SDRAM_DDR_DM, DIR=
=3D O,
> > VEC =3D
> > > [3:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_DQS =3D fpga_0_DDR_SDRAM_DDR_DQS, DIR =
=3D IO,
> > VEC =3D
> > > [3:0]
> > > >> PORT fpga_0_DDR_SDRAM_DDR_DQ =3D fpga_0_DDR_SDRAM_DDR_DQ, DIR =3D=
IO,
> > VEC =3D
> > > [31:0]
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TXD_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TXD_0, DIR =3D O, VEC =3D [7:0]
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0, DIR =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0, DIR =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0, DIR =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RXD_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RXD_0, DIR =3D I, VEC =3D [7:0]
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0_pin =3D
> > > fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0, DIR =3D I
> > > >> PORT fpga_0_TriMode_MAC_GMII_MDIO_0_pin =3D
> > fpga_0_TriMode_MAC_GMII_MDIO_0,
> > > DIR =3D IO
> > > >> PORT fpga_0_TriMode_MAC_GMII_MDC_0_pin =3D
> > fpga_0_TriMode_MAC_GMII_MDC_0, DIR
> > > =3D O
> > > >> PORT fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n_pin =3D
> > > fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n, DIR =3D O
> > > >> PORT sys_clk_pin =3D dcm_clk_s, DIR =3D I, SIGIS =3D CLK, CLK_FRE=
Q =3D
> > 100000000
> > > >> PORT sys_rst_pin =3D sys_rst_s, DIR =3D I, RST_POLARITY =3D 0, SI=
GIS =3D RST
> > > >>
> > > >>
> > > >> BEGIN ppc405_virtex4
> > > >> PARAMETER INSTANCE =3D ppc405_0
> > > >> PARAMETER HW_VER =3D 2.01.a
> > > >> PARAMETER C_FASTEST_PLB_CLOCK =3D DPLB1
> > > >> PARAMETER C_IDCR_BASEADDR =3D 0b0100000000
> > > >> PARAMETER C_IDCR_HIGHADDR =3D 0b0111111111
> > > >> BUS_INTERFACE JTAGPPC =3D jtagppc_0_0
> > > >> BUS_INTERFACE IPLB0 =3D plb
> > > >> BUS_INTERFACE DPLB0 =3D plb
> > > >> BUS_INTERFACE IPLB1 =3D ppc405_0_iplb1
> > > >> BUS_INTERFACE DPLB1 =3D ppc405_0_dplb1
> > > >> BUS_INTERFACE RESETPPC =3D ppc_reset_bus
> > > >> PORT CPMC405CLOCK =3D proc_clk_s
> > > >> PORT EICC405EXTINPUTIRQ =3D EICC405EXTINPUTIRQ
> > > >> END
> > > >>
> > > >> BEGIN jtagppc_cntlr
> > > >> PARAMETER INSTANCE =3D jtagppc_0
> > > >> PARAMETER HW_VER =3D 2.01.a
> > > >> BUS_INTERFACE JTAGPPC0 =3D jtagppc_0_0
> > > >> END
> > > >>
> > > >> BEGIN plb_v46
> > > >> PARAMETER INSTANCE =3D plb
> > > >> PARAMETER C_DCR_INTFCE =3D 0
> > > >> PARAMETER C_NUM_CLK_PLB2OPB_REARB =3D 100
> > > >> PARAMETER HW_VER =3D 1.02.a
> > > >> PORT PLB_Clk =3D sys_clk_s
> > > >> PORT SYS_Rst =3D sys_bus_reset
> > > >> END
> > > >>
> > > >> BEGIN xps_bram_if_cntlr
> > > >> PARAMETER INSTANCE =3D xps_bram_if_cntlr_1
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_SPLB_NATIVE_DWIDTH =3D 64
> > > >> PARAMETER C_BASEADDR =3D 0xffffe000
> > > >> PARAMETER C_HIGHADDR =3D 0xffffffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> BUS_INTERFACE PORTA =3D xps_bram_if_cntlr_1_port
> > > >> END
> > > >>
> > > >> BEGIN bram_block
> > > >> PARAMETER INSTANCE =3D plb_bram_if_cntlr_1_bram
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> BUS_INTERFACE PORTA =3D xps_bram_if_cntlr_1_port
> > > >> END
> > > >>
> > > >> BEGIN xps_uart16550
> > > >> PARAMETER INSTANCE =3D RS232_Uart
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_IS_A_16550 =3D 1
> > > >> PARAMETER C_BASEADDR =3D 0x83e00000
> > > >> PARAMETER C_HIGHADDR =3D 0x83e0ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT sin =3D fpga_0_RS232_Uart_sin
> > > >> PORT sout =3D fpga_0_RS232_Uart_sout
> > > >> PORT IP2INTC_Irpt =3D RS232_Uart_IP2INTC_Irpt
> > > >> END
> > > >>
> > > >> BEGIN xps_gpio
> > > >> PARAMETER INSTANCE =3D LEDs_4Bit
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_INTERRUPT_PRESENT =3D 1
> > > >> PARAMETER C_GPIO_WIDTH =3D 4
> > > >> PARAMETER C_IS_DUAL =3D 0
> > > >> PARAMETER C_IS_BIDIR =3D 1
> > > >> PARAMETER C_ALL_INPUTS =3D 0
> > > >> PARAMETER C_BASEADDR =3D 0x81400000
> > > >> PARAMETER C_HIGHADDR =3D 0x8140ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT GPIO_IO =3D fpga_0_LEDs_4Bit_GPIO_IO
> > > >> PORT IP2INTC_Irpt =3D LEDs_4Bit_IP2INTC_Irpt
> > > >> END
> > > >>
> > > >> BEGIN xps_iic
> > > >> PARAMETER INSTANCE =3D IIC_EEPROM
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_CLK_FREQ =3D 100000000
> > > >> PARAMETER C_IIC_FREQ =3D 100000
> > > >> PARAMETER C_TEN_BIT_ADR =3D 0
> > > >> PARAMETER C_BASEADDR =3D 0x81600000
> > > >> PARAMETER C_HIGHADDR =3D 0x8160ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT Scl =3D fpga_0_IIC_EEPROM_Scl
> > > >> PORT Sda =3D fpga_0_IIC_EEPROM_Sda
> > > >> PORT IIC2INTC_Irpt =3D IIC_EEPROM_IIC2INTC_Irpt
> > > >> END
> > > >>
> > > >> BEGIN xps_sysace
> > > >> PARAMETER INSTANCE =3D SysACE_CompactFlash
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_MEM_WIDTH =3D 16
> > > >> PARAMETER C_BASEADDR =3D 0x83600000
> > > >> PARAMETER C_HIGHADDR =3D 0x8360ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT SysACE_CLK =3D fpga_0_SysACE_CompactFlash_SysACE_CLK
> > > >> PORT SysACE_MPA =3D fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > > >> PORT SysACE_MPD =3D fpga_0_SysACE_CompactFlash_SysACE_MPD
> > > >> PORT SysACE_CEN =3D fpga_0_SysACE_CompactFlash_SysACE_CEN
> > > >> PORT SysACE_OEN =3D fpga_0_SysACE_CompactFlash_SysACE_OEN
> > > >> PORT SysACE_WEN =3D fpga_0_SysACE_CompactFlash_SysACE_WEN
> > > >> PORT SysACE_MPIRQ =3D fpga_0_SysACE_CompactFlash_SysACE_MPIRQ
> > > >> PORT SysACE_IRQ =3D SysACE_CompactFlash_SysACE_IRQ
> > > >> END
> > > >>
> > > >> BEGIN mpmc
> > > >> PARAMETER INSTANCE =3D DDR_SDRAM
> > > >> PARAMETER HW_VER =3D 4.00.a
> > > >> PARAMETER C_NUM_PORTS =3D 3
> > > >> PARAMETER C_MEM_PARTNO =3D HYB25D512160BE-5
> > > >> PARAMETER C_MEM_DATA_WIDTH =3D 32
> > > >> PARAMETER C_MEM_DQS_WIDTH =3D 4
> > > >> PARAMETER C_MEM_DM_WIDTH =3D 4
> > > >> PARAMETER C_MEM_TYPE =3D DDR
> > > >> PARAMETER C_NUM_IDELAYCTRL =3D 2
> > > >> PARAMETER C_IDELAYCTRL_LOC =3D IDELAYCTRL_X0Y3-IDELAYCTRL_X0Y2
> > > >> PARAMETER C_PIM0_BASETYPE =3D 2
> > > >> PARAMETER C_PIM1_BASETYPE =3D 2
> > > >> PARAMETER C_PIM2_BASETYPE =3D 3
> > > >> PARAMETER C_MPMC_CLK0_PERIOD_PS =3D 10000
> > > >> PARAMETER C_SDMA2_PI2LL_CLK_RATIO =3D 1
> > > >> PARAMETER C_MPMC_BASEADDR =3D 0x00000000
> > > >> PARAMETER C_MPMC_HIGHADDR =3D 0x07ffffff
> > > >> PARAMETER C_SDMA_CTRL_BASEADDR =3D 0x84600000
> > > >> PARAMETER C_SDMA_CTRL_HIGHADDR =3D 0x8460ffff
> > > >> BUS_INTERFACE SPLB0 =3D ppc405_0_iplb1
> > > >> BUS_INTERFACE SPLB1 =3D ppc405_0_dplb1
> > > >> BUS_INTERFACE SDMA_LL2 =3D TriMode_MAC_GMII_LLINK0
> > > >> BUS_INTERFACE SDMA_CTRL2 =3D plb
> > > >> PORT DDR_Addr =3D fpga_0_DDR_SDRAM_DDR_Addr
> > > >> PORT DDR_BankAddr =3D fpga_0_DDR_SDRAM_DDR_BankAddr
> > > >> PORT DDR_CAS_n =3D fpga_0_DDR_SDRAM_DDR_CAS_n
> > > >> PORT DDR_CE =3D fpga_0_DDR_SDRAM_DDR_CE
> > > >> PORT DDR_CS_n =3D fpga_0_DDR_SDRAM_DDR_CS_n
> > > >> PORT DDR_RAS_n =3D fpga_0_DDR_SDRAM_DDR_RAS_n
> > > >> PORT DDR_WE_n =3D fpga_0_DDR_SDRAM_DDR_WE_n
> > > >> PORT DDR_DM =3D fpga_0_DDR_SDRAM_DDR_DM
> > > >> PORT DDR_DQS =3D fpga_0_DDR_SDRAM_DDR_DQS
> > > >> PORT DDR_DQ =3D fpga_0_DDR_SDRAM_DDR_DQ
> > > >> PORT DDR_Clk =3D fpga_0_DDR_SDRAM_DDR_Clk
> > > >> PORT DDR_Clk_n =3D fpga_0_DDR_SDRAM_DDR_Clk_n
> > > >> PORT MPMC_Clk0 =3D sys_clk_s
> > > >> PORT MPMC_Clk90 =3D DDR_SDRAM_mpmc_clk_90_s
> > > >> PORT SDMA2_Clk =3D sys_clk_s
> > > >> PORT MPMC_Clk_200MHz =3D clk_200mhz_s
> > > >> PORT MPMC_Rst =3D sys_periph_reset
> > > >> PORT SDMA2_Rx_IntOut =3D DDR_SDRAM_SDMA2_Rx_IntOut
> > > >> PORT SDMA2_Tx_IntOut =3D DDR_SDRAM_SDMA2_Tx_IntOut
> > > >> END
> > > >>
> > > >> BEGIN xps_ll_temac
> > > >> PARAMETER INSTANCE =3D TriMode_MAC_GMII
> > > >> PARAMETER HW_VER =3D 1.01.a
> > > >> PARAMETER C_SPLB_CLK_PERIOD_PS =3D 10000
> > > >> PARAMETER C_PHY_TYPE =3D 1
> > > >> PARAMETER C_NUM_IDELAYCTRL =3D 4
> > > >> PARAMETER C_IDELAYCTRL_LOC =3D IDELAYCTRL_X1Y1-IDELAYCTRL_X1Y3-
> > > IDELAYCTRL_X2Y2-IDELAYCTRL_X2Y3
> > > >> PARAMETER C_TEMAC_TYPE =3D 1
> > > >> PARAMETER C_BUS2CORE_CLK_RATIO =3D 1
> > > >> PARAMETER C_BASEADDR =3D 0x81c00000
> > > >> PARAMETER C_HIGHADDR =3D 0x81c0ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> BUS_INTERFACE LLINK0 =3D TriMode_MAC_GMII_LLINK0
> > > >> PORT GMII_TXD_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TXD_0
> > > >> PORT GMII_TX_EN_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_EN_0
> > > >> PORT GMII_TX_ER_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_ER_0
> > > >> PORT GMII_TX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_GMII_TX_CLK_0
> > > >> PORT GMII_RXD_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RXD_0
> > > >> PORT GMII_RX_DV_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_DV_0
> > > >> PORT GMII_RX_ER_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_ER_0
> > > >> PORT GMII_RX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_GMII_RX_CLK_0
> > > >> PORT MII_TX_CLK_0 =3D fpga_0_TriMode_MAC_GMII_MII_TX_CLK_0
> > > >> PORT MDIO_0 =3D fpga_0_TriMode_MAC_GMII_MDIO_0
> > > >> PORT MDC_0 =3D fpga_0_TriMode_MAC_GMII_MDC_0
> > > >> PORT TemacPhy_RST_n =3D fpga_0_TriMode_MAC_GMII_TemacPhy_RST_n
> > > >> PORT GTX_CLK_0 =3D temac_clk_s
> > > >> PORT REFCLK =3D clk_200mhz_s
> > > >> PORT LlinkTemac0_CLK =3D sys_clk_s
> > > >> PORT TemacIntc0_Irpt =3D TriMode_MAC_GMII_TemacIntc0_Irpt
> > > >> END
> > > >>
> > > >> BEGIN util_bus_split
> > > >> PARAMETER INSTANCE =3D SysACE_CompactFlash_util_bus_split_0
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_SIZE_IN =3D 7
> > > >> PARAMETER C_LEFT_POS =3D 0
> > > >> PARAMETER C_SPLIT =3D 6
> > > >> PORT Sig =3D fpga_0_SysACE_CompactFlash_SysACE_MPA_split
> > > >> PORT Out1 =3D fpga_0_SysACE_CompactFlash_SysACE_MPA
> > > >> END
> > > >>
> > > >> BEGIN plb_v46
> > > >> PARAMETER INSTANCE =3D ppc405_0_iplb1
> > > >> PARAMETER HW_VER =3D 1.02.a
> > > >> PORT PLB_Clk =3D sys_clk_s
> > > >> PORT SYS_Rst =3D sys_bus_reset
> > > >> END
> > > >>
> > > >> BEGIN plb_v46
> > > >> PARAMETER INSTANCE =3D ppc405_0_dplb1
> > > >> PARAMETER HW_VER =3D 1.02.a
> > > >> PORT PLB_Clk =3D sys_clk_s
> > > >> PORT SYS_Rst =3D sys_bus_reset
> > > >> END
> > > >>
> > > >> BEGIN clock_generator
> > > >> PARAMETER INSTANCE =3D clock_generator_0
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_EXT_RESET_HIGH =3D 1
> > > >> PARAMETER C_CLKIN_FREQ =3D 100000000
> > > >> PARAMETER C_CLKOUT0_FREQ =3D 100000000
> > > >> PARAMETER C_CLKOUT0_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT0_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT0_GROUP =3D DCM0
> > > >> PARAMETER C_CLKOUT1_FREQ =3D 100000000
> > > >> PARAMETER C_CLKOUT1_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT1_PHASE =3D 90
> > > >> PARAMETER C_CLKOUT1_GROUP =3D DCM0
> > > >> PARAMETER C_CLKOUT2_FREQ =3D 300000000
> > > >> PARAMETER C_CLKOUT2_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT2_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT2_GROUP =3D DCM0
> > > >> PARAMETER C_CLKOUT3_FREQ =3D 200000000
> > > >> PARAMETER C_CLKOUT3_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT3_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT3_GROUP =3D NONE
> > > >> PARAMETER C_CLKOUT4_FREQ =3D 125000000
> > > >> PARAMETER C_CLKOUT4_BUF =3D TRUE
> > > >> PARAMETER C_CLKOUT4_PHASE =3D 0
> > > >> PARAMETER C_CLKOUT4_GROUP =3D NONE
> > > >> PORT CLKOUT0 =3D sys_clk_s
> > > >> PORT CLKOUT1 =3D DDR_SDRAM_mpmc_clk_90_s
> > > >> PORT CLKOUT2 =3D proc_clk_s
> > > >> PORT CLKOUT3 =3D clk_200mhz_s
> > > >> PORT CLKOUT4 =3D temac_clk_s
> > > >> PORT CLKIN =3D dcm_clk_s
> > > >> PORT LOCKED =3D Dcm_all_locked
> > > >> PORT RST =3D net_gnd
> > > >> END
> > > >>
> > > >> BEGIN proc_sys_reset
> > > >> PARAMETER INSTANCE =3D proc_sys_reset_0
> > > >> PARAMETER HW_VER =3D 2.00.a
> > > >> PARAMETER C_EXT_RESET_HIGH =3D 0
> > > >> BUS_INTERFACE RESETPPC0 =3D ppc_reset_bus
> > > >> PORT Slowest_sync_clk =3D sys_clk_s
> > > >> PORT Dcm_locked =3D Dcm_all_locked
> > > >> PORT Ext_Reset_In =3D sys_rst_s
> > > >> PORT Bus_Struct_Reset =3D sys_bus_reset
> > > >> PORT Peripheral_Reset =3D sys_periph_reset
> > > >> END
> > > >>
> > > >> BEGIN xps_intc
> > > >> PARAMETER INSTANCE =3D xps_intc_0
> > > >> PARAMETER HW_VER =3D 1.00.a
> > > >> PARAMETER C_BASEADDR =3D 0x81800000
> > > >> PARAMETER C_HIGHADDR =3D 0x8180ffff
> > > >> BUS_INTERFACE SPLB =3D plb
> > > >> PORT Irq =3D EICC405EXTINPUTIRQ
> > > >> PORT Intr =3D RS232_Uart_IP2INTC_Irpt & LEDs_4Bit_IP2INTC_Irpt &
> > > IIC_EEPROM_IIC2INTC_Irpt & SysACE_CompactFlash_SysACE_IRQ &
> > > TriMode_MAC_GMII_TemacIntc0_Irpt & DDR_SDRAM_SDMA2_Rx_IntOut &
> > > DDR_SDRAM_SDMA2_Tx_IntOut
> > > >> END
> > > >>
> > > >>
> > > >>
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,virtex";
> > > >> model =3D "testing";
> > > >> DDR_SDRAM: memory@0 {
> > > >> device_type =3D "memory";
> > > >> reg =3D < 0 8000000 >;
> > > >> } ;
> > > >> chosen {
> > > >> bootargs =3D "console=3DttyS0,9600 ip=3Don
> > > nfsroot=3D172.16.40.76:/v2pclients/jhl26,tcp";
> > > >> linux,stdout-path =3D "/plb@0/serial@83e00000";
> > > >> } ;
> > > >> cpus {
> > > >> #address-cells =3D <1>;
> > > >> #cpus =3D <1>;
> > > >> #size-cells =3D <0>;
> > > >> ppc405_0: cpu@0 {
> > > >> clock-frequency =3D <11e1a300>;
> > > >> compatible =3D "PowerPC,405", "ibm,ppc405";
> > > >> d-cache-line-size =3D <20>;
> > > >> d-cache-size =3D <4000>;
> > > >> device_type =3D "cpu";
> > > >> i-cache-line-size =3D <20>;
> > > >> i-cache-size =3D <4000>;
> > > >> model =3D "PowerPC,405";
> > > >> reg =3D <0>;
> > > >> timebase-frequency =3D <11e1a300>;
> > > >> xlnx,apu-control =3D <de00>;
> > > >> xlnx,apu-udi-1 =3D <a18983>;
> > > >> xlnx,apu-udi-2 =3D <a38983>;
> > > >> xlnx,apu-udi-3 =3D <a589c3>;
> > > >> xlnx,apu-udi-4 =3D <a789c3>;
> > > >> xlnx,apu-udi-5 =3D <a98c03>;
> > > >> xlnx,apu-udi-6 =3D <ab8c03>;
> > > >> xlnx,apu-udi-7 =3D <ad8c43>;
> > > >> xlnx,apu-udi-8 =3D <af8c43>;
> > > >> xlnx,deterministic-mult =3D <0>;
> > > >> xlnx,disable-operand-forwarding =3D <1>;
> > > >> xlnx,fastest-plb-clock =3D "DPLB0";
> > > >> xlnx,generate-plb-timespecs =3D <1>;
> > > >> xlnx,mmu-enable =3D <1>;
> > > >> xlnx,pvr-high =3D <0>;
> > > >> xlnx,pvr-low =3D <0>;
> > > >> } ;
> > > >> } ;
> > > >> plb: plb@0 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,plb-v46-1.02.a";
> > > >> ranges ;
> > > >> IIC_EEPROM: i2c@81600000 {
> > > >> compatible =3D "xlnx,xps-iic-2.00.a";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 4 2 >;
> > > >> reg =3D < 81600000 10000 >;
> > > >> xlnx,clk-freq =3D <5f5e100>;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,gpo-width =3D <1>;
> > > >> xlnx,iic-freq =3D <186a0>;
> > > >> xlnx,scl-inertial-delay =3D <0>;
> > > >> xlnx,sda-inertial-delay =3D <0>;
> > > >> xlnx,ten-bit-adr =3D <0>;
> > > >> } ;
> > > >> LEDs_4Bit: gpio@81400000 {
> > > >> compatible =3D "xlnx,xps-gpio-1.00.a";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 5 2 >;
> > > >> reg =3D < 81400000 10000 >;
> > > >> xlnx,all-inputs =3D <0>;
> > > >> xlnx,all-inputs-2 =3D <0>;
> > > >> xlnx,dout-default =3D <0>;
> > > >> xlnx,dout-default-2 =3D <0>;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,gpio-width =3D <4>;
> > > >> xlnx,interrupt-present =3D <1>;
> > > >> xlnx,is-bidir =3D <1>;
> > > >> xlnx,is-bidir-2 =3D <1>;
> > > >> xlnx,is-dual =3D <0>;
> > > >> xlnx,tri-default =3D <ffffffff>;
> > > >> xlnx,tri-default-2 =3D <ffffffff>;
> > > >> } ;
> > > >> RS232_Uart: serial@83e00000 {
> > > >> compatible =3D "xlnx,xps-uart16550-2.00.a";
> > > >> // compatible =3D "ns16550";
> > > >> device_type =3D "serial";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 6 2 >;
> > > >> reg =3D < 83e00000 10000 >;
> > > >> current-speed =3D <d#9600>;
> > > >> clock-frequency =3D <d#100000000>; /* added
> > > by jhl */
> > > >> reg-shift =3D <2>;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,has-external-rclk =3D <0>;
> > > >> xlnx,has-external-xin =3D <0>;
> > > >> xlnx,is-a-16550 =3D <1>;
> > > >> } ;
> > > >> SysACE_CompactFlash: sysace@83600000 {
> > > >> compatible =3D "xlnx,xps-sysace-1.00.a";
> > > >> interrupt-parent =3D <&xps_intc_0>;
> > > >> interrupts =3D < 3 2 >;
> > > >> reg =3D < 83600000 10000 >;
> > > >> xlnx,family =3D "virtex4";
> > > >> xlnx,mem-width =3D <10>;
> > > >> } ;
> > > >> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,compound";
> > > >> ethernet@81c00000 {
> > > >> compatible =3D "xlnx,xps-ll-temac-
> > > 1.01.a";
> > > >> device_type =3D "network";
> > > >> interrupt-parent =3D
> > > <&xps_intc_0>;
> > > >> interrupts =3D < 2 2 >;
> > > >> llink-connected =3D <&PIM2>;
> > > >> local-mac-address =3D [ 02 00 00
> > > 00 00 01 ];
> > > >> reg =3D < 81c00000 40 >;
> > > >> xlnx,bus2core-clk-ratio =3D <1>;
> > > >> xlnx,phy-type =3D <1>;
> > > >> xlnx,phyaddr =3D <1>;
> > > >> xlnx,rxcsum =3D <0>;
> > > >> xlnx,rxfifo =3D <1000>;
> > > >> xlnx,temac-type =3D <1>;
> > > >> xlnx,txcsum =3D <0>;
> > > >> xlnx,txfifo =3D <1000>;
> > > >> } ;
> > > >> } ;
> > > >> mpmc@0 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,mpmc-4.00.a";
> > > >> PIM2: sdma@84600100 {
> > > >> compatible =3D "xlnx,ll-dma-
> > > 1.00.a";
> > > >> interrupt-parent =3D
> > > <&xps_intc_0>;
> > > >> interrupts =3D < 1 2 0 2 >;
> > > >> reg =3D < 84600100 80 >;
> > > >> } ;
> > > >> } ;
> > > >> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
> > > >> compatible =3D "xlnx,xps-bram-if-cntlr-
> > > 1.00.a";
> > > >> reg =3D < ffffe000 2000 >;
> > > >> xlnx,family =3D "virtex4";
> > > >> } ;
> > > >> xps_intc_0: interrupt-controller@81800000 {
> > > >> #interrupt-cells =3D <2>;
> > > >> compatible =3D "xlnx,xps-intc-1.00.a";
> > > >> interrupt-controller ;
> > > >> reg =3D < 81800000 10000 >;
> > > >> xlnx,num-intr-inputs =3D <7>;
> > > >> } ;
> > > >> } ;
> > > >> ppc405_0_dplb1: plb@1 {
> > > >> #address-cells =3D <1>;
> > > >> #size-cells =3D <1>;
> > > >> compatible =3D "xlnx,plb-v46-1.02.a";
> > > >> ranges ;
> > > >> } ;
> > > >> } ;
> > > >>
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: Magnus Hjorth [mailto:mh@omnisys.se]
> > > >> Sent: Saturday, March 29, 2008 6:54 AM
> > > >> To: git
> > > >> Cc: linuxppc-embedded@ozlabs.org
> > > >> Subject: Xilinx LLTEMAC driver issues
> > > >>
> > > >> Hi,
> > > >>
> > > >> I'm having some networking troubles with the Xilinx LLTEMAC driver
> > from the
> > > >> Xilinx Linux git tree (powerpc arch) on an ML403 board. EDK9.2SP2,
> > > >> xps_ll_temac v1.00.b
> > > >>
> > > >> The weird thing is, that it sort of half works. It successfully ma=
kes
> > a DHCP
> > > >> request and gets its IP address. I tried setting up a tftpd server,
> > and I can
> > > >> see UDP requests coming in but the response doesn't seem to come o=
ut.
> > I also
> > > >> tried running a TCP server on the board, and it can see and accept
> > incoming
> > > >> connections but after that no data seems to get through. I can ping
> > out and
> > > >> get around 40% packet loss.
> > > >>
> > > >> Looking at /proc/interrupts, I can see both TxDma interrupts and
> > RxDma
> > > >> interrupts. No eth0 interrupts but that seems to be OK judging by =
the
> > driver
> > > >> source comments. Ifconfig shows no collistions, no dropped packets,
> > no
> > > errors,
> > > >> so the system seems to think that everything is OK.
> > > >>
> > > >> Clues anyone? I'm starting to run out of ideas...
> > > >>
> > > >> Best regards,
> > > >> Magnus
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Magnus Hjorth, M.Sc.
> > > >> Omnisys Instruments AB
> > > >> Gruvgatan 8
> > > >> SE-421 30 V=C3=A4stra Fr=C3=B6lunda, SWEDEN
> > > >> Phone: +46 31 734 34 09
> > > >> Fax: +46 31 734 34 29
> > > >> http://www.omnisys.se
> > > >>
> > > >
> > > > _______________________________________________
> > > > 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
> >
>=20
>=20
>=20
> --=20
> Johann Baudy
> johaahn@gmail.com
>=20
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 0:44 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel list, Kamalesh Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Balbir Singh
In-Reply-To: <20080402155247.5e746be7.akpm@linux-foundation.org>
On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
>
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> >
> > on powerpc,
> >
> > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > >
> > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > > > Andrew Morton wrote:
> > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > > > >
> > > > > >> Hi Andrew,
> > > > > >>
> > > > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > > > > >>
> > > > > >> [ 0.000000] ------------[ cut here ]------------
> > > > > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > > > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > > > > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > > > > >> [ 0.000000] Modules linked in:
> > > > > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > > > > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > > > > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > > > > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > > > > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > > > > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > > > > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > > > > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > > > > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > > > > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > > > > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > > > > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > > > > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > > > > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > > > > >> [ 0.000000] Call Trace:
> > > > > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > > > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > > > > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > > > > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > > > > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > > > > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > > > > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > > > > >> [ 0.000000] Instruction dump:
> > > > > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > > > > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > > > > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > > > > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > >
> > > mm-make-mem_map-allocation-continuous.patch
> > > and its friends in -mm.
> > >
> > > You have to call sparse_init_one_section() on each pmap and usemap
> > > as we allocate - since valid_section() depends on it (which is needed
> > > by vmemmap_populate() to check if the section is populated or not).
> > > On ppc, we need to call htab_bolted_mapping() on each section and
> > > we need to skip existing sections.
> > >
> > > These patches tried to group all allocations together and then later
> > > calls sparse_init_one_section() - which is not good :(
> >
> > so try to allocate usemap at first altogether.
>
> I have to turn all the above crud into a proper changelog. I'd prefer that
> you do it.
>
> Unless this patch should be folded into another one, in which case it
> doesn't matter.
>
>
> > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index d3cb085..782ebe5 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
>
> We shouldn't merge this patch on its own because then that will leave a
> non-bisectable region in the powerpc history.
>
> So which patch is this patch fixing? Lexically it applies to
> mm-allocate-section_map-for-sparse_init.patch (and its updates). But is
> that where it logically lies?
yes. we should fold
mm-make-mem_map-allocation-continuous.patch
mm-allocate-section_map-for-sparse_init.patch
and this one
to big one (not big really).
YH
^ permalink raw reply
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 0:47 UTC (permalink / raw)
To: Badari Pulavarty
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
Ingo Molnar, Balbir Singh
In-Reply-To: <1207180285.30407.45.camel@dyn9047017100.beaverton.ibm.com>
On Wed, Apr 2, 2008 at 4:51 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> > so try to allocate usemap at first altogether.
> >
> > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index d3cb085..782ebe5 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -294,7 +294,7 @@ void __init sparse_init(void)
> > unsigned long pnum;
> > struct page *map;
> > unsigned long *usemap;
> > - struct page **section_map;
> > + unsigned long **usemap_map;
> > int size;
> > int node;
> >
> > @@ -305,27 +305,31 @@ void __init sparse_init(void)
> > * make next 2M slip to one more 2M later.
> > * then in big system, the memmory will have a lot hole...
> > * here try to allocate 2M pages continously.
>
> Comments are x86-64 specific. On ppc its 16MB chunks :(
>
>
>
> > + *
> > + * powerpc hope to sparse_init_one_section right after each
> > + * sparse_early_mem_map_alloc, so allocate usemap_map
> > + * at first.
> > */
> > - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> > - section_map = alloc_bootmem(size);
> > - if (!section_map)
> > - panic("can not allocate section_map\n");
> > + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> > + usemap_map = alloc_bootmem(size);
> > + if (!usemap_map)
> > + panic("can not allocate usemap_map\n");
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> > - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> > + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> > }
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> >
> > - map = section_map[pnum];
> > + map = sparse_early_mem_map_alloc(pnum);
> > if (!map)
> > continue;
> >
> > - usemap = sparse_early_usemap_alloc(pnum);
> > + usemap = usemap_map[pnum];
> > if (!usemap)
> > continue;
>
> You may want to move this check before doing sparse_early_mem_map_alloc
> (). We are also not handling errors properly (freeing up the unused
> map or usemap) if we "continue". I know the original code is this way,
> but you touched it last :)
Yes. could avoid some leak...
YH
^ permalink raw reply
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Josh Boyer @ 2008-04-03 0:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <200804030139.05497.arnd@arndb.de>
On Thu, 3 Apr 2008 01:39:04 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 02 April 2008, Grant Likely wrote:
> > On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> > > From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> > >
> > > =C2=A0The of_serial driver queries the current-speed property and att=
empts
> > > =C2=A0to use it to register the custom_divisor property of the uart_p=
ort.
> > > =C2=A0However, if current-speed is not set, then this code will deref=
erence
> > > =C2=A0a bad pointer. =C2=A0The fix is to only set custom_divisor when=
a
> > > =C2=A0current-speed property appears in the device tree.
> > >
> > > =C2=A0Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilin=
x.com>
> > > =C2=A0Signed-off-by: John Linn <john.linn@xilinx.com>
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
>=20
> Acked-by: Arnd Bergmann <arnd@arndb.de>
This is the second time all three of us have Acked this. I'm pulling
it in my tree.
josh
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-03 1:16 UTC (permalink / raw)
To: John Linn, linuxppc-dev, grant.likely
In-Reply-To: <20080403000229.GA6663@localhost.localdomain>
On Wed, Apr 2, 2008 at 6:02 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based adressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
> >
> > This code updates the ns16550 driver to use the reg-offset property
> > so that the Xilinx UART 16550 can be used with it. The reg-shift
> > was already being handled.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> > arch/powerpc/boot/ns16550.c | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> > index f8f1b2f..da9d2c2 100644
> > --- a/arch/powerpc/boot/ns16550.c
> > +++ b/arch/powerpc/boot/ns16550.c
> > @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> > {
> > int n;
> > unsigned long reg_phys;
> > + u32 reg_offset;
> >
> > n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> > if (n != sizeof(reg_base)) {
> > @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> > reg_base = (void *)reg_phys;
> > }
> >
> > + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> > + if (n == sizeof(reg_offset))
> > + reg_base += reg_offset;
>
> Uh... how does the behaviour of reg-offset differ from just bumping
> the address in "reg"?
Mostly because the registers are actually 32 bit registers that can be
accessed with 32bit reads at offset 0. Using this property keeps the
reg property describing the real address range.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
From: Josh Boyer @ 2008-04-03 1:25 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1206629011-28821-1-git-send-email-sr@denx.de>
On Thu, 27 Mar 2008 15:43:31 +0100
Stefan Roese <sr@denx.de> wrote:
> diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
> index d279db4..1782d41 100644
> --- a/arch/powerpc/platforms/44x/sequoia.c
> +++ b/arch/powerpc/platforms/44x/sequoia.c
> @@ -23,8 +23,6 @@
> #include <asm/uic.h>
> #include <asm/pci-bridge.h>
>
> -#include "44x.h"
> -
Almost a perfect patch. Alas, missing a #include <asm/ppc4xx.h> which
breaks the sequoia build.
I'll fix it up locally :).
josh
^ permalink raw reply
* [PATCH] mm: make mem_map allocation continuous v2.
From: Yinghai Lu @ 2008-04-03 1:30 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Badari Pulavarty,
Balbir Singh
In-Reply-To: <86802c440804021744m7c6e3d94vcb6af3ebcaa71b5b@mail.gmail.com>
vmemmap allocation current got
[ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
[ffffe20000200000-ffffe200003fffff] PMD ->ffff810001800000 on node 0
[ffffe20000400000-ffffe200005fffff] PMD ->ffff810001c00000 on node 0
[ffffe20000600000-ffffe200007fffff] PMD ->ffff810002000000 on node 0
[ffffe20000800000-ffffe200009fffff] PMD ->ffff810002400000 on node 0
...
there is 2M hole between them.
the rootcause is that usemap (24 bytes) will be allocated after every 2M
mem_map. and it will push next vmemmap (2M) to next align (2M).
solution:
try to allocate mem_map continously.
after patch, will get
[ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
[ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0
[ffffe20000400000-ffffe200005fffff] PMD ->ffff810001800000 on node 0
[ffffe20000600000-ffffe200007fffff] PMD ->ffff810001a00000 on node 0
[ffffe20000800000-ffffe200009fffff] PMD ->ffff810001c00000 on node 0
...
and usemap will share in page because of they are allocated continuously too.
sparse_early_usemap_alloc: usemap = ffff810024e00000 size = 24
sparse_early_usemap_alloc: usemap = ffff810024e00080 size = 24
sparse_early_usemap_alloc: usemap = ffff810024e00100 size = 24
sparse_early_usemap_alloc: usemap = ffff810024e00180 size = 24
...
so we make the bootmem allocation more compact and use less memory for usemap.
for power pc
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
so try to allocate usemap at first altogether.
v2 replace:
[PATCH] mm: make mem_map allocation continuous.
[PATCH] mm: allocate section_map for sparse_init
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
diff --git a/mm/sparse.c b/mm/sparse.c
index f6a43c0..2881222 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -294,22 +294,48 @@ void __init sparse_init(void)
unsigned long pnum;
struct page *map;
unsigned long *usemap;
+ unsigned long **usemap_map;
+ int size;
+
+ /*
+ * map is using big page (aka 2M in x86 64 bit)
+ * usemap is less one page (aka 24 bytes)
+ * so alloc 2M (with 2M align) and 24 bytes in turn will
+ * make next 2M slip to one more 2M later.
+ * then in big system, the memory will have a lot of holes...
+ * here try to allocate 2M pages continously.
+ *
+ * powerpc need to call sparse_init_one_section right after each
+ * sparse_early_mem_map_alloc, so allocate usemap_map at first.
+ */
+ size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
+ usemap_map = alloc_bootmem(size);
+ if (!usemap_map)
+ panic("can not allocate usemap_map\n");
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
+ usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
+ }
- map = sparse_early_mem_map_alloc(pnum);
- if (!map)
+ for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+ if (!present_section_nr(pnum))
continue;
- usemap = sparse_early_usemap_alloc(pnum);
+ usemap = usemap_map[pnum];
if (!usemap)
continue;
+ map = sparse_early_mem_map_alloc(pnum);
+ if (!map)
+ continue;
+
sparse_init_one_section(__nr_to_section(pnum), pnum, map,
usemap);
}
+
+ free_bootmem(__pa(usemap_map), size);
}
#ifdef CONFIG_MEMORY_HOTPLUG
^ permalink raw reply related
* Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
From: Yinghai Lu @ 2008-04-03 1:43 UTC (permalink / raw)
To: Andrew Morton
Cc: kernel list, Kamalesh Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Balbir Singh
In-Reply-To: <86802c440804021744m7c6e3d94vcb6af3ebcaa71b5b@mail.gmail.com>
On Wed, Apr 2, 2008 at 5:44 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>
> On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
> >
> > > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> > >
> > > on powerpc,
> > >
> > > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > >
> > > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > > > > Andrew Morton wrote:
> > > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > > so try to allocate usemap at first altogether.
> >
> > I have to turn all the above crud into a proper changelog. I'd prefer that
> > you do it.
> >
> > Unless this patch should be folded into another one, in which case it
> > doesn't matter.
> >
> >
> > > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
> > >
> > > diff --git a/mm/sparse.c b/mm/sparse.c
> > > index d3cb085..782ebe5 100644
> > > --- a/mm/sparse.c
> > > +++ b/mm/sparse.c
> >
> > We shouldn't merge this patch on its own because then that will leave a
> > non-bisectable region in the powerpc history.
> >
> > So which patch is this patch fixing? Lexically it applies to
> > mm-allocate-section_map-for-sparse_init.patch (and its updates). But is
> > that where it logically lies?
>
> yes. we should fold
>
>
> mm-make-mem_map-allocation-continuous.patch
>
> mm-allocate-section_map-for-sparse_init.patch
> and this one
>
please check the big one.
http://lkml.org/lkml/2008/4/2/650
YH
^ permalink raw reply
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Arnd Bergmann @ 2008-04-03 2:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, John Linn
In-Reply-To: <20080402195600.67b2eaf2@zod.rchland.ibm.com>
On Thursday 03 April 2008, Josh Boyer wrote:
> > > > =C2=A0Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xil=
inx.com>
> > > > =C2=A0Signed-off-by: John Linn <john.linn@xilinx.com>
> > > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >=20
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
>=20
> This is the second time all three of us have Acked this. =C2=A0I'm pulling
> it in my tree.
>=20
Hehe, thanks!
I never know what the right thing to do with of_serial patches is.
In the past, I've sent them to akpm, in the absense of a dedicated
serial driver maintainer, but I'm just as happy when they get into
mainline any other way.
Of course, it feels a bit wrong for me to forward a patch that
was never sent to me personally.
Arnd <><
^ permalink raw reply
* Re: [PATCH] mm: make mem_map allocation continuous v2.
From: Andrew Morton @ 2008-04-03 2:22 UTC (permalink / raw)
To: yhlu.kernel
Cc: Balbir, Kamalesh, kernel list, Babulal, Yinghai Lu, linuxppc-dev,
Badari Pulavarty, Ingo Molnar, Singh
In-Reply-To: <200804021830.24563.yhlu.kernel@gmail.com>
On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <yhlu.kernel.send@gmail.com> wrote:
> v2 replace:
> [PATCH] mm: make mem_map allocation continuous.
> [PATCH] mm: allocate section_map for sparse_init
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
err, no.
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index f6a43c0..2881222 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
Sorry, but I'd rather not do it this way. We presently have this:
mm-make-mem_map-allocation-continuous.patch
mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch
mm-fix-alloc_bootmem_core-to-use-fast-searching-for-all-nodes.patch
mm-allocate-section_map-for-sparse_init.patch
mm-allocate-section_map-for-sparse_init-update.patch
mm-allocate-section_map-for-sparse_init-update-fix.patch
mm-allocate-section_map-for-sparse_init-powerpc-fix.patch
mm-offset-align-in-alloc_bootmem.patch
mm-make-reserve_bootmem-can-crossed-the-nodes.patch
mm-make-reserve_bootmem-can-crossed-the-nodes-checkpatch-fixes.patch
and you purport to throw some of them away and combine them into a single
patch? We assume that the later patches will still apply and work on top
of this newer patch? It is up to me to check that the replacement patch
incorporates the third-party changes to the original patches?
Too hard, too risky. Can't we just do a fix against 2.6.25-rc8-mm1?
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-03 2:43 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, John Linn
In-Reply-To: <200804030134.11437.arnd@arndb.de>
On Wed, Apr 2, 2008 at 5:34 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 03 April 2008, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based addressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
> >
> > This code updates the of_serial driver to handle the reg-offset
> > and reg-shift properties to enable this core to be used.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
>
> I may not be the best driver maintainer, but please keep the illusion
> alive for me and Cc me on patches to drivers I wrote ;-)
>
>
> > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > index 87f4d84..4066ec8 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model.
> > differ between different families. May be
> > 'virtex2p', 'virtex4', or 'virtex5'.
> >
> > + iv) Xilinx Uart 16550
> > +
> > + Xilinx UART 16550 devices are very similar to the NS16550 but with
> > + different register spacing and an offset from the base address.
> > +
> > + Requred properties:
> > + - clock-frequency : Frequency of the clock input
> > + - reg-offset : A value of 3 is required
> > + - reg-shift : A value of 2 is required
> > +
> > More devices will be defined as this spec matures.
>
> Since it is not really compatible with ns16550, shouldn't you at least specify
> a different "compatible" property? That way, the driver won't do incorrect
> accesses when you try to use an old driver with a device tree that specifies
> one of these.
Heh; we've gone back and forth on this issue. The problem is that we
have a common case of ns16550 like devices that require a little bit
of register address tweaking that spans a whole range of vendors (so
adding a compatible match with each of those vendor's prefixes is
probably non-scalable). So, if "ns16550" is not a good idea, then
what should be used? "sparse16550" has been suggested more than once.
On the other side of the coin; the draft ePAPR spec already redefines
the meaning of "ns16550" to add an optional "reg-shift" property.
Also, in this particular case the problem is most likely more
theoretical than actual. The likely hood of a platform needing these
new properties being handed a kernel which does not support the
"reg-*" properties is very slim.
Anyway, all that just to say that I prefer "ns16550", but I'll put my
vote and support behind "sparse16550" (or any other string) if other
people express consensus with it.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] mm: make mem_map allocation continuous v2.
From: Yasunori Goto @ 2008-04-03 3:22 UTC (permalink / raw)
To: yhlu.kernel
Cc: kernel list, Kamalesh Babulal, linuxppc-dev, Badari Pulavarty,
Andrew Morton, Ingo Molnar, Balbir Singh
In-Reply-To: <200804021830.24563.yhlu.kernel@gmail.com>
Looks good to me. And ia64 boots up with this patch too.
Thanks.
Acked-by: Yasunori Goto <y-goto@jp.fujitsu.com>
>
> vmemmap allocation current got
> [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
> [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001800000 on node 0
> [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001c00000 on node 0
> [ffffe20000600000-ffffe200007fffff] PMD ->ffff810002000000 on node 0
> [ffffe20000800000-ffffe200009fffff] PMD ->ffff810002400000 on node 0
> ...
>
> there is 2M hole between them.
>
> the rootcause is that usemap (24 bytes) will be allocated after every 2M
> mem_map. and it will push next vmemmap (2M) to next align (2M).
>
> solution:
> try to allocate mem_map continously.
>
> after patch, will get
> [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001400000 on node 0
> [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0
> [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001800000 on node 0
> [ffffe20000600000-ffffe200007fffff] PMD ->ffff810001a00000 on node 0
> [ffffe20000800000-ffffe200009fffff] PMD ->ffff810001c00000 on node 0
> ...
> and usemap will share in page because of they are allocated continuously too.
> sparse_early_usemap_alloc: usemap = ffff810024e00000 size = 24
> sparse_early_usemap_alloc: usemap = ffff810024e00080 size = 24
> sparse_early_usemap_alloc: usemap = ffff810024e00100 size = 24
> sparse_early_usemap_alloc: usemap = ffff810024e00180 size = 24
> ...
>
> so we make the bootmem allocation more compact and use less memory for usemap.
>
> for power pc
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > You have to call sparse_init_one_section() on each pmap and usemap
> > as we allocate - since valid_section() depends on it (which is needed
> > by vmemmap_populate() to check if the section is populated or not).
> > On ppc, we need to call htab_bolted_mapping() on each section and
> > we need to skip existing sections.
>
> so try to allocate usemap at first altogether.
>
> v2 replace:
> [PATCH] mm: make mem_map allocation continuous.
> [PATCH] mm: allocate section_map for sparse_init
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index f6a43c0..2881222 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -294,22 +294,48 @@ void __init sparse_init(void)
> unsigned long pnum;
> struct page *map;
> unsigned long *usemap;
> + unsigned long **usemap_map;
> + int size;
> +
> + /*
> + * map is using big page (aka 2M in x86 64 bit)
> + * usemap is less one page (aka 24 bytes)
> + * so alloc 2M (with 2M align) and 24 bytes in turn will
> + * make next 2M slip to one more 2M later.
> + * then in big system, the memory will have a lot of holes...
> + * here try to allocate 2M pages continously.
> + *
> + * powerpc need to call sparse_init_one_section right after each
> + * sparse_early_mem_map_alloc, so allocate usemap_map at first.
> + */
> + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> + usemap_map = alloc_bootmem(size);
> + if (!usemap_map)
> + panic("can not allocate usemap_map\n");
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
> + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> + }
>
> - map = sparse_early_mem_map_alloc(pnum);
> - if (!map)
> + for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> + if (!present_section_nr(pnum))
> continue;
>
> - usemap = sparse_early_usemap_alloc(pnum);
> + usemap = usemap_map[pnum];
> if (!usemap)
> continue;
>
> + map = sparse_early_mem_map_alloc(pnum);
> + if (!map)
> + continue;
> +
> sparse_init_one_section(__nr_to_section(pnum), pnum, map,
> usemap);
> }
> +
> + free_bootmem(__pa(usemap_map), size);
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> --
> 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
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