* [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-19 5:22 UTC (permalink / raw)
To: linux-i2c, linuxppc-dev
This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads. With this patch, it is possible to do an i2c_transfer() with
additional i2c_msg's following the I2C_M_RD messages.
It still needs to be resolved if it is possible to fix this issue
by removing the STOP condition after reads in a robust way.
Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
---
drivers/i2c/busses/i2c-mpc.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4af5c09..0199f9a 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -456,17 +456,22 @@ static int mpc_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num)
}
for (i = 0; ret >= 0 && i < num; i++) {
+ int restart = i;
pmsg = &msgs[i];
dev_dbg(i2c->dev,
"Doing %s %d bytes to 0x%02x - %d of %d messages\n",
pmsg->flags & I2C_M_RD ? "read" : "write",
pmsg->len, pmsg->addr, i + 1, num);
+ if (i > 0 && ((pmsg - 1)->flags & I2C_M_RD))
+ restart = 0;
if (pmsg->flags & I2C_M_RD)
ret =
- mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
else
ret =
- mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
+ mpc_write(i2c, pmsg->addr, pmsg->buf, pmsg->len,
+ restart);
}
mpc_i2c_stop(i2c);
return (ret < 0) ? ret : num;
--
1.6.3.1
^ permalink raw reply related
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Sean MacLennan @ 2009-05-19 3:57 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev, Timur Tabi
In-Reply-To: <fa686aa40905181958ye89c1far6a53dc57cf650728@mail.gmail.com>
On Mon, 18 May 2009 20:58:03 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> Then let it lie fallow on the list and in patchwork. It is published,
> and people know that it is available (I'll certainly consider it as I
> do driver work), but there must be real (not just theoretical) in
> kernel users of the interface. I someone wants to use it, then they
> can add it to their series or ping the list about getting it merged.
That's too bad. If it is ever merged, could you also ping the list?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Grant Likely @ 2009-05-19 2:58 UTC (permalink / raw)
To: Timur Tabi; +Cc: scottwood, linuxppc-dev, smaclennan
In-Reply-To: <ed82fe3e0905181549n6d9a5370rcc0e1f52cebdc2d3@mail.gmail.com>
On Mon, May 18, 2009 at 4:49 PM, Timur Tabi <timur@freescale.com> wrote:
> On Thu, May 14, 2009 at 11:10 AM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> In other words, write your patches which use it and submit the lot as
>> a patch series with this patch as the first. =A0That gives some evidence
>> that this macro will actually be used and useful.
>
> This is going to be more difficult than you think. =A0The problem is
> that I don't have access to much hardware that uses drivers which can
> take advantage of this macro. =A0I can find one, maybe two examples, but
> if I put a timeout that's too short, I might break some other platform
> without knowing it.
Then let it lie fallow on the list and in patchwork. It is published,
and people know that it is available (I'll certainly consider it as I
do driver work), but there must be real (not just theoretical) in
kernel users of the interface. I someone wants to use it, then they
can add it to their series or ping the list about getting it merged.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] Allow selecting mv643xx_eth on Pegasos again
From: David Miller @ 2009-05-19 2:35 UTC (permalink / raw)
To: paubert; +Cc: netdev, linuxppc-dev, pacman, tbm, buytenh
In-Reply-To: <20090518232113.GA18469@iram.es>
From: Gabriel Paubert <paubert@iram.es>
Date: Tue, 19 May 2009 01:21:13 +0200
> Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity
> to remove the stale MV64360 config option.
>
> Signed-off-by: Gabriel Paubert <paubert@iram.es>
This patch doesn't even apply to net-next-2.6, please send me
changes relative to that.
^ permalink raw reply
* Re: [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Hongjun Chen @ 2009-05-19 1:37 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc-dev@ozlabs.org; +Cc: Piotr Ziecik, Wolfgang Denk
In-Reply-To: <1241640919-4650-12-git-send-email-wd@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
Since you have reuse most part of our BSP, why should you reinvent wheel for MPC512x DMA? We have one ready DMA driver, which has been used by AC97, ATA, VIU etc.
Hongjun Chen
2009-05-19
发件人： Wolfgang Denk
发送时间： 2009-05-07 04:15:18
收件人： linuxppc-dev@ozlabs.org
抄送： Piotr Ziecik; Wolfgang Denk
主题： [PATCH 11/12] mpc5121: Added MPC512x DMA driver.
From: Piotr Ziecik <kosmo@semihalf.com>
This patch adds initial version of MPC512x DMA driver.
Only memory to memory transfers are currenly supported.
Signed-off-by: Piotr Ziecik <kosmo@semihalf.com>
Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: John Rigby <jcrigby@gmail.com>
---
arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 1 +
drivers/dma/Kconfig | 7 +
drivers/dma/Makefile | 1 +
drivers/dma/mpc512x_dma.c | 642 ++++++++++++++++++++++++++
drivers/dma/mpc512x_dma.h | 192 ++++++++
6 files changed, 844 insertions(+), 1 deletions(-)
create mode 100644 drivers/dma/mpc512x_dma.c
create mode 100644 drivers/dma/mpc512x_dma.h
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[-- Attachment #2: Type: text/html, Size: 4230 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc/pci: clean up direct access to sysdata by iseries platform
From: Stephen Rothwell @ 2009-05-19 0:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1242651387-13194-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi Kumar,
On Mon, 18 May 2009 07:56:27 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> We shouldn't directly access sysdata to get the device node. We should
> be calling pci_device_to_OF_node().
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> * Fixed compile error (dev -> pdev)
I tested the previous version with the typo fixed, so assuming that you
changed nothing else,
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 23:21 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2702C2D459@az33exm24.fsl.freescale.net>
Since PPC_MUTIPLATFORM was removed, it was impossible to select the
driver for mv643xx_eth on the Pegasos. Fix it and take the opportunity
to remove the stale MV64360 config option.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 214a92d..aff4f8c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
- depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) || PLAT_ORION
+ depends on MV64X60 || PPC32 || PLAT_ORION
select INET_LRO
select PHYLIB
help
^ permalink raw reply related
* RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Medve Emilian-EMMEDVE1 @ 2009-05-18 22:53 UTC (permalink / raw)
To: Gabriel Paubert
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <20090518221847.GA17348@iram.es>
Hello Gabriel,
> -----Original Message-----
> From: Gabriel Paubert [mailto:paubert@iram.es]
> Sent: Monday, May 18, 2009 5:19 PM
> To: Medve Emilian-EMMEDVE1
> Cc: Lennert Buytenhek; tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
netdev@vger.kernel.org; David
> Miller
> Subject: Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
>=20
> Hello Medve
>=20
> On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1
wrote:
> >
> > You're correct. MV64360 seems to be stale. Do you want to re-spin
your
> > patch to get rid of it?
>=20
>=20
> No problem, bu should I respin in from the current official git
> or on top of yours?
Top of the tree should be good.
Cheers,
Emil.
> > (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.)
>=20
> Fine with me.
>=20
> Regards,
> Gabriel
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-18 22:49 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev, smaclennan
In-Reply-To: <fa686aa40905140910i194acbd7y34142720874b8299@mail.gmail.com>
On Thu, May 14, 2009 at 11:10 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> In other words, write your patches which use it and submit the lot as
> a patch series with this patch as the first. =A0That gives some evidence
> that this macro will actually be used and useful.
This is going to be more difficult than you think. The problem is
that I don't have access to much hardware that uses drivers which can
take advantage of this macro. I can find one, maybe two examples, but
if I put a timeout that's too short, I might break some other platform
without knowing it.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Benjamin Herrenschmidt @ 2009-05-18 22:17 UTC (permalink / raw)
To: Grant Likely
Cc: Becky Bruce, Piotr Zięcik, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood, Wolfgang Denk
In-Reply-To: <fa686aa40905140700k3ca28ac0m74c9c161ad538abc@mail.gmail.com>
On Thu, 2009-05-14 at 08:00 -0600, Grant Likely wrote:
>
> All of this doesn't actually affect the driver code at all. It's all
> handled by the kernel and the DMA apis. What it does affect is
> multiplatform kernels. The DMA behaviour is set at compile time, not
> run time, depending on the setting of CONFIG_NON_COHERENT_CACHE (see
> arch/powerpc/platforms/Kconfig.cputype). A kernel which has it on
> won't run properly on a platform which has it off, and visa-versa.
We are close to the point where we can make this a runtime option
though, by just having a different set of dma_ops hooked in.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 22:18 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2702C2D3A5@az33exm24.fsl.freescale.net>
Hello Medve
On Mon, May 18, 2009 at 01:15:12PM -0700, Medve Emilian-EMMEDVE1 wrote:
>
> You're correct. MV64360 seems to be stale. Do you want to re-spin your
> patch to get rid of it?
No problem, bu should I respin in from the current official git
or on top of yours?
>
> (I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.)
Fine with me.
Regards,
Gabriel
^ permalink raw reply
* Re: [OT] Lite5200B w/ nfs root hangs after some time
From: Jerome Walters @ 2009-05-18 22:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1240422181.5492.0@antares>
We experience exactly the same problem. Our client is Debian Testing
(_Squeeze_) x86 =E2=80=93 diskless node which uses nfsroot and boots from t=
he server
also Debian Testing (_Squeeze_) x86. While the client hang the server is
responding to everyone else's requests. Restarting the nfsd on the server
doesn't solve the problem.
At first I wasnt able to capture debug information on the client side since
/var/log was mounted over the nfs, so I have installed a hard drive where I
mounted only /var/log to be able to capture debug logs from the client as
well.
Debug Logs:=20
http://fixity.net/tmp/client.log.gz - Kernel RPC Debug Log from the client
http://fixity.net/tmp/server.log.gz - Kernel RPC Debug Log from the server
How reproducible:
Happens from 10 to 90 minutes after booting the diskless node.
Actual results:
NFS connections stop responding, system hangs or becomes very slow and
unresponsive (it doesnt respond to Ctrl+Alt+Del as well). 60 to 90 minutes
after the first server time out client says server OK but the client is
still
unresponsive. Immediately after that the client logs server connection loss
again which leads to continues loop. Client is still unresponsive. Sometime=
s
client resumes normal operation for couple of hours but then the problem
repeats.
Connectivity info:=20
Both the client and the server are connected to Gigabit Ethernet Cisco Metr=
o
series managable switch. Both of them use Intel Pro 82545GM Gigabit Etherne=
t
Server Controllers. Neither one of them log any Ethernet errors and none ar=
e
logged by the switch.
Client & Server Load:
For the purposes of testing both machines were only running needed daemons
and
weren't loaded at all.
Client & Server Kernel:
On both the client and server custom compiled linux 2.6.29.3 kernel was
used.
Configuration file @ http://fixity.net/tmp/config-2.6.29.3.gz
Client & Server Network interface fragmented packet queue length:
net.ipv4.ipfrag_high_thresh =3D 524288
net.ipv4.ipfrag_low_thresh =3D 393216
Client Versions:
libnfsidmap2/squeeze uptodate 0.21-2
nfs-common/squeeze uptodate 1:1.1.4-1
Client Mount (cat /proc/mounts | grep nfsroot):
10.11.11.1:/nfsroot / nfs
rw,vers=3D3,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,nointr,nolock,p=
roto=3Dtcp,timeo=3D7,retrans=3D10,sec=3Dsys,addr=3D10.11.11.1
0 0
Client fstab:
proc /proc proc defaults 0 0
/dev/nfs / nfs defaults 1 1
none /tmp tmpfs defaults 0 0
none /var/run tmpfs defaults 0 0
none /var/lock tmpfs defaults 0 0
none /var/tmp tmpfs defaults 0 0
Client Daemons:
portmap, rpc.statd, rpc.idmapd
Server Daemons:
portmap, rpc.statd, rpc.idmapd, rpc.mountd --manage-gids
Server Versions:
libnfsidmap2/squeeze uptodate 0.21-2
nfs-common/squeeze uptodate 1:1.1.4-1
nfs-kernel-server/testing uptodate 1:1.1.4-1
Server Export:
/nfsroot 10.11.11.*(rw,no_root_squash,async,no_subtree_check)
Server Options:
RPCNFSDCOUNT=3D16
RPCNFSDPRIORITY=3D0
RPCMOUNTDOPTS=3D--manage-gids
NEED_SVCGSSD=3Dno
RPCSVCGSSDOPTS=3Dno
Additional Info:
Since I have read that tweaking the nfsroot mount options could improve the=
=20
situation a have tested with different options as follows:
rsize/wsize=3D1024|2048|4096|8192|32768|524288
timeo=3D7|15|60|600
retrans=3D3|10|20
None resulted in solving the problem.
I have also tested with the following version on the client and server end
without any difference in the behaviour:
libnfsidmap2/testing uptodate 0.21-2
nfs-common 1:1.1.6-1 newer than version in archive
nfs-kernel-server 1:1.1.6-1 newer than version in archive
Any help or suggestions on fixing the problem would be highly appreciated. =
I=20
have been messing with that problem for the last couple of weeks and ran ou=
t
of ideas.
Best Regards,
Jerome Walters =20
--=20
View this message in context: http://www.nabble.com/-OT--Lite5200B-w--nfs-r=
oot-hangs-after-some-time-tp23181953p23606187.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: fs_enet build breakage
From: Benjamin Herrenschmidt @ 2009-05-18 21:50 UTC (permalink / raw)
To: Scott Wood; +Cc: Kumar Gala, linuxppc-dev list
In-Reply-To: <20090518172016.GB18620@b07421-ec1.am.freescale.net>
On Mon, 2009-05-18 at 12:20 -0500, Scott Wood wrote:
> > I'm pretty sure the driver changes to address this are in dave's
> net-
> > next tree.
>
> Won't this break git bisect?
>
> Not to mention anyone trying to use your tree now...
Right, though if you have the commit ID in DaveM tree, I can work with
him to sort out that driver, for example by having the same commit in
my tree.
Ben.
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc: Add support for swiotlb on 32-bit
From: Benjamin Herrenschmidt @ 2009-05-18 21:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: fujita.tomonori, linuxppc-dev
In-Reply-To: <DE108B1C-85A6-4D1F-8E4D-E1AB5495578A@kernel.crashing.org>
On Mon, 2009-05-18 at 08:25 -0500, Kumar Gala wrote:
>
> Part of this is how the generic swiotlb code works and part of it
> was
> our desire not to bloat dev archdata by adding such info that as you
> say is either bus specific or conveyed in the dma addr mask.
Right but perf sucks :-)
Maybe an option is to clamp the DMA mask when it's set by the driver to
limit it to the available inbound window ?
Cheers,
Ben.
^ permalink raw reply
* RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Medve Emilian-EMMEDVE1 @ 2009-05-18 20:15 UTC (permalink / raw)
To: Gabriel Paubert
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <20090518184752.GA12972@iram.es>
Hello Gabriel,
> -----Original Message-----
> From: Gabriel Paubert [mailto:paubert@iram.es]
> Sent: Monday, May 18, 2009 1:48 PM
> To: Medve Emilian-EMMEDVE1
> Cc: Lennert Buytenhek; tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
netdev@vger.kernel.org; David
> Miller
> Subject: Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
>=20
> On Mon, May 18, 2009 at 10:48:58AM -0700, Medve Emilian-EMMEDVE1
wrote:
> > > -----Original Message-----
> > > From: =
linuxppc-dev-bounces+emilian.medve=3Dfreescale.com@ozlabs.org
> > [mailto:linuxppc-dev-
> > > bounces+emilian.medve=3Dfreescale.com@ozlabs.org] On Behalf Of
Gabriel
> > Paubert
> > > Sent: Monday, May 18, 2009 12:38 PM
> > > To: Lennert Buytenhek
> > > Cc: tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
> > netdev@vger.kernel.org; David Miller
> > > Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again
> > >
> > > Since PPC_MUTIPLATFORM was removed, it was impossible to select
the
> > > driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> > > the driver on CHRP platforms; Pegasos is a CHRP platform and the
> > driver
> > > will not work without arch/powerpc/platforms/chrp/pegasos_eth.
> > >
> > > Signed-off-by: Gabriel Paubert <paubert@iram.es>
> > >
> > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > > index 214a92d..6fc0ff4 100644
> > > --- a/drivers/net/Kconfig
> > > +++ b/drivers/net/Kconfig
> > > @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
> > >
> > > config MV643XX_ETH
> > > tristate "Marvell Discovery (643XX) and Orion ethernet support"
> > > - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) ||
> > PLAT_ORION
> > > + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> > > select INET_LRO
> > > select PHYLIB
> > > help
> >
> > This got fixed here:
> >
http://git.kernel.org/?p=3Dlinux/kernel/git/davem/net-next-2.6.git;a=3Dco=
mmi
> > tdiff;h=3D952ee9df26c487f2d73b2dced58ec904f19ea0f8
>=20
> Ok, I was not aware of it, but the fact is that MV64360 no more exists
> and the only non MV64X60 platform that may need it is the Pegasos (to
my
> knowledge) and it relies on some platform specific code enabled
> by PPC_CHRP.
You're correct. MV64360 seems to be stale. Do you want to re-spin your
patch to get rid of it?
(I wouldn't create a dependency between MV643XX_ETH and PPC_CHRP.)
=20
Cheers,
Emil.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Segher Boessenkool @ 2009-05-18 19:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Ingo Molnar, Sam Ravnborg
In-Reply-To: <1242620044.18075.31.camel@pasglop>
> Segher, what are we missing here ?
The symbol name is misleading, and the help text is incorrect.
With those things fixed, I won't oppose the patch; it would
be nice if the logic here was cleaned up to avoid all the
double negations, but I'm not going to do it, so I won't ask
others to either.
Segher
^ permalink raw reply
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 18:47 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1
Cc: netdev, tbm, LinuxPPC, pacman, David Miller, Lennert Buytenhek
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E2702C2D323@az33exm24.fsl.freescale.net>
On Mon, May 18, 2009 at 10:48:58AM -0700, Medve Emilian-EMMEDVE1 wrote:
> > -----Original Message-----
> > From: linuxppc-dev-bounces+emilian.medve=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-
> > bounces+emilian.medve=freescale.com@ozlabs.org] On Behalf Of Gabriel
> Paubert
> > Sent: Monday, May 18, 2009 12:38 PM
> > To: Lennert Buytenhek
> > Cc: tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
> netdev@vger.kernel.org; David Miller
> > Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again
> >
> > Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> > driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> > the driver on CHRP platforms; Pegasos is a CHRP platform and the
> driver
> > will not work without arch/powerpc/platforms/chrp/pegasos_eth.
> >
> > Signed-off-by: Gabriel Paubert <paubert@iram.es>
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 214a92d..6fc0ff4 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
> >
> > config MV643XX_ETH
> > tristate "Marvell Discovery (643XX) and Orion ethernet support"
> > - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) ||
> PLAT_ORION
> > + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> > select INET_LRO
> > select PHYLIB
> > help
>
> This got fixed here:
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commi
> tdiff;h=952ee9df26c487f2d73b2dced58ec904f19ea0f8
Ok, I was not aware of it, but the fact is that MV64360 no more exists
and the only non MV64X60 platform that may need it is the Pegasos (to my
knowledge) and it relies on some platform specific code enabled
by PPC_CHRP.
Regards,
Gabriel
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Chris Plasun @ 2009-05-18 18:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <c384c5ea0905181118g34896cc3s1e77b9ba22c4e164@mail.gmail.com>
Hi Leon,
Leon Woestenberg wrote:
> Hello Chris,
>
> On Mon, May 18, 2009 at 8:06 PM, Chris Plasun <chrispl78@yahoo.com> wrote:
>> Scott Wood wrote:
>>> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>>>> (I haven't found any answers in the archives)
>>>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>>> Will Samba run on a Freescale MPC8313?
>>> It should (and if it doesn't, file a bug with them).
>>> Userspace is pretty much the same at the source-code and user-interface
>>> level -- the answer to "how do I do X on this PPC board" is generally the
>>> same as the answer to "how do I do X on Linux", other than that you may
>>> need to compile some packages manually if they don't come with whatever
>>> distribution you're using.
>> Thanks Scott.
>>
>> I did some more reading on the board and it appears that it's not as limited
>> as I thought. The "custom" Linux we're running is very limited (so it
>> appears) and I interpreted the board to be so as well.
>>
>
> To build your own fully-open Linux for this board, I can recommend
> both these projects:
>
> LTIB (http://www.bitshrine.org/)
> OpenEmbedded (http://www.openembedded.org/)
>
> We use the latter in an industrial setting with much success,
Thanks Leon. I'll definitely be back to ask for help to get these
distributions running =)
cp
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Leon Woestenberg @ 2009-05-18 18:18 UTC (permalink / raw)
To: Chris Plasun; +Cc: linuxppc-dev
In-Reply-To: <4A11A3B4.7060801@yahoo.com>
Hello Chris,
On Mon, May 18, 2009 at 8:06 PM, Chris Plasun <chrispl78@yahoo.com> wrote:
> Scott Wood wrote:
>> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>>> (I haven't found any answers in the archives)
>>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>> Will Samba run on a Freescale MPC8313?
>>
>> It should (and if it doesn't, file a bug with them).
>> Userspace is pretty much the same at the source-code and user-interface
>> level -- the answer to "how do I do X on this PPC board" is generally the
>> same as the answer to "how do I do X on Linux", other than that you may
>> need to compile some packages manually if they don't come with whatever
>> distribution you're using.
>
> Thanks Scott.
>
> I did some more reading on the board and it appears that it's not as limited
> as I thought. The "custom" Linux we're running is very limited (so it
> appears) and I interpreted the board to be so as well.
>
To build your own fully-open Linux for this board, I can recommend
both these projects:
LTIB (http://www.bitshrine.org/)
OpenEmbedded (http://www.openembedded.org/)
We use the latter in an industrial setting with much success,
Regards,
--
Leon
^ permalink raw reply
* Re: Accessing NTFS Shares from Freescale MPC8313
From: Chris Plasun @ 2009-05-18 18:06 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090518171028.GA18620@b07421-ec1.am.freescale.net>
Scott Wood wrote:
> On Sun, May 17, 2009 at 01:45:30AM -0700, Chris Plasun wrote:
>> Hi,
>>
>> (I haven't found any answers in the archives)
>>
>> How would I access a NTFS shared directory from a Freescale MPC8313?
>>
>> Will Samba run on a Freescale MPC8313?
>
> It should (and if it doesn't, file a bug with them).
>
> Userspace is pretty much the same at the source-code and user-interface
> level -- the answer to "how do I do X on this PPC board" is generally the
> same as the answer to "how do I do X on Linux", other than that you may
> need to compile some packages manually if they don't come with whatever
> distribution you're using.
Thanks Scott.
I did some more reading on the board and it appears that it's not as
limited as I thought. The "custom" Linux we're running is very limited
(so it appears) and I interpreted the board to be so as well.
I'm a Windows ASP.NET developer thrown off the deep end into Linux so
please forgive the noob questions. After going through many post it
appears my questions are pertinent to general Linux.
Thank you!
Chris Plasun
^ permalink raw reply
* RE: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Medve Emilian-EMMEDVE1 @ 2009-05-18 17:48 UTC (permalink / raw)
To: Gabriel Paubert, Lennert Buytenhek
Cc: LinuxPPC, David Miller, pacman, tbm, netdev
In-Reply-To: <20090518173756.GA11805@iram.es>
> -----Original Message-----
> From: linuxppc-dev-bounces+emilian.medve=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+emilian.medve=3Dfreescale.com@ozlabs.org] On Behalf Of Gabriel
Paubert
> Sent: Monday, May 18, 2009 12:38 PM
> To: Lennert Buytenhek
> Cc: tbm@cyrius.com; LinuxPPC; pacman@kosh.dhis.org;
netdev@vger.kernel.org; David Miller
> Subject: [PATCH] Allow selecting mv643xx_eth on Pegasos again
>=20
> Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> the driver on CHRP platforms; Pegasos is a CHRP platform and the
driver
> will not work without arch/powerpc/platforms/chrp/pegasos_eth.
>=20
> Signed-off-by: Gabriel Paubert <paubert@iram.es>
>=20
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 214a92d..6fc0ff4 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
>=20
> config MV643XX_ETH
> tristate "Marvell Discovery (643XX) and Orion ethernet support"
> - depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) ||
PLAT_ORION
> + depends on MV64X60 || PPC_CHRP || PLAT_ORION
> select INET_LRO
> select PHYLIB
> help
This got fixed here:
http://git.kernel.org/?p=3Dlinux/kernel/git/davem/net-next-2.6.git;a=3Dco=
mmi
tdiff;h=3D952ee9df26c487f2d73b2dced58ec904f19ea0f8
Cheers,
Emil.
^ permalink raw reply
* mpc5200 fec error
From: Eric Millbrandt @ 2009-05-18 17:36 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3592 bytes --]
Hello all,
I am testing a 2.6.29.3 (with preempt_rt patches) kernel on a phytec
pcm030 and am getting a kernel hang when testing the fec Ethernet
controller. The error only occurs when running the preempt-patched
kernel, an unmodified kernel works fine. Is anyone out there using
preempt_rt on an MPC5200 successfully?
Eric
root@rudolph-ui:/root> iperf -c linux-5200bdevl01 -P 2 -i 1 -p 5001 -f k
-t 600
------------------------------------------------------------
Client connecting to linux-5200bdevl01, TCP port 5001
TCP window size: 36.2 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.4.88 port 37872 connected with 10.1.5.234 port 5001
[ 3] local 10.1.4.88 port 37871 connected with 10.1.5.234 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 3824 KBytes 31326 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 3656 KBytes 29950 Kbits/sec
[SUM] 0.0- 1.0 sec 7480 KBytes 61276 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 1.0- 2.0 sec 3760 KBytes 30802 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 1.0- 2.0 sec 3752 KBytes 30736 Kbits/sec
[SUM] 1.0- 2.0 sec 7512 KBytes 61538 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 2.0- 3.0 sec 3728 KBytes 30540 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 2.0- 3.0 sec 3816 KBytes 31261 Kbits/sec
[SUM] 2.0- 3.0 sec 7544 KBytes 61800 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 3.0- 4.0 sec 3712 KBytes 30409 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 3.0- 4.0 sec 3824 KBytes 31326 Kbits/sec
[SUM] 3.0- 4.0 sec 7536 KBytes 61735 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 4.0- 5.0 sec 3968 KBytes 32506 Kbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 4.0- 5.0 sec 3624 KBytes 29688 Kbits/sec
[SUM] 4.0- 5.0 sec 7592 KBytes 62194 Kbits/sec
[ 5761.999175] net eth0: transmit queue overrun
[ 5762.003591] net eth0: transmit queue overrun
[ 5762.007948] net eth0: transmit queue overrun
[ 5762.012302] net eth0: transmit queue overrun
[ 5762.016658] net eth0: transmit queue overrun
[ 5762.021013] net eth0: transmit queue overrun
[ 5762.025381] net eth0: transmit queue overrun
[ 5762.029735] net eth0: transmit queue overrun
[ 5762.034090] net eth0: transmit queue overrun
[ 5762.038445] net eth0: transmit queue overrun
[ 5767.000928] net eth0: transmit queue overrun
[ 5767.005278] net eth0: transmit queue overrun
[ 5767.009634] net eth0: transmit queue overrun
[ 5767.013990] net eth0: transmit queue overrun
[ 5767.018345] net eth0: transmit queue overrun
[ 5767.022701] net eth0: transmit queue overrun
...
_________________________________________________________________________________________
This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
[-- Attachment #2: Type: text/html, Size: 12384 bytes --]
^ permalink raw reply
* [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 17:37 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: tbm, LinuxPPC, pacman, netdev, David Miller
Since PPC_MUTIPLATFORM was removed, it was impossible to select the
driver for mv643xx_eth on the Pegasos. Fix by allowing to select
the driver on CHRP platforms; Pegasos is a CHRP platform and the driver
will not work without arch/powerpc/platforms/chrp/pegasos_eth.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 214a92d..6fc0ff4 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2351,7 +2351,7 @@ config UGETH_TX_ON_DEMAND
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
- depends on MV64360 || MV64X60 || (PPC_MULTIPLATFORM && PPC32) || PLAT_ORION
+ depends on MV64X60 || PPC_CHRP || PLAT_ORION
select INET_LRO
select PHYLIB
help
^ permalink raw reply related
* Re: [PATCH] Allow selecting mv643xx_eth on Pegasos again
From: Gabriel Paubert @ 2009-05-18 17:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: LinuxPPC
In-Reply-To: <1242617089.18075.25.camel@pasglop>
On Mon, May 18, 2009 at 01:24:49PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-05-15 at 20:18 +0200, Gabriel Paubert wrote:
> > Since PPC_MUTIPLATFORM was removed, it was impossible to select the
> > driver for mv643xx_eth on the Pegasos. Fix by allowing to select
> > the driver on CHRP platforms; Pegasos is a CHRP platform and the driver
> > will not work wihtout arch/powerpc/platforms/chrp/pegasos_eth.
> >
> > The patch also removes all references to MV64360 config option which
> > no more exists.
> >
> > Signed-off-by: Gabriel Paubert <paubert@iram.es>
>
> Please break that up into 2 different patches. The arch/powerpc one that
> removes the reference from IRQ_ALL_CPUs and the drivers/net/ one which
> should be set to the netdev mailing list.
>
Ok, but I have a doubt about the PPC one, should MV64360 be removed or
changed to MV64X60?
In any case, I can't test it.
Gabriel
^ permalink raw reply
* Re: [BUG] 2.6.30-rc3: BUG triggered on some hugepage usages
From: Linus Torvalds @ 2009-05-18 17:26 UTC (permalink / raw)
To: Mel Gorman; +Cc: ebmunson, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20090518171322.GB13093@csn.ul.ie>
On Mon, 18 May 2009, Mel Gorman wrote:
>
> What's the story with this patch? I'm still hearing of failures with huge pages
> that this patch fixes but I'm no seeing it upstream. Was the patch
> rejected or did it just slip through the cracks?
It didn't slip through the cracks, it was apparently just delayed. It's
part of the merge requests I've gotten today (well, strictly speaking it
seems to have hit my inbox just before midnight yesterday, but that's
because those silly aussies stand upside down and sleep at odd hours).
In fact, I just merged it, I haven't even had time to push that out.
Linus
^ 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