* Re: Attempt at addressing head*.S for modpost warnings
From: Kumar Gala @ 2007-07-31 4:29 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070731115047.8b88cb78.sfr@canb.auug.org.au>
On Jul 30, 2007, at 8:50 PM, Stephen Rothwell wrote:
> Hi Kumar,
>
> [sorry for the slow reply]
>
> On Wed, 25 Jul 2007 01:49:04 -0500 (CDT) Kumar Gala
> <galak@kernel.crashing.org> wrote:
>>
>> Paul said you were looking into this issue as well. Wanted to
>> post what I
>> did on ppc32/e500 as a start for you to look at. I think the
>> other ppc32
>> head*.S can follow the same pattern if we like this. However,
>> wasn't sure
>> how to do _ENTRY() for ppc64.
>
> What I have done so far is to put some peices of the asm code into
> the .text.init.refok section (see the _INIT_STATIC macro in asm/
> ppc_asm.h
> in the current kernel). I was hoping to separate some of the asm
> into a
> new file (init_64.S) that would contain this and other code in
> the .init.text section. That is currently not working (ld crashed on
> me :-)).
>
> Even if you create a .text.head, you will need to teach modpost
> about it.
Modpost is already aware of .text.head. Its used on x86 and a few
other archs today.
- k
^ permalink raw reply
* Re: ml403 ac97 driver
From: Qin Lin @ 2007-07-31 4:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11859770.post@talk.nabble.com>
HI ALL
I have compile the driver and test it with the help of Joachim.
1.add the lm4550 driver to kernel source
(someboby may can add them as a patch to kernel source)
#cp -r ml403_ac97cr $(KERNEL)/sound/drivers/
#vi $(KERNEL)/sound/drivers/Makefile
=add=
obj-$(CONFIG_SND_ML403_AC97) +=ml403_ac97cr/
#vi $(KERNEL)/sound/drivers/
=add=
config SND_ML403_AC97
tristate "ml403 ac97 codec(LM4550)"
depends on SND
select SND_AC97_CODEC
help
ml403 ac97 codec added by Joachim
enjoy it !
#vi $(KERNEL)/sound/drivers/ml403_ac97cr/Makefile
obj-$(CONFIG_SND_ML403_AC97) += ml403_ac97cr.o
#make xconfig
you can see the ml403_ac97cr in SOUND ALSA
2.cross-compile alsa-lib
I use ELDK4.0 to install cross compile in XILINX ML403.
$echo $CROSS_COMPILE
ppc_4xx-
$export CC=${CROSS_COMPILE}gcc
$export CPP=${CROSS_COMPILE}cpp
$export CXX=${CROSS_COMPILE}g++
$export LDD=${CROSS_COMPILE}ldd
$export AR=${CROSS_COMPILE}ar
$export LD=${CROSS_COMPILE}ld
$export RANLIB=${CROSS_COMPILE}ranlib
$export STRIP=${CROSS_COMPILE}strip
$cd ${ALSA-LIB-SOURCE}
$./configure --host=ppc-4xx-linux --target=ppc --prefix=/usr
$make install DESTDIR=${ALSA}
ps:ALSA lib will be install in path ${ALSA}/usr.Here use prefix=/usr is
important,do not change to another
path. Otherwise in the target board alsa will not find the config file by
default.You can use DESTDIR to set the lib path .
3.cross-compile alsa-utils
$export CC=${CROSS_COMPILE}gcc
$export CPP=${CROSS_COMPILE}cpp
$export CXX=${CROSS_COMPILE}g++
$export LDD=${CROSS_COMPILE}ldd
$export AR=${CROSS_COMPILE}ar
$export LD=${CROSS_COMPILE}ld
$export RANLIB=${CROSS_COMPILE}ranlib
$export STRIP=${CROSS_COMPILE}strip
$export CFLAGS="-I${ALSA}/usr/include -L${ALSA}/usr/lib"
$cd ${ALSA-UTILS-SOURCE}
$./configure --host=ppc-4xx-linux --target=ppc --prefix=/usr --disable-nls
$make install DESTDIR=${ALSA}
ps:use --disable-nls,otherwise there is an error about LC_ALL not defined.
3.copy the ${ALSA}/usr/* to the target rootfile /usr/ ,so you can use the
alsa utils.
4.insmod the drive module and create device node ,use
#aplay music.wav
to test the drive.
--
View this message in context: http://www.nabble.com/Re%3A-ml403-ac97-driver-tf4164866.html#a11918008
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Leonid Grossman @ 2007-07-31 3:58 UTC (permalink / raw)
To: Andrew Gallatin, Linas Vepstas
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, Christoph Raisch, linux-ppc, Jan-Bernd Themann,
Marcus Eder, Stefan Roscher, David Miller
In-Reply-To: <46AE232F.3080409@myri.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Andrew Gallatin
> Sent: Monday, July 30, 2007 10:43 AM
> To: Linas Vepstas
> Cc: Jan-Bernd Themann; netdev; Thomas Klein; Jeff Garzik; Jan-Bernd
> Themann; linux-kernel; linux-ppc; Christoph Raisch; Marcus Eder;
Stefan
> Roscher; David Miller
> Subject: Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for
> TCP traffic
>=20
>=20
> Here is a quick reply before something more official can
> be written up:
>=20
> Linas Vepstas wrote:
>=20
> > -- what is LRO?
>=20
> Large Receive Offload
>=20
> > -- Basic principles of operation?
>=20
> LRO is analogous to a receive side version of TSO. The NIC (or
> driver) merges several consecutive segments from the same connection,
> fixing up checksums, etc. Rather than up to 45 separate 1500 byte
> frames (meaning up to 45 trips through the network stack), the driver
> merges them into one 65212 byte frame. It currently works only
> with TCP over IPv4.
>=20
> LRO was, AFAIK, first though of by Neterion. They had a paper about
> it at OLS2005.
> http://www.linuxinsight.com/files/ols2005/grossman-reprint.pdf
>=20
> > -- Can I use it in my driver?
>=20
> Yes, it can be used in any driver.
>=20
> > -- Does my hardware have to have some special feature before I can
> use it?
>=20
> No.
Ditto. LRO hw assists (or full LRO offload, meaning that the merge
happens in the ASIC but the merge criteria are set by the host) are
quite beneficial, especially as the number of LRO connections gets very
large (Neterion has IP around fw/hw LRO and will release full hw LRO
offload in the next ASIC), but as Andrew indicated sw-only LRO
implementation can be done for any NIC and provides good results -
especially for non-jumbo workloads.=20
>=20
> > -- What sort of performance improvement does it provide?
Throughput?
> > Latency? CPU usage? How does it affect DMA allocation? Does it
> > improve only a certain type of traffic (large/small packets,
> etc.)
>=20
> The benefit is directly proportional to the packet rate.
>=20
> See my reply to the previous RFC for performance information. The
> executive summary is that for the myri10ge 10GbE driver on low end
> hardware with 1500b frames, I've seen it increase throughput by a
> factor of nearly 2.5x, while at the same time reducing CPU utilization
> by 17%. The affect for jumbo frames is less dramatic, but still
> impressive (1.10x, 14% CPU reduction)
>=20
> You can achieve better speedups if your driver receives into
> high-order pages.
>=20
> > -- Example code? What's the API? How should my driver use it?
>=20
> The 3/4 in this patch showed an example of converting a driver
> to use LRO for skb based receive buffers. I'm working on
> a patch for myri10ge that shows how you would use it in a driver
> which receives into pages.
>=20
> Cheers,
>=20
> Drew
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [patch][0/5] powerpc V2 : Add support to fully comply with IEEE-754 standard
From: Zhu Ebony-r57400 @ 2007-07-31 3:36 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, paulus
In-Reply-To: <46ADFC36.5060709@ru.mvista.com>
Hi Sergei,
I did some further tests and some development work in past several
months,
but due to project schedule and limited bandwidth, no patches can be
submitted
to the list by now. Anyway, I will keep you and the community updated
once there
is some progress.
Thanks.
B.R.
Ebony
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com]=20
> Sent: Monday, July 30, 2007 10:57 PM
> To: Zhu Ebony-r57400
> Cc: Kumar Gala; linuxppc-dev@ozlabs.org; paulus@samba.org
> Subject: Re: [patch][0/5] powerpc V2 : Add support to fully=20
> comply with IEEE-754 standard
>=20
> Hello.
>=20
> Zhu Ebony-r57400 wrote:
>=20
> >>>>>>Did you end up getting testfloat running? I'd like to see some=20
> >>>>>>testing results before accepting these patches. I=20
> think estfloat=20
> >>>>>>is our best bet at this point.
>=20
> >>>>>Hi Kumar,
>=20
> >>>>>I looked into the testfloat suit, and found all the=20
> instructions it=20
> >>>>>tests (more than 50)should be implemented based on ASM.
>=20
> >>>>Don't follow? Can't you build it with the e500 compiler?
>=20
> >>>The TestFloat suite provided the target of 386-Win32-gcc and=20
> >>>SPARC-Solaris-gcc only, and a template for user to porting his own=20
> >>>processor. Some general instructions are implemented in C,=20
> but some=20
> >>>CPU specific instructions like evfsmul need to be implemented=20
> >>>assemblely. To build it with e500 compiler we still Have=20
> some porting=20
> >>>work to do.
>=20
> >>I wouldn't worry too much about the vector forms. If the scalar=20
> >>single fp and double fp test out ok the vectors are pretty much=20
> >>similar enough.
>=20
> >>Lets just get the scalar versions tested and work out any issues=20
> >>there.
>=20
> > OK, I will focus on scalar SFPF and DPFP versions first.
>=20
> Any progress with this patchset?
>=20
> WBR, Sergei
>=20
^ permalink raw reply
* Re: Attempt at addressing head*.S for modpost warnings
From: Stephen Rothwell @ 2007-07-31 1:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0707250147150.9086@blarg.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 948 bytes --]
Hi Kumar,
[sorry for the slow reply]
On Wed, 25 Jul 2007 01:49:04 -0500 (CDT) Kumar Gala <galak@kernel.crashing.org> wrote:
>
> Paul said you were looking into this issue as well. Wanted to post what I
> did on ppc32/e500 as a start for you to look at. I think the other ppc32
> head*.S can follow the same pattern if we like this. However, wasn't sure
> how to do _ENTRY() for ppc64.
What I have done so far is to put some peices of the asm code into
the .text.init.refok section (see the _INIT_STATIC macro in asm/ppc_asm.h
in the current kernel). I was hoping to separate some of the asm into a
new file (init_64.S) that would contain this and other code in
the .init.text section. That is currently not working (ld crashed on
me :-)).
Even if you create a .text.head, you will need to teach modpost about it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Jeff Garzik @ 2007-07-31 0:00 UTC (permalink / raw)
To: David Miller
Cc: tklein, themann, netdev, linux-kernel, raisch, linuxppc-dev,
ossthema, meder, gallatin, stefan.roscher
In-Reply-To: <20070730.154332.72713181.davem@davemloft.net>
David Miller wrote:
> From: Jeff Garzik <jeff@garzik.org>
> Date: Mon, 30 Jul 2007 12:17:58 -0400
>
>> David, thoughts on merging? I'm not We could stick this into your tree
>> or mine. Whether yours or mine, I would like to keep the driver and
>> net-core patches together in the same git tree.
>
> No objections and I'll stick it into my net-2.6.24 tree once I cut
> that, I'll have the NAPI stuff in there too so I'll keep these two
> merge nightmares out of your hair :-)
Works for me.
Thanks,
Jeff
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Dave Jiang @ 2007-07-30 22:58 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, bluesmoke-devel, norsk5
In-Reply-To: <20070730214404.GE4884@austin.ibm.com>
Linas Vepstas wrote:
> On Mon, Jul 30, 2007 at 01:17:40PM -0700, Dave Jiang wrote:
>> Arnd Bergmann wrote:
>>> The best solution may be to look at how it's structured at the
>>> register level. If the PCI EDAC registers are implemented separately
>>> from the regular PCI registers, a device tree entry would be appropriate.
>>> If not, your idea of registering a platform_device from fsl_add_bridge
>>> is probably more sensible.
>>>
>> We can probably do either. From looking at the 8560 and 8548 manuals, the PCI
>> error registers are 0xe00 offset of the start of PCI registers. For example,
>> the PCI registers would start at 0x8000 offset. And the PCI error registers
>> would be at 0xe00 offset from there and would be the very last block of
>> registers.
>
> Anywhere I can easily get an overview of these "PCI error registers"?
http://www.freescale.com/files/32bit/doc/ref_manual/MPC8548ERM.pdf?fsrch=1
Page 966. Section 16.3.1.4.
Is this what you mean?
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Doug Thompson @ 2007-07-30 22:47 UTC (permalink / raw)
To: Linas Vepstas, Dave Jiang
Cc: linuxppc-dev, norsk5, Arnd Bergmann, bluesmoke-devel
In-Reply-To: <20070730214404.GE4884@austin.ibm.com>
--- Linas Vepstas <linas@austin.ibm.com> wrote:
> On Mon, Jul 30, 2007 at 01:17:40PM -0700, Dave Jiang wrote:
> > Arnd Bergmann wrote:
> > > The best solution may be to look at how it's structured at the
> > > register level. If the PCI EDAC registers are implemented separately
> > > from the regular PCI registers, a device tree entry would be appropriate.
> > > If not, your idea of registering a platform_device from fsl_add_bridge
> > > is probably more sensible.
> > >
> >
> > We can probably do either. From looking at the 8560 and 8548 manuals, the PCI
> > error registers are 0xe00 offset of the start of PCI registers. For example,
> > the PCI registers would start at 0x8000 offset. And the PCI error registers
> > would be at 0xe00 offset from there and would be the very last block of
> > registers.
>
> Anywhere I can easily get an overview of these "PCI error registers"?
>
> Also: please note that the linux kernel has a pci error recovery
> mechanism built in; its used by pseries and PCI-E. I'm not clear
> on what any of this has to do with EDAC, which I thought was supposed
> to be for RAM only. (The EDAC project once talked about doing pci error
> recovery, but that was years ago, and there is a separate system for
> that, now.)
no, edac can/does harvest PCI bus errors, via polling and other hardware error detectors.
The pci error recovery added a couple of NEW device callback functions in the driver interface,
which the bus layer can call to notify drivers that a PCI bus error occurred. Then the driver can
do some action on the event.
But at the current time, few PCI device drivers initialize those callback functions and
thus errors are lost and some IO transactions fail.
Over time, as drivers get updated (might take some time) then drivers
can take some sort of action FOR THEMSELVES
Yet, there is no tracking of errors - except for a log message in the log file.
There is NO meter on frequency of errors, etc. One must grep the log file and that is not a very
cycle friendly mechanism.
The reason I added PCI parity/error device scanning, was that when I was at Linux Networx, we had
parity errors on the PCI-X bus, but didn't know the cause. After we discovered that a simple
PCI-X riser card had manufacturing problems (quality) and didn't drive lines properly, it caused
parity errors. This feature allowed us to track nodes that were having parity problems, but we had
no METER to know it.
Recovery is a good thing, BUT how do you know you having LOTS of errors/recovery events? You need
a meter. EDAC provides that METER
I met with Yanmin Zhang of Intel at OLS after his paper presentation on PCI Express Advanced Error
Reporting in the Kernel, and we talked about this same thing. I am talking with him on having the
recovery code present information into EDAC sysfs area. (hopefully, anyway)
The recovery generates log messages BUT having to periodically 'grep' the log file looking for
errors is not a good use of CPU cycles. grep once for a count and then grep later for a count and
then compare the counts for a delta count per unit time. ugly.
The EDAC solution is to be able to have a Listener thread in user space that can be notified (via
poll()) that an event has occurred.
There are more than one consumer (error recover) of error events:
1) driver recovery after a transaction (which is the recovery consumer above)
2) Management agents for health of a node
3) Maintainance agents for predictive component replacement
Rates of change of errors can be gathered as well.
EDAC allows for presentation of error counts via sysfs entries, from which user space
programs can harvest for over-time profiling
We have MEMORY (edac_mc) devices for chipsets now, but via the new edac_device class, such things
as ECC error tracking on DMA error checkers, FABRIC switchs, L1 and L2 cache ECC events, core CPU
data ECC checkers, etc can be done. I have an out of kernel tree MIPS driver do just this. Other
types of harvesters can be generated as well for other and/or new hardware error detectors.
doug thompson
>
> --linas
>
>
>
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: David Miller @ 2007-07-30 22:43 UTC (permalink / raw)
To: jeff
Cc: tklein, themann, netdev, linux-kernel, raisch, linuxppc-dev,
ossthema, meder, gallatin, stefan.roscher
In-Reply-To: <46AE0F36.8030605@garzik.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Mon, 30 Jul 2007 12:17:58 -0400
> David, thoughts on merging? I'm not We could stick this into your tree
> or mine. Whether yours or mine, I would like to keep the driver and
> net-core patches together in the same git tree.
No objections and I'll stick it into my net-2.6.24 tree once I cut
that, I'll have the NAPI stuff in there too so I'll keep these two
merge nightmares out of your hair :-)
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Linas Vepstas @ 2007-07-30 21:44 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, norsk5, Arnd Bergmann, bluesmoke-devel
In-Reply-To: <46AE4764.7020101@mvista.com>
On Mon, Jul 30, 2007 at 01:17:40PM -0700, Dave Jiang wrote:
> Arnd Bergmann wrote:
> > The best solution may be to look at how it's structured at the
> > register level. If the PCI EDAC registers are implemented separately
> > from the regular PCI registers, a device tree entry would be appropriate.
> > If not, your idea of registering a platform_device from fsl_add_bridge
> > is probably more sensible.
> >
>
> We can probably do either. From looking at the 8560 and 8548 manuals, the PCI
> error registers are 0xe00 offset of the start of PCI registers. For example,
> the PCI registers would start at 0x8000 offset. And the PCI error registers
> would be at 0xe00 offset from there and would be the very last block of
> registers.
Anywhere I can easily get an overview of these "PCI error registers"?
Also: please note that the linux kernel has a pci error recovery
mechanism built in; its used by pseries and PCI-E. I'm not clear
on what any of this has to do with EDAC, which I thought was supposed
to be for RAM only. (The EDAC project once talked about doing pci error
recovery, but that was years ago, and there is a separate system for
that, now.)
--linas
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin @ 2007-07-30 20:32 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Stefan Roscher, David Miller
In-Reply-To: <200707301724.33865.ossthema@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]
Jan-Bernd Themann wrote:
> Hi,
>
> this patch set contains the latest generic LRO code, a Kconfig / Makefile
> and an eHEA patch demonstrating how the "aggregate SKB" interface has to
> to be used.
> Drew, could you provide a patch for the myri10ge driver to show how the
> "receive in page" interface works?
Hi,
Thank you for the many fixes, and especially for the counters!
I was working on testing the myri10ge patch, and I ran into a few
problems. I've attached a patch to inet_lro.c to fix some of them,
and a patch to myri10ge.c to show how to use the page based
interface. Both patches are signed off by Andrew Gallatin
<gallatin@myri.com>
First, the LRO_MAX_PG_HLEN is still a problem. Minimally sized 60
byte frames still cause problems in lro_gen_skb due to skb->len
going negative. Fixed in the attached patch. It may be simpler
to just drop LRO_MAX_PG_HLEN to ETH_ZLEN, but I'm not sure if
that is enough. Are there "smart" NICs which might chop off padding
themselves?
Second, you still need to set skb->ip_summed = CHECKSUM_UNNECESSARY
when modified packets are flushed, else the stack will see bad
checksums for packets from CHECKSUM_COMPLETE drivers using the
skb interface. Fixed in the attached patch.
Third, for some reason I have yet to figure out, this version of the
patch takes a while to "ramp up", but only when the receiver MTU
is 9000 and the sender MTU is 1500. If the receiver MTU is also
1500, even a 10 second netperf easily shows line rate. I don't
see this with our LRO, and I'm so far at a loss to explain it.
Here is the first 3 seconds of output from a simple program
which diffs the interface counters once / sec.
Ipkts IBytes Opkts Obytes
rx MTU=9000:
0 0 0 0
72 99092 14 1102
105 158970 7 420
750324 1135987084 17804 1068240
814427 1233042478 18529 1111740
<....>
rx MTU=1500
0 0 0 0
441344 668180168 13132 788182
815938 1235328656 18716 1122960
817698 1237994772 18628 1117680
<.....>
Once it has ramped up, the bandwidth is fine, and there
doesn't seem to be much difference between setting the
receiver MTU to 1500 or 9000. But it takes a very long
netperf run to overcome the ramp up period.
Fourth, I did some traffic sniffing to try to figure out what's going
on above, and saw tcpdump complain about bad checksums. Have you tried
running tcpdump -s 65535 -vvv? Have you also seen bad checksums?
I seem to see this for both page- and skb-based versions of the driver.
Last, the pointer to the TCP header in __lro_proc_segment() in the
unaccelerated vlan hdr case needs to also be offset by vlan_hdr_len
from skb->data. I've fixed this in the attached patch.
Thanks,
Drew
[-- Attachment #2: inet_lro.diff --]
[-- Type: text/plain, Size: 665 bytes --]
--- linux-2.6.23-rc1.orig/net/ipv4/inet_lro.c 2007-07-30 13:10:49.000000000 -0400
+++ linux-2.6.23-rc1/net/ipv4/inet_lro.c 2007-07-30 15:17:51.000000000 -0400
@@ -126,6 +126,7 @@ static void lro_update_tcp_ip_header(str
htons(lro_desc->ip_tot_len) -
IP_HDR_LEN(iph), IPPROTO_TCP,
lro_desc->data_csum);
+ lro_desc->parent->ip_summed = CHECKSUM_UNNECESSARY;
}
static __wsum lro_tcp_data_csum(struct iphdr *iph, struct tcphdr *tcph, int len)
@@ -396,6 +397,9 @@ static struct sk_buff *lro_gen_skb(struc
if (!skb)
return NULL;
+ if (hlen > len)
+ hlen = len;
+
skb->len = len;
skb->data_len = len - hlen;
skb->truesize += true_size;
[-- Attachment #3: myri10ge_lro.diff --]
[-- Type: text/plain, Size: 6221 bytes --]
diff -urp a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
--- a/drivers/net/myri10ge/myri10ge.c 2007-07-24 15:57:12.000000000 -0400
+++ b/drivers/net/myri10ge/myri10ge.c 2007-07-30 16:12:06.000000000 -0400
@@ -48,6 +48,7 @@
#include <linux/etherdevice.h>
#include <linux/if_ether.h>
#include <linux/if_vlan.h>
+#include <linux/inet_lro.h>
#include <linux/ip.h>
#include <linux/inet.h>
#include <linux/in.h>
@@ -62,6 +63,8 @@
#include <linux/io.h>
#include <linux/log2.h>
#include <net/checksum.h>
+#include <net/ip.h>
+#include <net/tcp.h>
#include <asm/byteorder.h>
#include <asm/io.h>
#include <asm/processor.h>
@@ -89,6 +92,7 @@ MODULE_LICENSE("Dual BSD/GPL");
#define MYRI10GE_EEPROM_STRINGS_SIZE 256
#define MYRI10GE_MAX_SEND_DESC_TSO ((65536 / 2048) * 2)
+#define MYRI10GE_MAX_LRO_DESCRIPTORS 8
#define MYRI10GE_NO_CONFIRM_DATA htonl(0xffffffff)
#define MYRI10GE_NO_RESPONSE_RESULT 0xffffffff
@@ -151,6 +155,8 @@ struct myri10ge_rx_done {
dma_addr_t bus;
int cnt;
int idx;
+ struct net_lro_mgr lro_mgr;
+ struct net_lro_desc lro_desc[MYRI10GE_MAX_LRO_DESCRIPTORS];
};
struct myri10ge_priv {
@@ -276,6 +282,14 @@ static int myri10ge_debug = -1; /* defau
module_param(myri10ge_debug, int, 0);
MODULE_PARM_DESC(myri10ge_debug, "Debug level (0=none,...,16=all)");
+static int myri10ge_lro = 1;
+module_param(myri10ge_lro, int, S_IRUGO);
+MODULE_PARM_DESC(myri10ge_lro, "Enable large receive offload\n");
+
+static int myri10ge_lro_max_pkts = MYRI10GE_LRO_MAX_PKTS;
+module_param(myri10ge_lro_max_pkts, int, S_IRUGO);
+MODULE_PARM_DESC(myri10ge_lro, "Number of LRO packets to be aggregated\n");
+
static int myri10ge_fill_thresh = 256;
module_param(myri10ge_fill_thresh, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(myri10ge_fill_thresh, "Number of empty rx slots allowed\n");
@@ -1019,6 +1033,16 @@ myri10ge_rx_done(struct myri10ge_priv *m
remainder -= MYRI10GE_ALLOC_SIZE;
}
+ if (mgp->csum_flag && myri10ge_lro) {
+ rx_frags[0].page_offset += MXGEFW_PAD;
+ rx_frags[0].size -= MXGEFW_PAD;
+ len -= MXGEFW_PAD;
+ lro_receive_frags(&mgp->rx_done.lro_mgr, rx_frags,
+ len, bytes,
+ (void *)(unsigned long)csum, csum);
+ return 1;
+ }
+
hlen = MYRI10GE_HLEN > len ? len : MYRI10GE_HLEN;
/* allocate an skb to attach the page(s) to. */
@@ -1137,6 +1161,9 @@ static inline void myri10ge_clean_rx_don
mgp->stats.rx_packets += rx_packets;
mgp->stats.rx_bytes += rx_bytes;
+ if (myri10ge_lro)
+ lro_flush_all(&rx_done->lro_mgr);
+
/* restock receive rings if needed */
if (mgp->rx_small.fill_cnt - mgp->rx_small.cnt < myri10ge_fill_thresh)
myri10ge_alloc_rx_pages(mgp, &mgp->rx_small,
@@ -1378,7 +1405,8 @@ static const char myri10ge_gstrings_stat
"dropped_pause", "dropped_bad_phy", "dropped_bad_crc32",
"dropped_unicast_filtered", "dropped_multicast_filtered",
"dropped_runt", "dropped_overrun", "dropped_no_small_buffer",
- "dropped_no_big_buffer"
+ "dropped_no_big_buffer", "LRO aggregated", "LRO flushed",
+ "LRO avg aggr", "LRO no_desc"
};
#define MYRI10GE_NET_STATS_LEN 21
@@ -1444,6 +1472,14 @@ myri10ge_get_ethtool_stats(struct net_de
data[i++] = (unsigned int)ntohl(mgp->fw_stats->dropped_overrun);
data[i++] = (unsigned int)ntohl(mgp->fw_stats->dropped_no_small_buffer);
data[i++] = (unsigned int)ntohl(mgp->fw_stats->dropped_no_big_buffer);
+ data[i++] = mgp->rx_done.lro_mgr.stats.aggregated;
+ data[i++] = mgp->rx_done.lro_mgr.stats.flushed;
+ if (mgp->rx_done.lro_mgr.stats.flushed)
+ data[i++] = mgp->rx_done.lro_mgr.stats.aggregated /
+ mgp->rx_done.lro_mgr.stats.flushed;
+ else
+ data[i++] = 0;
+ data[i++] = mgp->rx_done.lro_mgr.stats.no_desc;
}
static void myri10ge_set_msglevel(struct net_device *netdev, u32 value)
@@ -1717,10 +1753,69 @@ static void myri10ge_free_irq(struct myr
pci_disable_msi(pdev);
}
+static int
+myri10ge_get_frag_header(struct skb_frag_struct *frag, void **mac_hdr,
+ void **ip_hdr, void **tcpudp_hdr,
+ u64 * hdr_flags, void *priv)
+{
+ struct ethhdr *eh;
+ struct vlan_ethhdr *veh;
+ struct iphdr *iph;
+ u8 *va = page_address(frag->page) + frag->page_offset;
+ unsigned long ll_hlen;
+ __wsum csum = (__wsum) (unsigned long)priv;
+
+ /* find the mac header, aborting if not IPv4 */
+
+ eh = (struct ethhdr *)va;
+ *mac_hdr = eh;
+ ll_hlen = ETH_HLEN;
+ if (eh->h_proto != htons(ETH_P_IP)) {
+ if (eh->h_proto == htons(ETH_P_8021Q)) {
+ veh = (struct vlan_ethhdr *)va;
+ if (veh->h_vlan_encapsulated_proto != htons(ETH_P_IP))
+ return -1;
+
+ ll_hlen += VLAN_HLEN;
+
+ /*
+ * HW checksum starts ETH_HLEN bytes into
+ * frame, so we must subtract off the VLAN
+ * header's checksum before csum can be used
+ */
+ csum = csum_sub(csum, csum_partial(va + ETH_HLEN,
+ VLAN_HLEN, 0));
+ } else {
+ return -1;
+ }
+ }
+ *hdr_flags = LRO_IPV4;
+
+ iph = (struct iphdr *)(va + ll_hlen);
+ *ip_hdr = iph;
+ if (iph->protocol != IPPROTO_TCP)
+ return -1;
+ *hdr_flags |= LRO_TCP;
+ *tcpudp_hdr = (u8 *) (*ip_hdr) + (iph->ihl << 2);
+
+ /* verify the IP checksum */
+ if (unlikely(ip_fast_csum((u8 *) iph, iph->ihl)))
+ return -1;
+
+ /* verify the checksum */
+ if (unlikely(csum_tcpudp_magic(iph->saddr, iph->daddr,
+ ntohs(iph->tot_len) - (iph->ihl << 2),
+ IPPROTO_TCP, csum)))
+ return -1;
+
+ return 0;
+}
+
static int myri10ge_open(struct net_device *dev)
{
struct myri10ge_priv *mgp;
struct myri10ge_cmd cmd;
+ struct net_lro_mgr *lro_mgr;
int status, big_pow2;
mgp = netdev_priv(dev);
@@ -1852,6 +1947,17 @@ static int myri10ge_open(struct net_devi
mgp->link_state = htonl(~0U);
mgp->rdma_tags_available = 15;
+ lro_mgr = &mgp->rx_done.lro_mgr;
+ lro_mgr->dev = dev;
+ lro_mgr->features = LRO_F_NAPI;
+ lro_mgr->ip_summed = CHECKSUM_COMPLETE;
+ lro_mgr->max_desc = MYRI10GE_MAX_LRO_DESCRIPTORS;
+ lro_mgr->lro_arr = mgp->rx_done.lro_desc;
+ lro_mgr->get_frag_header = myri10ge_get_frag_header;
+ lro_mgr->max_aggr = myri10ge_lro_max_pkts;
+ if (lro_mgr->max_aggr > MAX_SKB_FRAGS)
+ lro_mgr->max_aggr = MAX_SKB_FRAGS;
+
netif_poll_enable(mgp->dev); /* must happen prior to any irq */
status = myri10ge_send_cmd(mgp, MXGEFW_CMD_ETHERNET_UP, &cmd, 0);
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Dave Jiang @ 2007-07-30 20:17 UTC (permalink / raw)
To: Arnd Bergmann, galak; +Cc: linuxppc-dev, bluesmoke-devel, norsk5
In-Reply-To: <200707302158.16530.arnd@arndb.de>
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>> Maybe we are just better off adding entries in the DTS to get around this
>> problem....
>
> The best solution may be to look at how it's structured at the
> register level. If the PCI EDAC registers are implemented separately
> from the regular PCI registers, a device tree entry would be appropriate.
> If not, your idea of registering a platform_device from fsl_add_bridge
> is probably more sensible.
>
We can probably do either. From looking at the 8560 and 8548 manuals, the PCI
error registers are 0xe00 offset of the start of PCI registers. For example,
the PCI registers would start at 0x8000 offset. And the PCI error registers
would be at 0xe00 offset from there and would be the very last block of
registers. Currently the PCI dts devices seem to claim 0x1000 for size. So the
way to have the least code changes would be to register a platform_device from
fsl_add_bridge() or where appropriate for the 85xx PCI code. Most likely the
83xx and 86xx will have similar code and maybe we can do some reuse out of this.
I can add dts entries instead and pick up of_devices if Kumar prefers it that
way instead....
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Stephen Hemminger @ 2007-07-30 19:57 UTC (permalink / raw)
To: Andrew Gallatin
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, Stefan Roscher,
netdev, linux-kernel, Christoph Raisch, linux-ppc,
Jan-Bernd Themann, Marcus Eder, David Miller
In-Reply-To: <46AE232F.3080409@myri.com>
Could someone add this to:
http://linux-net.osdl.org Wiki?
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Arnd Bergmann @ 2007-07-30 19:58 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, bluesmoke-devel, norsk5
In-Reply-To: <46AE3C06.5060100@mvista.com>
On Monday 30 July 2007, Dave Jiang wrote:
> I don't believe that EDAC core has been loaded at the time of 85xx PCI
> initialization. Plus, the EDAC driver can be loaded as a kernel module. So that
> probably won't work....
ok, good point.
> Also, instead of having centralized EDAC chip driver,
> now you have things scattered over various places. One probably needs to add
> 83xx and 86xx code as well and whatever else eventually.
>
> Maybe we are just better off adding entries in the DTS to get around this
> problem....
The best solution may be to look at how it's structured at the
register level. If the PCI EDAC registers are implemented separately
from the regular PCI registers, a device tree entry would be appropriate.
If not, your idea of registering a platform_device from fsl_add_bridge
is probably more sensible.
Arnd <><
^ permalink raw reply
* Re: [PATCH] gfar: Fix modpost warning
From: Jeff Garzik @ 2007-07-30 19:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0707260051550.30449@blarg.am.freescale.net>
Kumar Gala wrote:
> Fix the following modpost warning:
>
> WARNING: vmlinux.o(.init.text+0x1aa6c): Section mismatch: reference to .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/net/gianfar_mii.c | 2 +-
> drivers/net/gianfar_mii.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
applied
^ permalink raw reply
* 44x hardware watchpoints support
From: Rodrigo Rubira Branco @ 2007-07-30 19:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 199 bytes --]
--
Rodrigo Rubira Branco
Software Engineer
Advanced Linux Response Team (ALRT) / Linux on Power Toolchain
IBM Linux Technology Center (IBM/LTC)
rrbranco@br.ibm.com
GPG KeyID: 1FCEDEA1
[-- Attachment #1.2: mcp-ppc-hwwatchpoint-latest-27-07-07.diff --]
[-- Type: text/x-patch, Size: 11393 bytes --]
Attached a patch to add Linux PPC 44x Hardware Watchpoints. It's an updated version of the work done by Michel C. Darneille, also from IBM.
I need to redefine in include/asm-powerpc/reg_booke.h the values of DBCR_D1R and DBCR_D1W to 0x00080000 and 0x00040000. I can't put ifdef to be CONFIG_4xx since some values are not valid in the 405 systems for example (tks Josh Boyer for spot me that). What is the best way to do that?
Signed-off-by: Rodrigo Rubira Branco <rrbranco@br.ibm.com>
---
diff -ruN linux.orig/arch/powerpc/kernel/entry_32.S linux/arch/powerpc/kernel/entry_32.S
--- linux.orig/arch/powerpc/kernel/entry_32.S 2007-07-12 17:04:21.000000000 -0300
+++ linux/arch/powerpc/kernel/entry_32.S 2007-07-27 10:33:46.000000000 -0300
@@ -112,7 +112,7 @@
/* Check to see if the dbcr0 register is set up to debug. Use the
single-step bit to do this. */
lwz r12,THREAD_DBCR0(r12)
- andis. r12,r12,DBCR0_IC@h
+ andis. r12,r12,(DBCR0_IC | DBCR_D1R | DBCR_D1W)@h
beq+ 3f
/* From user and task is ptraced - load up global dbcr0 */
li r12,-1 /* clear all pending debug events */
@@ -238,10 +238,13 @@
stw r11,_CCR(r1)
syscall_exit_cont:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* If the process has its own DBCR0 value, load it up. The single
- step bit tells us that dbcr0 should be loaded. */
+ /*
+ * If the process has its own DBCR0 value, load it up. The single
+ * step bit tells us that dbcr0 should be loaded. GDB hw watchpoints
+ * may also be set
+ */
lwz r0,THREAD+THREAD_DBCR0(r2)
- andis. r10,r0,DBCR0_IC@h
+ andis. r10,r0,(DBCR0_IC | DBCR_D1R | DBCR_D1W)@h
bnel- load_dbcr0
#endif
stwcx. r0,0,r1 /* to clear the reservation */
@@ -646,10 +649,13 @@
restore_user:
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- /* Check whether this process has its own DBCR0 value. The single
- step bit tells us that dbcr0 should be loaded. */
+ /*
+ * Check whether this process has its own DBCR0 value. The single
+ * step bit tells us that dbcr0 should be loaded. GDB hw watchpoints
+ * may also be set
+ */
lwz r0,THREAD+THREAD_DBCR0(r2)
- andis. r10,r0,DBCR0_IC@h
+ andis. r10,r0,(DBCR0_IC | DBCR_D1R | DBCR_D1W)@h
bnel- load_dbcr0
#endif
diff -ruN linux.orig/arch/powerpc/kernel/process.c linux/arch/powerpc/kernel/process.c
--- linux.orig/arch/powerpc/kernel/process.c 2007-07-12 17:04:21.000000000 -0300
+++ linux/arch/powerpc/kernel/process.c 2007-07-27 10:14:04.000000000 -0300
@@ -197,6 +197,20 @@
}
#endif /* CONFIG_SPE */
+/* Add support for HW Debug breakpoint. Use DAC register */
+void set_dac(unsigned long dac)
+{
+ mtspr(SPRN_DAC1, dac);
+}
+unsigned int get_dac()
+{
+ return mfspr(SPRN_DAC1);
+}
+void set_dbcr0(unsigned long dbcr)
+{
+ mtspr(SPRN_DBCR0, dbcr);
+}
+
#ifndef CONFIG_SMP
/*
* If we are doing lazy switching of CPU state (FP, altivec or SPE),
@@ -308,6 +322,10 @@
__get_cpu_var(current_dabr) = new->thread.dabr;
}
+ /* If new thread dac (hw bp) is the same then leave it. */
+ if (new->thread.dac)
+ set_dac(new->thread.dac);
+
new_thread = &new->thread;
old_thread = ¤t->thread;
@@ -475,6 +493,13 @@
discard_lazy_cpu_state();
+ if (current->thread.dac) {
+ current->thread.dac = 0;
+ current->thread.dbcr0 &= ~(DBCR_D1R | DBCR_D1W); /* clear
+ debug control */
+ set_dac(0);
+ }
+
if (current->thread.dabr) {
current->thread.dabr = 0;
set_dabr(0);
diff -ruN linux.orig/arch/powerpc/kernel/ptrace.c linux/arch/powerpc/kernel/ptrace.c
--- linux.orig/arch/powerpc/kernel/ptrace.c 2007-07-12 17:04:21.000000000 -0300
+++ linux/arch/powerpc/kernel/ptrace.c 2007-07-27 10:37:03.000000000 -0300
@@ -273,11 +273,14 @@
static void clear_single_step(struct task_struct *task)
{
+ if (task->thread.dac) /* if dac then not single step, skip */
+ return;
+
struct pt_regs *regs = task->thread.regs;
if (regs != NULL) {
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
- task->thread.dbcr0 = 0;
+ task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_IDM);
regs->msr &= ~MSR_DE;
#else
regs->msr &= ~MSR_SE;
@@ -286,22 +289,48 @@
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
+static int ptrace_get_debugreg(struct task_struct *task, unsigned long data)
+{
+ #ifdef CONFIG_PPC64
+ ret = put_user(child->thread.dabr,
+ (unsigned long __user *)data);
+ #else
+ ret = put_user(child->thread.dac,
+ (unsigned long __user *)data);
+ #endif
+
+ return ret;
+}
+
+int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
- /* We only support one DABR and no IABRS at the moment */
+ /* We only support one DAC and no IABRS at the moment */
if (addr > 0)
return -EINVAL;
- /* The bottom 3 bits are flags */
- if ((data & ~0x7UL) >= TASK_SIZE)
- return -EIO;
-
- /* Ensure translation is on */
- if (data && !(data & DABR_TRANSLATION))
- return -EIO;
+ task->thread.dac = data & ~0x3UL;
+
+ if (task->thread.dac == 0) {
+ task->thread.dbcr0 &= ~(DBCR_D1R | DBCR_D1W | DBCR_IDM);
+ task->thread.regs->msr &= ~MSR_DE;
+ return 0;
+ }
+
+ if (!(data & 0x3UL)) /* R or W must be set */
+ return -EINVAL;
+
+ /* Check data lsb for r/w flag: 1 = r 2 = w then mask lower 2 bits
+ keeping watchpoint addr aligned to 32 bits. */
+ task->thread.dbcr0 = DBCR_IDM;
+
+ if (data & 1)
+ task->thread.dbcr0 |= DBCR_D1R;
+ if (data & 2)
+ task->thread.dbcr0 |= DBCR_D1W;
+
+ task->thread.regs->msr |= MSR_DE;
- task->thread.dabr = data;
return 0;
}
@@ -503,11 +532,10 @@
case PTRACE_GET_DEBUGREG: {
ret = -EINVAL;
- /* We only support one DABR and no IABRS at the moment */
+ /* We only support one DAC at the moment */
if (addr > 0)
break;
- ret = put_user(child->thread.dabr,
- (unsigned long __user *)data);
+ ret = ptrace_get_debugreg(child, data);
break;
}
diff -ruN linux.orig/arch/powerpc/kernel/signal.c linux/arch/powerpc/kernel/signal.c
--- linux.orig/arch/powerpc/kernel/signal.c 2007-07-12 17:04:21.000000000 -0300
+++ linux/arch/powerpc/kernel/signal.c 2007-07-27 10:30:47.000000000 -0300
@@ -142,6 +142,16 @@
set_dabr(current->thread.dabr);
if (is32) {
+ /*
+ * Reenable the DAC before delivering the signal to
+ * user space. The DAC will have been cleared if it
+ * triggered inside the kernel.
+ */
+ if (current->thread.dac) {
+ set_dac(current->thread.dac);
+ set_dbcr0(current->thread.dbcr0);
+ }
+
if (ka.sa.sa_flags & SA_SIGINFO)
ret = handle_rt_signal32(signr, &ka, &info, oldset,
regs);
diff -ruN linux.orig/arch/powerpc/kernel/traps.c linux/arch/powerpc/kernel/traps.c
--- linux.orig/arch/powerpc/kernel/traps.c 2007-07-12 17:04:21.000000000 -0300
+++ linux/arch/powerpc/kernel/traps.c 2007-07-27 11:01:31.000000000 -0300
@@ -54,6 +54,10 @@
#endif
#include <asm/kexec.h>
+extern int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
+ unsigned long data);
+extern int get_dac();
+
#ifdef CONFIG_DEBUGGER
int (*__debugger)(struct pt_regs *regs);
int (*__debugger_ipi)(struct pt_regs *regs);
@@ -61,6 +65,7 @@
int (*__debugger_sstep)(struct pt_regs *regs);
int (*__debugger_iabr_match)(struct pt_regs *regs);
int (*__debugger_dabr_match)(struct pt_regs *regs);
+int (*__debugger_dac_match)(struct pt_regs *regs);
int (*__debugger_fault_handler)(struct pt_regs *regs);
EXPORT_SYMBOL(__debugger);
@@ -69,6 +74,7 @@
EXPORT_SYMBOL(__debugger_sstep);
EXPORT_SYMBOL(__debugger_iabr_match);
EXPORT_SYMBOL(__debugger_dabr_match);
+EXPORT_SYMBOL(__debugger_dac_match);
EXPORT_SYMBOL(__debugger_fault_handler);
#endif
@@ -242,6 +248,25 @@
}
#endif
+static void do_dac(struct pt_regs *regs, unsigned long address,
+ unsigned long error_code)
+{
+ siginfo_t info;
+
+ /* Clear the DAC and struct entries. One shot trigger */
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBCR_D1R | DBCR_D1W
+ | DBCR_IDM));
+ set_dac(0);
+ ptrace_set_debugreg(current, 0, 0);
+
+ /* Deliver the signal to userspace */
+ info.si_signo = SIGTRAP;
+ info.si_errno = 0;
+ info.si_code = TRAP_HWBKPT;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGTRAP, &info, current);
+}
+
/*
* I/O accesses can cause machine checks on powermacs.
* Check if the NIP corresponds to the address of a sync
@@ -978,6 +1003,20 @@
return;
}
_exception(SIGTRAP, regs, TRAP_TRACE, 0);
+ } else if (debug_status & (DBSR_DAC1R | DBSR_DAC1W)) {
+ regs->msr &= ~MSR_DE;
+ if (user_mode(regs)) {
+ current->thread.dbcr0 &= ~(DBCR_D1R | DBCR_D1W |
+ DBCR_IDM);
+ } else {
+ /* Disable dac interupts */
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) & ~(DBCR_D1R |
+ DBCR_D1W | DBCR_IDM));
+ /* Clear the dac event */
+ mtspr(SPRN_DBSR, (DBSR_DAC1R | DBSR_DAC1W));
+ }
+ /* Setup and send the trap to the handler */
+ do_dac(regs, get_dac(), debug_status);
}
}
#endif /* CONFIG_4xx || CONFIG_BOOKE */
diff -ruN linux.orig/include/asm-powerpc/processor.h linux/include/asm-powerpc/processor.h
--- linux.orig/include/asm-powerpc/processor.h 2007-07-12 17:04:56.000000000 -0300
+++ linux/include/asm-powerpc/processor.h 2007-07-27 10:47:34.000000000 -0300
@@ -129,6 +129,7 @@
#if defined(CONFIG_4xx) || defined (CONFIG_BOOKE)
unsigned long dbcr0; /* debug control register values */
unsigned long dbcr1;
+ unsigned long dac; /* Data Address Compare register */
#endif
double fpr[32]; /* Complete floating point set */
struct { /* fpr ... fpscr must be contiguous */
diff -ruN linux.orig/include/asm-powerpc/system.h linux/include/asm-powerpc/system.h
--- linux.orig/include/asm-powerpc/system.h 2007-07-12 17:04:56.000000000 -0300
+++ linux/include/asm-powerpc/system.h 2007-07-27 11:05:14.000000000 -0300
@@ -72,6 +72,7 @@
extern int (*__debugger_sstep)(struct pt_regs *regs);
extern int (*__debugger_iabr_match)(struct pt_regs *regs);
extern int (*__debugger_dabr_match)(struct pt_regs *regs);
+extern int (*__debugger_dac_match)(struct pt_regs *regs);
extern int (*__debugger_fault_handler)(struct pt_regs *regs);
#define DEBUGGER_BOILERPLATE(__NAME) \
@@ -88,6 +89,7 @@
DEBUGGER_BOILERPLATE(debugger_sstep)
DEBUGGER_BOILERPLATE(debugger_iabr_match)
DEBUGGER_BOILERPLATE(debugger_dabr_match)
+DEBUGGER_BOILERPLATE(debugger_dac_match)
DEBUGGER_BOILERPLATE(debugger_fault_handler)
#else
@@ -97,10 +99,13 @@
static inline int debugger_sstep(struct pt_regs *regs) { return 0; }
static inline int debugger_iabr_match(struct pt_regs *regs) { return 0; }
static inline int debugger_dabr_match(struct pt_regs *regs) { return 0; }
+static inline int debugger_dac_match(struct pt_regs *regs) { return 0; }
static inline int debugger_fault_handler(struct pt_regs *regs) { return 0; }
#endif
extern int set_dabr(unsigned long dabr);
+extern void set_dac(unsigned long dac);
+extern void set_dbcr0(unsigned long dbcr);
extern void print_backtrace(unsigned long *);
extern void show_regs(struct pt_regs * regs);
extern void flush_instruction_cache(void);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Dave Jiang @ 2007-07-30 19:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, bluesmoke-devel, norsk5
In-Reply-To: <200707302046.10010.arnd@arndb.de>
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>>> What about the other option I mentioned, handling the EDAC stuff from the
>>> fsl_add_bridge() function?
>> I'm not sure I follow your thought on this quite yet. Do you mean the setup of
>> either of_device or platform_device or do you mean the actual pci err driver?
>> I'm not understanding how doing the setup code in fsl_add_bridge() would allow
>> us to prevent the of_device being monopolized by the EDAC driver or the future
>> PCI code.... The EDAC driver still needs some sort of "device" to claim one way
>> or another right?
>
> What I meant is calling the edac_pci_alloc_ctl_info() function directly
> from fsl_add_bridge() where appropriate, with all the 85xx PCI EDAC
> code moved into fsl_pci.c.
I don't believe that EDAC core has been loaded at the time of 85xx PCI
initialization. Plus, the EDAC driver can be loaded as a kernel module. So that
probably won't work.... Also, instead of having centralized EDAC chip driver,
now you have things scattered over various places. One probably needs to add
83xx and 86xx code as well and whatever else eventually.
Maybe we are just better off adding entries in the DTS to get around this
problem....
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Arnd Bergmann @ 2007-07-30 18:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: norsk5, bluesmoke-devel
In-Reply-To: <46AE2487.7060103@mvista.com>
On Monday 30 July 2007, Dave Jiang wrote:
>
> > What about the other option I mentioned, handling the EDAC stuff from the
> > fsl_add_bridge() function?
>
> I'm not sure I follow your thought on this quite yet. Do you mean the setup of
> either of_device or platform_device or do you mean the actual pci err driver?
> I'm not understanding how doing the setup code in fsl_add_bridge() would allow
> us to prevent the of_device being monopolized by the EDAC driver or the future
> PCI code.... The EDAC driver still needs some sort of "device" to claim one way
> or another right?
What I meant is calling the edac_pci_alloc_ctl_info() function directly
from fsl_add_bridge() where appropriate, with all the 85xx PCI EDAC
code moved into fsl_pci.c.
Arnd <><
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin @ 2007-07-30 17:43 UTC (permalink / raw)
To: Linas Vepstas
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, Christoph Raisch, linux-ppc, Jan-Bernd Themann,
Marcus Eder, Stefan Roscher, David Miller
In-Reply-To: <20070730170038.GA4884@austin.ibm.com>
Here is a quick reply before something more official can
be written up:
Linas Vepstas wrote:
> -- what is LRO?
Large Receive Offload
> -- Basic principles of operation?
LRO is analogous to a receive side version of TSO. The NIC (or
driver) merges several consecutive segments from the same connection,
fixing up checksums, etc. Rather than up to 45 separate 1500 byte
frames (meaning up to 45 trips through the network stack), the driver
merges them into one 65212 byte frame. It currently works only
with TCP over IPv4.
LRO was, AFAIK, first though of by Neterion. They had a paper about
it at OLS2005.
http://www.linuxinsight.com/files/ols2005/grossman-reprint.pdf
> -- Can I use it in my driver?
Yes, it can be used in any driver.
> -- Does my hardware have to have some special feature before I can
use it?
No.
> -- What sort of performance improvement does it provide? Throughput?
> Latency? CPU usage? How does it affect DMA allocation? Does it
> improve only a certain type of traffic (large/small packets, etc.)
The benefit is directly proportional to the packet rate.
See my reply to the previous RFC for performance information. The
executive summary is that for the myri10ge 10GbE driver on low end
hardware with 1500b frames, I've seen it increase throughput by a
factor of nearly 2.5x, while at the same time reducing CPU utilization
by 17%. The affect for jumbo frames is less dramatic, but still
impressive (1.10x, 14% CPU reduction)
You can achieve better speedups if your driver receives into
high-order pages.
> -- Example code? What's the API? How should my driver use it?
The 3/4 in this patch showed an example of converting a driver
to use LRO for skb based receive buffers. I'm working on
a patch for myri10ge that shows how you would use it in a driver
which receives into pages.
Cheers,
Drew
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Dave Jiang @ 2007-07-30 17:48 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, norsk5, bluesmoke-devel
In-Reply-To: <200707301928.51253.arnd@arndb.de>
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>> Arnd Bergmann wrote:
>
>>> I'd suggest either to integrate EDAC into the 85xx specific PCI code,
>>> or to have an extra device in the device tree for this.
>> How about I create a platform device just for EDAC and leave the PCI of_device
>> to the 85xx PCI code? That would be a lot less modification than adding a
>> device for every PCI hose per DTS file.... Just a thought....
>
> Hmm, I can see your point about not having to change all the device trees,
> but if you really want to have a device for each of them, an of_device seems
> more natural to me than a platform_device.
>
> What about the other option I mentioned, handling the EDAC stuff from the
> fsl_add_bridge() function?
I'm not sure I follow your thought on this quite yet. Do you mean the setup of
either of_device or platform_device or do you mean the actual pci err driver?
I'm not understanding how doing the setup code in fsl_add_bridge() would allow
us to prevent the of_device being monopolized by the EDAC driver or the future
PCI code.... The EDAC driver still needs some sort of "device" to claim one way
or another right?
Of course I can go ahead and add the PCI err device in the DTS files for all
85xx if Kumar is okay with that idea....
--
------------------------------------------------------
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: MPC85xx EDAC device driver
From: Arnd Bergmann @ 2007-07-30 17:28 UTC (permalink / raw)
To: Dave Jiang; +Cc: linuxppc-dev, norsk5, bluesmoke-devel
In-Reply-To: <46AE146D.8010504@mvista.com>
On Monday 30 July 2007, Dave Jiang wrote:
> Arnd Bergmann wrote:
> > I'd suggest either to integrate EDAC into the 85xx specific PCI code,
> > or to have an extra device in the device tree for this.
>
> How about I create a platform device just for EDAC and leave the PCI of_device
> to the 85xx PCI code? That would be a lot less modification than adding a
> device for every PCI hose per DTS file.... Just a thought....
Hmm, I can see your point about not having to change all the device trees,
but if you really want to have a device for each of them, an of_device seems
more natural to me than a platform_device.
What about the other option I mentioned, handling the EDAC stuff from the
fsl_add_bridge() function?
> > The error handling could use some improvement here. In particular, you should
> > unregister the buses in the failure path, maybe you need to clean up other
> > parts as well.
>
> I think I want individual "devices" work even some may fail or be missing. For
> example, even if L2 fails to register, I still want to be able to get the
> memory controller to report errors. So I really don't want to unregister
> everything that initialized properly even though some failures exists. Maybe I
> need to clean it up a little bit.
In that case, you shouldn't return failure from the module_init() function,
because that will remove the module again, while leaving the drivers
registered.
Another option might be to have separate modules, or separate initcall()
statements if the code can not be modular.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/4][RFC] lro: Kconfig and Makefile
From: Kok, Auke @ 2007-07-30 17:00 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, Stefan Roscher, netdev,
linux-kernel, Christoph Raisch, linux-ppc, Jan-Bernd Themann,
Marcus Eder, Andrew Gallatin, Stephen Hemminger, David Miller
In-Reply-To: <46AE1383.3050305@garzik.org>
Jeff Garzik wrote:
> Stephen Hemminger wrote:
>> Why make this a user selectable option at all? Unless you want
>> to deal with out of tree drivers (not my problem), it should be hidden
>> to avoid having to explain an support it.
>
> In this case it's an optional library kernel module. That seems to be a
> common setup for library modules. We do the same with CONFIG_MII and
> drivers/net/mii.ko as well.
>
> Originally it was done purely in the Makefile, but that does not account
> for net drivers in sub-directories (or out of tree as you point out).
speaking of that, shouldn't there be a NETIF_F_LRO ?
Auke
^ permalink raw reply
* BUG: scheduling while atomic
From: Girish kathalagiri @ 2007-07-30 17:07 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]
Hi,
I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress
./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s
I get the following stack.But this does not happen with non rt kernel.
LR = 0xff51fcc
BUG: scheduling while atomic: stress/0x00000002/739, CPU#0
Call Trace:
[c04fbb80] [c0008650] show_stack+0x50/0x190 (unreliable)
[c04fbbb0] [c0016fc0] __schedule_bug+0x38/0x48
[c04fbbc0] [c01d4f7c] __schedule+0x3dc/0x450
[c04fbbf0] [c01d56c8] schedule+0x54/0xf0
[c04fbc00] [c01d6390] rt_spin_lock_slowlock+0x100/0x224
[c04fbc60] [c0052198] get_zone_pcp+0x30/0x58
[c04fbc80] [c0053078] free_hot_cold_page+0x114/0x1fc
[c04fbcb0] [c0056424] put_page+0x50/0x15c
[c04fbcd0] [c0069854] free_page_and_swap_cache+0x44/0x80
[c04fbce0] [c005d760] unmap_vmas+0x2e0/0x788
[c04fbd70] [c006292c] exit_mmap+0x74/0x108
[c04fbda0] [c001adc0] mmput+0x54/0xf0
[c04fbdc0] [c001ecfc] exit_mm+0xc0/0x124
[c04fbde0] [c001ffd0] do_exit+0x164/0x8bc
[c04fbe20] [c0020760] do_group_exit+0x38/0x90
[c04fbe40] [c002ba48] get_signal_to_deliver+0x2ac/0x3c0
[c04fbe70] [c000739c] do_signal+0x50/0x60c
[c04fbf40] [c000fec0] do_user_signal+0x74/0xc4
--- Exception: c00 at 0xfeab1dc
LR = 0xff51fcc
Thanks in advance
--
Regards,
Giri
[-- Attachment #2: Type: text/html, Size: 1395 bytes --]
^ permalink raw reply
* I2C interrupts on 8541
From: Charles Krinke @ 2007-07-30 16:51 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Mark Freedkin
In-Reply-To: <11816893411272-git-send-email-grant.likely@secretlab.ca>
I'm puzzled about how to setup interrupts for the second I2C interface
in an 8541. This is the CPM interface, the one with buffer descriptors.
I see mention of its I2CER/I2CMR registers, but am having trouble
figuring out how to enable and interrupt so that when the interface is
in slave mode and a packet is received, it will vector to an interrupt
service routine.
I am using Linux-2.7.17.11 and I know you-all have gone past this a bit,
but in the midst of a project, we are constrained to finish with the
kernel we started with.
A few pointers on enabling an interrupt from this interface would be
greatly appreciated.
Charles
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Linas Vepstas @ 2007-07-30 17:00 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Andrew Gallatin, Stefan Roscher, David Miller
In-Reply-To: <200707301724.33865.ossthema@de.ibm.com>
On Mon, Jul 30, 2007 at 05:24:33PM +0200, Jan-Bernd Themann wrote:
>
> Changes to http://www.spinics.net/lists/netdev/msg36912.html
>
> 1) A new field called "features" has been added to the net_lro_mgr struct.
> It is set by the driver to indicate:
> - LRO_F_NAPI: Use NAPI / netif_rx to pass packets to stack
>
> - LRO_F_EXTRACT_VLAN_ID: Set by driver if HW extracts VLAN IDs for VLAN
> packets but does not modify ETH protocol (ETH_P_8021Q)
>
> 2) Padded frames are not aggregated for now. Bug fixed
>
> 3) Correct header length now used. No minimal header length for aggregated
> packets used anymore.
>
> 4) Statistic counters were introduced. They are stored in a new struct in
> the net_lro_mgr. This has the advantage that no locking is required in
> cases where the driver uses multiple lro_mgrs for different receive queues.
> Thus we get the following statistics per lro_mgr / eth device:
> - Number of aggregated packets
> - Number of flushed packets
> - Number of times we run out of lro_desc.
>
> The ratio of "aggregated packets" and "flushed packets" give you an
> idea how well LRO is working.
I'd like to see an edited form of this, together with an introduction to
LRO, written up in the Documentation subdirectory.
As someone with some driver experience, but not on te bleeding edge,
some basc newbie questions pop into mind:
-- what is LRO?
-- Basic principles of operation?
-- Can I use it in my driver?
-- Does my hardware have to have some special feature before I can use it?
-- What sort of performance improvement does it provide? Throughput?
Latency? CPU usage? How does it affect DMA allocation? Does it
improve only a certain type of traffic (large/small packets, etc.)
-- Example code? What's the API? How should my driver use it?
Right now, I can maybe find answers by doing lots of googling. I'd like
to have some quick way of getting a grip on this.
--linas
^ 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