headers
Joakim Tjernlund | 1 Nov 2002 12:01
Picon

RE: [PATCH] arch/ppc/8xx_io/enet.c, version 2


Hi Tom

Will you apply this patch?  No problems reported so far.

 Jocke

> >
> > On Thu, Oct 24, 2002 at 04:23:31PM +0200, Joakim Tjernlund wrote:
> >
> > > This is the second version of my patch that removes the expensive memcpy of
> > > received
> > > ethernet frames in interrupt context.
> > >
> > > I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet
> > > size 1500 when
> > > applied to 8260 FEC(needs to be applied manually). But min packet size
> > > decreased with 10 %.
> > > This version should fix the 10% decrease case.
> > >
> > > This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and
> > > 8260/fcc_enet.c with little effort.
> > >
> > > Better fix a bug in set_multicast_list(), move the dmi list forward when
> > >     walking it(dmi = dmi->next;)
> > >
> > > New stuff:
> > >    - Configrable: copy small packets or pass them directly, see
> > > COPY_SMALL_FRAMES in code.
> > >    - Collision reporting fix form Thomas Lange.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joakim Tjernlund | 1 Nov 2002 12:01
Picon

RE: 8xx i2c refers to unspecified chip errata


Hi Tom

Will you apply this patch? No problems reported so far.

 Jocke

> > >
> > > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c
> >
> > Can you please split this into logical chunks, or give me a list of each
> > fix in here?  Thanks.
>
> ohh, kind of hard to remember all that went into that patch. The path
> has evoled over many days, but I can try summarize. I have tested this code
> pretty well it does not fail for me. Speed has been between 10-150KHz. The
> old code fails as soon you start to stress it a little.
>
>  - replace invalidate_dcache_range with flush_dcache_range, since buffers are
>    NOT cache aligned. flush will write to memory AND invalidate the cache.
>
>  - move the chip errata stuff from irq routine into read/write routines. Made
>    it default off since it causes lock ups on my I2C device. I think it causes
>    a too short STOP condition. If enabled I2C will behave better than before, but
>    may still cause problems if the read/write is interrupted with a signal while
>    microcode is enabled.
>
>  - set default speed to 60 KHz instead.
>
>  - missing/faulty initialization of parameter ram when I2C micro patch is active.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joakim Tjernlund | 1 Nov 2002 12:14
Picon

RE: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx


> > Joakim Tjernlund wrote:
> >
> > > It seems that even the newest 8xx chips still has problems. I did not expect that.
> >
> > It may be the parts are working fine.  I long ago removed the code necessary
> > to detect the exception conditions when the cache instructions faulted, so
> > I wouldn't expect them to work properly.
>
> Aah, that would explain why __copy_tofrom_user doesn't work I guess. But the
> rest seems to be fine. Maybe there should be a new config option that
> would one could enable for modern 8xx CPUs? With a big warning sign of cource
> and default to off. Maybe even add the missing exception handler?
>
>    Jocke

Dan, could you add the missing code for 8xx to detect the exception conditions when
the cache instructions faulted? I would like to give it a try.

Maybe add a new CONFIG option to allow 8xx to use these optimizations when
explicitly enabled. Perhaps it's enough to let it depend on CONFIG_8xx_CPU6, that is,
if CONFIG_8xx_CPU6 is set do NOT enable dcbz et. all, otherwise enable them?

        Jocke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 4 comments |
headers
Thomas Geffert | 1 Nov 2002 13:22
Favicon

tqm 8260 scc ethernet crc errors


Hello,

I've problems with receiving packets with an TQM8260 board on the SCC
10Mbit ethernet interface.

If I connect two tqm boards directly via an ethernet crossover cable and
send udp packets from one board to another the receiving CPM marks
1-15% of all packets with an crc error flag (this depends on packet
size and send speed).  When I check the udp checksum of the received
packets this check only ails for approx 5-10% of the marked packets,
e.g.

Send packets in 5s      CPM says CRC-Error[1]   UDP checksum error
=====================================================================
6000 (512 bytes each)   591 / 9.8%              94 / 1.6%
4850 (512 bytes each )  220 / 4.5%              34 / 0.7%

6000 (128 bytes each)   182 / 3%                43 / 0.7%

The faster the packets are send and the longer the packets are the more errors
are detected. If I send the packets with a rate <50 packets/s I got almost
no crc errors.

I'm very surprised over the errors, as I use a direct connection
between the boards and send only in one direction. In such a case I
would expect to get no errors. Can this be an EMI error of the
physical SCC ethernet interface of the tqm boards?

I also connected the tqm board via a switch to a PC 10Mbit ethernet
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dayton, Dean | 1 Nov 2002 16:30

