* Re: [PATCH 01/10] powerpc: Set up OF properties for ppc32 kexec
From: Liang Chai @ 2009-02-26 19:37 UTC (permalink / raw)
To: linuxppc-dev
I have looking for kexec support on pppc32. Where can I find and download all the patches for kernel the kexec-tools? Which kernel version should the patches apply to?
Thanks
Liang Chai
^ permalink raw reply
* PHY not found after migration of gianfar driver to an of_platform_driver
From: Michael Guntsche @ 2009-02-26 19:15 UTC (permalink / raw)
To: linuxppc-dev
Hello everyone,
I recently obtained a Mikrotik RB600 and applied the patch from http://cynigram.com/~nfontes/rb600/
to get it up and running with 2.6.28.3
With this patch applied everything was detected on the board and
worked. For testing purposes I tried a recent git snapshot and noticed
that the gianfar driver had problems.
While the the Gianfar was detected
[ 0.549115] Gianfar MII Bus: probed
[ 0.553316] eth0 (fsl-gianfar): not using net_device_ops yet
[ 0.560861] eth0: Gianfar Ethernet Controller Version 1.2, 00:0c:
42:28:de:4e
[ 0.568024] eth0: Running with NAPI enabled
[ 0.572234] eth0: 256/256 RX/TX BD ring size
[ 0.576802] eth1 (fsl-gianfar): not using net_device_ops yet
[ 0.584200] eth1: Gianfar Ethernet Controller Version 1.2, 00:0c:
42:28:de:4f
[ 0.591345] eth1: Running with NAPI enabled
[ 0.595575] eth1: 256/256 RX/TX BD ring size
trying to up either of the devices gave me
[ 8.724818] mdio@24520:01 not found
[ 8.728330] eth1: Could not attach to PHY
[ 8.732945] mdio@24520:01 not found
[ 8.737720] eth1: Could not attach to PHY
I tracked this back to commit
"b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 gianfar: Convert gianfar to
an of_platform_driver". Reverting this one and applying for fsc_soc.c
made the two nics work again.
I tried to figure out what was causing the problem in the first place,
but failed miserably. I am pretty sure it is just a minor probing
issue somewhere in the code but I am not able to spot that.
Maybe someone more knowledgeable than me can take a look at it and
help me out a little bit.
According to lspci the board is a
00:00.0 Power PC: Freescale Semiconductor Inc MPC8343 (rev 30)
Please CC me in any replies since I am not subscribed to the ML .. yet.
Thanks in advance,
Michael
^ permalink raw reply
* OF -> platform_device
From: Gary Thomas @ 2009-02-26 18:28 UTC (permalink / raw)
To: Linux PPC Development
I'm trying to use some drivers which are not yet OF aware
(in particular net/dsa). In order to use these drivers, I
need platform_device pointers for my network any MII bus (PHY).
In the OF world, how do I get to these? I have a MPC834x
based board and somehow I need access to these devices (from
my DTS file):
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&ipic>;
interrupts = <17 0x8>;
reg = <0x1>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
interrupt-parent = <&ipic>;
interrupts = <18 0x8>;
reg = <0x2>;
device_type = "ethernet-phy";
};
};
enet0: ethernet@24000 {
cell-index = <0>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x24000 0x1000>;
local-mac-address = [ 00 08 e5 11 32 33 ];
interrupts = <32 0x8 33 0x8 34 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy0>;
linux,network-index = <0>;
};
enet1: ethernet@25000 {
cell-index = <1>;
device_type = "network";
model = "TSEC";
compatible = "gianfar";
reg = <0x25000 0x1000>;
local-mac-address = [ 00 08 e5 11 32 34 ];
interrupts = <35 0x8 36 0x8 37 0x8>;
interrupt-parent = <&ipic>;
phy-handle = <&phy1>;
linux,network-index = <1>;
};
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Geert Uytterhoeven @ 2009-02-26 17:40 UTC (permalink / raw)
To: Mark Nelson
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-ext4
In-Reply-To: <200902261020.34325.markn@au1.ibm.com>
On Thu, 26 Feb 2009, Mark Nelson wrote:
> On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote:
> > On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
> > > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > > Does the following patch fix the errors you're seeing? (it applies the
> > > > same fix as the previous patch but this time to copy_tofrom_user, which
> > > > I updated in a4e22f02f5b6518c1484faea1f88d81802b9feac)
> > >
> > > Thanks, but I still get crashes in copy_page_range().
> >
> > Hmmm... I'm out of ideas for the moment, but thanks for testing anyway!
>
> If you revert both 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556 and
> a4e22f02f5b6518c1484faea1f88d81802b9feac, does it help? You could also
> try to revert 57dda6ef5bd5b9e60410477ad29e654097e2cca1 just in case I
> need to keep wearing the brown paper bag for a bit longer :)
Still doesn't help.
However, I noticed I never enabled CONFIG_DEBUG_PAGEALLOC before 2.6.29-rc5.
So far I tried 2.6.2[5-8], and they all crash with CONFIG_DEBUG_PAGEALLOC.
I guess it never actually worked on PS3.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [RFC v2] virtio: add virtio-over-PCI driver
From: Geert Uytterhoeven @ 2009-02-26 16:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jan-Bernd Themann, netdev, Rusty Russell, linux-kernel,
linuxppc-dev, Ira Snyder
In-Reply-To: <200902261715.28440.arnd@arndb.de>
On Thu, 26 Feb 2009, Arnd Bergmann wrote:
> On Tuesday 24 February 2009, Ira Snyder wrote:
> > +/* Virtio-over-PCI descriptors: 12 bytes. These can chain together via "next" */
> > +struct vop_desc {
> > + /* Address (host physical) */
> > + __le32 addr;
^^^^
Only 32-bit? Is this future-proof?
> > + /* Length (bytes) */
> > + __le32 len;
> > + /* Flags */
> > + __le16 flags;
> > + /* Chaining for descriptors */
> > + __le16 next;
> > +} __attribute__((packed));
>
> I would drop the "packed" attribute in the structure definitions.
> It would imply that only byte accesses are allowed on these
> data structures, because the attribute invalidates any assumptions
> about alignment. None of your structures require padding, so
> the attribute does not have any positive effect either.
>
> > +/* MPC8349EMDS specific get_immrbase() */
> > +#include <sysdev/fsl_soc.h>
>
> Do you really need get_immrbase? I would expect that you can find
> all the registers you need in the device tree, or exported from
> other low-level drivers per subsystem.
>
> immrbase is a concept from the time before our device trees.
>
> > +/*
> > + * These are internal use only versions of the structures that
> > + * are exported over PCI by this driver
> > + *
> > + * They are used internally to keep track of the PowerPC queues so that
> > + * we don't have to keep flipping endianness all the time
> > + */
> > +struct vop_loc_desc {
> > + u32 addr;
^^^
Same here.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [RFC v2] virtio: add virtio-over-PCI driver
From: Arnd Bergmann @ 2009-02-26 16:15 UTC (permalink / raw)
To: Ira Snyder
Cc: linuxppc-dev, netdev, Rusty Russell, linux-kernel,
Jan-Bernd Themann
In-Reply-To: <20090224000002.GA578@ovro.caltech.edu>
On Tuesday 24 February 2009, Ira Snyder wrote:
> This adds support to Linux for using virtio between two computers linked by
> a PCI interface. This allows the use of virtio_net to create a familiar,
> fast interface for communication. It should be possible to use other virtio
> devices in the future, but this has not been tested.
Wonderful, I like it a lot!
One major aspect that I hope can be improved is the layering
of the driver to make it easier to reuse parts for other
hardware implementations and also for sharing code between
the two sides. Most of my comments below are about this.
A better split I can imagine would be:
1. of_device hardware specific probing, and creation of virtqueues
2. pci hardware specific probing, and detection of virtqueues
3. library with common code, hardware independent
4. library with common code, hardware specific but used by both of_device
and pci.
5. interface to virtio-net on top of that (symmetric)
> +/* Virtio-over-PCI descriptors: 12 bytes. These can chain together via "next" */
> +struct vop_desc {
> + /* Address (host physical) */
> + __le32 addr;
> + /* Length (bytes) */
> + __le32 len;
> + /* Flags */
> + __le16 flags;
> + /* Chaining for descriptors */
> + __le16 next;
> +} __attribute__((packed));
I would drop the "packed" attribute in the structure definitions.
It would imply that only byte accesses are allowed on these
data structures, because the attribute invalidates any assumptions
about alignment. None of your structures require padding, so
the attribute does not have any positive effect either.
> +/* MPC8349EMDS specific get_immrbase() */
> +#include <sysdev/fsl_soc.h>
Do you really need get_immrbase? I would expect that you can find
all the registers you need in the device tree, or exported from
other low-level drivers per subsystem.
immrbase is a concept from the time before our device trees.
> +/*
> + * These are internal use only versions of the structures that
> + * are exported over PCI by this driver
> + *
> + * They are used internally to keep track of the PowerPC queues so that
> + * we don't have to keep flipping endianness all the time
> + */
> +struct vop_loc_desc {
> + u32 addr;
> + u32 len;
> + u16 flags;
> + u16 next;
> +};
> +
> +struct vop_loc_avail {
> + u16 index;
> + u16 ring[VOP_RING_SIZE];
> +};
> +
> +struct vop_loc_used_elem {
> + u32 id;
> + u32 len;
> +};
> +
> +struct vop_loc_used {
> + u16 index;
> + struct vop_loc_used_elem ring[VOP_RING_SIZE];
> +};
Are you worried about the overhead of having to do byte flips,
or the code complexity? I would guess that the overhead is
near zero, but I'm not sure about the source code complexity.
Generally, I'd expect that you'd be better off just using the
wire-level data structures directly.
> +/*
> + * DMA Resolver state information
> + */
> +struct vop_dma_info {
> + struct dma_chan *chan;
> +
> + /* The currently processing avail entry */
> + u16 loc_avail;
> + u16 rem_avail;
> +
> + /* The currently processing used entries */
> + u16 loc_used;
> + u16 rem_used;
> +};
> +
> +struct vop_vq {
> +
> + /* The actual virtqueue itself */
> + struct virtqueue vq;
> + struct device *dev;
> +
> + /* The host ring address */
> + struct vop_host_ring __iomem *host;
> +
> + /* The guest ring address */
> + struct vop_guest_ring *guest;
> +
> + /* Our own memory descriptors */
> + struct vop_loc_desc desc[VOP_RING_SIZE];
> + struct vop_loc_avail avail;
> + struct vop_loc_used used;
> + unsigned int flags;
> +
> + /* Data tokens from add_buf() */
> + void *data[VOP_RING_SIZE];
> +
> + unsigned int num_free; /* number of free descriptors in desc */
> + unsigned int free_head; /* start of the free descriptors in desc */
> + unsigned int num_added; /* number of entries added to desc */
> +
> + u16 loc_last_used; /* the last local used entry processed */
> + u16 rem_last_used; /* the current value of remote used_idx */
> +
> + /* DMA resolver state */
> + struct vop_dma_info dma;
> + struct work_struct work;
> + int (*resolve)(struct vop_vq *vq);
> +
> + void __iomem *immr;
> + int kick_val;
> +};
This data structure mixes generic information with fsl-834x specific
members. I think you should try to split this better into a common
part (also common for host and guest) to allow sharing the code
across other low-level implementations:
struct vop_vq {
struct virtqueue vq;
struct vop_host_ring __iomem *host;
struct vop_guest_ring *guest;
...
};
and in another file:
struct fsl834x_vq {
struct vop_vq;
struct fsl834x_vop_regs __iomem *regs; /* instead of immr */
}
If you split the structures this way, the abstraction should
come naturally.
> +/*
> + * This represents a virtio_device for our driver. It follows the memory
> + * layout shown above. It has pointers to all of the host and guest memory
> + * areas that we need to access
> + */
> +struct vop_vdev {
> +
> + /* The specific virtio device (console, net, blk) */
> + struct virtio_device vdev;
> +
> + #define VOP_DEVICE_REGISTERED 1
> + int status;
> +
> + /* Start address of local and remote memory */
> + void *loc;
> + void __iomem *rem;
> +
> + /*
> + * These are the status, feature, and configuration information
> + * for this virtio device. They are exposed in our memory block
> + * starting at offset 0.
> + */
> + struct vop_status __iomem *host_status;
> +
> + /*
> + * These are the status, feature, and configuration information
> + * for the guest virtio device. They are exposed in the guest
> + * memory block starting at offset 0.
> + */
> + struct vop_status *guest_status;
> +
> + /*
> + * These are the virtqueues for the virtio driver running this
> + * device to use. The host portions are exposed in our memory block
> + * starting at offset 1024. The exposed areas are aligned to 1024 byte
> + * boundaries, so they appear at offets 1024, 2048, and 3072
> + * respectively.
> + */
> + struct vop_vq virtqueues[3];
> +};
Unfortunately, that structure layout implies an extra pointer level here:
struct vop_vq *virtqueues[3];
I also wonder if the number of virtqueues should be variable here.
> +struct vop_dev {
> +
> + struct of_device *op;
> + struct device *dev;
> +
> + /* Reset and start */
> + struct mutex mutex;
> + struct work_struct reset_work;
> + struct work_struct start_work;
> +
> + int irq;
> +
> + /* Our board control registers */
> + void __iomem *immr;
> +
> + /* The guest memory, exposed at PCI BAR1 */
> + #define VOP_GUEST_MEM_SIZE 16384
> + void *guest_mem;
> + dma_addr_t guest_mem_addr;
> +
> + /* Host memory, given to us by host in OMR0 */
> + #define VOP_HOST_MEM_SIZE 16384
> + void __iomem *host_mem;
> +
> + /* The virtio devices */
> + struct vop_vdev devices[4];
> + struct dma_chan *chan;
> +};
This one again is hardware specific, right? If so, it should go
together with what I call fsl834x_vq above.
> +/*----------------------------------------------------------------------------*/
> +/* Local descriptor ring access helpers */
> +/*----------------------------------------------------------------------------*/
> +
> +static void vop_set_desc_addr(struct vop_vq *vq, unsigned int idx, u32 addr)
> +{
> + vq->desc[idx].addr = addr;
> +}
> +
> +static void vop_set_desc_len(struct vop_vq *vq, unsigned int idx, u32 len)
> +{
> + vq->desc[idx].len = len;
> +}
> +
> +static void vop_set_desc_flags(struct vop_vq *vq, unsigned int idx, u16 flags)
> +{
> + vq->desc[idx].flags = flags;
> +}
> +
> +static void vop_set_desc_next(struct vop_vq *vq, unsigned int idx, u16 next)
> +{
> + vq->desc[idx].next = next;
> +}
> +
> +static u16 vop_get_desc_flags(struct vop_vq *vq, unsigned int idx)
> +{
> + return vq->desc[idx].flags;
> +}
> +
> +static u16 vop_get_desc_next(struct vop_vq *vq, unsigned int idx)
> +{
> + return vq->desc[idx].next;
> +}
I don't quite get the point in these accessors. Calling one of these
functions would be longer than open-coding the content.
> +/*----------------------------------------------------------------------------*/
> +/* Scatterlist DMA helpers */
> +/*----------------------------------------------------------------------------*/
> +
> +/*
> + * This function abuses some of the scatterlist code and implements
> + * dma_map_sg() in such a way that we don't need to keep the scatterlist
> + * around in order to unmap it.
> + *
> + * It is also designed to never merge scatterlist entries, which is
> + * never what we want for virtio.
> + *
> + * When it is time to unmap the buffer, you can use dma_unmap_single() to
> + * unmap each entry in the chain. Get the address, length, and direction
> + * from the descriptors! (keep a local copy for speed)
> + */
Why is that an advantage over dma_unmap_sg?
> +static int vop_dma_map_sg(struct device *dev, struct scatterlist sg[],
> + unsigned int out, unsigned int in)
> +{
> + dma_addr_t addr;
> + enum dma_data_direction dir;
> + struct scatterlist *start;
> + unsigned int i, failure;
> +
> + start = sg;
> +
> + for (i = 0; i < out + in; i++) {
> +
> + /* Check for scatterlist chaining abuse */
> + BUG_ON(sg == NULL);
> +
> + dir = (i < out) ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
> + addr = dma_map_single(dev, sg_virt(sg), sg->length, dir);
> +
> + if (dma_mapping_error(dev, addr))
> + goto unwind;
> +
> + sg_dma_address(sg) = addr;
> + sg = sg_next(sg);
> + }
I believe this kind of loop can be simplified using for_each_sg().
> + /* Remap IMMR */
> + priv->immr = ioremap(get_immrbase(), 0x100000);
> + if (!priv->immr) {
> + dev_err(&op->dev, "Unable to remap IMMR registers\n");
> + ret = -ENOMEM;
> + goto out_dma_release_channel;
> + }
As mentioned above, this should be something like an of_iomap(op, ...)
> +struct vop_vq {
> +
> + /* The actual virtqueue itself */
> + struct virtqueue vq;
> +
> + struct device *dev;
> +
> + /* The host ring address */
> + struct vop_host_ring *host;
> +
> + /* The guest ring address */
> + struct vop_guest_ring __iomem *guest;
> +
> + /* Local copy of the descriptors for fast access */
> + struct vop_loc_desc desc[VOP_RING_SIZE];
> +
> + /* The data token from add_buf() */
> + void *data[VOP_RING_SIZE];
> +
> + unsigned int num_free;
> + unsigned int free_head;
> + unsigned int num_added;
> +
> + u16 avail_idx;
> + u16 last_used_idx;
> +
> + /* The doorbell to kick() */
> + unsigned int kick_val;
> + void __iomem *immr;
> +};
I find it very confusing to have almost-identical data structures by the
same name in two files. Obviously, you have a lot of common code between
the two sides, but rather than making the implementation files *look*
similar, it would be better to focus on splitting out the shared code
into a common file and keep the different/duplicated code small.
> + switch (index) {
> + case 0: /* x86 recv virtqueue -- ppc xmit virtqueue */
> + vq->guest = vdev->rem + 1024;
> + vq->host = vdev->loc + 1024;
> + break;
> + case 1: /* x86 xmit virtqueue -- ppc recv virtqueue */
> + vq->guest = vdev->rem + 2048;
> + vq->host = vdev->loc + 2048;
> + break;
> + default:
> + dev_err(vq->dev, "unknown virtqueue %d\n", index);
> + return ERR_PTR(-ENODEV);
> + }
I'd avoid making assumptions or comments about the architectures.
Rather than "x86" and "ppc", I'd write "local" and "remote".
Arnd <><
^ permalink raw reply
* Re: [PATCH v2 net] gianfar : Do right check on num_txbdfree
From: Geert Uytterhoeven @ 2009-02-26 16:03 UTC (permalink / raw)
To: Rini van Zetten; +Cc: Linuxppc-dev, afleming, David Miller, netdev
In-Reply-To: <49A66E2D.3060204@arvoo.nl>
On Thu, 26 Feb 2009, Rini van Zetten wrote:
> This patch fixes a wrong check on num_txbdfree. It could lead to num_txbdfree
> become nagative.
> Result was that the gianfar stops sending data.
A quick mental note for your next patch submission:
> Changes from first version :
> - removed a space between parens (David Millers comment)
> - full email address in signed off line
Changelogs since previous versions should be ...
> Signed-off-by: Rini van Zetten <rini@arvoo.nl>
> ---
... here, below the `---', as they're not supposed to be end up in the final
commit message.
> drivers/net/gianfar.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: defining platform_devices in DTS
From: Grant Likely @ 2009-02-26 15:57 UTC (permalink / raw)
To: Pieter; +Cc: linuxppc-dev, devicetree-discuss list
In-Reply-To: <49A50D74.50409@vastech.co.za>
(note: added the devicetree-discuss mailing list to this thread)
On Wed, Feb 25, 2009 at 2:20 AM, Pieter <phenning@vastech.co.za> wrote:
> Hi all
>
> I am busy porting my board to Linux 2.6.27 from 2.6.19. The old Linux
> was compiled using the ppc architecture, and had a "platform_device"
> struct ure containing the custom devices on my board. (
> /arch/ppc/platform/sdh8548.c and /arch/ppc/platform/sdh8548.h )
>
> I assume these devices should now be declared in the device tree source.
> Building the new Linux using the powerpc architecture, but I am
> strugeling translating teh information defined in the "platform_device"
> to a device tree node. In particular what happens to the resource.flags
> could anyone help please?
For the most common flags (IO_RESOURCE_MEM & IO_RESOURCE_IRQ), you use
the 'reg' and 'interrupts' properties respectively to describe your
device. The usage of them is well established.
> Below is the "platform_device" definition and my interpretation of how
> it should look in the device tree. Am I on the right track?
Yes, you're on the right track; comments below
> thanks pieter
>
> platform_device definition:
> =A0{
> =A0 =A0 =A0 =A0.name =3D "bio",
> =A0 =A0 =A0 =A0.id =3D 0,
> =A0 =A0 =A0 =A0.dev.platform_data =3D NULL,
> =A0 =A0 =A0 =A0.num_resources =3D 2,
> =A0 =A0 =A0 =A0.resource =3D (struct resource[]) {
> =A0 =A0 =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.start =A0=3D 0xe0100000,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.end =A0 =A0=3D 0xe0100000 + 0x10000 -1,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.flags =A0=3D IORESOURCE_MEM, =A0 =A0/* 0x=
00000200 */
> =A0 =A0 =A0 =A0 =A0 =A0},
> =A0 =A0 =A0 =A0 =A0 =A0{
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.name =A0 =3D "int",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.start =A0=3D MPC85xx_IRQ_EXT0, =A0 =A0/* =
48 +
> MPC85xx_OPENPIC_IRQ_OFFSET */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.end =A0 =A0=3D MPC85xx_IRQ_EXT0,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.flags =A0=3D IORESOURCE_IRQ, =A0 =A0/*0x0=
0000400 */
> =A0 =A0 =A0 =A0 =A0 =A0},
> =A0 =A0 =A0 =A0},
>
> FDT source:
> =A0 =A0localbus@e0000000 {
> =A0 =A0 =A0 =A0#address-cells =3D <2>;
> =A0 =A0 =A0 =A0#size-cells =3D <1>;
> =A0 =A0 =A0 =A0compatible =3D "simple-bus";
> =A0 =A0 =A0 =A0reg =3D <0xe0000000 0x5000>;
> =A0 =A0 =A0 =A0interrupt-parent =3D <&mpic>;
>
> =A0 =A0 =A0 =A0ranges =3D <
> =A0 =A0 =A0 =A0 =A0 =A00x0 0x0 0xf8000000 0x07ffffff =A0 =A0 =A0 =A0/*128=
MB Flash*/
> =A0 =A0 =A0 =A0 =A0 =A00x1 0x0 0xe0200000 0x00200000 =A0 =A0 =A0 =A0/*2MB=
FPGA*/
> =A0 =A0 =A0 =A0 =A0 =A00x2 0x0 0xe0100000 0x00100000 =A0 =A0 =A0 =A0 /*1M=
B BIO CPLD*/
> =A0 =A0 =A0 =A0>;
Your ranges property appears to be correct.
> =A0 =A0 =A0 =A0bio@2,0 {
> =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "wrs,epld-localbus";
This property is what the whole system hangs of and it is important
that it is unique for the device you are describing. Device drivers
read the compatible property and use it to decide whether or not it
can drive the device. If this is a board-specific EPLD, then the name
of the board should be part of the name. Once you've selected a name,
you must document what the name means in
Documentation/powerpc/dts-bindings/ and what properties are required
in nodes with this value.
> =A0 =A0 =A0 =A0 =A0 =A0#address-cells =3D <2>;
> =A0 =A0 =A0 =A0 =A0 =A0#size-cells =3D <1>;
Only use #address-cells and #size-cells if there is a child node that
has a 'reg' property.
> =A0 =A0 =A0 =A0 =A0 =A0//interrupt-parent =3D <&mpic>;
You don't need interrupt-parent if the parent node already sets it correctl=
y.
> =A0 =A0 =A0 =A0 =A0 =A0//interrupts =3D <48>;
This is probably where you are having trouble. To determine the
format of the interrupts property you need to look at the interrupt
parent node. The #interrupt-cells property in the interrupt parent
will tell you how many numbers (cells) need to be in the interrupts
property for each irq line. In this case the mpic specifies
'#interrupt-cells=3D<2>;'. So, the interrupts property here should be
in the form: "interrupts =3D < [irq-number] [irq-type] >;"
irq-number is the irq line
irq-type is the sense (edge/level, high/low). See mpic_host_xlate()
in arch/powerpc/sysdev/mpic.c for the mapping (map_mpic_senses)
between the irq-type value and the type of interrupt (duplicated
here):
static unsigned char map_mpic_senses[4] =3D {
IRQ_TYPE_EDGE_RISING,
IRQ_TYPE_LEVEL_LOW,
IRQ_TYPE_LEVEL_HIGH,
IRQ_TYPE_EDGE_FALLING,
};
> =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x2 0x0 0x0010000>;
reg looks correct.
> =A0 =A0 =A0 =A0 =A0 =A0ranges =3D <0x0 0x0 0x2 0x0 0x00100000>;
Only use ranges if there is a child node.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* How to set external interrupts falling edge sensitive
From: Frank Prepelica @ 2009-02-26 14:46 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm using the mpc8313erdb. I got two external interrupt sources which
are
handled by two UIO drivers.=20
These interrupts shall be triggered on falling edge.=20
Therefore I just added (Kernel version 2.6.24) in
arch/powerpc/sysdev/ipic.c in function ipic_set_irq_type
at line ~484 "flow_type =3D IRQ_TYPE_EDGE_FALLING;"
/* only EXT IRQ senses are programmable on ipic
* internal IRQ senses are LEVEL_LOW
*/
flow_type =3D IRQ_TYPE_EDGE_FALLING; // <---- added this line
if (src =3D=3D IPIC_IRQ_EXT0)
edibit =3D 15;
else
if (src >=3D IPIC_IRQ_EXT1 && src <=3D IPIC_IRQ_EXT7)
edibit =3D (14 - (src - IPIC_IRQ_EXT1));
else
return (flow_type & IRQ_TYPE_LEVEL_LOW) ? 0 :
-EINVAL;
and it seemed to work for me.
But when I'm adding this line in Kernel version 2.6.28.7
I'll get these messages on startup:
setting trigger mode 8 for irq 38 failed (0xc0017160)
setting trigger mode 8 for irq 37 failed (0xc0017160)
setting trigger mode 8 for irq 36 failed (0xc0017160)
setting trigger mode 8 for irq 35 failed (0xc0017160)
setting trigger mode 8 for irq 34 failed (0xc0017160)
setting trigger mode 8 for irq 33 failed (0xc0017160)
setting trigger mode 8 for irq 32 failed (0xc0017160)
...
It seems to me, that this is not the right place to configure the
external interrupts as "falling edge"
I guess that the dtb file might be the right place, please correct me if
I'm wrong. But I have no idea
how to add those both external interrupt sources into the dts file.
Any hints are appreciated! Thanks
regards
Frank
^ permalink raw reply
* [PATCH] Add MPC52xx simple interrupt GPIO support
From: Roman Fietze @ 2009-02-26 14:24 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I've got a target derived from the Lite5200 that needs to use simple
interrupt GPIO pins. I created a patch to support this kind of GPIO.
I would need your opinion and like to hear any criticism. Esp. the
facts that I ad to split up struct mpc52xx_gpio and that the GPIO
numbering might get mixed up concern me.
Because I'm somewhat new to git, at least when it comes to create and
incorporate patches via mail, you have to point out those errors as
well. The first thing I found lready out ist, that my patch isn't
signed off. I'll do that with an final version if I get the chance to
deliver one.
And here the patch:
Add MPC52xx simple interrupt GPIO support
Split of struct mpc52xx_sint_gpio from struct mpc52xx_gpio to allow a
different reg base address in the device tree.
Add the appropriate functions.
Update Documentation.
=2D--
.../powerpc/mpc52xx-device-tree-bindings.txt | 2 +
arch/powerpc/include/asm/mpc52xx.h | 40 +++--
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 164=20
+++++++++++++++++++-
3 files changed, 185 insertions(+), 21 deletions(-)
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt=20
b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index 6f12f1c..b5b31b2 100644
=2D-- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -190,6 +190,8 @@ gpt@<addr> gpt fsl,mpc5200-gpt-gpio General purpose
timers in GPIO mode
gpio@<addr> fsl,mpc5200-gpio MPC5200 simple gpio
controller
+gpio@<addr> fsl,mpc5200-gpio-sint MPC5200 simple interrupt
+ gpio controller
gpio@<addr> fsl,mpc5200-gpio-wkup MPC5200 wakeup gpio
controller
rtc@<addr> rtc mpc5200-rtc Real time clock
diff --git a/arch/powerpc/include/asm/mpc52xx.h=20
b/arch/powerpc/include/asm/mpc52xx.h
index 7655504..01abe61 100644
=2D-- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -126,24 +126,28 @@ struct mpc52xx_gpio {
u8 reserved1[3]; /* GPIO + 0x19 */
u8 outo_dvo; /* GPIO + 0x1c */
u8 reserved2[3]; /* GPIO + 0x1d */
=2D u8 sint_gpioe; /* GPIO + 0x20 */
=2D u8 reserved3[3]; /* GPIO + 0x21 */
=2D u8 sint_ode; /* GPIO + 0x24 */
=2D u8 reserved4[3]; /* GPIO + 0x25 */
=2D u8 sint_ddr; /* GPIO + 0x28 */
=2D u8 reserved5[3]; /* GPIO + 0x29 */
=2D u8 sint_dvo; /* GPIO + 0x2c */
=2D u8 reserved6[3]; /* GPIO + 0x2d */
=2D u8 sint_inten; /* GPIO + 0x30 */
=2D u8 reserved7[3]; /* GPIO + 0x31 */
=2D u16 sint_itype; /* GPIO + 0x34 */
=2D u16 reserved8; /* GPIO + 0x36 */
=2D u8 gpio_control; /* GPIO + 0x38 */
=2D u8 reserved9[3]; /* GPIO + 0x39 */
=2D u8 sint_istat; /* GPIO + 0x3c */
=2D u8 sint_ival; /* GPIO + 0x3d */
=2D u8 bus_errs; /* GPIO + 0x3e */
=2D u8 reserved10; /* GPIO + 0x3f */
+};
+
+/* Simple Interrupt GPIO */
+struct mpc52xx_sint_gpio {
+ u8 sint_gpioe; /* GPIO + 0x00 */
+ u8 reserved3[3]; /* GPIO + 0x01 */
+ u8 sint_ode; /* GPIO + 0x04 */
+ u8 reserved4[3]; /* GPIO + 0x05 */
+ u8 sint_ddr; /* GPIO + 0x08 */
+ u8 reserved5[3]; /* GPIO + 0x09 */
+ u8 sint_dvo; /* GPIO + 0x0c */
+ u8 reserved6[3]; /* GPIO + 0x0d */
+ u8 sint_inten; /* GPIO + 0x10 */
+ u8 reserved7[3]; /* GPIO + 0x11 */
+ u16 sint_itype; /* GPIO + 0x14 */
+ u16 reserved8; /* GPIO + 0x16 */
+ u8 gpio_control; /* GPIO + 0x18 */
+ u8 reserved9[3]; /* GPIO + 0x19 */
+ u8 sint_istat; /* GPIO + 0x1c */
+ u8 sint_ival; /* GPIO + 0x1d */
+ u8 bus_errs; /* GPIO + 0x1e */
+ u8 reserved10; /* GPIO + 0x1f */
};
=20
#define MPC52xx_GPIO_PSC_CONFIG_UART_WITHOUT_CD 4
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c=20
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 07f89ae..8595aad 100644
=2D-- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -31,9 +31,9 @@ static DEFINE_SPINLOCK(gpio_lock);
=20
struct mpc52xx_gpiochip {
struct of_mm_gpio_chip mmchip;
=2D unsigned int shadow_dvo;
=2D unsigned int shadow_gpioe;
=2D unsigned int shadow_ddr;
+ uint32_t shadow_dvo;
+ uint32_t shadow_gpioe;
+ uint32_t shadow_ddr;
};
=20
/*
@@ -355,6 +355,161 @@ static struct of_platform_driver=20
mpc52xx_simple_gpiochip_driver =3D {
};
=20
/*
+ * GPIO LIB API implementation for simple interrupt GPIOs
+ *
+ * There's a maximum of 8 simple interrupt GPIOs. Which of these are
+ * available for use depends on your board setup. The numbering
+ * reflects the bit numbering in the port registers:
+ *
+ * 0.. 3 > ETH_16..ETH_13
+ * 4 > USB1_9
+ * 5 > PSC3_8
+ * 6.. 7 > PSC3_5..PSC3_4
+ */
+static int mpc52xx_simple_interrupt_gpio_get(struct gpio_chip *gc, unsigne=
d=20
int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc =3D to_of_mm_gpio_chip(gc);
+ struct mpc52xx_sint_gpio __iomem *regs =3D mm_gc->regs;
+ unsigned int ret;
+
+ ret =3D (in_8(®s->sint_ival) >> (7 - gpio)) & 1;
+
+ pr_info("%s(..,%u) data=3D0x%02x ret=3D%d\n", __func__, gpio, in_8
(®s->sint_ival), ret);
+
+ return ret;
+}
+
+static inline void
+__mpc52xx_simple_interrupt_gpio_set(struct gpio_chip *gc, unsigned int gpi=
o,=20
int val)
+{
+ struct of_mm_gpio_chip *mm_gc =3D to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpiochip *chip =3D container_of(mm_gc,
+ struct mpc52xx_gpiochip, mmchip);
+ struct mpc52xx_sint_gpio __iomem *regs =3D mm_gc->regs;
+
+ if (val)
+ chip->shadow_dvo |=3D 1 << (7 - gpio);
+ else
+ chip->shadow_dvo &=3D ~(1 << (7 - gpio));
+ out_8(®s->sint_dvo, chip->shadow_dvo);
+}
+
+static void
+mpc52xx_simple_interrupt_gpio_set(struct gpio_chip *gc, unsigned int gpio,=
=20
int val)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ __mpc52xx_simple_interrupt_gpio_set(gc, gpio, val);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+}
+
+static int mpc52xx_simple_interrupt_gpio_dir_in(struct gpio_chip *gc,=20
unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc =3D to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpiochip *chip =3D container_of(mm_gc,
+ struct mpc52xx_gpiochip, mmchip);
+ struct mpc52xx_sint_gpio __iomem *regs =3D mm_gc->regs;
+ unsigned long flags;
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ /* set the direction */
+ chip->shadow_ddr &=3D ~(1 << (7 - gpio));
+ out_8(®s->sint_ddr, chip->shadow_ddr);
+
+ /* and enable the pin */
+ chip->shadow_gpioe |=3D 1 << (7 - gpio);
+ out_8(®s->sint_gpioe, chip->shadow_gpioe);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ return 0;
+}
+
+static int
+mpc52xx_simple_interrupt_gpio_dir_out(struct gpio_chip *gc, unsigned int=20
gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc =3D to_of_mm_gpio_chip(gc);
+ struct mpc52xx_gpiochip *chip =3D container_of(mm_gc,
+ struct mpc52xx_gpiochip, mmchip);
+ struct mpc52xx_sint_gpio __iomem *regs =3D mm_gc->regs;
+ unsigned long flags;
+
+ pr_info("%s(...,%u,%d)\n", __func__, gpio, val);
+
+ spin_lock_irqsave(&gpio_lock, flags);
+
+ /* First set initial value */
+ __mpc52xx_simple_interrupt_gpio_set(gc, gpio, val);
+
+ /* Then set direction */
+ chip->shadow_ddr |=3D 1 << (7 - gpio);
+ out_8(®s->sint_ddr, chip->shadow_ddr);
+
+ /* Finally enable the pin */
+ chip->shadow_gpioe |=3D 1 << (7 - gpio);
+ out_8(®s->sint_gpioe, chip->shadow_gpioe);
+
+ spin_unlock_irqrestore(&gpio_lock, flags);
+
+ pr_info("%s: gpio: %d val: %d\n", __func__, gpio, val);
+
+ return 0;
+}
+
+static int __devinit mpc52xx_simple_interrupt_gpiochip_probe(struct of_dev=
ice=20
*ofdev,
+ const struct of_device_id *match)
+{
+ struct mpc52xx_gpiochip *chip;
+ struct of_gpio_chip *ofchip;
+ struct mpc52xx_sint_gpio __iomem *regs;
+ int ret;
+
+ chip =3D kzalloc(sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ ofchip =3D &chip->mmchip.of_gc;
+
+ ofchip->gpio_cells =3D 2;
+ ofchip->gc.ngpio =3D 8;
+ ofchip->gc.direction_input =3D mpc52xx_simple_interrupt_gpio_dir_in;
+ ofchip->gc.direction_output =3D mpc52xx_simple_interrupt_gpio_dir_out;
+ ofchip->gc.get =3D mpc52xx_simple_interrupt_gpio_get;
+ ofchip->gc.set =3D mpc52xx_simple_interrupt_gpio_set;
+
+ ret =3D of_mm_gpiochip_add(ofdev->node, &chip->mmchip);
+ if (ret)
+ return ret;
+
+ regs =3D chip->mmchip.regs;
+ pr_info("%s() regs=3D%p\n", __func__, regs);
+
+ chip->shadow_gpioe =3D in_8(®s->sint_gpioe);
+ chip->shadow_ddr =3D in_8(®s->sint_ddr);
+ chip->shadow_dvo =3D in_8(®s->sint_dvo);
+
+ return 0;
+}
+
+static const struct of_device_id mpc52xx_simple_interrupt_gpiochip_match[]=
=3D=20
{
+ {
+ .compatible =3D "fsl,mpc5200-gpio-sint",
+ },
+ {}
+};
+
+static struct of_platform_driver mpc52xx_simple_interrupt_gpiochip_driver =
=3D {
+ .name =3D "gpio_sint",
+ .match_table =3D mpc52xx_simple_interrupt_gpiochip_match,
+ .probe =3D mpc52xx_simple_interrupt_gpiochip_probe,
+ .remove =3D mpc52xx_gpiochip_remove,
+};
+
+/*
* GPIO LIB API implementation for gpt GPIOs.
*
* Each gpt only has a single GPIO.
@@ -444,6 +599,9 @@ static int __init mpc52xx_gpio_init(void)
if (of_register_platform_driver(&mpc52xx_simple_gpiochip_driver))
printk(KERN_ERR "Unable to register simple GPIO driver\n");
=20
+ if (of_register_platform_driver(&mpc52xx_simple_interrupt_gpiochip_driver=
))
+ printk(KERN_ERR "Unable to register simple interrupt GPIO driver\n");
+
if (of_register_platform_driver(&mpc52xx_gpt_gpiochip_driver))
printk(KERN_ERR "Unable to register gpt GPIO driver\n");
=20
=2D-=20
1.6.1.2
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
^ permalink raw reply
* Re: MPC8313E-RDB and USB OTG
From: Michael Bergandi @ 2009-02-26 13:22 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <2a27d3730902252243i6e0e65f6te78831cfcbae823b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 763 bytes --]
Leo, sorry for sending this twice. Forgot to cc the list.
> I am hoping someone can shed some light on the state of the USB support in
> > the
> > 2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options
> are
> > a bit different than the ones from the provided LTIB kernel--- for
> obvious
> > reasons---
> > and I am trying to figure out how to get OTG working in this version of
> the
> > kernel
> > on my board.
>
> USB OTG support for Freescale USB has not been included in mainline.
> So you need to bring the OTG code up-to-date, or stay with the LTIB
> kernel.
>
> - Leo
>
Thanks Leo. I will look into getting the OTG code included.
Do you have a general outline of what would need to be done to it?
Any potential trouble spots?
Mike
[-- Attachment #2: Type: text/html, Size: 1059 bytes --]
^ permalink raw reply
* Two thoughts about SPI chip-selects in the DTS
From: Henk Stegeman @ 2009-02-26 12:13 UTC (permalink / raw)
To: linuxppc-dev
As far as I understand the DTS bindings now support an SPI master controller to
- use the chip-selects controlled directly by the SPI master controller hardware
or
- to use GPIO's trough gpiolib as chip selects
but not a combination of both, am I right?
Now every SPI driver needs to be adapted to provide support for using
gpios as chip-selects, Wouldn't it be possible to let the
divers/of/of_spi take care of all the work required to use gpios as
chip-selects?
^ permalink raw reply
* Re: [PATCH] Enable hashdist by default on 64bit NUMA
From: David Miller @ 2009-02-26 11:34 UTC (permalink / raw)
To: anton; +Cc: linuxppc-dev
In-Reply-To: <20090226112431.GA25330@kryten>
From: Anton Blanchard <anton@samba.org>
Date: Thu, 26 Feb 2009 22:24:32 +1100
> On PowerPC we allocate large boot time hashes on node 0. This leads to
> an imbalance in the free memory, for example on a 64GB box (4 x 16GB
> nodes):
>
> Free memory:
> Node 0: 97.03%
> Node 1: 98.54%
> Node 2: 98.42%
> Node 3: 98.53%
>
> If we switch to using vmalloc (like ia64 and x86-64) things are more
> balanced:
>
> Free memory:
> Node 0: 97.53%
> Node 1: 98.35%
> Node 2: 98.33%
> Node 3: 98.33%
>
> For many HPC applications we are limited by the free available memory on
> the smallest node, so even though the same amount of memory is used the
> better balancing helps.
>
> Since all 64bit NUMA capable architectures should have sufficient
> vmalloc space, it makes sense to enable it via CONFIG_64BIT.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [git pull] Please pull powerpc.git merge branch
From: Josh Boyer @ 2009-02-26 11:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1235621244.8805.340.camel@pasglop>
On Thu, Feb 26, 2009 at 03:07:24PM +1100, Benjamin Herrenschmidt wrote:
>Hi Linus !
>
>Please pull a few regression fixes for powerpc.
>
>Cheers,
>Ben.
>
>The following changes since commit 169d418b127b98a3e464e9c4b807ad083760f98c:
> Linus Torvalds (1):
> Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6
>
>are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
>Mark Nelson (2):
> powerpc: Fix 64bit memcpy() regression
> powerpc: Fix 64bit __copy_tofrom_user() regression
>
>Michael Neuling (1):
> powerpc: Fix load/store float double alignment handler
You don't seem to have your fix for PCI 2.x stuff on 4xx here. Patchwork
has it in accepted state and Geert has been asking if it would go in 2.6.29.
Any idea what is up with that one?
josh
^ permalink raw reply
* [PATCH] Enable hashdist by default on 64bit NUMA
From: Anton Blanchard @ 2009-02-26 11:24 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20090220.000354.198880712.davem@davemloft.net>
Hi David,
> Hmmm... my bad, I think you need to keep the CONFIG_NUMA
> there too as there is a TLB usage penalty for non-NUMA
> systems if you only use CONFIG_64BIT there.
Sorry that was my screwup, here's a fixed version.
Anton
--
On PowerPC we allocate large boot time hashes on node 0. This leads to
an imbalance in the free memory, for example on a 64GB box (4 x 16GB
nodes):
Free memory:
Node 0: 97.03%
Node 1: 98.54%
Node 2: 98.42%
Node 3: 98.53%
If we switch to using vmalloc (like ia64 and x86-64) things are more
balanced:
Free memory:
Node 0: 97.53%
Node 1: 98.35%
Node 2: 98.33%
Node 3: 98.33%
For many HPC applications we are limited by the free available memory on
the smallest node, so even though the same amount of memory is used the
better balancing helps.
Since all 64bit NUMA capable architectures should have sufficient
vmalloc space, it makes sense to enable it via CONFIG_64BIT.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 95837bf..0c4d4b7 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -144,10 +144,10 @@ extern void *alloc_large_system_hash(const char *tablename,
#define HASH_EARLY 0x00000001 /* Allocating during early boot? */
-/* Only NUMA needs hash distribution.
- * IA64 and x86_64 have sufficient vmalloc space.
+/* Only NUMA needs hash distribution. 64bit NUMA architectures have
+ * sufficient vmalloc space.
*/
-#if defined(CONFIG_NUMA) && (defined(CONFIG_IA64) || defined(CONFIG_X86_64))
+#if defined(CONFIG_NUMA) && defined(CONFIG_64BIT)
#define HASHDIST_DEFAULT 1
#else
#define HASHDIST_DEFAULT 0
^ permalink raw reply related
* [PATCH v2 net] gianfar : Do right check on num_txbdfree
From: Rini van Zetten @ 2009-02-26 10:25 UTC (permalink / raw)
To: David Miller; +Cc: Linuxppc-dev, afleming, netdev
In-Reply-To: <20090226.020318.50178027.davem@davemloft.net>
This patch fixes a wrong check on num_txbdfree. It could lead to num_txbdfree become nagative.
Result was that the gianfar stops sending data.
Changes from first version :
- removed a space between parens (David Millers comment)
- full email address in signed off line
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
---
drivers/net/gianfar.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 7ef1ffd..2dc3bd3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1284,9 +1284,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock_irqsave(&priv->txlock, flags);
/* check if there is space to queue this packet */
- if (nr_frags > priv->num_txbdfree) {
+ if ((nr_frags+1) > priv->num_txbdfree) {
/* no space, stop the queue */
netif_stop_queue(dev);
dev->stats.tx_fifo_errors++;
spin_unlock_irqrestore(&priv->txlock, flags);
--
^ permalink raw reply related
* [PATCH 1/1] Fix 64bit Mapple Host Bridge Address and Size Nodes
From: Tiejun Chen @ 2009-02-26 10:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm
In-Reply-To: <1235642785-9684-1-git-send-email-tiejun.chen@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
In the DTB tree created by firmware on Maple 64bit target, host bridge
parent
node has specified both of these two properties to be 2. However, the actual
"cell" value for host bridge node is 1. we have to provide one fixup
function.
Signed-off-by: Tiejun Chen <tiejun.china@gmail.com>
---
arch/powerpc/kernel/prom_init.c | 42
+++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
index 2445945..9cd23b6 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1948,8 +1948,49 @@ static void __init fixup_device_tree_maple(void)
prom_setprop(isa, name, "ranges",
isa_ranges, sizeof(isa_ranges));
}
+
+/* On Maple 64bit target host bridge parent node has specified address and
+ * size properties to be 2. But the actual "cell" value for host bridge
node
+ * is 1 since early MOTLoad internal bug. */
+static void __init fixup_device_tree_maple_hb(void)
+{
+ phandle hb;
+ u32 hb_ranges[4];
+ u32 size_cell, addr_cell;
+ struct prom_t *_prom = &RELOC(prom);
+ char *name;
+
+ name = "/hostbridge@f8000000";
+ hb = call_prom("finddevice", 1, 1, ADDR(name));
+ if (!PHANDLE_VALID(hb))
+ return;
+
+ if (prom_getproplen(hb, "reg") != 8)
+ return;
+
+ if (prom_getprop(hb, "reg", hb_ranges, (sizeof(hb_ranges))/2)
+ == PROM_ERROR)
+ return;
+
+ prom_getprop(_prom->root, "#address-cells", &addr_cell,
sizeof(addr_cell));
+ prom_getprop(_prom->root, "#size-cells", &size_cell,
sizeof(size_cell));
+
+ if ((addr_cell != 2) || (size_cell != 2) ||
+ (hb_ranges[0] != 0xf8000000))
+ return;
+
+ prom_printf("Fixing up bogus HOSTBRIDGE reg on Maple/Apache...\n");
+
+ hb_ranges[3] = hb_ranges[1];
+ hb_ranges[1] = hb_ranges[0];
+ hb_ranges[0] = hb_ranges[2] = 0;
+ prom_setprop(hb, name, "reg",
+ hb_ranges, sizeof(hb_ranges));
+}
+
#else
#define fixup_device_tree_maple()
+#define fixup_device_tree_maple_hb()
#endif
#ifdef CONFIG_PPC_CHRP
@@ -2190,6 +2231,7 @@ static void __init fixup_device_tree_efika(void)
static void __init fixup_device_tree(void)
{
fixup_device_tree_maple();
+ fixup_device_tree_maple_hb();
fixup_device_tree_chrp();
fixup_device_tree_pmac();
fixup_device_tree_efika();
--
1.5.6
[-- Attachment #2: Type: text/html, Size: 3143 bytes --]
^ permalink raw reply related
* Re: [PATCH net] gianfar : Do right check on num_txbdfree
From: David Miller @ 2009-02-26 10:03 UTC (permalink / raw)
To: rini; +Cc: Linuxppc-dev, afleming, netdev
In-Reply-To: <49A6595A.9000405@arvoo.nl>
From: Rini van Zetten <rini@arvoo.nl>
Date: Thu, 26 Feb 2009 09:56:58 +0100
> This patch fixes a wrong check on num_txbdfree. It could lead to
> num_txbdfree become nagative. Result was that the gianfar stops
> sending data.
>
> Signed-off-by: Rini van Zetten <rini at arvoo dot nl
Please use rini@arvoo.nl in your signoffs, you cannot
hide on the inna-net.
> - if (nr_frags > priv->num_txbdfree) {
> + if ( (nr_frags+1) > priv->num_txbdfree) {
Please don't put a space between the parens there "( (", like
that.
^ permalink raw reply
* [PATCH net] gianfar : Do right check on num_txbdfree
From: Rini van Zetten @ 2009-02-26 8:56 UTC (permalink / raw)
To: Linuxppc-dev, netdev, afleming
This patch fixes a wrong check on num_txbdfree. It could lead to num_txbdfree become nagative.
Result was that the gianfar stops sending data.
Signed-off-by: Rini van Zetten <rini at arvoo dot nl>
---
drivers/net/gianfar.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 7ef1ffd..2dc3bd3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1284,9 +1284,8 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock_irqsave(&priv->txlock, flags);
/* check if there is space to queue this packet */
- if (nr_frags > priv->num_txbdfree) {
+ if ( (nr_frags+1) > priv->num_txbdfree) {
/* no space, stop the queue */
netif_stop_queue(dev);
dev->stats.tx_fifo_errors++;
spin_unlock_irqrestore(&priv->txlock, flags);
--
^ permalink raw reply related
* Re: MPC8313E-RDB and USB OTG
From: Li Yang @ 2009-02-26 6:43 UTC (permalink / raw)
To: Michael Bergandi; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1c641bc80902251151v5a4a5e15g13f6711510acb7ee@mail.gmail.com>
On Thu, Feb 26, 2009 at 3:51 AM, Michael Bergandi <mbergandi@gmail.com> wrote:
> Hi all,
>
> I am hoping someone can shed some light on the state of the USB support in
> the
> 2.6.28 kernel for USB OTG on the MPC8313E RDB. The configuration options are
> a bit different than the ones from the provided LTIB kernel--- for obvious
> reasons---
> and I am trying to figure out how to get OTG working in this version of the
> kernel
> on my board.
USB OTG support for Freescale USB has not been included in mainline.
So you need to bring the OTG code up-to-date, or stay with the LTIB
kernel.
- Leo
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-02-26 4:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Please pull a few regression fixes for powerpc.
Cheers,
Ben.
The following changes since commit 169d418b127b98a3e464e9c4b807ad083760f98c:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../tiwai/sound-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Mark Nelson (2):
powerpc: Fix 64bit memcpy() regression
powerpc: Fix 64bit __copy_tofrom_user() regression
Michael Neuling (1):
powerpc: Fix load/store float double alignment handler
arch/powerpc/kernel/align.c | 29 +++++++++++++----------------
arch/powerpc/lib/copyuser_64.S | 38 +++++++++++++++++++++++++++++++-------
arch/powerpc/lib/memcpy_64.S | 26 ++++++++++++++++++++------
3 files changed, 64 insertions(+), 29 deletions(-)
^ permalink raw reply
* [PATCH] powerpc: Fix 64bit __copy_tofrom_user() regression
From: Mark Nelson @ 2009-02-25 23:46 UTC (permalink / raw)
To: benh
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Geert Uytterhoeven, Andrew Morton, linux-ext4
In-Reply-To: <200902261026.48183.markn@au1.ibm.com>
This fixes a regression introduced by commit
a4e22f02f5b6518c1484faea1f88d81802b9feac ("powerpc: Update 64bit
__copy_tofrom_user() using CPU_FTR_UNALIGNED_LD_STD").
The same bug that existed in the 64bit memcpy() also exists here so fix
it here too. The fix is the same as that applied to memcpy() with the
addition of fixes for the exception handling code required for
__copy_tofrom_user().
This stops us reading beyond the end of the source region we were told
to copy.
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
arch/powerpc/lib/copyuser_64.S | 38 +++++++++++++++++++++++++++++++-------
1 file changed, 31 insertions(+), 7 deletions(-)
Index: upstream/arch/powerpc/lib/copyuser_64.S
===================================================================
--- upstream.orig/arch/powerpc/lib/copyuser_64.S
+++ upstream/arch/powerpc/lib/copyuser_64.S
@@ -62,18 +62,19 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
72: std r8,8(r3)
beq+ 3f
addi r3,r3,16
-23: ld r9,8(r4)
.Ldo_tail:
bf cr7*4+1,1f
- rotldi r9,r9,32
+23: lwz r9,8(r4)
+ addi r4,r4,4
73: stw r9,0(r3)
addi r3,r3,4
1: bf cr7*4+2,2f
- rotldi r9,r9,16
+44: lhz r9,8(r4)
+ addi r4,r4,2
74: sth r9,0(r3)
addi r3,r3,2
2: bf cr7*4+3,3f
- rotldi r9,r9,8
+45: lbz r9,8(r4)
75: stb r9,0(r3)
3: li r3,0
blr
@@ -141,11 +142,24 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
6: cmpwi cr1,r5,8
addi r3,r3,32
sld r9,r9,r10
- ble cr1,.Ldo_tail
+ ble cr1,7f
34: ld r0,8(r4)
srd r7,r0,r11
or r9,r7,r9
- b .Ldo_tail
+7:
+ bf cr7*4+1,1f
+ rotldi r9,r9,32
+94: stw r9,0(r3)
+ addi r3,r3,4
+1: bf cr7*4+2,2f
+ rotldi r9,r9,16
+95: sth r9,0(r3)
+ addi r3,r3,2
+2: bf cr7*4+3,3f
+ rotldi r9,r9,8
+96: stb r9,0(r3)
+3: li r3,0
+ blr
.Ldst_unaligned:
PPC_MTOCRF 0x01,r6 /* put #bytes to 8B bdry into cr7 */
@@ -218,7 +232,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
121:
132:
addi r3,r3,8
-123:
134:
135:
138:
@@ -226,6 +239,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
140:
141:
142:
+123:
+144:
+145:
/*
* here we have had a fault on a load and r3 points to the first
@@ -309,6 +325,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
187:
188:
189:
+194:
+195:
+196:
1:
ld r6,-24(r1)
ld r5,-8(r1)
@@ -329,7 +348,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
.llong 72b,172b
.llong 23b,123b
.llong 73b,173b
+ .llong 44b,144b
.llong 74b,174b
+ .llong 45b,145b
.llong 75b,175b
.llong 24b,124b
.llong 25b,125b
@@ -347,6 +368,9 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
.llong 79b,179b
.llong 80b,180b
.llong 34b,134b
+ .llong 94b,194b
+ .llong 95b,195b
+ .llong 96b,196b
.llong 35b,135b
.llong 81b,181b
.llong 36b,136b
^ permalink raw reply
* [PATCH] powerpc: Fix 64bit memcpy() regression
From: Mark Nelson @ 2009-02-25 23:26 UTC (permalink / raw)
To: benh
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Geert Uytterhoeven, Andrew Morton, linux-ext4
In-Reply-To: <200902251752.56514.markn@au1.ibm.com>
This fixes a regression introduced by commit
25d6e2d7c58ddc4a3b614fc5381591c0cfe66556 ("powerpc: Update 64bit memcpy()
using CPU_FTR_UNALIGNED_LD_STD").
This commit allowed CPUs that have the CPU_FTR_UNALIGNED_LD_STD CPU
feature bit present to do the memcpy() with unaligned load doubles. But,
along with this came a bug where our final load double would read bytes
beyond a page boundary and into the next (unmapped) page. This was caught
by enabling CONFIG_DEBUG_PAGEALLOC,
The fix was to read only the number of bytes that we need to store rather
than reading a full 8-byte doubleword and storing only a portion of that.
In order to minimise the amount of existing code touched we use the
original do_tail for the src_unaligned case.
Below is an example of the regression, as reported by Sachin Sant:
Unable to handle kernel paging request for data at address 0xc00000003f380000
Faulting instruction address: 0xc000000000039574
cpu 0x1: Vector: 300 (Data Access) at [c00000003baf3020]
pc: c000000000039574: .memcpy+0x74/0x244
lr: d00000000244916c: .ext3_xattr_get+0x288/0x2f4 [ext3]
sp: c00000003baf32a0
msr: 8000000000009032
dar: c00000003f380000
dsisr: 40000000
current = 0xc00000003e54b010
paca = 0xc000000000a53680
pid = 1840, comm = readahead
enter ? for help
[link register ] d00000000244916c .ext3_xattr_get+0x288/0x2f4 [ext3]
[c00000003baf32a0] d000000002449104 .ext3_xattr_get+0x220/0x2f4 [ext3]
(unreliab
le)
[c00000003baf3390] d00000000244a6e8 .ext3_xattr_security_get+0x40/0x5c [ext3]
[c00000003baf3400] c000000000148154 .generic_getxattr+0x74/0x9c
[c00000003baf34a0] c000000000333400 .inode_doinit_with_dentry+0x1c4/0x678
[c00000003baf3560] c00000000032c6b0 .security_d_instantiate+0x50/0x68
[c00000003baf35e0] c00000000013c818 .d_instantiate+0x78/0x9c
[c00000003baf3680] c00000000013ced0 .d_splice_alias+0xf0/0x120
[c00000003baf3720] d00000000243e05c .ext3_lookup+0xec/0x134 [ext3]
[c00000003baf37c0] c000000000131e74 .do_lookup+0x110/0x260
[c00000003baf3880] c000000000134ed0 .__link_path_walk+0xa98/0x1010
[c00000003baf3970] c0000000001354a0 .path_walk+0x58/0xc4
[c00000003baf3a20] c000000000135720 .do_path_lookup+0x138/0x1e4
[c00000003baf3ad0] c00000000013645c .path_lookup_open+0x6c/0xc8
[c00000003baf3b70] c000000000136780 .do_filp_open+0xcc/0x874
[c00000003baf3d10] c0000000001251e0 .do_sys_open+0x80/0x140
[c00000003baf3dc0] c00000000016aaec .compat_sys_open+0x24/0x38
[c00000003baf3e30] c00000000000855c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff0ef18
SP (ffc6f4b0) is in userspace
1:mon>
Signed-off-by: Mark Nelson <markn@au1.ibm.com>
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Tested-by: Sachin Sant <sachinp@in.ibm.com>
---
arch/powerpc/lib/memcpy_64.S | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
Index: upstream/arch/powerpc/lib/memcpy_64.S
===================================================================
--- upstream.orig/arch/powerpc/lib/memcpy_64.S
+++ upstream/arch/powerpc/lib/memcpy_64.S
@@ -53,18 +53,19 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
3: std r8,8(r3)
beq 3f
addi r3,r3,16
- ld r9,8(r4)
.Ldo_tail:
bf cr7*4+1,1f
- rotldi r9,r9,32
+ lwz r9,8(r4)
+ addi r4,r4,4
stw r9,0(r3)
addi r3,r3,4
1: bf cr7*4+2,2f
- rotldi r9,r9,16
+ lhz r9,8(r4)
+ addi r4,r4,2
sth r9,0(r3)
addi r3,r3,2
2: bf cr7*4+3,3f
- rotldi r9,r9,8
+ lbz r9,8(r4)
stb r9,0(r3)
3: ld r3,48(r1) /* return dest pointer */
blr
@@ -133,11 +134,24 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
cmpwi cr1,r5,8
addi r3,r3,32
sld r9,r9,r10
- ble cr1,.Ldo_tail
+ ble cr1,6f
ld r0,8(r4)
srd r7,r0,r11
or r9,r7,r9
- b .Ldo_tail
+6:
+ bf cr7*4+1,1f
+ rotldi r9,r9,32
+ stw r9,0(r3)
+ addi r3,r3,4
+1: bf cr7*4+2,2f
+ rotldi r9,r9,16
+ sth r9,0(r3)
+ addi r3,r3,2
+2: bf cr7*4+3,3f
+ rotldi r9,r9,8
+ stb r9,0(r3)
+3: ld r3,48(r1) /* return dest pointer */
+ blr
.Ldst_unaligned:
PPC_MTOCRF 0x01,r6 # put #bytes to 8B bdry into cr7
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Mark Nelson @ 2009-02-25 23:20 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, Paul Mackerras,
Geert Uytterhoeven, Andrew Morton, linux-ext4
In-Reply-To: <200902260945.41990.markn@au1.ibm.com>
On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote:
> On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
> > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
> > > > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > > > On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > > > > > Jan Kara wrote:
> > > > > > > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > > > > > > somehow got beyond end of the page referenced by bh->b_data. So it means
> > > > > > > that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> > > > > > > ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> > > > > > > particular checks whether e_value_offs + e_value_size isn't greater than
> > > > > > > bh->b_size. So I see no way how memcpy can get beyond end of the page.
> > > > > > > Sachin, is the problem reproducible? If yes, can you send us contents
> > > > > > >
> > > > > > Yes, i am able to recreate this problem easily. As i had mentioned if the
> > > > > > earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
> > > > > > i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
> > > > > > without any problem.
> > > > >
> > > > > Hi Sanchin and Geert,
> > > > >
> > > > > Does the patch below fix the problems you're seeing? If it does I'll send
> > > > > a properly written up and formatted patch to linuxppc-dev (as well as
> > > > > another one to fix the same problem in copy_tofrom_user()).
> > > >
> > > > Unfortunately not, now it crashes while accessing the memory pointed to by
> > > > GPR16, in
> > > >
> > > > NIP: copy_page_range+x0608/0x628
> > > > LR: dup_mm+0x2e4/0x428
> > > > Trace: debug_table+0xcc70/0x1afe0 (unreliable)
> > > > dup_mm+0x2e4/0x428
> > > > copy_process+0x86c/0xf9c
> > > > do_fork+0x188/0x39c
> > > > sys_clone+0x58/0x70
> > > > ppc_clone+0x8/0xc
> > > >
> > > > However, after reverting 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556, I still see
> > > > similar problems as above (crash in copy_page_range()).
> > > > Which makes me think that
> > > > 1. Your new patch fixes the problem introduced by 25d6e2d7,
> > > > 2. There's still another issue than the one introduced by 25d6e2d7.
> > >
> > > Does the following patch fix the errors you're seeing? (it applies the
> > > same fix as the previous patch but this time to copy_tofrom_user, which
> > > I updated in a4e22f02f5b6518c1484faea1f88d81802b9feac)
> >
> > Thanks, but I still get crashes in copy_page_range().
> >
>
> Hmmm... I'm out of ideas for the moment, but thanks for testing anyway!
>
> Mark
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
If you revert both 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556 and
a4e22f02f5b6518c1484faea1f88d81802b9feac, does it help? You could also
try to revert 57dda6ef5bd5b9e60410477ad29e654097e2cca1 just in case I
need to keep wearing the brown paper bag for a bit longer :)
Thanks!
Mark
^ permalink raw reply
* Re: Crash (ext3 ) during 2.6.29-rc6 boot
From: Mark Nelson @ 2009-02-25 22:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jan Kara, Jan Kara, Mel Gorman, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-ext4
In-Reply-To: <alpine.LRH.2.00.0902251430410.4063@vixen.sonytel.be>
On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
> On Wed, 25 Feb 2009, Mark Nelson wrote:
> > On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
> > > On Wed, 25 Feb 2009, Mark Nelson wrote:
> > > > On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
> > > > > Jan Kara wrote:
> > > > > > Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
> > > > > > somehow got beyond end of the page referenced by bh->b_data. So it means
> > > > > > that le16_to_cpu(entry->e_value_offs) + size > page_size. But
> > > > > > ext3_xattr_find_entry() calls ext3_xattr_check_entry() which in
> > > > > > particular checks whether e_value_offs + e_value_size isn't greater than
> > > > > > bh->b_size. So I see no way how memcpy can get beyond end of the page.
> > > > > > Sachin, is the problem reproducible? If yes, can you send us contents
> > > > > >
> > > > > Yes, i am able to recreate this problem easily. As i had mentioned if the
> > > > > earlier kernel is booted with selinux enabled and then 2.6.29-rc6 is booted
> > > > > i get this crash. But if i specify selinux=0 at command line, 2.6.29-rc6 boots
> > > > > without any problem.
> > > >
> > > > Hi Sanchin and Geert,
> > > >
> > > > Does the patch below fix the problems you're seeing? If it does I'll send
> > > > a properly written up and formatted patch to linuxppc-dev (as well as
> > > > another one to fix the same problem in copy_tofrom_user()).
> > >
> > > Unfortunately not, now it crashes while accessing the memory pointed to by
> > > GPR16, in
> > >
> > > NIP: copy_page_range+x0608/0x628
> > > LR: dup_mm+0x2e4/0x428
> > > Trace: debug_table+0xcc70/0x1afe0 (unreliable)
> > > dup_mm+0x2e4/0x428
> > > copy_process+0x86c/0xf9c
> > > do_fork+0x188/0x39c
> > > sys_clone+0x58/0x70
> > > ppc_clone+0x8/0xc
> > >
> > > However, after reverting 25d6e2d7c58ddc4a3b614fc5381591c0cfe66556, I still see
> > > similar problems as above (crash in copy_page_range()).
> > > Which makes me think that
> > > 1. Your new patch fixes the problem introduced by 25d6e2d7,
> > > 2. There's still another issue than the one introduced by 25d6e2d7.
> >
> > Does the following patch fix the errors you're seeing? (it applies the
> > same fix as the previous patch but this time to copy_tofrom_user, which
> > I updated in a4e22f02f5b6518c1484faea1f88d81802b9feac)
>
> Thanks, but I still get crashes in copy_page_range().
>
Hmmm... I'm out of ideas for the moment, but thanks for testing anyway!
Mark
^ 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