* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-13 0:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B2300B.4060101@freescale.com>
On Tue, Feb 12, 2008 at 05:47:23PM -0600, Timur Tabi wrote:
> David Gibson wrote:
>
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation. This
> > way madness lies.
>
> Then let them. We can have version numbers associated with the conditional
> expressions. If they want to make more complex condition expressions, they can
> bump the version number and define a spec and write code to parse it.
>
> > No. As Grant says, that's not what the version number is for. It
> > represents the version of the encoding, not the content. If you must
> > version the content (which you should try really hard to avoid) the
> > correct way is to add versioning properties to the root node.
>
> And that's why I prefer updating the DTB format to allow attaching
> conditional expressions to nodes. This would then necessitate
> bumping the version number. Older U-Boots will reject this new DTB.
> We can also modify DTC to support conditional nodes, so that if a
> customer has an older U-Boot he can't update, he can use DTC to
> generate a V17 DTB that has the conditionals already processed.
Well, yes, folding conditionals into the format would mean a version
bump. But I am *not* going to put conditionals into a dtb version,
and I'm pretty sure BenH and Paulus would also reject this notion.
It's simply not what the format is for. dtbs are for parsing by the
kernel, giving a complete device representation. If bootloaders and
other things also find them a useful input format, that's great, but
I'm not going to significantly extend the semantics just to support
other uses.
Now, if you want to define a new binary-level "meta-dtb" format,
designed for representing various conditionals or whatnot, which can
be processed into a final true dtb, go for it. But a) if you base it
on the dtb format, make sure you use a different magic number so as
not to interfere with the actual dtbs version progression and b) I
think you'll find it's more trouble than it's worth, at least at this
stage (feel free to try to prove me wrong on this point, of course).
At present, I think the "meta-dtb" format which makes the most sense,
based on a balance between simplicity and flexibility is C, with one
or more dtb fragments embedded. This can be done now (though if there
are libfdt extensions which would make this usage easier, please
suggest them - fdt_graft() is an obvious one).
--
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
* [PATCH rev2] powerpc: Marvell 64x60 EDAC platform devices setup
From: Dave Jiang @ 2008-02-13 0:11 UTC (permalink / raw)
To: paulus; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080212105113.553659b0.sfr@canb.auug.org.au>
Creating platform devices (memory controller, sram error registers, cpu
error registers, PCI error registers) for Error Detection and Correction
(EDAC) driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from
the memory controller (ECC erorrs), SRAM controller, CPU data path error
registers, and PCI error registers. The errors are reported to syslog.
Software ECC scrubbing is provided. These replace the mv64x60 error handlers
in the ppc branch. They are being moved to EDAC subsystem in order to
centralize error reporting.
The error reporting can be triggered via interrupts from the mv64x60 bridge
chip or via polling mechanism provided by the EDAC core code.
Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
---
Updated with changes from Stephen Rothwell
mv64x60_dev.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index efda002..21bb791 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -17,6 +17,7 @@
#include <linux/platform_device.h>
#include <asm/prom.h>
+#include <asm/io.h>
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -439,6 +440,63 @@ error:
return err;
}
+static int __init mv64x60_edac_pdev_init(struct device_node *np,
+ int id,
+ int num_addr,
+ const char *pdev_name)
+{
+ struct resource *r;
+ struct platform_device *pdev;
+ int i, ret;
+
+ r = kzalloc(num_addr * sizeof(*r) + sizeof(*r), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+
+ for (i = 0; i < num_addr; i++) {
+ ret = of_address_to_resource(np, i, &r[i]);
+ if (ret) {
+ kfree(r);
+ return ret;
+ }
+ }
+
+ of_irq_to_resource(np, 0, &r[i]);
+
+ pdev = platform_device_register_simple(pdev_name, id, r, num_addr + 1);
+
+ kfree(r);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ void __iomem *pci_serr;
+
+ pci_serr = of_iomap(np, 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
@@ -460,6 +518,36 @@ static int __init mv64x60_device_setup(void)
if ((err = mv64x60_i2c_device_setup(np, id++)))
goto error;
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-mem-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_mc_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-cpu-error")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 2,
+ "mv64x60_cpu_err")))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-sram-ctrl")
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_sram_err")))
+ goto error;
+
+#ifdef CONFIG_PCI
+ id = 0;
+ for_each_compatible_node(np, NULL, "marvell,mv64x60-pci-error") {
+ if ((err = mv64x60_pci_fixup(np)))
+ goto error;
+
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ "mv64x60_pci_err")))
+ goto error;
+ }
+#endif
+
/* support up to one watchdog timer */
np = of_find_compatible_node(np, NULL, "marvell,mv64x60-wdt");
if (np) {
^ permalink raw reply related
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-13 0:10 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, Arnd Bergmann
In-Reply-To: <20080212233548.GE21230@localhost.localdomain>
On Feb 12, 2008 4:35 PM, David Gibson <david@gibson.dropbear.id.au> wrote:
> In fact, in one way of looking at it that's always what happens: the
> dtb format is defined for passing hardware information from the
> bootloader to the kernel; nothing else. Passing a dtb *into* the
> bootloader is just a bootloader implementation convenience, because
> the possible variations on an output tree are small, so it's useful to
> have a skeleton tree built-in. But in order for the bootloader to
> process those variations correctly, the skeleton *must* be in the
> right format. dtb input to a bootloader must match the bootloaders
> expectations. This has always been true, and will continue to be
> true.
Well said.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Grant Likely @ 2008-02-13 0:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <47B2300B.4060101@freescale.com>
On Feb 12, 2008 4:47 PM, Timur Tabi <timur@freescale.com> wrote:
> David Gibson wrote:
>
> > I can pretty much guarantee you that someone will find that
> > insufficient and want to expand the conditional representation. This
> > way madness lies.
>
> Then let them. We can have version numbers associated with the conditional
> expressions. If they want to make more complex condition expressions, they can
> bump the version number and define a spec and write code to parse it.
You say that as if bumping the version number is cheap to do.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [Spam Mail] Re: populate_rootfs fail (This message should be blocked: bkdh372119)
From: jay_chen @ 2008-02-13 1:52 UTC (permalink / raw)
To: linuxppc-embedded-bounces+jay_chen=alphanetworks.com; +Cc: linuxppc-embedded
In-Reply-To: <47B19543.70808@coritel.it>
-----Original Message-----
From: linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jay_chen=alphanetworks.com@ozlabs.org]
Sent: Tuesday, February 12, 2008 8:47 PM
To: jay_chen
Cc: linuxppc-embedded@ozlabs.org
Subject: [Spam Mail] Re: populate_rootfs fail (This message should be
blocked: bkdh372119)
jay_chen ha scritto:
> Hello all:
>
> I am using mpc8548, kernel 2.6.14.5, and uboot as boot loader.
> When I upgrade ram from 512MB to 2G, my kernel can't boot anymore.
> (I pass mem=2048M to kernel in uboot now)
>
> It always dies in exec sys_write( ) in populate_rootfs( ).
> I did more tests about this and I found that sys_write( ) could write
> only about 4MB in 2G ram case.
> (My initrd is about 19MB, initrd_start : 0xCE7C7000, initrd_end :
> 0xCFAAF289, initrd_end - initrd_start : 0x012E8289 ==> about 19MB)
> Could anybody give me some hints?
> Is this issue related to the location of "/initrd.image"? Could I
> control it?
> Is there any size limit in ppc arch about ramdisk/initrd?
>
> Thanks for help.
>
> Jay...
>
> void __init populate_rootfs(void)
> {
> char *err;
> ...
> #ifdef CONFIG_BLK_DEV_INITRD
> if (initrd_start) {
> ...
> printk("it isn't (%s); looks like an initrd\n", err);
> fd = sys_open("/initrd.image", O_WRONLY|O_CREAT, 700);
> if (fd >= 0) {
> sys_write(fd, (char *)initrd_start,
> initrd_end - initrd_start);
> sys_close(fd);
> free_initrd();
> }
> }
> #endif
> }
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I think can be a problem with the u-boot initrd_high option. Have you been
enabled the highmem support to use 2G of ram, right? You can try to set this
option to 0x30000000.
Marco
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
0x30000000 doesn't work in my system, but 0x08000000 does.
I am not quiet understand the function of initrd_high and how to set it.
Since it may helps, I will try to figure out the whole story.
Thanks for your help.
Jay...
^ permalink raw reply
* [PATCH] FIx compile of swim3 as module
From: Tony Breeds @ 2008-02-13 2:40 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds, LinuxPPC-dev
Cc: Paul Mackerras, Bartlomiej Zolnierkiewicz
The current pmac32_defconfig fails to build with the following error:
Building modules, stage 2.
ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
WARNING: modpost: Found 23 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[2]: *** [__modpost] Error 1
This patch fixes that.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
drivers/block/swim3.c | 4 ----
drivers/macintosh/mediabay.c | 2 --
2 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index b4e462f..730ccea 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -251,10 +251,6 @@ static int floppy_release(struct inode *inode, struct file *filp);
static int floppy_check_change(struct gendisk *disk);
static int floppy_revalidate(struct gendisk *disk);
-#ifndef CONFIG_PMAC_MEDIABAY
-#define check_media_bay(which, what) 1
-#endif
-
static void swim3_select(struct floppy_state *fs, int sel)
{
struct swim3 __iomem *sw = fs->swim3;
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index 9367882..51a1128 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -416,7 +416,6 @@ static void poll_media_bay(struct media_bay_info* bay)
}
}
-#ifdef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what)
{
int i;
@@ -431,7 +430,6 @@ int check_media_bay(struct device_node *which_bay, int what)
return -ENODEV;
}
EXPORT_SYMBOL(check_media_bay);
-#endif /* CONFIG_MAC_FLOPPY */
#ifdef CONFIG_BLK_DEV_IDE_PMAC
int check_media_bay_by_base(unsigned long base, int what)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] FIx compile of swim3 as module
From: Josh Boyer @ 2008-02-13 2:48 UTC (permalink / raw)
To: Tony Breeds
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080213024019.GX6887@bakeyournoodle.com>
On Wed, 13 Feb 2008 13:40:20 +1100
tony@bakeyournoodle.com (Tony Breeds) wrote:
> The current pmac32_defconfig fails to build with the following error:
>
> Building modules, stage 2.
> ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[2]: *** [__modpost] Error 1
>
> This patch fixes that.
Kyle posted a slightly different patch that seemed to still keep
the original intention of ifdefery in tact. I've no idea which is
better, but the three of you might want to compare notes.
josh
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Tony Breeds @ 2008-02-13 2:51 UTC (permalink / raw)
To: Josh Boyer
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080212204802.18a7a868@zod.rchland.ibm.com>
On Tue, Feb 12, 2008 at 08:48:02PM -0600, Josh Boyer wrote:
> Kyle posted a slightly different patch that seemed to still keep
> the original intention of ifdefery in tact. I've no idea which is
> better, but the three of you might want to compare notes.
/me checks ....
Hmm Kyle's seem the leave the:
#ifndef CONFIG_PMAC_MEDIABAY
#define check_media_bay(which, what) 1
#endif
in swim3.c, which doesn't seem right.
But I'm easy as long as it gets fixed. :)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Benjamin Herrenschmidt @ 2008-02-13 3:26 UTC (permalink / raw)
To: Tony Breeds
Cc: LinuxPPC-dev, Andrew Morton, Linus Torvalds,
Bartlomiej Zolnierkiewicz, Paul Mackerras
In-Reply-To: <20080213024019.GX6887@bakeyournoodle.com>
On Wed, 2008-02-13 at 13:40 +1100, Tony Breeds wrote:
> The current pmac32_defconfig fails to build with the following error:
>
> Building modules, stage 2.
> ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[2]: *** [__modpost] Error 1
Bart, I told you I didn't want those ifdef's in mediabay ... they are
just cluttering things and causing trouble.
> This patch fixes that.
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> drivers/block/swim3.c | 4 ----
> drivers/macintosh/mediabay.c | 2 --
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
> index b4e462f..730ccea 100644
> --- a/drivers/block/swim3.c
> +++ b/drivers/block/swim3.c
> @@ -251,10 +251,6 @@ static int floppy_release(struct inode *inode, struct file *filp);
> static int floppy_check_change(struct gendisk *disk);
> static int floppy_revalidate(struct gendisk *disk);
>
> -#ifndef CONFIG_PMAC_MEDIABAY
> -#define check_media_bay(which, what) 1
> -#endif
> -
> static void swim3_select(struct floppy_state *fs, int sel)
> {
> struct swim3 __iomem *sw = fs->swim3;
> diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
> index 9367882..51a1128 100644
> --- a/drivers/macintosh/mediabay.c
> +++ b/drivers/macintosh/mediabay.c
> @@ -416,7 +416,6 @@ static void poll_media_bay(struct media_bay_info* bay)
> }
> }
>
> -#ifdef CONFIG_MAC_FLOPPY
> int check_media_bay(struct device_node *which_bay, int what)
> {
> int i;
> @@ -431,7 +430,6 @@ int check_media_bay(struct device_node *which_bay, int what)
> return -ENODEV;
> }
> EXPORT_SYMBOL(check_media_bay);
> -#endif /* CONFIG_MAC_FLOPPY */
>
> #ifdef CONFIG_BLK_DEV_IDE_PMAC
> int check_media_bay_by_base(unsigned long base, int what)
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [PATCH] FIx compile of swim3 as module
From: Benjamin Herrenschmidt @ 2008-02-13 6:03 UTC (permalink / raw)
To: Josh Boyer
Cc: Bartlomiej Zolnierkiewicz, kyle, LinuxPPC-dev, Paul Mackerras,
Andrew Morton, Linus Torvalds
In-Reply-To: <20080212204802.18a7a868@zod.rchland.ibm.com>
On Tue, 2008-02-12 at 20:48 -0600, Josh Boyer wrote:
> > The current pmac32_defconfig fails to build with the following
> error:
> >
> > Building modules, stage 2.
> > ERROR: "check_media_bay" [drivers/block/swim3.ko] undefined!
> > WARNING: modpost: Found 23 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > make[2]: *** [__modpost] Error 1
> >
> > This patch fixes that.
>
> Kyle posted a slightly different patch that seemed to still keep
> the original intention of ifdefery in tact. I've no idea which is
> better, but the three of you might want to compare notes.
Just remove the bloody ifdef's, they are just a useless pain.
Ben.
^ permalink raw reply
* Re: [PATCH 09/18] ide: rework PowerMac media-bay support
From: Michael Ellerman @ 2008-02-13 7:29 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004523.17746.24578.sendpatchset@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote:
> Rework PowerMac media-bay support in such way that instead of
> un/registering the IDE interface we un/register IDE devices:
>
> * Add ide_port_scan() helper for probing+registerering devices on a port.
>
> * Rename ide_port_unregister_devices() to __ide_port_unregister_devices().
>
> * Add ide_port_unregister_devices() helper for unregistering devices on a port.
>
> * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead
> of hwif->index to media_bay_set_ide_infos() and use it to setup 'cd_port'.
>
> * Use ide_port_unregister_devices() instead of ide_unregister()
> and ide_port_scan() instead of ide_register_hw() in media_bay_step().
>
> * Unexport ide_register_hw() and make it static.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
> drivers/ide/ide-probe.c | 18 ++++++++++++++++++
> drivers/ide/ide.c | 22 ++++++++++++++++------
> drivers/ide/ppc/pmac.c | 3 ++-
> drivers/macintosh/mediabay.c | 17 +++++++----------
> include/asm-powerpc/mediabay.h | 4 +++-
> include/linux/ide.h | 6 ++----
> 6 files changed, 48 insertions(+), 22 deletions(-)
> Index: b/include/asm-powerpc/mediabay.h
> ===================================================================
> --- a/include/asm-powerpc/mediabay.h
> +++ b/include/asm-powerpc/mediabay.h
> @@ -22,10 +22,12 @@ int check_media_bay(struct device_node *
> /* Number of bays in the machine or 0 */
> extern int media_bay_count;
>
> +#ifdef CONFIG_BLK_DEV_IDE_PMAC
> int check_media_bay_by_base(unsigned long base, int what);
> /* called by IDE PMAC host driver to register IDE controller for media bay */
> int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
> - int irq, int index);
> + int irq, ide_hwif_t *hwif);
> +#endif
>
> #endif /* __KERNEL__ */
> #endif /* _PPC_MEDIABAY_H */
This hunk breaks pmac32_defconfig for me.
include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t'
make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
make[2]: *** [arch/powerpc/platforms/powermac] Error 2
make[1]: *** [arch/powerpc/platforms] Error 2
make: *** [sub-make] Error 2
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Quit the mailling list
From: 조은상 @ 2008-02-13 7:30 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Thanks for help
Please Let me quit the list
Thank you
[-- Attachment #2: Type: text/html, Size: 301 bytes --]
^ permalink raw reply
* TEMAC on Virtex FX12: device occupation
From: llandre @ 2008-02-13 8:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'd like to hear some opinions about this post by Massimiliano:
http://article.gmane.org/gmane.linux.ports.ppc.embedded/17568
The results he got are quite impressive. It seems that everybody here
can hardly fit a design with just one hard TEMAC in FX12 while he was
able to fit two! Unfortunately Massimiliano did not say precisely how he
did it. I'd like to hear someone from Xilinx sharing his/her opinion
about this outstanding result. Maybe he used 3rd-party synthesizer or he
discovered some magical command-line parameters for Xilinx synthesizer ...
Any comment will be appreciated.
Regards,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave.eu
email: r&d2@dave-tech.it
^ permalink raw reply
* [GIT]: Make LMB code sharable with sparc64.
From: David Miller @ 2008-02-13 8:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sparclinux, linux-kernel
As I mentioned to a few ppc folks at LCA08 I plan to use
the LMB code from powerpc as a basis for NUMA support on
sparc64.
There are two changes.
1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
interface bits in include/linux/lmb.h, put arch-specific
bits in asm/lmb.h and add Kconfig machinery to build this
stuff on sparc64.
2) Fix a bug in lmb_alloc() wherein the size was not aligned
so we could easily run out of reserve blocks because
every aligned allocation would create a tiny hole, and
secondly the lmb_reserve() call there did not have it's
return value checked.
Powerpc folks, if there are no objections please pull, thanks!
The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
Linus Torvalds (1):
WMI: initialize wmi_blocks.list even if ACPI is disabled
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
David S. Miller (2):
[LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
[LMB]: Fix bug in __lmb_alloc_base().
arch/powerpc/Kconfig | 3 +
arch/powerpc/kernel/btext.c | 2 +-
arch/powerpc/kernel/crash.c | 2 +-
arch/powerpc/kernel/crash_dump.c | 2 +-
arch/powerpc/kernel/machine_kexec.c | 2 +-
arch/powerpc/kernel/prom.c | 2 +-
arch/powerpc/kernel/rtas.c | 2 +-
arch/powerpc/kernel/setup-common.c | 2 +-
arch/powerpc/kernel/setup_64.c | 2 +-
arch/powerpc/kernel/vdso.c | 2 +-
arch/powerpc/mm/Makefile | 2 +-
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/init_32.c | 2 +-
arch/powerpc/mm/init_64.c | 2 +-
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/numa.c | 2 +-
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
arch/powerpc/mm/stab.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/maple/setup.c | 2 +-
arch/powerpc/platforms/powermac/setup.c | 2 +-
arch/powerpc/platforms/ps3/htab.c | 2 +-
arch/powerpc/platforms/ps3/mm.c | 2 +-
arch/powerpc/platforms/ps3/os-area.c | 2 +-
arch/powerpc/sysdev/dart_iommu.c | 2 +-
arch/sparc64/Kconfig | 3 +
include/asm-powerpc/abs_addr.h | 2 +-
include/asm-powerpc/lmb.h | 82 +++---------------------------
include/asm-sparc64/lmb.h | 10 ++++
include/linux/lmb.h | 83 +++++++++++++++++++++++++++++++
lib/Makefile | 2 +
{arch/powerpc/mm => lib}/lmb.c | 39 ++++++++-------
32 files changed, 155 insertions(+), 117 deletions(-)
create mode 100644 include/asm-sparc64/lmb.h
create mode 100644 include/linux/lmb.h
rename {arch/powerpc/mm => lib}/lmb.c (92%)
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: Sam Ravnborg @ 2008-02-13 8:57 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
On Wed, Feb 13, 2008 at 12:41:20AM -0800, David Miller wrote:
>
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
>
> The following changes since commit 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
> Linus Torvalds (1):
> WMI: initialize wmi_blocks.list even if ACPI is disabled
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
Review had been easier if the patch was inlined.
Took a quick look at the small Kconfig bits.
>From arch/sparc64/Kconfig:
+config LMB
+ def_bool y
+
Can we plase have this changed to use:
config SPARC64
+ select HAVE_LMB
And then in lib/Kconfig have
+config HAVE_LMB
+ bool
So we avoid creating a new variable each time we introdce LMB support.
You would need to update powerpc Kconfig too of course.
This way of doing it is documented in:
Documenation/kbuild/kconfig.language.txt
Thanks,
Sam
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: David Miller @ 2008-02-13 9:05 UTC (permalink / raw)
To: sam; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213085735.GB8091@uranus.ravnborg.org>
From: Sam Ravnborg <sam@ravnborg.org>
Date: Wed, 13 Feb 2008 09:57:35 +0100
> Review had been easier if the patch was inlined.
Sorry :)
> Can we plase have this changed to use:
>
> config SPARC64
> + select HAVE_LMB
>
> And then in lib/Kconfig have
> +config HAVE_LMB
> + bool
>
> So we avoid creating a new variable each time we introdce LMB support.
> You would need to update powerpc Kconfig too of course.
Sure, I'll rework this in the next day or so to do things
that way.
Thanks for the review.
^ permalink raw reply
* V4 FX12 and PLB TEMAC: no space for user logic?
From: llandre @ 2008-02-13 9:32 UTC (permalink / raw)
To: mamsadegh; +Cc: linuxppc-embedded
Hi Mohammad,
I've just had a look at the messages you generously posted in the ml
about your experience with linux on V4 FX12 FPGA.
I'd like to ask your opinion about FX12 practical usability in this
context (gigabit PLB TEMAC/linux).
In this message
http://article.gmane.org/gmane.linux.ports.ppc.embedded/16816
you say the device is completely full. If I understand correctly your
system provides just the devices required to run the bandwidth test so
it seems there is no room for user logic (I think you did not even add
the memory controller required to access the NOR Flash containing
bootloader, kernel image and root fs that is clearly mandatory for
standalone product). Is that true? If it is, this limits a lot the
flexibility of this architecture in this configuration. What do you think?
Regards,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave.eu
email: r&d2@dave-tech.it
^ permalink raw reply
* Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies
From: Gabriel Paubert @ 2008-02-13 10:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide, linux-kernel, Bartlomiej Zolnierkiewicz, linuxppc-dev
In-Reply-To: <20080212123002.GA11000@iram.es>
On Tue, Feb 12, 2008 at 01:30:03PM +0100, Gabriel Paubert wrote:
> On Tue, Feb 12, 2008 at 12:49:05PM +0100, Gabriel Paubert wrote:
> > On Fri, Feb 08, 2008 at 07:40:43PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote:
> > > > - couple of fixes and preparatory patches
> > > >
> > > > - rework of PowerMac media-bay support ([un]register IDE devices instead of
> > > > [un]registering IDE interface) [ it is the main reason for spamming PPC ML ]
> > >
> > > Interesting... I was thinking about doing a full remove of the device at
> > > a higher level instead but I suppose what you propose is easier.
> >
> > Well, I have serious problem on a Pegasos which appeared some time
> > between 2.6.24 and 2.6.25-rc1: at boot I get an infinite string of
> >
> > hdb: empty DMA table?
> >
> > I'm trying to bisect it right now.
>
> Argh, the first bisect point ended up with timeouts on hdb...
>
> Flagged as bad, to try to see when the problems started, but
> I suspect that there are several.
Well, it's worse than this. After 7 or 8 bisections (all flagged
bad) the symptoms changed: the system boots up to the point where
it does not recognize LVM volumes. So there are at least 3 bugs:
1) the timeout on interrupts (only seen on hdb)
2) the empty DMA table messages (seen on hda and hdb)
3) the inability to see logical volumes ("pvs" does not find them,
they are back when rebooting into 2.6.24). This is the apparently
the earliest introduced bug (no problems with the disks with that
version).
I am away from that machine until next Tuesday. IIRC the last git
bisect was something like 160 revisions left.
Gabriel
>
> Gabriel
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Cannot mount root file system using nfs.
From: rakesh bk @ 2008-02-13 10:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4165 bytes --]
Hi EveryOne,
I am new to Xenomai , I have ported linux-2.6.14 to our custom board
based on IBM750Cxe Iam unable to boot my kernel cross compiled with eldk-3.0with
enabled xenomai support.If i remove xenomai and ipipe support the kernel
boots correctly , but if i enable CONFIG_IPIPE I get stuck in the before
mounting the root file system .
The following patches are applied and arguements of scripts/prepare-
kernel.sh is mentioned as follows
adeos-ipipe-2.6.14-ppc-1.3-05.patch,
Target architecture [default i686]: ppc
Adeos patch[default linux-2.6.14/xenomai-2.2.0
/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc64-1.2-03.patch]:
adeos-ipipe-2.6.14-ppc-1.3-05.patch,
## Booting image at 00800000 ...
Image Name: Linux-2.6.14
Created: 2008-02-13 8:23:56 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1568257 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
initrd != NULL ea100000
outside initrd
root=/dev/nfs rw nfsroot=192.168.50.92:/home/eldk/ppc_7xx ip=
192.168.50.39:192.168.50.92:192.168.50.92::ATSLinux:eth0:none c
onsole=ttyS0,9600 ip1=off
## Transferring control to Linux (at address 00000000) ...
Total memory = 128MB; using 256kB for hash table (at a03c0000)
Linux version 2.6.14 (root@localhost.localdomain) (gcc version
3.2.220030217 (Yellow Dog Linux
3.0 3.2.2-2a_1)) #38 PREEMPT
Wed Feb 13 13:53:52 IST 2008
Kernel command line: root=/dev/nfs rw nfsroot=
192.168.50.92:/home/eldk/ppc_7xx ip=192.168.50.39:192.168.50.92:
192.168.50.92:
:ATSLinux:eth0:none console=ttyS0,9600 ip1=off
Initializing init_irq
PID hash table entries: 1024 (order: 10, 16384 bytes)
time_init: decrementer frequency = 17.000000 MHz
Warning: real time clock seems stuck!
I-pipe 1.3-05: pipeline enabled.
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 125696k available (2588k kernel code, 960k data, 156k init, 0k
highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
Xenomai: ALTIVEC support enabled in kernel but no hardware found.
Disable CONFIG_ALTIVEC in the kernel configuration.
Xenomai: system init failed, code -19.
Xenomai: native skin init failed, code -19.
Xenomai: starting POSIX services.
Xenomai: POSIX skin init failed, code -19.
Xenomai: RTDM skin init failed, code -19.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 85) is a 16550A
ttyS1 at MMIO 0x0 (irq = 86) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
gt64260_eth_open : Assigned IRQ 32 to gt64260_eth0
eth0: MII said 3, GT said 9, restarting autoneg
eth0: link state:
GT:100: Link:HD:nFC
mii:100: Link:FD: FC ANc:AN
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.50.39, mask=255.255.255.0, gw=192.168.50.92,
host=ATSLinux, domain=, nis-domain=(none),
bootserver=192.168.50.92, rootserver=192.168.50.92, rootpath=
Looking up port of RPC 100003/2 on 192.168.50.92
[-- Attachment #2: Type: text/html, Size: 5360 bytes --]
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: Michael Ellerman @ 2008-02-13 12:12 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On Wed, 2008-02-13 at 00:41 -0800, David Miller wrote:
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
Looks like there are a few places (in arch/powerpc) that were getting
asm/prom.h via asm/lmb.h, I'll send a patch in the morning.
cheers
arch/powerpc/mm/numa.c:124: error: implicit declaration of function 'of_find_node_by_type'
arch/powerpc/platforms/ps3/os-area.c:215: error: variable 'property_rtc_diff' has initializer but incomplete type
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 09/18] ide: rework PowerMac media-bay support
From: Bartlomiej Zolnierkiewicz @ 2008-02-13 12:26 UTC (permalink / raw)
To: michael; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <1202887776.7971.19.camel@concordia.ozlabs.ibm.com>
Hi,
On Wednesday 13 February 2008, Michael Ellerman wrote:
> On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote:
> > Rework PowerMac media-bay support in such way that instead of
> > un/registering the IDE interface we un/register IDE devices:
> >
> > * Add ide_port_scan() helper for probing+registerering devices on a port.
> >
> > * Rename ide_port_unregister_devices() to __ide_port_unregister_devices().
> >
> > * Add ide_port_unregister_devices() helper for unregistering devices on a port.
> >
> > * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead
> > of hwif->index to media_bay_set_ide_infos() and use it to setup 'cd_port'.
> >
> > * Use ide_port_unregister_devices() instead of ide_unregister()
> > and ide_port_scan() instead of ide_register_hw() in media_bay_step().
> >
> > * Unexport ide_register_hw() and make it static.
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > ---
> > drivers/ide/ide-probe.c | 18 ++++++++++++++++++
> > drivers/ide/ide.c | 22 ++++++++++++++++------
> > drivers/ide/ppc/pmac.c | 3 ++-
> > drivers/macintosh/mediabay.c | 17 +++++++----------
> > include/asm-powerpc/mediabay.h | 4 +++-
> > include/linux/ide.h | 6 ++----
> > 6 files changed, 48 insertions(+), 22 deletions(-)
>
> > Index: b/include/asm-powerpc/mediabay.h
> > ===================================================================
> > --- a/include/asm-powerpc/mediabay.h
> > +++ b/include/asm-powerpc/mediabay.h
> > @@ -22,10 +22,12 @@ int check_media_bay(struct device_node *
> > /* Number of bays in the machine or 0 */
> > extern int media_bay_count;
> >
> > +#ifdef CONFIG_BLK_DEV_IDE_PMAC
Does adding:
#include <linux/ide.h>
after ifdef help?
> > int check_media_bay_by_base(unsigned long base, int what);
> > /* called by IDE PMAC host driver to register IDE controller for media bay */
> > int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
> > - int irq, int index);
> > + int irq, ide_hwif_t *hwif);
> > +#endif
> >
> > #endif /* __KERNEL__ */
> > #endif /* _PPC_MEDIABAY_H */
>
> This hunk breaks pmac32_defconfig for me.
>
> include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t'
> make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> make[2]: *** [arch/powerpc/platforms/powermac] Error 2
> make[1]: *** [arch/powerpc/platforms] Error 2
> make: *** [sub-make] Error 2
>
> cheers
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: Kumar Gala @ 2008-02-13 13:12 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
On Feb 13, 2008, at 2:41 AM, David Miller wrote:
>
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
>
> The following changes since commit
> 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
> Linus Torvalds (1):
> WMI: initialize wmi_blocks.list even if ACPI is disabled
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
>
> David S. Miller (2):
> [LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
> [LMB]: Fix bug in __lmb_alloc_base().
Does sparc have the concept of a phys_addr_t? We are in the process
of expanding the lmb support to deal with 36-bit physical addresses on
32-bit machines.
- k
^ permalink raw reply
* [PATCH] [POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-13 13:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sparclinux, davem, linux-kernel
If we add to an empty lmb region with a non-zero base we will not coalesce
the number of regions done to one. This causes problems on ppc32 for the
memory region as its assumed to only have one region.
We can fix this be easily specially casing the initial add to just replace
the dummy region.
---
Posting this since Dave's looking a pulling the lmb code out into lib/ and
sharing it between powerpc and sparc.
(this is my git tree git.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git)
- k
arch/powerpc/mm/lmb.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 4ce23bc..1ea8df0 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -141,6 +141,12 @@ static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
unsigned long coalesced = 0;
long adjacent, i;
+ if ((rgn->cnt == 1) && (rgn->region[0].size == 0)) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ return 0;
+ }
+
/* First try and coalesce this LMB with another. */
for (i=0; i < rgn->cnt; i++) {
unsigned long rgnbase = rgn->region[i].base;
--
1.5.3.8
^ permalink raw reply related
* Re: HDLC driver - dev_free_skb_irq causes Segfault
From: Laurent Pinchart @ 2008-02-13 14:11 UTC (permalink / raw)
To: linuxppc-embedded, rmcguire
In-Reply-To: <00be01c86b8d$27c2fcb0$6405a8c0@absolut>
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]
Hi Russ,
On Sunday 10 February 2008 03:32, Russell McGuire wrote:
> All,
>
> So I am in the process of debugging my newly established HDLC driver.
> More or less modeled after a simplified gianfar / ucc_geth idea.
>
> However, after loading, etc. and using the following commands
>
> -> insmod hdlc-8360.ko
> -> sethdlc hdlc0 hdlc-eth
> -> ifconfig hdlc0 up 192.168.1.100
>
> All is well, and I am seeing IDL interrupts. Great.
>
> Now I go to ping an address like,
> ping 192.168.1.101
>
> I can see that I get the start_xmit function, the IRQ from the QE comes
> back and reports the TXBD as successfully sent.
>
> Here is the problem, when I goto free the skb in the tx_handler, I get a
> 'Unable to Handle Kernel Paging Request for data at address 0x00000000'
> Even though for the life of me, I can't see any pointers that are at
> address zero.
I'm experiencing a similar problem here with a in-house HDLC driver. The
kernel oopses after some time under high HDLC loads.
Could you please post a backtrace to see if our problems are related ? How do
you free the skb ? Posting code snippet (or even the whole source code) would
help.
> I have checked the pointer value I am passing in, and indeed it is the
> exact same pointer I am receiving from the original
> start-xmit call..
>
> Are we supposed to copy the skb? And free it immediately in the start_xmit?
> Some special way to store the pointer?
My understanding is that the skb is supposed to be freed in the TX interrupt
handler.
> I have tried
> txbd->buf = skb->data;
> txbd->buf = virt_to_phys(skb->data);
> etc.. and various other ways to save that I have seen in the gianfar and
> ucc_geth drivers.
You should map the skb data buffer using dma_map_single. Don't forget to unmap
it with dma_unmap_single in the TX interrupt handler.
> My tx_sk_buff** is identical as alloced the same way.
>
> Anyone have any ideas?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix initial lmb add region with a non-zero base
From: Jon Loeliger @ 2008-02-13 14:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: sparclinux, linuxppc-dev, davem, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802130719330.14428@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> If we add to an empty lmb region with a non-zero base we will not coalesce
> the number of regions done to one. This causes problems on ppc32 for the
s/done/down
> memory region as its assumed to only have one region.
>
> We can fix this be easily specially casing the initial add to just replace
> the dummy region.
>
> ---
>
> Posting this since Dave's looking a pulling the lmb code out into lib/ and
> sharing it between powerpc and sparc.
Did you want to S-o-b: this patch? Or was this just informational?
Thanks,
jdl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox