* Re: [PATCH Resend2] Remove 'SBC8240 Wind River' Device Driver Code
From: Subrata Modak @ 2009-07-10 8:58 UTC (permalink / raw)
To: David Woodhouse
Cc: carolyn.j.smith, Stephen Rothwell, Artem Bityutskiy, dedekind,
linux-kernel, Jim Cromie, Sachin P Sant, linux-next, linux-mtd,
Linuxppc-dev, Scott Wood, Balbir Singh
In-Reply-To: <1247216007.29541.2.camel@macbook.infradead.org>
On Fri, 2009-07-10 at 09:53 +0100, David Woodhouse wrote:
> On Fri, 2009-07-10 at 14:17 +0530, Subrata Modak wrote:
> > Is it possible to get this patch through and before 2.6.31 stable is
> > released ?
>
Hi David,
> Hm, I was ignoring this until I was sure all the last-minute fixes for
> 2.6.31 were out of the way; I was planning to submit it for 2.6.32.
>
> Do we really need to submit it for 2.6.31? It's not a regression, is it?
> It's been like this for _ages_.
True. But it gives annoying build fails on randconfig next trees. And
we(Sachin & myself) has been reporting it from March/April. If you feel
there is still room to be pushed to 2.6.31, then please do it. Else,
2.6.32 will be fine. Thanks for your support.
Regards--
Subrata
>
^ permalink raw reply
* Memory usage of a process
From: Günter Leonhardt @ 2009-07-10 9:08 UTC (permalink / raw)
To: linuxppc-dev
=20
Hello,
analysing the memory usage of a process, I found some questions.
I'am using a system with 128 MB physical RAM, no disk, 2.6.27 kernel.
Running top, I see 38 MB in use, 90 MB free, but a VSZ for my process of =
158 MB.
Looking at /proc/<pid>/maps, I see that the process uses 140 MB without =
shared libs.
So how it is possible that the process can allocate more memory than =
there is, without posibility of swapping?
Why said top that 90 MB free? Does the kernel serve the allocation only =
if ist really used?
G=FCnter
^ permalink raw reply
* Re: Bestcomm trouble with NAPI for MPC5200 FEC
From: Wolfgang Grandegger @ 2009-07-10 9:16 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40907091422v3e93fc50j5fc30f99077a8df6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7548 bytes --]
Grant Likely wrote:
> On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger<wg@grandegger.com> wrote:
>> Hello,
>>
>> I'm currently trying to implement NAPI for the FEC on the MPC5200 to
>> solve the well known problem, that network packet storms can cause
>> interrupt flooding, which may totally block the system.
>
> Good to hear it! Thanks for this work.
>
>> The NAPI
>> implementation, in principle, is straight forward and works
>> well under normal and moderate network load. It just calls disable_irq()
>> in the receive interrupt handler to defer packet processing to the NAPI
>> poll callback, which calls enable_irq() when it has processed all
>> packets. Unfortunately, under heavy network load (packet storm),
>> problems show up:
>>
>> - With DENX 2.4.25, the Bestcomm RX task gets and remains stopped after
>> a while under additional system load. I have no idea how and when
>> Bestcom tasks are stopped. In the auto-start mode, the firmware should
>> poll forever for the next free descriptor block.
>>
>> - With 2.6.31-rc2, the RFIFO error occurs quickly which does reset the
>> FEC and Bestcomm (unfortunately, this does trigger an oops because
>> it's called from the interrupt context, but that's another issue).
>>
>> I'm realized that working with Bestcomm is a pain :-( but so far I have
>> little knowledge of the Bestcomm limitations and quirks. Any idea what
>> might go wrong or how to implement NAPI for that FEC properly.
>
> Yes, I have a few ideas. First, I suspect that the FEC rx queue isn't
> big enough and I wouldn't be surprised if the RFIFO error is occurring
> because Bestcomm gets overrun. This scenario needs to be handled more
> gracefully.
First some words concerning NAPI. NAPI is mainly used to improve network
performance by processing network packets in the process context while
reducing interrupt load at the same time. Thereby it also solves the
problem of interrupt flooding, which may totally block the system. Most
(maybe all?) Gigabit Ethernet drivers use NAPI, e.g. ucc_geth. Below I
have attached my preliminary (and not yet complete or even correct)
patch, which should demonstrate how NAPI is supposed to work. The old NAPI
implementation of 2.4 is documented here:
http://lxr.linux.no/linux-old+v2.4.31/Documentation/networking/NAPI_HOWTO.txt.
As the NAPI polling competes with other task/processes, it's clear that
a bigger queue only helps partially.
Wolfgang.
---
drivers/net/Kconfig | 7 ++++
drivers/net/fec_mpc52xx.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+)
Index: linux-2.6-denx/drivers/net/Kconfig
===================================================================
--- linux-2.6-denx.orig/drivers/net/Kconfig
+++ linux-2.6-denx/drivers/net/Kconfig
@@ -1896,6 +1896,13 @@ config FEC_MPC52xx
Fast Ethernet Controller
If compiled as module, it will be called fec_mpc52xx.
+config FEC_MPC52xx_NAPI
+ bool "Use NAPI for MPC52xx FEC driver"
+ depends on FEC_MPC52xx
+ ---help---
+ This option enables NAPI support for the MPC5200's on-chip
+ Fast Ethernet Controller driver.
+
config FEC_MPC52xx_MDIO
bool "MPC52xx FEC MDIO bus driver"
depends on FEC_MPC52xx
Index: linux-2.6-denx/drivers/net/fec_mpc52xx.c
===================================================================
--- linux-2.6-denx.orig/drivers/net/fec_mpc52xx.c
+++ linux-2.6-denx/drivers/net/fec_mpc52xx.c
@@ -44,6 +44,8 @@
#define DRIVER_NAME "mpc52xx-fec"
+#define FEC_MPC52xx_NAPI_WEIGHT 64
+
/* Private driver data structure */
struct mpc52xx_fec_priv {
struct net_device *ndev;
@@ -63,6 +65,9 @@ struct mpc52xx_fec_priv {
struct phy_device *phydev;
enum phy_state link;
int seven_wire_mode;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ struct napi_struct napi;
+#endif
};
@@ -226,6 +231,10 @@ static int mpc52xx_fec_open(struct net_d
phy_start(priv->phydev);
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_enable(&priv->napi);
+#endif
+
if (request_irq(dev->irq, &mpc52xx_fec_interrupt, IRQF_SHARED,
DRIVER_NAME "_ctrl", dev)) {
dev_err(&dev->dev, "ctrl interrupt request failed\n");
@@ -273,6 +282,9 @@ static int mpc52xx_fec_open(struct net_d
priv->phydev = NULL;
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_disable(&priv->napi);
+#endif
return err;
}
@@ -280,6 +292,10 @@ static int mpc52xx_fec_close(struct net_
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_disable(&priv->napi);
+#endif
+
netif_stop_queue(dev);
mpc52xx_fec_stop(dev);
@@ -379,17 +395,48 @@ static irqreturn_t mpc52xx_fec_tx_interr
return IRQ_HANDLED;
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ /* Disable the RX interrupt */
+ if (napi_schedule_prep(&priv->napi)) {
+ disable_irq_nosync(irq);
+ __napi_schedule(&priv->napi);
+ } else {
+ dev_err(dev->dev.parent, "FEC BUG: interrupt while in poll\n");
+ }
+ return IRQ_HANDLED;
+}
+#endif
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+static int mpc52xx_fec_rx_poll(struct napi_struct *napi, int budget)
+#else
+static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
+#endif
+{
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ struct mpc52xx_fec_priv *priv =
+ container_of(napi, struct mpc52xx_fec_priv, napi);
+ struct net_device *dev = napi->dev;
+ int pkt_received = 0;
+#else
+ struct net_device *dev = dev_id;
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+#endif
+
while (bcom_buffer_done(priv->rx_dmatsk)) {
struct sk_buff *skb;
struct sk_buff *rskb;
struct bcom_fec_bd *bd;
u32 status;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ pkt_received++;
+#endif
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
@@ -410,6 +457,10 @@ static irqreturn_t mpc52xx_fec_rx_interr
dev->stats.rx_dropped++;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ if (pkt_received >= budget)
+ break;
+#endif
continue;
}
@@ -425,7 +476,11 @@ static irqreturn_t mpc52xx_fec_rx_interr
rskb->dev = dev;
rskb->protocol = eth_type_trans(rskb, dev);
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ netif_receive_skb(rskb);
+#else
netif_rx(rskb);
+#endif
} else {
/* Can't get a new one : reuse the same & drop pkt */
dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
@@ -442,9 +497,23 @@ static irqreturn_t mpc52xx_fec_rx_interr
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ if (pkt_received >= budget)
+ break;
+#endif
+ }
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ if (pkt_received < budget) {
+ napi_complete(napi);
+ enable_irq(priv->r_irq);
}
+ return pkt_received;
+#else
return IRQ_HANDLED;
+#endif
}
static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
@@ -950,6 +1019,13 @@ mpc52xx_fec_probe(struct of_device *op,
priv->duplex = DUPLEX_HALF;
priv->mdio_speed = ((mpc5xxx_get_bus_frequency(op->node) >> 20) / 5) << 1;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ netif_napi_add(ndev, &priv->napi, mpc52xx_fec_rx_poll,
+ FEC_MPC52xx_NAPI_WEIGHT);
+ dev_info(&op->dev, "using NAPI with weigth %d\n",
+ FEC_MPC52xx_NAPI_WEIGHT);
+#endif
+
/* The current speed preconfigures the speed of the MII link */
prop = of_get_property(op->node, "current-speed", &prop_size);
if (prop && (prop_size >= sizeof(u32) * 2)) {
[-- Attachment #2: mpc52xx-fec-napi.patch --]
[-- Type: text/x-diff, Size: 5108 bytes --]
---
drivers/net/Kconfig | 7 ++++
drivers/net/fec_mpc52xx.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+)
Index: linux-2.6-denx/drivers/net/Kconfig
===================================================================
--- linux-2.6-denx.orig/drivers/net/Kconfig
+++ linux-2.6-denx/drivers/net/Kconfig
@@ -1896,6 +1896,13 @@ config FEC_MPC52xx
Fast Ethernet Controller
If compiled as module, it will be called fec_mpc52xx.
+config FEC_MPC52xx_NAPI
+ bool "Use NAPI for MPC52xx FEC driver"
+ depends on FEC_MPC52xx
+ ---help---
+ This option enables NAPI support for the MPC5200's on-chip
+ Fast Ethernet Controller driver.
+
config FEC_MPC52xx_MDIO
bool "MPC52xx FEC MDIO bus driver"
depends on FEC_MPC52xx
Index: linux-2.6-denx/drivers/net/fec_mpc52xx.c
===================================================================
--- linux-2.6-denx.orig/drivers/net/fec_mpc52xx.c
+++ linux-2.6-denx/drivers/net/fec_mpc52xx.c
@@ -44,6 +44,8 @@
#define DRIVER_NAME "mpc52xx-fec"
+#define FEC_MPC52xx_NAPI_WEIGHT 64
+
/* Private driver data structure */
struct mpc52xx_fec_priv {
struct net_device *ndev;
@@ -63,6 +65,9 @@ struct mpc52xx_fec_priv {
struct phy_device *phydev;
enum phy_state link;
int seven_wire_mode;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ struct napi_struct napi;
+#endif
};
@@ -226,6 +231,10 @@ static int mpc52xx_fec_open(struct net_d
phy_start(priv->phydev);
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_enable(&priv->napi);
+#endif
+
if (request_irq(dev->irq, &mpc52xx_fec_interrupt, IRQF_SHARED,
DRIVER_NAME "_ctrl", dev)) {
dev_err(&dev->dev, "ctrl interrupt request failed\n");
@@ -273,6 +282,9 @@ static int mpc52xx_fec_open(struct net_d
priv->phydev = NULL;
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_disable(&priv->napi);
+#endif
return err;
}
@@ -280,6 +292,10 @@ static int mpc52xx_fec_close(struct net_
{
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ napi_disable(&priv->napi);
+#endif
+
netif_stop_queue(dev);
mpc52xx_fec_stop(dev);
@@ -379,17 +395,48 @@ static irqreturn_t mpc52xx_fec_tx_interr
return IRQ_HANDLED;
}
+#ifdef CONFIG_FEC_MPC52xx_NAPI
static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
{
struct net_device *dev = dev_id;
struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+ /* Disable the RX interrupt */
+ if (napi_schedule_prep(&priv->napi)) {
+ disable_irq_nosync(irq);
+ __napi_schedule(&priv->napi);
+ } else {
+ dev_err(dev->dev.parent, "FEC BUG: interrupt while in poll\n");
+ }
+ return IRQ_HANDLED;
+}
+#endif
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+static int mpc52xx_fec_rx_poll(struct napi_struct *napi, int budget)
+#else
+static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void *dev_id)
+#endif
+{
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ struct mpc52xx_fec_priv *priv =
+ container_of(napi, struct mpc52xx_fec_priv, napi);
+ struct net_device *dev = napi->dev;
+ int pkt_received = 0;
+#else
+ struct net_device *dev = dev_id;
+ struct mpc52xx_fec_priv *priv = netdev_priv(dev);
+#endif
+
while (bcom_buffer_done(priv->rx_dmatsk)) {
struct sk_buff *skb;
struct sk_buff *rskb;
struct bcom_fec_bd *bd;
u32 status;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ pkt_received++;
+#endif
rskb = bcom_retrieve_buffer(priv->rx_dmatsk, &status,
(struct bcom_bd **)&bd);
dma_unmap_single(dev->dev.parent, bd->skb_pa, rskb->len,
@@ -410,6 +457,10 @@ static irqreturn_t mpc52xx_fec_rx_interr
dev->stats.rx_dropped++;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ if (pkt_received >= budget)
+ break;
+#endif
continue;
}
@@ -425,7 +476,11 @@ static irqreturn_t mpc52xx_fec_rx_interr
rskb->dev = dev;
rskb->protocol = eth_type_trans(rskb, dev);
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ netif_receive_skb(rskb);
+#else
netif_rx(rskb);
+#endif
} else {
/* Can't get a new one : reuse the same & drop pkt */
dev_notice(&dev->dev, "Memory squeeze, dropping packet.\n");
@@ -442,9 +497,23 @@ static irqreturn_t mpc52xx_fec_rx_interr
FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
bcom_submit_next_buffer(priv->rx_dmatsk, skb);
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ if (pkt_received >= budget)
+ break;
+#endif
+ }
+
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ if (pkt_received < budget) {
+ napi_complete(napi);
+ enable_irq(priv->r_irq);
}
+ return pkt_received;
+#else
return IRQ_HANDLED;
+#endif
}
static irqreturn_t mpc52xx_fec_interrupt(int irq, void *dev_id)
@@ -950,6 +1019,13 @@ mpc52xx_fec_probe(struct of_device *op,
priv->duplex = DUPLEX_HALF;
priv->mdio_speed = ((mpc5xxx_get_bus_frequency(op->node) >> 20) / 5) << 1;
+#ifdef CONFIG_FEC_MPC52xx_NAPI
+ netif_napi_add(ndev, &priv->napi, mpc52xx_fec_rx_poll,
+ FEC_MPC52xx_NAPI_WEIGHT);
+ dev_info(&op->dev, "using NAPI with weigth %d\n",
+ FEC_MPC52xx_NAPI_WEIGHT);
+#endif
+
/* The current speed preconfigures the speed of the MII link */
prop = of_get_property(op->node, "current-speed", &prop_size);
if (prop && (prop_size >= sizeof(u32) * 2)) {
^ permalink raw reply
* Re: [PATCH 00/11] swiotlb: Introduce architecture-specific APIs to replace __weak functions (v2)
From: Ian Campbell @ 2009-07-10 14:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Kumar, Jeremy Fitzhardinge, Tony Luck, linux-ia64, Olaf Kirch,
Greg KH, linux-kernel, FUJITA Tomonori, linuxppc-dev, Ingo Molnar,
x86
In-Reply-To: <1247205356.15530.18.camel@pasglop>
On Fri, 2009-07-10 at 15:55 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-06-01 at 16:32 +0100, Ian Campbell wrote:
> > This series:[...]
> Looks like I was only CCed on part of them... it's not very handy for me
> as I end up having some of the patches in one folder and some
> elsewhere :-)
Sorry about that -- I was concerned about spamming the world and his dog
with patches which didn't directly interest them. For any future series
of this type I'll CC everyone on everything.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-10 14:02 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, linuxppc-dev,
joerg.roedel, mingo
In-Reply-To: <20090710143408A.fujita.tomonori@lab.ntt.co.jp>
On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> I don't think that we need to take account of dom0 support; we don't
> have a clear idea about an acceptable dom0 design (it needs to use
> swiotlb code? I don't know yet), we don't even know we will have dom0
> support in mainline. That's why I didn't CC this patchset to Xen
> camp.
The core domain 0 patches which were the subject of the discussions a
few week back are completely orthogonal to the swiotlb side of things
and whatever form they eventually take I do not think it will have any
impact on the shape of the solution which we arrive at for swiotlb. I
don't think that assuming that domain 0 can never be done in a way which
everyone finds acceptable and therefore discounting all consideration of
it is a useful way to make progress with these issues.
The DMA use case is much more tightly tied to the paravirtualized MMU
(which is already in the kernel for domU purposes) than it is to "the
domain 0" patches anyway. Although domain 0 is probably the main use
case, at least today, swiotlb support is also used in a Xen domU as part
of the support for direct assignment of PCI devices to paravirtualised
guests (pci passthrough).
The pci frontend driver depends on some bits of the domain 0 physical
interrupt patches as well as swiotlb which is why I/we haven't tried to
upstream that particular series yet.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-10 14:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jeremy Fitzhardinge, tony.luck@intel.com,
linux-ia64@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, FUJITA Tomonori,
linuxppc-dev@ozlabs.org, Joerg Roedel
In-Reply-To: <20090710051236.GA22218@elte.hu>
On Fri, 2009-07-10 at 06:12 +0100, Ingo Molnar wrote:
> Hm, the functions and facilities you remove here were added as part
> of preparatory patches for Xen guest support. You were aware of
> them, you were involved in discussions about those aspects with Ian
> and Jeremy but still you chose not to Cc: either of them and you
> failed to address that aspect in the changelogs.
Thanks for adding me Ingo.
> Alas, on the technical level the cleanups themselves look mostly
> fine to me. Ian, Jeremy, the changes will alter Xen's use of
> swiotlb, but can the Xen side still live with these new methods - in
> particular is dma_capable() sufficient as a mechanism and can the
> Xen side filter out DMA allocations to make them physically
> continuous?
I've not examined the series in detail it looks OK but I don't think it
is quite sufficient. The Xen determination of whether a buffer is
dma_capable or not is based on the physical address while dma_capable
takes only the dma address.
I'm not sure we can "invert" our conditions to work back from dma
address to physical since given a start dma address and a length we
would need to check that dma_to_phys(dma+PAGE_SIZE) ==
dma_to_phys(dma)+PAGE_SIZE etc. However dma+PAGE_SIZE might belong to a
different domain so translating it to a physical address in isolation
tells us nothing especially useful since it would give us the physical
address in that other guest which is useless to us. If we could pass
both physical and dma address to dma_capable I think that would probably
be sufficient for our purposes.
As well as that Xen needs some way to influence the allocation of the
actual bounce buffer itself since we need to arrange for it to be
machine address contiguous as well as physical address contiguous. This
series explicitly removes those hooks without replacement. My most
recent proposal was to have a new swiotlb_init variant which was given a
preallocated buffer which this series doesn't necessarily preclude.
The phys_to_dma and dma_to_phys translation points are the last piece
Xen needs and seem to be preserved in this series.
However Fujita's objection to all of the previous swiotlb-for-xen
proposals was around the addition of the Xen hooks in whichever
location. Originally these hooks were via __weak functions and later
proposals implemented them via function pointer hooks in the x86
implementations of the arch-abstract interfaces (phys<->dma and
dma_capable etc). I don't think this series addresses those objections
(fair enough -- it wasn't intended to) or leads to any new approach to
solving the issue, although I also don't think it makes the issue any
harder to address. I don't think it will be possible to make progress on
Xen usage of swiotlb until a solution can be found to this conflict of
opinion.
Fujita suggested that we export the core sync_single() functionality and
reimplemented the surrounding infrastructure in terms of that (and
incorporating our additional requirements). I prototyped this (it is
currently unworking, in fact it seems to have developed rather a taste
for filesystems :-() but the diffstat of my WIP patch is:
arch/x86/kernel/pci-swiotlb.c | 6
arch/x86/xen/pci-swiotlb.c | 2
drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
include/linux/swiotlb.h | 12 +
lib/swiotlb.c | 10 -
5 files changed, 385 insertions(+), 30 deletions(-)
where a fair number of the lines in xen-iommu.c are copies of functions
from swiotlb.c with minor modifications. As I say it doesn't work yet
but I think it's roughly indicative of what such an approach would look
like. I don't like it much but am happy to run with it if it looks to be
the most acceptable approach. To be honest at the moment I've
deliberately been taking some time away from this stuff to try and gain
a bit of perspective so I haven't looked at it in a while.
Ian.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ingo Molnar @ 2009-07-10 14:12 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, tony.luck@intel.com,
linux-ia64@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, FUJITA Tomonori,
linuxppc-dev@ozlabs.org, Joerg Roedel
In-Reply-To: <1247234512.4002.417.camel@zakaz.uk.xensource.com>
* Ian Campbell <Ian.Campbell@eu.citrix.com> wrote:
> I've not examined the series in detail it looks OK but I don't
> think it is quite sufficient. The Xen determination of whether a
> buffer is dma_capable or not is based on the physical address
> while dma_capable takes only the dma address.
>
> I'm not sure we can "invert" our conditions to work back from dma
> address to physical since given a start dma address and a length
> we would need to check that dma_to_phys(dma+PAGE_SIZE) ==
> dma_to_phys(dma)+PAGE_SIZE etc. However dma+PAGE_SIZE might belong
> to a different domain so translating it to a physical address in
> isolation tells us nothing especially useful since it would give
> us the physical address in that other guest which is useless to
> us. If we could pass both physical and dma address to dma_capable
> I think that would probably be sufficient for our purposes.
>
> As well as that Xen needs some way to influence the allocation of
> the actual bounce buffer itself since we need to arrange for it to
> be machine address contiguous as well as physical address
> contiguous. This series explicitly removes those hooks without
> replacement. My most recent proposal was to have a new
> swiotlb_init variant which was given a preallocated buffer which
> this series doesn't necessarily preclude.
>
> The phys_to_dma and dma_to_phys translation points are the last
> piece Xen needs and seem to be preserved in this series.
>
> However Fujita's objection to all of the previous swiotlb-for-xen
> proposals was around the addition of the Xen hooks in whichever
> location. Originally these hooks were via __weak functions and
> later proposals implemented them via function pointer hooks in the
> x86 implementations of the arch-abstract interfaces (phys<->dma
> and dma_capable etc). I don't think this series addresses those
> objections (fair enough -- it wasn't intended to) or leads to any
> new approach to solving the issue, although I also don't think it
> makes the issue any harder to address. I don't think it will be
> possible to make progress on Xen usage of swiotlb until a solution
> can be found to this conflict of opinion.
>
> Fujita suggested that we export the core sync_single()
> functionality and reimplemented the surrounding infrastructure in
> terms of that (and incorporating our additional requirements). I
> prototyped this (it is currently unworking, in fact it seems to
> have developed rather a taste for filesystems :-() but the
> diffstat of my WIP patch is:
>
> arch/x86/kernel/pci-swiotlb.c | 6
> arch/x86/xen/pci-swiotlb.c | 2
> drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> include/linux/swiotlb.h | 12 +
> lib/swiotlb.c | 10 -
> 5 files changed, 385 insertions(+), 30 deletions(-)
>
> where a fair number of the lines in xen-iommu.c are copies of
> functions from swiotlb.c with minor modifications. As I say it
> doesn't work yet but I think it's roughly indicative of what such
> an approach would look like. I don't like it much but am happy to
> run with it if it looks to be the most acceptable approach. [...]
+400 lines of code to avoid much fewer lines of generic code impact
on the lib/swiotlb.c side sounds like a bad technical choice to me.
It makes the swiotlb code less useful and basically forks a random
implementation of it in drivers/pci/xen-iommu.c.
Fujita-san, can you think of a solution that avoids the whole-sale
copying of hundreds of lines of code?
Ingo
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 14:37 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090710041536.GE3181@bubble.grove.modra.org>
On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
> wrote:
>> I understand your arguments, but there is something inconsistent
>> about this.
>> If I change the script to be:
>> _end3 = . ;
>> . = _end3;
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>> }
>> The result is corrected:
>> c067f678 A _end3
>> c0680000 A _end
>>
>> Why the apuinfo section with zero VMA sometimes interfere with "."
>> and
>> sometimes not ?
>
> I said it was weird in my last email. Not so. The orphan gets placed
> between
>
> _end3 = . ;
> . = _end3;
>
> So dot is restored after the orphan section sets it.
This seems to be a bit of a chick and egg scenario. Older kernel
linker scripts aren't going to cover all sections and thus may have
orphan sections. How do we ensure _end can be set properly under such
conditions?
- k
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-10 15:04 UTC (permalink / raw)
To: Doug Thompson; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <2576.44687.qm@web50111.mail.re2.yahoo.com>
On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>
> Ok, is this the one you want me to push upstream?
>
Yep, this is the finished version.
Thanks,
Ira
> doug t
>
>
> --- On Thu, 7/9/09, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
>
> From: Ira W. Snyder <iws@ovro.caltech.edu>
> Subject: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
> To: bluesmoke-devel@lists.sourceforge.net, "Dave Jiang" <djiang@mvista.com>, "Kumar Gala" <galak@kernel.crashing.org>, linuxppc-dev@ozlabs.org
> Date: Thursday, July 9, 2009, 1:40 PM
>
> Add support for the Freescale MPC83xx memory controller to the existing
> driver for the Freescale MPC85xx memory controller. The only difference
> between the two processors are in the CS_BNDS register parsing code, which
> has been changed so it will work on both processors.
>
> The L2 cache controller does not exist on the MPC83xx, but the OF subsystem
> will not use the driver if the device is not present in the OF device tree.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> ---
>
> Kumar, I had to change the nr_pages calculation to make the math work
> out. I checked it on my board and did the math by hand for a 64GB 85xx
> using 64K pages. In both cases, nr_pages * PAGE_SIZE comes out to the
> correct value. Thanks for the help.
>
> v1 -> v2:
> * Use PAGE_SHIFT to parse cs_bnds regardless of board type
> * Remove special-casing for the 83xx processor
>
> drivers/edac/Kconfig | 6 +++---
> drivers/edac/mpc85xx_edac.c | 28 +++++++++++++++++++---------
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 4339b1a..78303f9 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -176,11 +176,11 @@ config EDAC_I5100
> San Clemente MCH.
>
> config EDAC_MPC85XX
> - tristate "Freescale MPC85xx"
> - depends on EDAC_MM_EDAC && FSL_SOC && MPC85xx
> + tristate "Freescale MPC83xx / MPC85xx"
> + depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
> help
> Support for error detection and correction on the Freescale
> - MPC8560, MPC8540, MPC8548
> + MPC8349, MPC8560, MPC8540, MPC8548
>
> config EDAC_MV64X60
> tristate "Marvell MV64x60"
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index b4f5c63..ba2a264 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -43,7 +43,9 @@ static u32 orig_pci_err_en;
> #endif
>
> static u32 orig_l2_err_disable;
> +#ifdef CONFIG_MPC85xx
> static u32 orig_hid1[2];
> +#endif
>
> /************************ MC SYSFS parts ***********************************/
>
> @@ -790,19 +792,20 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
> csrow = &mci->csrows[index];
> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
> (index * MPC85XX_MC_CS_BNDS_OFS));
> - start = (cs_bnds & 0xfff0000) << 4;
> - end = ((cs_bnds & 0xfff) << 20);
> - if (start)
> - start |= 0xfffff;
> - if (end)
> - end |= 0xfffff;
> +
> + start = (cs_bnds & 0xffff0000) >> 16;
> + end = (cs_bnds & 0x0000ffff);
>
> if (start == end)
> continue; /* not populated */
>
> + start <<= (24 - PAGE_SHIFT);
> + end <<= (24 - PAGE_SHIFT);
> + end |= (1 << (24 - PAGE_SHIFT)) - 1;
> +
> csrow->first_page = start >> PAGE_SHIFT;
> csrow->last_page = end >> PAGE_SHIFT;
> - csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
> + csrow->nr_pages = end + 1 - start;
> csrow->grain = 8;
> csrow->mtype = mtype;
> csrow->dtype = DEV_UNKNOWN;
> @@ -986,6 +989,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
> { .compatible = "fsl,mpc8560-memory-controller", },
> { .compatible = "fsl,mpc8568-memory-controller", },
> { .compatible = "fsl,mpc8572-memory-controller", },
> + { .compatible = "fsl,mpc8349-memory-controller", },
> {},
> };
>
> @@ -1001,13 +1005,13 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
> },
> };
>
> -
> +#ifdef CONFIG_MPC85xx
> static void __init mpc85xx_mc_clear_rfxe(void *data)
> {
> orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
> mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
> }
> -
> +#endif
>
> static int __init mpc85xx_mc_init(void)
> {
> @@ -1040,26 +1044,32 @@ static int __init mpc85xx_mc_init(void)
> printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
> #endif
>
> +#ifdef CONFIG_MPC85xx
> /*
> * need to clear HID1[RFXE] to disable machine check int
> * so we can catch it
> */
> if (edac_op_state == EDAC_OPSTATE_INT)
> on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
> +#endif
>
> return 0;
> }
>
> module_init(mpc85xx_mc_init);
>
> +#ifdef CONFIG_MPC85xx
> static void __exit mpc85xx_mc_restore_hid1(void *data)
> {
> mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
> }
> +#endif
>
> static void __exit mpc85xx_mc_exit(void)
> {
> +#ifdef CONFIG_MPC85xx
> on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
> +#endif
> #ifdef CONFIG_PCI
> of_unregister_platform_driver(&mpc85xx_pci_err_driver);
> #endif
> --
> 1.5.4.3
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> bluesmoke-devel mailing list
> bluesmoke-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluesmoke-devel
>
>
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 15:27 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Edmar Wienskoski-RA8797,
Alan Modra, bug-binutils
In-Reply-To: <D4C31507-B4F9-4979-A6E1-7971242D644B@kernel.crashing.org>
On Jul 10, 2009, at 9:37 AM, Kumar Gala wrote:
>
> On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
>
>> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797
>> wrote:
>>> I understand your arguments, but there is something inconsistent
>>> about this.
>>> If I change the script to be:
>>> _end3 = . ;
>>> . = _end3;
>>> . = ALIGN(PAGE_SIZE);
>>> _end = . ;
>>> PROVIDE32 (end = .);
>>> }
>>> The result is corrected:
>>> c067f678 A _end3
>>> c0680000 A _end
>>>
>>> Why the apuinfo section with zero VMA sometimes interfere with "."
>>> and
>>> sometimes not ?
>>
>> I said it was weird in my last email. Not so. The orphan gets
>> placed
>> between
>>
>> _end3 = . ;
>> . = _end3;
>>
>> So dot is restored after the orphan section sets it.
>
> This seems to be a bit of a chick and egg scenario. Older kernel
> linker scripts aren't going to cover all sections and thus may have
> orphan sections. How do we ensure _end can be set properly under
> such conditions?
Not sure if this helps, but I've isolated down the version of binutils
that changes to:
binutils-2.19 _end is what we expect
binutils-2.19.1 _end is what we expect
binutils-2.19.50.0.1 _end is what we expect
binutils-2.19.51.0.1 _end is 00001000
From the release notes:
binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-10 15:34 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090710041123.GD3181@bubble.grove.modra.org>
On Jul 9, 2009, at 11:11 PM, Alan Modra wrote:
> Hmm, having said all that, the following linker patch seems reasonable
> to me and probably won't break anything else (always some risk).
> Please test it for me.
>
> Index: ld/ldlang.c
> ===================================================================
> RCS file: /cvs/src/src/ld/ldlang.c,v
> retrieving revision 1.311
> diff -u -p -r1.311 ldlang.c
> --- ld/ldlang.c 25 Jun 2009 13:18:46 -0000 1.311
> +++ ld/ldlang.c 10 Jul 2009 04:04:57 -0000
> @@ -1615,10 +1615,12 @@ output_prev_sec_find (lang_output_sectio
> idea is to skip over anything that might be inside a SECTIONS {}
> statement in a script, before we find another output section
> statement. Assignments to "dot" before an output section statement
> - are assumed to belong to it. An exception to this rule is made
> for
> - the first assignment to dot, otherwise we might put an orphan
> - before . = . + SIZEOF_HEADERS or similar assignments that set the
> - initial address. */
> + are assumed to belong to it, except in two cases; The first
> + assignment to dot, and assignments before non-alloc sections.
> + Otherwise we might put an orphan before . = . + SIZEOF_HEADERS or
> + similar assignments that set the initial address, or we might
> + insert non-alloc note sections among assignments setting end of
> + image symbols. */
>
> static lang_statement_union_type **
> insert_os_after (lang_output_section_statement_type *after)
> @@ -1662,7 +1664,12 @@ insert_os_after (lang_output_section_sta
> continue;
> case lang_output_section_statement_enum:
> if (assign != NULL)
> - where = assign;
> + {
> + asection *s = (*where)->output_section_statement.bfd_section;
> +
> + if (s == NULL || (s->flags & SEC_ALLOC) != 0)
> + where = assign;
> + }
> break;
> case lang_input_statement_enum:
> case lang_address_statement_enum:
>
> --
This patch seems to "fix" things.
- k
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-10 15:36 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, Doug Thompson, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090710150420.GA11719@ovro.caltech.edu>
On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>>
>> Ok, is this the one you want me to push upstream?
>>
>
> Yep, this is the finished version.
>
> Thanks,
> Ira
>
>> doug t
>
is that for .31 or .32? If .31 I'm fine. If for .32 I still have
some things I like to deal with. (like the other 85xx specific bits)
- k
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-10 17:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Doug Thompson, bluesmoke-devel, Dave Jiang
In-Reply-To: <D2ADC85F-2986-42EA-B8AD-03F30E871A55@kernel.crashing.org>
On Fri, Jul 10, 2009 at 10:36:20AM -0500, Kumar Gala wrote:
>
> On Jul 10, 2009, at 10:04 AM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 04:24:38PM -0700, Doug Thompson wrote:
>>>
>>> Ok, is this the one you want me to push upstream?
>>>
>>
>> Yep, this is the finished version.
>>
>> Thanks,
>> Ira
>>
>>> doug t
>>
>
> is that for .31 or .32? If .31 I'm fine. If for .32 I still have some
> things I like to deal with. (like the other 85xx specific bits)
>
.32 is fine for me. This is a new feature, not really a bugfix. I can
maintain it in my (growing) set of patches against mainline until it
gets merged.
Ira
^ permalink raw reply
* [PATCH] powerpc: Fix another bug in move of altivec code to vector.S
From: Andreas Schwab @ 2009-07-10 21:17 UTC (permalink / raw)
To: linuxppc-dev
When moving load_up_altivec to vector.S a typo in a comment caused a
thinko setting the wrong variable.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
---
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index ef36cbb..ea4d646 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -80,10 +80,10 @@ _GLOBAL(load_up_altivec)
mtvscr vr0
REST_32VRS(0,r4,r5)
#ifndef CONFIG_SMP
- /* Update last_task_used_math to 'current' */
+ /* Update last_task_used_altivec to 'current' */
subi r4,r5,THREAD /* Back to 'current' */
fromreal(r4)
- PPC_STL r4,ADDROFF(last_task_used_math)(r3)
+ PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
#endif /* CONFIG_SMP */
/* restore registers and return */
blr
@@ -172,7 +172,7 @@ _GLOBAL(load_up_vsx)
oris r12,r12,MSR_VSX@h
std r12,_MSR(r1)
#ifndef CONFIG_SMP
- /* Update last_task_used_math to 'current' */
+ /* Update last_task_used_vsx to 'current' */
ld r4,PACACURRENT(r13)
std r4,0(r3)
#endif /* CONFIG_SMP */
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix another bug in move of altivec code to vector.S
From: Benjamin Herrenschmidt @ 2009-07-10 23:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <m2iqi0w83z.fsf@igel.home>
On Fri, 2009-07-10 at 23:17 +0200, Andreas Schwab wrote:
> When moving load_up_altivec to vector.S a typo in a comment caused a
> thinko setting the wrong variable.
>
> Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Good catch, thanks.
Cheers,
Ben.
> ---
> diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
> index ef36cbb..ea4d646 100644
> --- a/arch/powerpc/kernel/vector.S
> +++ b/arch/powerpc/kernel/vector.S
> @@ -80,10 +80,10 @@ _GLOBAL(load_up_altivec)
> mtvscr vr0
> REST_32VRS(0,r4,r5)
> #ifndef CONFIG_SMP
> - /* Update last_task_used_math to 'current' */
> + /* Update last_task_used_altivec to 'current' */
> subi r4,r5,THREAD /* Back to 'current' */
> fromreal(r4)
> - PPC_STL r4,ADDROFF(last_task_used_math)(r3)
> + PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
> #endif /* CONFIG_SMP */
> /* restore registers and return */
> blr
> @@ -172,7 +172,7 @@ _GLOBAL(load_up_vsx)
> oris r12,r12,MSR_VSX@h
> std r12,_MSR(r1)
> #ifndef CONFIG_SMP
> - /* Update last_task_used_math to 'current' */
> + /* Update last_task_used_vsx to 'current' */
> ld r4,PACACURRENT(r13)
> std r4,0(r3)
> #endif /* CONFIG_SMP */
>
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-11 0:05 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <4F69F333-8BCA-4BB8-A5C1-4B25EA5D1287@kernel.crashing.org>
On Fri, Jul 10, 2009 at 10:27:26AM -0500, Kumar Gala wrote:
> binutils-2.19 _end is what we expect
> binutils-2.19.1 _end is what we expect
> binutils-2.19.50.0.1 _end is what we expect
> binutils-2.19.51.0.1 _end is 00001000
>
> From the release notes:
>
> binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
> binutils-2.19.51.0.1 is based on CVS binutils 2009 0106
Yes, I already have good reason to suspect this patch
2008-10-22 Alan Modra <amodra@bigpond.net.au>
* ldlang.c (lang_output_section_find_by_flags): Handle non-alloc
sections.
* emultempl/elf32.em (enum orphan_save_index): Add orphan_nonalloc.
(hold): Likewise.
(gld${EMULATION_NAME}_place_orphan): Handle non-alloc orphans.
causes the change in linker behaviour. Did you try the patch I posted?
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-11 0:08 UTC (permalink / raw)
To: Kumar Gala, Scott Wood, linuxppc-dev@ozlabs.org list,
bug-binutils, Edmar Wienskoski-RA8797
In-Reply-To: <20090711000503.GO3181@bubble.grove.modra.org>
On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
> Did you try the patch I posted?
/me reads other email. I see you did. Applying.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* Re: Memory usage of a process
From: Nicholas Mc Guire @ 2009-07-11 10:05 UTC (permalink / raw)
To: G?nter Leonhardt; +Cc: linuxppc-dev
In-Reply-To: <D0B748CCD5DF144CA5C56A9D860A31341DE613@men-exch1.intra.men.de>
On Fri, 10 Jul 2009, G?nter Leonhardt wrote:
>
> Hello,
> analysing the memory usage of a process, I found some questions.
> I'am using a system with 128 MB physical RAM, no disk, 2.6.27 kernel.
>
> Running top, I see 38 MB in use, 90 MB free, but a VSZ for my process of 158 MB.
> Looking at /proc/<pid>/maps, I see that the process uses 140 MB without shared libs.
>
> So how it is possible that the process can allocate more memory than there is, without posibility of swapping?
>
> Why said top that 90 MB free? Does the kernel serve the allocation only if ist really used?
>
an allocation does not actually set aside any physical ram (unless you do an mlock and actually touch the memory) - it only reserves virtual memory areas (vma's) and when your process accesses the respective address the OS page-faults and prvides the physical RAM as needed (and possible) - if you have no swap and you allow overcommitting of memory then you are potentially going to see this application failing as soon as it tries to utilize the memory.
This can be set in the system via /proc/sys/vm/overcommit_memory (see
linux/Documentation/vm/overcommit-accounting for details).
hofrat
^ permalink raw reply
* [PATCH 1/5] drivers/char/hvc_console.c: Drop unnecessary NULL test
From: Julia Lawall @ 2009-07-12 20:03 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
The result of container_of should not be NULL. In particular, in this case
the argument to the enclosing function has passed though INIT_WORK, which
dereferences it, implying that its container cannot be NULL.
A simplified version of the semantic patch that makes this change is as
follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
identifier fn,work,x,fld;
type T;
expression E1,E2;
statement S;
@@
static fn(struct work_struct *work) {
... when != work = E1
x = container_of(work,T,fld)
... when != x = E2
- if (x == NULL) S
...
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/char/hvc_console.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 94e7e3c..e367630 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -516,8 +516,6 @@ static void hvc_set_winsz(struct work_struct *work)
struct winsize ws;
hp = container_of(work, struct hvc_struct, tty_resize);
- if (!hp)
- return;
spin_lock_irqsave(&hp->lock, hvc_flags);
if (!hp->tty) {
^ permalink raw reply related
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 4:20 UTC (permalink / raw)
To: mingo
Cc: fujita.tomonori, jeremy, tony.luck, linux-ia64, x86, linux-kernel,
Ian.Campbell, linuxppc-dev, joerg.roedel
In-Reply-To: <20090710141248.GE26264@elte.hu>
On Fri, 10 Jul 2009 16:12:48 +0200
Ingo Molnar <mingo@elte.hu> wrote:
> > functionality and reimplemented the surrounding infrastructure in
> > terms of that (and incorporating our additional requirements). I
> > prototyped this (it is currently unworking, in fact it seems to
> > have developed rather a taste for filesystems :-() but the
> > diffstat of my WIP patch is:
> >
> > arch/x86/kernel/pci-swiotlb.c | 6
> > arch/x86/xen/pci-swiotlb.c | 2
> > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > include/linux/swiotlb.h | 12 +
> > lib/swiotlb.c | 10 -
> > 5 files changed, 385 insertions(+), 30 deletions(-)
> >
> > where a fair number of the lines in xen-iommu.c are copies of
> > functions from swiotlb.c with minor modifications. As I say it
> > doesn't work yet but I think it's roughly indicative of what such
> > an approach would look like. I don't like it much but am happy to
> > run with it if it looks to be the most acceptable approach. [...]
>
> +400 lines of code to avoid much fewer lines of generic code impact
> on the lib/swiotlb.c side sounds like a bad technical choice to me.
The amount of code is not the point. The way to impact on the
lib/swiotlb.c is totally wrong from the perspective of the kernel
design; it uses architecture code in the very original (xen) way.
> It makes the swiotlb code less useful and basically forks a random
> implementation of it in drivers/pci/xen-iommu.c.
I don't think so. We always have the reasonable amount of duplication
rather than integration in a dirty way (at least about IOMMU
code).
> Fujita-san, can you think of a solution that avoids the whole-sale
> copying of hundreds of lines of code?
Ian didn't give a pointer to his code in a public place so I'm not
sure his claim is valid. But if his code does the right thing and
the duplication is less than 400 lines, it doesn't sound that bad to
me.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 4:20 UTC (permalink / raw)
To: Ian.Campbell
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, fujita.tomonori,
linuxppc-dev, joerg.roedel, mingo
In-Reply-To: <1247234520.4002.418.camel@zakaz.uk.xensource.com>
On Fri, 10 Jul 2009 15:02:00 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > I don't think that we need to take account of dom0 support; we don't
> > have a clear idea about an acceptable dom0 design (it needs to use
> > swiotlb code? I don't know yet), we don't even know we will have dom0
> > support in mainline. That's why I didn't CC this patchset to Xen
> > camp.
>
> The core domain 0 patches which were the subject of the discussions a
> few week back are completely orthogonal to the swiotlb side of things
? If we don't merge dom0 patch, we don't need dom0 changes to
swiotlb. We don't know we would have dom0 support in mainline. Or I
overlooked something?
> and whatever form they eventually take I do not think it will have any
> impact on the shape of the solution which we arrive at for swiotlb. I
> don't think that assuming that domain 0 can never be done in a way which
> everyone finds acceptable and therefore discounting all consideration of
> it is a useful way to make progress with these issues.
>
> The DMA use case is much more tightly tied to the paravirtualized MMU
> (which is already in the kernel for domU purposes) than it is to "the
> domain 0" patches anyway. Although domain 0 is probably the main use
> case, at least today, swiotlb support is also used in a Xen domU as part
> of the support for direct assignment of PCI devices to paravirtualised
> guests (pci passthrough).
>
> The pci frontend driver depends on some bits of the domain 0 physical
> interrupt patches as well as swiotlb which is why I/we haven't tried to
> upstream that particular series yet.
As far as I know, you have not posted anything about changes to
swiotlb for domU. I can't discuss it. If you want, please send
patches.
^ permalink raw reply
* mmap() problem in own driver
From: Sauce.Cheng @ 2009-07-13 7:00 UTC (permalink / raw)
To: linuxppc-dev
Hi everyone
there is a problem of my own driver
I want to get data from kernel space to user space indirectly using mmap()
but i dont know how I can do , anyone can give me some advices ?
firstly, fetch data by DMA to a memory allocated by "kmalloc"
then i want to mmap it to user space and save the data as a file
Cheers everyone~
Martin
--
View this message in context: http://www.nabble.com/mmap%28%29-problem-in-own-driver-tp24457031p24457031.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Soft Reset for PPC44x Virtex 5 hangs saying Restarting System
From: srikanth krishnakar @ 2009-07-13 7:16 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
Hi all,
Kernel : Linux-2.6.29
Arch: Powerpc (ppc44x)
Target: Xilinx ML507 Virtex5
I have an issue in "Reset System" of Xilinx ML507 target board. I am using
Compact Flash to boot the target ( using system ACE file to boot the
target), during the process reset or reboot command on the target, I am not
able to reboot the target completely, here is the snapshot:
---------------------------------------------------------------------------------------------------
root@ml507:~# reboot
INIT: Sending processes the TERM signalWed Jul
INIT: Stopping OpenBSD Secure Shell server: sshdstopped /usr/sbin/sshd (pid
1052)
.
Stopping Vixie-cron.
Stopping network benchmark server: netserverstopped /usr/sbin/netserver (pid
1058)
.
Stopping syslogd/klogd: stopped syslogd (pid 1061)
stopped klogd (pid 1063)
done
NOT deconfiguring network interfaces: / is an NFS mount
Sending all processes the TERM signal...
Sending all processes the KILL signal...
hwclock: can't open '/dev/misc/rtc': No such file or directory
Unmounting remote filesystems...
Deactivating swap...
/etc/rc6.d/S40umountfs: line 9: swapoff: not found
Unmounting local filesystems...
umount2: Device or resource busy
umount: none busy - remounted read-only
Rebooting... Restarting system. <--------------- Target
hangs here..
-----------------------------------------------------------------------------------------------------
The target again doesn't provide me the boot options as obtained when done
hard reset :
Welcome to the Xilinx Virtex-5 ML507 Evaluation Platform Bootloader
Menu!
Please choose a demo by typing in the number of the demo you want to
use
Or select a demo using the directional buttons (C,W,S,E,N)
(Then press the center (C) button to start the selected demo)
1. Virtex-5 Slide Show
2. Web Server Demo
3. Simon Game
4. Board Diagnostics (XROM)
5. USB Demo
6. My own ACE file
7. Ring Tone Player
Rebooting to System ACE Configuration Address 6...
zImage starting: loaded at 0x00800000 (sp: 0x00a44fb0)
Allocating 0x4e9138 bytes for kernel ...
gunzipping (0x00000000 <- 0x0080e000:0x00a437cc)...done 0x4a1bcc bytes
Any comments or suggestions are appreciated !!
Thanks
-Sriknt
[-- Attachment #2: Type: text/html, Size: 2616 bytes --]
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-13 9:16 UTC (permalink / raw)
To: mingo
Cc: jeremy, tony.luck, linux-ia64, x86, linux-kernel, Ian.Campbell,
linuxppc-dev, joerg.roedel
In-Reply-To: <20090713131157V.fujita.tomonori@lab.ntt.co.jp>
On Mon, 13 Jul 2009 13:20:22 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> On Fri, 10 Jul 2009 16:12:48 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > > functionality and reimplemented the surrounding infrastructure in
> > > terms of that (and incorporating our additional requirements). I
> > > prototyped this (it is currently unworking, in fact it seems to
> > > have developed rather a taste for filesystems :-() but the
> > > diffstat of my WIP patch is:
> > >
> > > arch/x86/kernel/pci-swiotlb.c | 6
> > > arch/x86/xen/pci-swiotlb.c | 2
> > > drivers/pci/xen-iommu.c | 385 ++++++++++++++++++++++++++++++++++++++++--
> > > include/linux/swiotlb.h | 12 +
> > > lib/swiotlb.c | 10 -
> > > 5 files changed, 385 insertions(+), 30 deletions(-)
> > >
> > > where a fair number of the lines in xen-iommu.c are copies of
> > > functions from swiotlb.c with minor modifications. As I say it
> > > doesn't work yet but I think it's roughly indicative of what such
> > > an approach would look like. I don't like it much but am happy to
> > > run with it if it looks to be the most acceptable approach. [...]
> >
> > +400 lines of code to avoid much fewer lines of generic code impact
> > on the lib/swiotlb.c side sounds like a bad technical choice to me.
>
> The amount of code is not the point. The way to impact on the
> lib/swiotlb.c is totally wrong from the perspective of the kernel
> design; it uses architecture code in the very original (xen) way.
btw, '+400 lines of code to avoid much fewer lines of generic code
impact on the lib/swiotlb.c' doesn't sound true to me.
Here is a patch in the way that Xen people want to do:
http://patchwork.kernel.org/patch/26343/
---
arch/x86/Kconfig | 4 +
arch/x86/include/asm/io.h | 2 +
arch/x86/include/asm/pci_x86.h | 1 +
arch/x86/include/asm/xen/iommu.h | 12 ++
arch/x86/kernel/pci-dma.c | 3 +
arch/x86/pci/Makefile | 1 +
arch/x86/pci/init.c | 6 +
arch/x86/pci/xen.c | 51 +++++++
drivers/pci/Makefile | 2 +
drivers/pci/xen-iommu.c | 271 ++++++++++++++++++++++++++++++++++++++
Even with the way that Xen people want to do, drivers/pci/xen-iommu.c
is about 300 lines. And my patchset removes the nice amount of lines
for dom0 support. I don't see much difference wrt lines.
^ permalink raw reply
* Re: [00/15] swiotlb cleanup
From: Ian Campbell @ 2009-07-13 9:40 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: jeremy@goop.org, tony.luck@intel.com, linux-ia64@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, joerg.roedel@amd.com, mingo@elte.hu
In-Reply-To: <20090713131859N.fujita.tomonori@lab.ntt.co.jp>
On Mon, 2009-07-13 at 05:20 +0100, FUJITA Tomonori wrote:
> On Fri, 10 Jul 2009 15:02:00 +0100
> Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
> > On Fri, 2009-07-10 at 14:35 +0900, FUJITA Tomonori wrote:
> > > I don't think that we need to take account of dom0 support; we don't
> > > have a clear idea about an acceptable dom0 design (it needs to use
> > > swiotlb code? I don't know yet), we don't even know we will have dom0
> > > support in mainline. That's why I didn't CC this patchset to Xen
> > > camp.
> >
> > The core domain 0 patches which were the subject of the discussions a
> > few week back are completely orthogonal to the swiotlb side of things
>
> ? If we don't merge dom0 patch, we don't need dom0 changes to
> swiotlb. We don't know we would have dom0 support in mainline. Or I
> overlooked something?
[...]
> As far as I know, you have not posted anything about changes to
> swiotlb for domU. I can't discuss it. If you want, please send
> patches.
There are no separate domU swiotlb patches -- the exact the same patches
as we have already been discussing are useful and necessary for both
domU and dom0.
Ian.
^ 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