On 10/8/07, Sascha Hauer <[EMAIL PROTECTED]> wrote:
> While the previous patch I sent fixed the reset path for the fec
> controller this patch makes sure the chip does not have to be resetted.
> Problem was that we ran out of receive buffers when we nmapped our
> board (nmap sends lots of small pac
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex: 36
> net eth0: rx: index: 24, outdex: 25
Hi,
On Fri, Sep 28, 2007 at 11:12:17AM +0200, Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues di
On Monday 01 October 2007 10:35, Juergen Beisert wrote:
> 2) Same target runs 2.6.23-rc8-rt1
>
> @host$ nmap 192.168.23.226
>
> Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-01 10:15 CEST
> Interesting ports on 192.168.23.226:
> Not shown: 871 filtered ports, 824 closed ports
> PORT STATE
On Friday 28 September 2007 17:38, Jon Smirl wrote:
> On 9/28/07, Juergen Beisert <[EMAIL PROTECTED]> wrote:
> > But I can't run it a second time, as the network on target's side doesn't
> > respond. Any idea?
>
> Do the stress tests complete on a non-rt kernel?
I tried it again:
1) Target runs 2
Juergen Beisert wrote:
> I tried with in_atomic(). The BUG report is gone, but the problem still
> exists.
>
> While network stress testing:
>
> [...]
> NETDEV WATCHDOG: eth0: transmit timed out
> net eth0: transmit timed out
> net eth0: queues didn't drain
> net eth0: tx: index: 35, outdex:
On 9/28/07, Juergen Beisert <[EMAIL PROTECTED]> wrote:
> But I can't run it a second time, as the network on target's side doesn't
> respond. Any idea?
Do the stress tests complete on a non-rt kernel?
That will narrow down the type of bug being looked for.
--
Jon Smirl
[EMAIL PROTECTED]
___
On Thursday 27 September 2007 19:07, Juergen Beisert wrote:
> On Friday 10 August 2007 11:51, Domen Puncer wrote:
> > Not for merge (yet)! But please do review.
> >
> > fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> > good shape, so I tried to change that.
> > Diff against or
On Thursday 27 September 2007 20:43, Scott Wood wrote:
> Jon Smirl wrote:
> > The call to msleep() is inside a block protected with
> >
> > :#define in_interrupt() (irq_count())
> >
> > if (!in_interrupt)
> >
> > The stack trace looks like it is in a timer interrupt so shouldn't
> > irq_co
Jon Smirl wrote:
> The call to msleep() is inside a block protected with
> :#define in_interrupt() (irq_count())
> if (!in_interrupt)
>
> The stack trace looks like it is in a timer interrupt so shouldn't
> irq_count be non-zero?
> Could there be some lack of coordination on irq_count and
On 9/27/07, Juergen Beisert <[EMAIL PROTECTED]> wrote:
> On Friday 10 August 2007 11:51, Domen Puncer wrote:
> > Not for merge (yet)! But please do review.
> >
> > fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> > good shape, so I tried to change that.
> > Diff against origina
On Friday 10 August 2007 11:51, Domen Puncer wrote:
> Not for merge (yet)! But please do review.
>
> fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> good shape, so I tried to change that.
> Diff against original is quite big (fec_phy.c is completely rewritten)
> and confuzing,
On 20/08/07 20:02 +0100, Matt Sealey wrote:
> Are you sure this is correct for the Efika?
It works (tm).
>
> The MPC5200B manual makes a decent distinction between MII operation and
> straight MDIO?
Uh? From what I read MDIO are the lines of MII.
Domen
>
> --
> Matt Sealey <[EMAIL
Are you sure this is correct for the Efika?
The MPC5200B manual makes a decent distinction between MII operation and
straight MDIO?
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
Domen Puncer wrote:
> On 20/08/07 10:31 +0200, Domen Puncer wrote:
>> On 19/08/07 16:39 +01
On 20/08/07 10:31 +0200, Domen Puncer wrote:
> On 19/08/07 16:39 +0100, Matt Sealey wrote:
> > Domen,
> >
> > Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
> > Linux with more fixups. The Efika PHY isn't going to change to something
> > else and it's a bog standard no-fri
On 19/08/07 16:39 +0100, Matt Sealey wrote:
> Domen,
>
> Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
> Linux with more fixups. The Efika PHY isn't going to change to something
> else and it's a bog standard no-frills MII PHY anyway.
Fine with me, but I'm worried people
Domen,
Do it in a Forth script, or in nvramrc (after probe-all). Don't clutter
Linux with more fixups. The Efika PHY isn't going to change to something
else and it's a bog standard no-frills MII PHY anyway.
I think it is a distinction that the OF docs forgot to make, that the
client interface is
Hi!
On 10/08/07 11:51 +0200, Domen Puncer wrote:
> Index: work-powerpc.git/arch/powerpc/boot/dts/lite5200b.dts
> ===
> --- work-powerpc.git.orig/arch/powerpc/boot/dts/lite5200b.dts
> +++ work-powerpc.git/arch/powerpc/boot/dts/lite5200
On 10/08/07 10:02 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 10, 2007 at 11:51:53AM +0200, Domen Puncer escreveu:
> > +static u8 null_mac[6];
>
> const
OK.
...
> > +static void fec_set_paddr(struct net_device *dev, u8 *mac)
> > +{
> > + struct fec_priv *priv = netdev_priv(dev);
> > +
Em Fri, Aug 10, 2007 at 11:51:53AM +0200, Domen Puncer escreveu:
> Hi!
>
> Not for merge (yet)! But please do review.
>
> fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> good shape, so I tried to change that.
> Diff against original is quite big (fec_phy.c is completely rewr
Hi!
Not for merge (yet)! But please do review.
fec_mpc52xx driver (not in-tree, but floating around) isn't in very
good shape, so I tried to change that.
Diff against original is quite big (fec_phy.c is completely rewritten)
and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
I stil
21 matches
Mail list logo