dcache and 8260_io/fcc_enet.c


I noticed that fcc_enet_start_xmit() does not flush the transmit data before
setting up the transmit buffer descriptor. I get the impression that this is
not necessary. But I don't understand why. I have spent the morning looking
through code and Motorola docs and am non the wiser.

Thanks
Dean

-------------
Dean Dayton
System Architect - Applied Innovation Inc.
(614)923-1174
deand <at> aiinet.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 2 comments |
headers
Joakim Tjernlund | 1 Nov 2002 16:46
Picon

RE: dcache and 8260_io/fcc_enet.c


>
> I noticed that fcc_enet_start_xmit() does not flush the transmit data before
> setting up the transmit buffer descriptor. I get the impression that this is
> not necessary. But I don't understand why. I have spent the morning looking
> through code and Motorola docs and am non the wiser.

That's because the 8260 CPU understand the CPU caches and, while the 8xx does not
and therefore needs a flush_dcache_range().

    Jocke

>
> Thanks
> Dean

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 1 comment |
headers
Joakim Tjernlund | 1 Nov 2002 17:01
Picon

RE: dcache and 8260_io/fcc_enet.c


Crap, disregard my previous mail.

The 8260 CPM is aware of the CPU dcache and therefor you don't need to flush
the data before handing the buffer over to the CPM. The CPM 8xx family CPU
has no understanding of the CPU caches and needs an explicit flush.

  Jocke
>
> >
> > I noticed that fcc_enet_start_xmit() does not flush the transmit data before
> > setting up the transmit buffer descriptor. I get the impression that this is
> > not necessary. But I don't understand why. I have spent the morning looking
> > through code and Motorola docs and am non the wiser.
>
> That's because the 8260 CPU understand the CPU caches and, while the 8xx does not
> and therefore needs a flush_dcache_range().
>
>     Jocke
>
> >
> > Thanks
> > Dean
>
>
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Malek | 1 Nov 2002 18:33

Re: dc* (Data Cache) instructions in mem*() and *_page() functions not used on 8xx


Joakim Tjernlund wrote:

> Dan, could you add the missing code for 8xx to detect the exception conditions when
> the cache instructions faulted? I would like to give it a try.

It's not very high on my list of things to do.  As I recall, the VM fault
handler may need knowledge of a dcbz fault and use a different method to
determine the address.  I also have this funny feeling that it isn't a
restartable operation, so we may have to emulate the instruction when
the fault occurs.

I know you can write a test that would show this to be a performance
benefit, which would just copy/zero lots of data, but that's not a real
world application.

IMHO, it's lots of work for little, if any, gain.  It has some specific
uses in specialized applications, but I don't think it's a general speed up
solution.

 > Maybe add a new CONFIG option to allow 8xx to use these optimizations when
> explicitly enabled.

How would you know when to do this?  It seldom appeared in any errata
so you couldn't know for certain if a particular chip version would
allow this.  I suspect people (like I have chosen to do) will just never
use the optimization because the software will always work in this case.
I don't like solutions that depend on luck or trial and error.

I'll do some research into this again, it's been many years since I
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nethorse | 1 Nov 2002 10:11
Picon
Favicon

telnetd problem in ELDK


Hi all,

    My MPC860 board boot from nfs, and the filesystem is from ELDK. But when
I try to telnet to it, it fails. I have turned on telnetd in xinetd.d.

    Telnet client print "telnetd: All network ports in use. Connection to
host lost" and exit.

who can help me?Thanks in advance!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Permalink | Reply | 0 comments |
headers
Brian Kuschak | 1 Nov 2002 20:13
Picon
Favicon

4xx watchdog handling


Regarding the way 2.4.19 handles the 4xx watchdog:

The 4xx timer interrupt, the PIT, is the lowest
priority exception (18). All the external IRQs come in
at a higher priority (16).  This is opposite of x86,
where the timer ISR is highest priority (0).

This would seem to negate the effectiveness of drivers
which implement "work limits" in their ISRs (like many
ethernet drivers).  These drivers do an RFI after
doing a certain amount of work, leaving the interrupt
pending and returning later to finish up.  In the case
of 4xx, a pending PIT interrupt would not be serviced
due to its lower priority.  In the case of heavy IRQ
load, the watchdog can expire.

Has anyone considered implementing the 4xx watchdog
interrupt itself as the place to refresh the watchdog?
 We could still use the existing method of a heartbeat
counter decremented each time, but just do the
refreshing in a watchdog ISR rather than the timer
ISR.  This way the watchdog could be reliably
refreshed even during heavy IRQ loads.

Any comments?

-Brian

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
(Continue reading)

Permalink | Reply | 0 comments |

Gmane