* Fwd: PPC beginner questions
From: Wade Maxfield @ 2006-08-21 16:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <45a1b53e0608210717r1ea48761hc733983bd02512fb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
Thanks! I'd already seen the #1 (#2) link in the FAQ and understood
that. I'm not doing this from userland, so I was assuming it did not apply,
although I was going to use it to play with in user space.
The #3 comes up as an error for me, the lists.linuxppc.org domain name
does not resolve. Several other links in the FAQ do not resolve properly.
One now points to a page that has paid links to other pages.
thanks again,
Wade
On 8/21/06, Fillod Stephane <stephane.fillod@thomson.net> wrote:
>
> Your question is a linuxppc-embedded FAQ. User-land access
>
> is documented in Denx's FAQ[1], and accessible through shorter URL[2].
>
> For more information, please follow this thread[3] (not ppc specific
> actually).
>
>
>
> [1]
> http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_AccessingPeripheralsFromUserSpace
>
> [2] http://tinyurl.com/6c7th
>
> [3] http://lists.linuxppc.org/linuxppc-embedded/200403/msg00059.html
>
>
>
> In kernel land, ioremap() is all you need.
>
>
>
> Don't forget to use the 'eieio' asm instruction if you want explicit I/O
> ordering.
>
>
>
> Regards,
>
> --
>
> Stephane
>
>
>
>
> ------------------------------
>
> *Envoyé :* lundi 21 août 2006 15:51
> *Objet :* PPC beginner questions
>
>
>
>
> I'm new to the PPC and I have a few questions. I have written a driver
> in the past for the X86 family, using i/o ports, but it was kernel 2.0 and
> i/o ports are not mmu handled.
> I've been looking through the archive and I am slowly growing more
> confused.
>
> We are using Xilinx with PPC built in.
>
> The PPC has a memory management unit. All of the IP we've added is
> mapped to physical addresses.
>
> 1. Can I access the memory the peripherasl are mapped to directly
> within the driver without going through functions?
> if NOT, then Do I use
> 1. ioremap(),
> 2. request_mem_region(),
> 3. request_region()
> 4. something else?
>
> 2. Are there any gotcha's with the ppc 405 that Xilinx uses that I
> should know about?
>
>
> thanks,
> wade
>
>
>
[-- Attachment #2: Type: text/html, Size: 6618 bytes --]
^ permalink raw reply
* Re: PPC beginner questions
From: Grant Likely @ 2006-08-21 16:24 UTC (permalink / raw)
To: Wade Maxfield; +Cc: linuxppc-embedded list
In-Reply-To: <45a1b53e0608210907k6acec26ag94b0621273109532@mail.gmail.com>
On 8/21/06, Wade Maxfield <wmaxfield@gmail.com> wrote:
> On 8/21/06, Grant Likely <grant.likely@secretlab.ca > wrote:
> > On 8/21/06, Wade Maxfield <wmaxfield@gmail.com > wrote:
> > > I'm assuming inb() outb(), inw() outw()?? I've been googling and have
> > > come up short with info that makes sense. It is almost all x86 centric.
> >
> > in_8, in_be16, in_be32, out_8, out_be16, out_be32 for big-endian
> > device registers
> > in_8, in_le16, in_le32, out_8, out_le16, out_le32 for little endian
> > device registers
>
>
> -->Interesting. Do these functions do 'eieio' (Email, Internet, Electronic
> Information Officer functions (southpark cartoon), err, or Enforce In-Order
> Execution of Input/Output) for me, or do I have to do that? I'm still
> confused as to that Old MacDonald function.
The in functions do isync
The out functions do eieio
> >
> > heh, yes you can; but if your writing new code why not use good
> > practice from the start? :)
>
>
> --> Ok, you win. How about ioread8() or inb() also? Are they not coded in
> PPC correctly? Or is the in_8() more modern?
read include/asm/io.h. All the IO routines are defined there.
read[bwl] and write[bwl] are just macros to in_* out_*, as are inb,
outb, etc.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/6] Sizing zones and holes in an architecture independent manner V9
From: Keith Mannthey @ 2006-08-21 18:52 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
linux-mm
In-Reply-To: <20060821134518.22179.46355.sendpatchset@skynet.skynet.ie>
On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
> This is V9 of the patchset to size zones and memory holes in an
> architecture-independent manner. It booted successfully on 5 different
> machines (arches were x86, x86_64, ppc64 and ia64) in a number of different
> configurations and successfully built a kernel. If it fails on any machine,
> booting with loglevel=8 and the console log should tell me what went wrong.
>
I am wondering why this new api didn't cleanup the pfn_to_nid code
path as well. Arches are left to still keep another set of
nid-start-end info around. We are sending info like
add_active_range(unsigned int nid, unsigned long start_pfn, unsigned
long end_pfn)
With this info making a common pnf_to_nid seems to be of intrest so we
don't have to keep redundant information in both generic and arch
specific data structures.
Are you intending the hot-add memory code path to call add_active_range or ???
Thanks,
Keith
^ permalink raw reply
* [PATCH] Fix FEC node in 8540 ADS dts
From: Andy Fleming @ 2006-08-21 19:29 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev, galak
* Fixed the FEC node, and its accompanying PHY
* Fixed a spacing issue in the PIC node
---
arch/powerpc/boot/dts/mpc8540ads.dts | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
index 93d2c2d..5f41c1f 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -83,11 +83,11 @@
reg = <1>;
device_type = "ethernet-phy";
};
- ethernet-phy@2 {
- linux,phandle = <2452002>;
+ ethernet-phy@3 {
+ linux,phandle = <2452003>;
interrupt-parent = <40000>;
interrupts = <37 1>;
- reg = <2>;
+ reg = <3>;
device_type = "ethernet-phy";
};
};
@@ -124,14 +124,14 @@
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
- model = "TSEC";
+ model = "FEC";
compatible = "gianfar";
reg = <26000 1000>;
address = [ 00 E0 0C 00 73 02 ];
local-mac-address = [ 00 E0 0C 00 73 02 ];
interrupts = <19 2>;
interrupt-parent = <40000>;
- phy-handle = <2452002>;
+ phy-handle = <2452003>;
};
serial@4500 {
@@ -251,7 +251,7 @@
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
- big-endian;
+ big-endian;
};
};
};
--
2006_06_07.01.gittree_pull-dirty
^ permalink raw reply related
* Re: [PATCH] Fix FEC node in 8540 ADS dts
From: Hollis Blanchard @ 2006-08-21 19:39 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.61.0608211427330.12614@ld0175-tx32.am.freescale.net>
On Mon, 2006-08-21 at 14:29 -0500, Andy Fleming wrote:
>
> diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
> b/arch/powerpc/boot/dts/mpc8540ads.dts
> index 93d2c2d..5f41c1f 100644
> --- a/arch/powerpc/boot/dts/mpc8540ads.dts
> +++ b/arch/powerpc/boot/dts/mpc8540ads.dts
> @@ -83,11 +83,11 @@
> reg = <1>;
> device_type = "ethernet-phy";
> };
> - ethernet-phy@2 {
> - linux,phandle = <2452002>;
> + ethernet-phy@3 {
> + linux,phandle = <2452003>;
Again, doesn't DTC assign linux,phandle properties as needed (i.e. when
the node is referenced with & syntax)?
-Hollis
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Will Schmidt @ 2006-08-21 20:09 UTC (permalink / raw)
To: segher; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <37280.84.105.60.119.1156030372.squirrel@gate.crashing.org>
On Sat, 2006-19-08 at 18:32 -0500, segher@gate.crashing.org wrote:
> >> > Is that the right check? The other similar traps check against a
> >> mask of 0x7c0007fe.
> >>
> So we have a bug here; could you take care of it please
> Arnd?
I'm not Arnd :-) , but since I'm poking at it anyways,.. how about
this?
In an attempt to make it easier for a power5 optimized app to run on a
power4 or a 970 or random earlier machine, this provides emulation of
the popcntb instruction.
This version incorporates the suggestions from Arnd, Kumar and Segher;
including using a better MASK for popcntb, updating the existing masks
to include the msb for the instruction primary opcode.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2105767..caba187 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -575,19 +575,22 @@ #define INST_MFSPR_PVR 0x7c1f42a6
#define INST_MFSPR_PVR_MASK 0xfc1fffff
#define INST_DCBA 0x7c0005ec
-#define INST_DCBA_MASK 0x7c0007fe
+#define INST_DCBA_MASK 0xfc0007fe
#define INST_MCRXR 0x7c000400
-#define INST_MCRXR_MASK 0x7c0007fe
+#define INST_MCRXR_MASK 0xfc0007fe
#define INST_STRING 0x7c00042a
-#define INST_STRING_MASK 0x7c0007fe
-#define INST_STRING_GEN_MASK 0x7c00067e
+#define INST_STRING_MASK 0xfc0007fe
+#define INST_STRING_GEN_MASK 0xfc00067e
#define INST_LSWI 0x7c0004aa
#define INST_LSWX 0x7c00042a
#define INST_STSWI 0x7c0005aa
#define INST_STSWX 0x7c00052a
+#define INST_POPCNTB 0x7c0000f4
+#define INST_POPCNTB_MASK 0xfc0007fe
+
static int emulate_string_inst(struct pt_regs *regs, u32 instword)
{
u8 rT = (instword >> 21) & 0x1f;
@@ -656,6 +659,23 @@ static int emulate_string_inst(struct pt
return 0;
}
+static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
+{
+ u32 ra,rs;
+ u64 tmp;
+
+ ra = (instword >> 16) & 0x1f;
+ rs = (instword >> 21) & 0x1f;
+
+ tmp = regs->gpr[rs];
+ tmp = tmp - ((tmp >> 1) & 0x5555555555555555);
+ tmp = (tmp & 0x3333333333333333) + ((tmp >> 2) & 0x3333333333333333);
+ tmp = (tmp + (tmp >> 4)) & 0x0f0f0f0f0f0f0f0f;
+ regs->gpr[ra] = tmp;
+
+ return 0;
+}
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -693,6 +713,11 @@ static int emulate_instruction(struct pt
if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
return emulate_string_inst(regs, instword);
+ /* Emulate the popcntb (Population Count Bytes) instruction. */
+ if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ return emulate_popcntb_inst(regs, instword);
+ }
+
return -EINVAL;
}
^ permalink raw reply related
* Re: [PATCH] Fix FEC node in 8540 ADS dts
From: Andy Fleming @ 2006-08-21 20:15 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1156189170.11326.56.camel@basalt.austin.ibm.com>
On Aug 21, 2006, at 14:39, Hollis Blanchard wrote:
> On Mon, 2006-08-21 at 14:29 -0500, Andy Fleming wrote:
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
>> b/arch/powerpc/boot/dts/mpc8540ads.dts
>> index 93d2c2d..5f41c1f 100644
>> --- a/arch/powerpc/boot/dts/mpc8540ads.dts
>> +++ b/arch/powerpc/boot/dts/mpc8540ads.dts
>> @@ -83,11 +83,11 @@
>> reg = <1>;
>> device_type = "ethernet-phy";
>> };
>> - ethernet-phy@2 {
>> - linux,phandle = <2452002>;
>> + ethernet-phy@3 {
>> + linux,phandle = <2452003>;
>
> Again, doesn't DTC assign linux,phandle properties as needed (i.e.
> when
> the node is referenced with & syntax)?
That's what I hear. I think this would be a good place for using
that, but I'm waiting for someone to determine whether some sort of
labeling system is going to be added, first. As it doesn't require
changes to u-boot or linux, it's an easy fix for a later time.
I will, of course, accede to popular opinion. But I'd rather change
all the phandles in exactly the same way, and I feel that the
notation gets clunky when seen iterated in a table (as shown in Jon's
patch for that change).
Andy
^ permalink raw reply
* Re: [PATCH] Add adder87x board support to 2.6.x
From: Mark A. Greer @ 2006-08-21 20:43 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-embedded
In-Reply-To: <20060820203649.4dbf89a6@localhost.localdomain>
On Sun, Aug 20, 2006 at 08:36:49PM +0100, Bryan O'Donoghue wrote:
> Greetings all.
>
> This set of patches adds support for the Analogue & Micro Adder87x to Linux.
>
> The port is based on mpc885ads in the 2.6.18-rc4 tree.
> The patches are very simple really consisting of a stripped down version of
> mpc885ads renamed to adder87x*blah, a defconfig and appropriate entries in
> arch/ppc/Kconfig, arch/ppc/platforms/Makefile and include/asm-ppc/mpc8xx.h.
>
> I've spent a bit of time testing this out, and I'm reasonably happy that this
> should be useful to others using this development board.
>
>
> Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
Bryan,
If you're not already on the linuxppc-dev mailing list, you should be.
The 'ppc' tree is deprecated and all new work should be happening in the
'powerpc' tree (as in arch/powerpc).
The odds of this being accepted are slim but either way, you should read
the mail archive and get involved in the powerpc migration.
Mark
^ permalink raw reply
* NAPI documentation
From: Stephen Hemminger @ 2006-08-21 20:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, Jonathan Corbet, linux-kernel,
linuxppc-dev, Jens Osterkamp, Linas, Jeff Garzik, David Miller
In-Reply-To: <200608201948.20596.arnd@arndb.de>
I took this opportunity to get a start on improving NAPI documentation.
I mashed together the short text about NAPI (with permission) from lwn.net
and the existing NAPI-HOWTO, to make a page on the Linux net wiki.
I took the liberty of removing some of the bits that were out of date, or referred
to old Becker code. It still needs lots of editing to be presentable.
Please edit and improve
http://linux-net.osdl.org/index.php/NAPI
When the page is in good shape, I will de-wiki it to place in kernel doc tree.
^ permalink raw reply
* RE: Linux hanging on Xilinx SystemACE
From: Clint Thomas @ 2006-08-21 20:45 UTC (permalink / raw)
To: Keith J Outwater, linuxppc-embedded
In-Reply-To: <OF66C0423D.E933F8BD-ON072571CC.0077CC69-072571CC.007906BE@mck.us.ray.com>
The adapter.c file fixed the problem, however running in polling I/O
mode is far too slow. Since this is not an option for successful
operation of our machine, do you know of a driver fix for this problem?
Perhaps a newer version of the linux source tree is necessary. I'm using
the Linuxppc_2_4_devel tree available from bkbits/mvista. Thanks for the
help so far!
Clint Thomas
-----Original Message-----
From: linuxppc-embedded-bounces+cthomas=3Dsoneticom.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+cthomas=3Dsoneticom.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Wednesday, August 16, 2006 6:02 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Linux hanging on Xilinx SystemACE
Clint,
> Using the powerpc development tree of Linux 2.4, I am trying to boot=20
> my
system from CompactFlash using Xilinx SystemACE. My compact flash card
has two partitions, a 16MB FAT16 that holds the combination FPGA image /
Linux Kernel ELF file, and an Ext2 partition that holds the root file
system.=20
The system starts the boot process, uncompresses the Linux kernel and
begins loading drivers. Part way into this process, it conducts a
partition check of the drive being reported to it by SystemACE, however,
it hangs at that point. No kernel panic, no error message, it simply
hangs. Here is the output at that point...
>=20
> Partition check:
> xsysacea:
>=20
> what I am trying to find out is if this problem has been seen/fixed in
the past? or did I format the CF card incorrectly?
>=20
I have a system that uses the SystemAce in a similar way. I was also
having lockups. After a lot of digging, I found a patch by John Masters
(e-mail unknown) to the MontaVista SystemAce driver in the 2.4 kernel
that disables the use of interrupts and runs the SystemAce in a polled
mode.=20
Performance is not that great, but at least it does not crash with the
patch. As I recall, the reason that the unpatched driver crashed is
that the SystemAce is issuing more than one interrupt upon completion of
a sector read or write. Apparently, the Xilinx ML300 board works fine
without this patch while other eval boards like the Memec DS-BD-2VPxx
crash without the patch.
This still may not be your problem, but the patch may help later on.
I've attached the patched file. The file is from
./drivers/block/xilinx_sysace/adapter.c in the 2.4.30 from MontaVista.
Keith
^ permalink raw reply
* RE: Linux hanging on Xilinx SystemACE
From: Keith J Outwater @ 2006-08-21 21:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952918DE10@bluefin.Soneticom.local>
> The adapter.c file fixed the problem, however running in polling I/O
> mode is far too slow. Since this is not an option for successful
> operation of our machine, do you know of a driver fix for this problem?
> Perhaps a newer version of the linux source tree is necessary. I'm using
> the Linuxppc_2_4_devel tree available from bkbits/mvista. Thanks for the
> help so far!
Sorry, I am not aware of any driver fix to make interrupt mode work.
Unfortunately, the use of the SystemACE under Linux for access to CF
file systems appears to be a niche application, so it does not receive
a lot of attention.
I recall someone on the net stating that they had observed the SystemAce
issuing more than one interrupt in response to sector transfers. The
SystemACE is a strange beast (as you may have already observed!) and
perhaps it is being configured in hardware or software differently in your
design versus the Xilinx ML300 design.
For my particular application, I used the CF card to hold a root
filesystem image that was placed in RAM on boot, so I did not see a big
hit during operation. Basically, the mediocre performance of the driver
in polled mode was good enough for me. Maybe some day I'll return to that
problem, but right now other issues are more pressing. As I stated
originally, the SystemACE driver appears to work fine in interrupt
mode for ML300 boards, but dies with Memec eval boards. Perhaps you can
download the relevant designs for each board and compare them. If you
do this, be sure to check the schematics as well as the configuration
of the SystemACE and the interrupt controller IP blocks in the Xilinx EDK
tool. Maybe this will uncover something obvious. Also, if MontaVista
supports their kernel on the Memec board, they may have seen this problem
and maybe even have fixed it. I also used the mvista kernel and there is
support for a Memec board in there, although I don't know the exact part
number.
Keith
>
> Clint Thomas
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+cthomas=soneticom.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+cthomas=soneticom.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Wednesday, August 16, 2006 6:02 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux hanging on Xilinx SystemACE
>
> Clint,
>
> > Using the powerpc development tree of Linux 2.4, I am trying to boot
> > my
> system from CompactFlash using Xilinx SystemACE. My compact flash card
> has two partitions, a 16MB FAT16 that holds the combination FPGA image /
> Linux Kernel ELF file, and an Ext2 partition that holds the root file
> system.
> The system starts the boot process, uncompresses the Linux kernel and
> begins loading drivers. Part way into this process, it conducts a
> partition check of the drive being reported to it by SystemACE, however,
> it hangs at that point. No kernel panic, no error message, it simply
> hangs. Here is the output at that point...
> >
> > Partition check:
> > xsysacea:
> >
> > what I am trying to find out is if this problem has been seen/fixed in
> the past? or did I format the CF card incorrectly?
> >
>
> I have a system that uses the SystemAce in a similar way. I was also
> having lockups. After a lot of digging, I found a patch by John Masters
> (e-mail unknown) to the MontaVista SystemAce driver in the 2.4 kernel
> that disables the use of interrupts and runs the SystemAce in a polled
> mode.
> Performance is not that great, but at least it does not crash with the
> patch. As I recall, the reason that the unpatched driver crashed is
> that the SystemAce is issuing more than one interrupt upon completion of
> a sector read or write. Apparently, the Xilinx ML300 board works fine
> without this patch while other eval boards like the Memec DS-BD-2VPxx
> crash without the patch.
>
> This still may not be your problem, but the patch may help later on.
>
> I've attached the patched file. The file is from
> ./drivers/block/xilinx_sysace/adapter.c in the 2.4.30 from MontaVista.
>
> Keith
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Nathan Lynch @ 2006-08-21 21:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20060817204712.GD354@localdomain>
Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2006-08-16 at 19:18 -0500, Nathan Lynch wrote:
> >
> > > No? I didn't find anything about mftb having synchronizing
> > > behavior. How should we ensure that temp_varp is assigned before
> > > reading the timebase?
> >
> > I sync an isync would be enough.
>
> I see, thanks.
Actually, after checking Book 2 and discussing with some other folks
I'm not so sure -- isync "may complete before storage accesses
associated with instructions preceding the isync instruction have been
performed."
^ permalink raw reply
* ML403: module make fails with interesting error
From: Wade Maxfield @ 2006-08-21 21:28 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
I created an NFS disk using devrocket 2.03, copied the kernel image from a
devrocket build to the system.ace. I booted the ml403 board and did an nfs
mount. I copied the kernel directory created under the devrocket
2.03kernel project into /usr/src/linux
I created a simple module:
-----------------------------------------------------------------------------------------------------------------
root@ml403:/home/moduletest# cat moduletest.c
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
MODULE_DESCRIPTION("Test Kernel Module");
MODULE_AUTHOR("wade maxfield (maxfield@ctelcom.net)");
MODULE_LICENSE("$LICENSE$");
static int moduletest_init_module(void)
{
printk( KERN_DEBUG "Module moduletest init\nHello World!\n" );
return 0;
}
static void moduletest_exit_module(void)
{
printk( KERN_DEBUG "Module moduletest exit\nGoodbye Cruel World!\n"
);
}
module_init(moduletest_init_module);
module_exit(moduletest_exit_module);
---------------------------------------------------------------------------------------------------------------------------
This has compiled under RHEL 4.0 and worked.
if I go do a build on the ml403 board I get the following (ignore the
time problems)
----------------------------------------------------------------------------------------------------------------------
root@ml403:/home/moduletest# make
make: Warning: File `Makefile' has modification time 1.2e+09 s in the future
make -C /lib/modules/2.6.10_mvl401-ml40x/build SUBDIRS=/home/moduletest
modules
make[1]: Entering directory `/usr/src/linux'
Makefile:503: .config: No such file or directory
make[1]: Warning: File `/usr/src/linux/arch/ppc/Makefile' has modification
time 1.2e+09 s in the future
make[2]: Warning: File `scripts/Makefile.lib' has modification time
1.1e+09s in the future
CC [M] /home/moduletest/moduletest.o
/bin/sh: line 1: scripts/basic/fixdep: cannot execute binary file
make[2]: *** [/home/moduletest/moduletest.o] Error 126
make[1]: *** [_module_/home/moduletest] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [default] Error 2
----------------------------------------------------------------------------------------------------------
I think that "fixdep" was created as x86. Any suggestions as to getting
fixdep to be powerpc executable?
thanks,
wade
[-- Attachment #2: Type: text/html, Size: 2849 bytes --]
^ permalink raw reply
* Re: booting with BootX corrupts memory
From: Benjamin Herrenschmidt @ 2006-08-21 21:31 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Niels Kristian Bech Jensen
In-Reply-To: <20060821121708.GA28713@aepfle.de>
> > No, now I dont even get console= output on serial console.
>
> It doesnt work on a 7200, butit works on a beige G3.
> But later it locks up in 'PM: Adding info for No Bus:target0:0',
> after mesh init. This one is likely unrelated.
Depends.... does it work if you netboot a zImage.coff ?
Ben.
^ permalink raw reply
* ML40X, ppc 405 crash
From: Wade Maxfield @ 2006-08-21 21:34 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 6490 bytes --]
I was running NFS on ML40X. I did a "updatedb" and then immediately,
"locate fixdep"
I got the following crash
root@ml403:/home/moduletest# updatedb
locate fixdep
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01D0F74 LR: C01D0910 SP: C28B1930 REGS: c28b1880 TRAP: 0300 Not
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c0b034c0[5097] 'frcode' THREAD: c28b0000
Last syscall: 234
GPR00: 00000000 C28B1930 C0B034C0 C35E3200 C03CC380 C276E810 000005E8
C3CE8880
GPR08: 00000002 00000000 C3CE890C 00000000 33003599 10018E04 100C3208
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 0000000A C28B1DF8 C02E0000 C02A0000
C3A30940
GPR24: 00000000 00000000 00000000 C3A30940 00000000 C35E3200 C3CE8880
C03A8800
NIP [c01d0f74] pfifo_fast_dequeue+0x40/0x74
LR [c01d0910] qdisc_restart+0x30/0x2b4
Call trace:
[c01c1e94] dev_queue_xmit+0x264/0x318
[c01dd8dc] ip_finish_output+0x140/0x2cc
[c01dddb0] ip_queue_xmit+0x348/0x53c
[c01ef628] tcp_transmit_skb+0x324/0x7f8
[c01f05fc] tcp_write_xmit+0x14c/0x31c
[c01ed360] __tcp_data_snd_check+0xc8/0xfc
[c01ed9a4] tcp_rcv_established+0x2c0/0x8ac
[c01f7250] tcp_v4_do_rcv+0x184/0x374
[c01f7d9c] tcp_v4_rcv+0x95c/0xa4c
[c01da000] ip_local_deliver+0x120/0x298
[c01da86c] ip_rcv+0x400/0x508
[c01c2614] netif_receive_skb+0x24c/0x2fc
[c01c276c] process_backlog+0xa8/0x1a0
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
-----------------------------------------------------------------------------------------------------------------------------------------------------
Here is the kernel build and boot information. (I use the demo compact
flash disk image shipped with the ml403 as an intermediate. I've not yet
been able to get a small enough build to fit on 412 meg using your tools.)
Linux version 2.6.10_mvl401-ml40x (root@localhost.localdomain) (gcc version
3.4.3 (MontaV
ista 3.4.3-25.0.107.0601076 2006-07-21)) #1 Fri Aug 18 14:43:45 CDT 2006
Xilinx ML40x Reference System (Virtex-4 FX)
Port by MontaVista Software, Inc. (source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,115200 ip=on root=/dev/xsysace2 rw
Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
PID hash table entries: 512 (order: 9, 8192 bytes)
hr_time_init: arch_to_nsec = 6990506, nsec_to_arch = 1288490158
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 61824k available (2244k kernel code, 640k data, 140k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
Registering platform device 'xilinx_emac.0'. Parent at platform
Registering platform device 'xilinx_fb.0'. Parent at platform
Registering platform device 'xilinx_sysace.0'. Parent at platform
Registering platform device 'xilinx_iic.0'. Parent at platform
Registering platform device 'xilinx_gpio.0'. Parent at platform
Registering platform device 'xilinx_gpio.1'. Parent at platform
Registering platform device 'xilinx_gpio.2'. Parent at platform
Registering platform device 'xilinx_ps2.0'. Parent at platform
Registering platform device 'xilinx_ps2.1'. Parent at platform
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Console: switching to colour frame buffer device 80x30
xgpio #0 at 0x90000000 mapped to 0xC505C000
xgpio #1 at 0x90001000 mapped to 0xC505E000
xgpio #2 at 0x90002000 mapped to 0xC5060000
xilinx_ps2 #0 at 0xA9000000 mapped to 0xC5062000
xilinx_ps2 #1 at 0xA9001000 mapped to 0xC5064000
Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing disabled
Registering platform device 'serial8250'. Parent at platform
ttyS0 at MMIO 0x0 (irq = 9) is a 16450
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
elevator: using anticipatory as default io scheduler
System ACE at 0xCF000000 mapped to 0xC5066000, irq=3, 500472KB
xsysace: xsysace1 xsysace2
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
NET: Registered protocol family 24
xemac 0: using fifo mode.
eth0: Xilinx EMAC #0 at 0x60000000 mapped to 0xC5068000, irq=0
i2c /dev entries driver
xilinx_iic.0 #0 at 0xA8000000 mapped to 0xC506E000, irq=6
mice: PS/2 mouse device common for all mice
atkbd.c: keyboard reset failed on xilinxps2/serio0
atkbd.c: keyboard reset failed on xilinxps2/serio1
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 172.17.6.49
IP-Config: Complete:
device=eth0, addr=172.17.6.49, mask=255.255.254.0, gw=172.17.7.254,
host=172.17.6.49, domain=precisiondrilling.com, nis-domain=(none),
bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 140k init
INIT: version 2.78 booting
Activating swap...
Checking all file systems...
fsck 1.27 (8-Mar-2002)
Calculating module dependencies... depmod: QM_MODULES: Function not
implemented
done.
Loading modules:
modprobe: QM_MODULES: Function not implemented
Mounting local filesystems...
nothing was mounted
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Disable TCP/IP Explicit Congestion Notification: done.
Configuring network interfaces: done.
Starting portmap daemon: portmap.
Starting dhcpcd on eth0
Running ntpdate to synchronize clock.
Cleaning: /tmp /var/lock /var/rundhcpcd[775]: dhcpConfig: ioctl SIOCADDRT:
File exists
.
INIT: Entering runlevel: 3
Starting kernel log daemon: klogd.
Starting system log daemon: syslogd.
Hostname: ml403.
Creating barrier for shutdown
Starting X11 session for user 'linux'
Welcome to the ML403 Evaluation Board
(C) 2004 Xilinx, Inc - Systems Engineering Group
[-- Attachment #2: Type: text/html, Size: 7617 bytes --]
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Benjamin Herrenschmidt @ 2006-08-21 21:43 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20060821212555.GC9828@localdomain>
On Mon, 2006-08-21 at 16:25 -0500, Nathan Lynch wrote:
> Nathan Lynch wrote:
> > Benjamin Herrenschmidt wrote:
> > > On Wed, 2006-08-16 at 19:18 -0500, Nathan Lynch wrote:
> > >
> > > > No? I didn't find anything about mftb having synchronizing
> > > > behavior. How should we ensure that temp_varp is assigned before
> > > > reading the timebase?
> > >
> > > I sync an isync would be enough.
> >
> > I see, thanks.
>
> Actually, after checking Book 2 and discussing with some other folks
> I'm not so sure -- isync "may complete before storage accesses
> associated with instructions preceding the isync instruction have been
> performed."
Of sure, I was thinking about isync preventing mftb from being executed
and we can have a proper data dependency. Anyway, that's not necessary,
I've looked at the code and we no longer need to pass the tb value in
(it's historical). Thus we can just move the mftb in the protected area
and maybe with a twi/isync pair make sure we got the gtod pointer before
we do the mftb
Ben.
^ permalink raw reply
* ML403, ppc 405 crash
From: Wade Maxfield @ 2006-08-21 21:45 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
I tried it again. This time I put updatedb in background. I'm running an
nfs mount. I tried doing a make to get fixdep built while updatedb was
running in background:
bash-2.05b# eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
protocol 0800 is buggy, dev eth0
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01C2744 LR: C01C276C SP: C2E25C90 REGS: c2e25be0 TRAP: 0300 Not
tainted
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c2cf6170[1027] 'frcode' THREAD: c2e24000
Last syscall: 234
GPR00: 00021030 C2E25C90 C2CF6170 C3BF4480 C03CC380 C3190810 000005E8
C3CE8880
GPR08: 00000003 00000000 00000008 00000000 35005599 10018E04 100C3248
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 00000004 C2E25DF8 C02E0000 C02A0000
C2E25CC8
GPR24: 000254C8 C02ED728 C02ED750 00000040 00000000 C03A8800 00000001
C02ED734
NIP [c01c2744] process_backlog+0x80/0x1a0
LR [c01c276c] process_backlog+0xa8/0x1a0
Call trace:
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
[c001bfc4] __do_softirq+0x38/0x64
[c001c080] do_softirq+0x58/0x60
[c001c0fc] local_bh_enable+0x74/0x80
[c021f328] __rpc_execute+0x2c0/0x3d4
[c00dab38] nfs_execute_write+0x3c/0x60
[c00db084] nfs_flush_list+0x528/0x550
[c00db1b8] nfs_flush_inode+0x10c/0x120
[c00dbc44] nfs_sync_inode+0x54/0xb4
[c00d1660] nfs_file_flush+0x7c/0xf0
[c005bbbc] filp_close+0xa0/0xd8
[c00182f0] put_files_struct+0xb0/0x130
[c0018ab8] do_exit+0x1c0/0xda8
[c0019714] do_group_exit+0x38/0xf8
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
[-- Attachment #2: Type: text/html, Size: 1904 bytes --]
^ permalink raw reply
* Re: NAPI documentation
From: David Miller @ 2006-08-21 22:05 UTC (permalink / raw)
To: shemminger
Cc: akpm, arnd, netdev, jklewis, corbet, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik
In-Reply-To: <20060821134053.7225987b@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 21 Aug 2006 13:40:53 -0700
> Please edit and improve
> http://linux-net.osdl.org/index.php/NAPI
>
> When the page is in good shape, I will de-wiki it to place in kernel doc tree.
How do I edit the introduction paragraphs at the top? I want to edit
this sentence since it sounds awful:
NAPI ("New API") is a modification to the packet process, ...
I want to change "packet process" to something more descriptive
and accurate.
^ permalink raw reply
* Re: NAPI documentation
From: Stephen Hemminger @ 2006-08-21 22:09 UTC (permalink / raw)
To: David Miller
Cc: akpm, arnd, netdev, jklewis, corbet, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik
In-Reply-To: <20060821.150509.111198790.davem@davemloft.net>
On Mon, 21 Aug 2006 15:05:09 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Mon, 21 Aug 2006 13:40:53 -0700
>
> > Please edit and improve
> > http://linux-net.osdl.org/index.php/NAPI
> >
> > When the page is in good shape, I will de-wiki it to place in kernel doc tree.
>
> How do I edit the introduction paragraphs at the top?
Click edit on wiki and it is the first sentence.
> I want to edit
> this sentence since it sounds awful:
>
> NAPI ("New API") is a modification to the packet process, ...
>
> I want to change "packet process" to something more descriptive
> and accurate.
>
Yes.
Also, does Jamal have a link to his UKUUG paper?
--
Stephen Hemminger <shemminger@osdl.org>
All non-trivial abstractions, to some degree, are leaky.
^ permalink raw reply
* Re: NAPI documentation
From: David Miller @ 2006-08-21 22:17 UTC (permalink / raw)
To: shemminger
Cc: akpm, arnd, netdev, jklewis, corbet, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik
In-Reply-To: <20060821150935.0d59791b@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 21 Aug 2006 15:09:35 -0700
> Click edit on wiki and it is the first sentence.
Thanks a lot.
> Also, does Jamal have a link to his UKUUG paper?
I don't think there is a copy online right now.
^ permalink raw reply
* ML40x, ppc 405 crash
From: Wade Maxfield @ 2006-08-21 22:20 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]
I was trying to fix the problem with fixdep not being executable. I was
on the ml403, and have the kernel directory copied into /usr/src/linux and
/usr/src/linux-2.6.10_mvl401:
bash-2.05b# date
Thu Jan 1 00:28:20 UTC 1970
bash-2.05b# date --set "17:11 Aug 21,2006"
Mon Aug 21 17:11:00 UTC 2006
bash-2.05b# date
Mon Aug 21 17:11:03 UTC 2006
bash-2.05b# make clean
CLEAN drivers/char
CLEAN drivers/video/logo
CLEAN init
CLEAN kernel
CLEAN lib
CLEAN usr
CLEAN include/asm-ppc/offsets.h
arch/ppc/kernel/asm-offsets.s.tmp_gas_check vmlinux
System.map
bash-2.05b# make config
HOSTCC scripts/basic/fixdep
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01D0F74 LR: C01D0910 SP: C02ABAE0 REGS: c02aba30 TRAP: 0300 Not
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c0274710[0] 'swapper' THREAD: c02aa000
Last syscall: 120
GPR00: 00000000 C02ABAE0 C0274710 C3679BC0 C03CC380 C33D6010 000005E8
C3CE8880
GPR08: 00000002 00000000 C3CE890C 00000000 33003099 10018E04 100C3248
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 00000004 FFFFFFFF C02E0000 C02A0000
C3AEC540
GPR24: 00000000 00000000 00000000 C3AEC540 00000000 C3679BC0 C3CE8880
C03A8800
NIP [c01d0f74] pfifo_fast_dequeue+0x40/0x74
LR [c01d0910] qdisc_restart+0x30/0x2b4
Call trace:
[c01c1e94] dev_queue_xmit+0x264/0x318
[c01dd8dc] ip_finish_output+0x140/0x2cc
[c01dddb0] ip_queue_xmit+0x348/0x53c
[c01ef628] tcp_transmit_skb+0x324/0x7f8
[c01f05fc] tcp_write_xmit+0x14c/0x31c
[c01ed360] __tcp_data_snd_check+0xc8/0xfc
[c01ed9a4] tcp_rcv_established+0x2c0/0x8ac
[c01f7250] tcp_v4_do_rcv+0x184/0x374
[c01f7d9c] tcp_v4_rcv+0x95c/0xa4c
[c01da000] ip_local_deliver+0x120/0x298
[c01da86c] ip_rcv+0x400/0x508
[c01c2614] netif_receive_skb+0x24c/0x2fc
[c01c276c] process_backlog+0xa8/0x1a0
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
[-- Attachment #2: Type: text/html, Size: 2479 bytes --]
^ permalink raw reply
* [PATCH] windfarm_smu_sat.c: simplify around i2c_add_driver()
From: Alexey Dobriyan @ 2006-08-21 23:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/macintosh/windfarm_smu_sat.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -397,12 +397,7 @@ static int wf_sat_detach(struct i2c_clie
static int __init sat_sensors_init(void)
{
- int err;
-
- err = i2c_add_driver(&wf_sat_driver);
- if (err < 0)
- return err;
- return 0;
+ return i2c_add_driver(&wf_sat_driver);
}
static void __exit sat_sensors_exit(void)
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Linas Vepstas @ 2006-08-21 23:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller, Stephen Hemminger
In-Reply-To: <200608191325.19557.arnd@arndb.de>
On Sat, Aug 19, 2006 at 01:25:18PM +0200, Arnd Bergmann wrote:
>
> What is the best way to treat the IRQ mask for TX interrupts?
> I guess it should be roughly:
>
> - off when we expect ->poll() to be called, i.e. after calling
> netif_rx_schedule() or returning after a partial rx from poll().
Under what circumstance does one turn TX interrupts back on?
I couldn't quite figure that out.
--linas
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: David Miller @ 2006-08-21 23:56 UTC (permalink / raw)
To: linas
Cc: akpm, arnd, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik, shemminger
In-Reply-To: <20060821235244.GJ5427@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Mon, 21 Aug 2006 18:52:44 -0500
> Under what circumstance does one turn TX interrupts back on?
> I couldn't quite figure that out.
Don't touch interrupts until both RX and TX queue work is
fullydepleted. You seem to have this notion that RX and TX interrupts
are seperate. They aren't, even if your device can generate those
events individually. Whatever interrupt you get, you shut down all
interrupt sources and schedule the ->poll(). Then ->poll() does
something like:
all_tx_completion_work();
ret = as_much_rx_work_as_budget_and_quota_allows();
if (!ret)
reenable_interrupts_and_complet_napi_poll();
You always run the TX completion work fully, then you do the RX work
within the quota/budget.
See the tg3 driver for details, really...
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-22 0:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: arnd, netdev, jklewis, linux-kernel, linuxppc-dev, Jens.Osterkamp,
David Miller
In-Reply-To: <1155962022.5803.68.camel@localhost.localdomain>
On Sat, Aug 19, 2006 at 02:33:42PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-08-18 at 18:45 -0500, Linas Vepstas wrote:
> > On Fri, Aug 18, 2006 at 06:29:42PM -0500, linas wrote:
> > >
> > > I don't understand what you are saying. If I call the transmit
> > > queue cleanup code from the poll() routine, nothing hapens,
> > > because the kernel does not call the poll() routine often
> > > enough. I've stated this several times.
> >
> > OK, Arnd gave me a clue stick. I need to call the (misnamed)
> > netif_rx_schedule() from the tx interrupt in order to get
> > this to work. That makes sense, and its easy, I'll send the
> > revised patch.. well, not tonight, but shortly.
>
> You might not want to call it all the time though... You need some
> interrupt mitigation and thus a timer that calls netif_rx_schedule()
> might be of some use still...
Well, again, the whole point of a low-watermark interrupt is to
get zero of them when the system is working correctly; they're
self-mitigating by design.
-------------
Anyway, I tried the suggestion, but am getting less-than-ideal
results.
To recap: my original patch did this:
spider_interrupt_handler(struct whatever *) {
...
if (tx_interrupt)
schedule_work (tx_cleanup_handler)
}
which David Miller objected to. Once I understood the why
(sorry for not getting it right away), I then replaced the
above with the below, which is what I think everyone wanted:
spider_interrupt_handler(struct whatever *) {
...
if (tx_interrupt)
netif_rx_schedule(netdev);
}
spidernet_poll(stuct whatever *) {
tx_cleanup_handler(txring);
// rx_stuff too ...
}
I was expecting this to be a no-op from the performance
point of view. Instead, I get a fairly dramatic (11%) slowdown:
the first patch runs in the 785-805 Mbits/sec range, while
the second patch runs in the 705-715 Mbits/sec range.
I am surprised, ad don't understand why this would be so.
For the record, the alternate patch is below.
----
Index: linux-2.6.18-rc2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc2.orig/drivers/net/spider_net.c 2006-08-21 16:59:33.000000000 -0500
+++ linux-2.6.18-rc2/drivers/net/spider_net.c 2006-08-21 17:15:28.000000000 -0500
@@ -1087,6 +1090,8 @@ spider_net_poll(struct net_device *netde
int packets_to_do, packets_done = 0;
int no_more_packets = 0;
+ spider_net_cleanup_tx_ring(card);
+
packets_to_do = min(*budget, netdev->quota);
while (packets_to_do) {
@@ -1495,16 +1500,16 @@ spider_net_interrupt(int irq, void *ptr,
if (!status_reg)
return IRQ_NONE;
- if (status_reg & SPIDER_NET_RXINT ) {
+ if (status_reg & SPIDER_NET_RXINT) {
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
- if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
- }
- if (status_reg & SPIDER_NET_ERRINT )
+ /* Call rx_schedule from the tx interrupt, so that NAPI poll runs. */
+ if (status_reg & SPIDER_NET_TXINT)
+ netif_rx_schedule(netdev);
+
+ if (status_reg & SPIDER_NET_ERRINT)
spider_net_handle_error_irq(card, status_reg);
/* clear interrupt sources */
^ 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