* Re: [patch 3/3] Fix phy id for LXT971A/LXT972A
From: Jeff Garzik @ 2006-06-25 9:15 UTC (permalink / raw)
To: akpm; +Cc: netdev, Uwe_Zeisberger, afleming
In-Reply-To: <200606250844.k5P8ichl020797@shell0.pdx.osdl.net>
akpm@osdl.org wrote:
> From: Uwe Zeisberger <Uwe_Zeisberger@digi.com>
>
> The phy ids used are taken from an driver that used a right shift of 4 to chop
> off the revision number. This driver does not shift, so the id and mask
> values are wrong and must be left shifted by 4 to actually detect the chips.
>
> Signed-off-by: Uwe Zeisberger <Uwe_Zeisberger@digi.com>
> Acked-by: Andy Fleming <afleming@freescale.com>
>
> [akpm: this is a previously-nacked patch, but the problem is real]
> Signed-off-by: Andrew Morton <akpm@osdl.org>
This was nak'd? Does anyone recall why?
Jeff
^ permalink raw reply
* Re: [patch 1/2] tulip: fix for 64-bit mips
From: Martin Michlmayr @ 2006-06-25 9:31 UTC (permalink / raw)
To: akpm; +Cc: val_henson, jeff, netdev, maillist, grundler, pdh
In-Reply-To: <200606250845.k5P8j1Tt020829@shell0.pdx.osdl.net>
* akpm@osdl.org <akpm@osdl.org> [2006-06-25 01:45]:
> Cc: Valerie Henson <val_henson@linux.intel.com>
>
> [akpm: this is a previously-nacked patch, but the problem is real]
And, for the record, Jeff's suggestion as to how to rework the patch:
| Answer hasn't changed since this was last discussed: sleep, rather than
| delay for an extra-long time. That's the only hurdle for the tulip
| patches you keep resending.
| Francois Romieu even had an untested patch that attempted this,
| somewhere.
Now we just need someone to complete this work...
--
Martin Michlmayr
tbm@cyrius.com
^ permalink raw reply
* Re: [patch 3/3] Fix phy id for LXT971A/LXT972A
From: Andrew Morton @ 2006-06-25 9:44 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Uwe_Zeisberger, afleming
In-Reply-To: <449E5431.3020904@garzik.org>
On Sun, 25 Jun 2006 05:15:29 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> akpm@osdl.org wrote:
> > From: Uwe Zeisberger <Uwe_Zeisberger@digi.com>
> >
> > The phy ids used are taken from an driver that used a right shift of 4 to chop
> > off the revision number. This driver does not shift, so the id and mask
> > values are wrong and must be left shifted by 4 to actually detect the chips.
> >
> > Signed-off-by: Uwe Zeisberger <Uwe_Zeisberger@digi.com>
> > Acked-by: Andy Fleming <afleming@freescale.com>
> >
> > [akpm: this is a previously-nacked patch, but the problem is real]
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
>
> This was nak'd? Does anyone recall why?
>
No, it was not nacked - I'd simply misfiled it (actually, failed to refile
it after we got a changelog).
^ permalink raw reply
* Re: [patch 1/6] ppp_async hang fix
From: Paul Mackerras @ 2006-06-25 11:44 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev, xeb
In-Reply-To: <200606250847.k5P8lS0L020897@shell0.pdx.osdl.net>
akpm@osdl.org writes:
> From: <xeb@mail.ru>
>
> Adapted from http://bugzilla.kernel.org/show_bug.cgi?id=6530
>
> Reschedule the async Tx tasklet if the transmit queue was full.
>
> Cc: Paul Mackerras <paulus@samba.org>
>
> [akpm: submitted before, discussion petered off inconclusively]
NACK.
This "fix" is inefficient and also unnecessary now that I have found
and fixed the real problem, which was in n_tty.c.
Paul.
^ permalink raw reply
* Re: Streamline testing of 802.11 drivers
From: Johannes Berg @ 2006-06-25 12:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Larry Finger, netdev
In-Reply-To: <43e72e890606231556o57f1590fve91a98b5adfa5379@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Fri, 2006-06-23 at 18:56 -0400, Luis R. Rodriguez wrote:
> Thanks Larry -- I'm sorry for not mentioning in the original thread
> but basically miniPCI and USB is what we can slap onto our nodes so
> far. We'll have to figure something out for Cardbus.. I searched and
> it seems there some miniPCI bcm4306. I'll see if we can come up with a
> cardbus solution though as I'm sure there's gotta be some card which
> don't ship in other form factors. Will get back to you on that.
I'd say most cards come at least in USB or miniPCI as they are/were
mostly for use in laptops. bcm43xx certainly does, we still have some
funds that were donated so we could probably fund a few bcm43xx cards
for the testbed.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [patch 2/2] tulip: NatSemi DP83840A PHY fix
From: Thibaut VARENE @ 2006-06-25 13:22 UTC (permalink / raw)
To: akpm@osdl.org; +Cc: val_henson, jeff, netdev, grundler, jgarzik, kyle
In-Reply-To: <200606250845.k5P8j3GU020832@shell0.pdx.osdl.net>
On 6/25/06, akpm@osdl.org <akpm@osdl.org> wrote:
>
> From: Thibaut VARENE <T-Bone@parisc-linux.org>
>
> Fix a problem with Tulip 21142 HP branded PCI cards (PN#: B5509-66001),
> which feature a NatSemi DP83840A PHY.
>
> Without that patch, it is impossible to properly initialize the card's PHY,
> and it's thus impossible to monitor/configure it.
This patch can now be dropped. There's a better fix from Kyle McMartin
in our cvs, and Val should have gotten it already.
HTH
T-Bone
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
^ permalink raw reply
* Re: [patch 6/6] neighbour.c, pneigh_get_next() skips published entry
From: Herbert Xu @ 2006-06-25 14:47 UTC (permalink / raw)
To: akpm; +Cc: davem, netdev, akpm, Jari.Takkala
In-Reply-To: <200606250847.k5P8lXH2020912@shell0.pdx.osdl.net>
akpm@osdl.org wrote:
>
> [akpm: submitted before, discussion ended inconclusively, iirc]
> Signed-off-by: Andrew Morton <akpm@osdl.org>
I still need to try to reproduce this. I might be able to allocate some
time on this soon.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] skb_find_text ignores to argument
From: Phil Oester @ 2006-06-25 14:52 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
skb_find_text takes a "to" argument which is supposed to limit how
far into the skb it will search for the given text. At present,
it seems to ignore that argument on the first skb, and instead
return a match even if the text occurs beyond the limit.
Patch below fixes this, after adjusting for the "from" starting
point. This consequently fixes the netfilter string match's "--to"
handling, which currently is broken.
Phil
Signed-off-by: Phil Oester <kernel@linuxace.com>
[-- Attachment #2: patch-skbfindtext --]
[-- Type: text/plain, Size: 616 bytes --]
diff -ruN linux-orig/net/core/skbuff.c linux-new/net/core/skbuff.c
--- linux-orig/net/core/skbuff.c 2006-06-25 01:26:02.000000000 -0400
+++ linux-new/net/core/skbuff.c 2006-06-25 01:29:40.000000000 -0400
@@ -1739,12 +1739,15 @@
unsigned int to, struct ts_config *config,
struct ts_state *state)
{
+ unsigned int ret;
+
config->get_next_block = skb_ts_get_next_block;
config->finish = skb_ts_finish;
skb_prepare_seq_read(skb, from, to, TS_SKB_CB(state));
- return textsearch_find(config, state);
+ ret = textsearch_find(config, state);
+ return (ret <= to - from ? ret : UINT_MAX);
}
/**
^ permalink raw reply
* Re: Streamline testing of 802.11 drivers
From: Luis R. Rodriguez @ 2006-06-25 15:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, netdev
In-Reply-To: <1151239341.7608.63.camel@localhost>
On 6/25/06, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2006-06-23 at 18:56 -0400, Luis R. Rodriguez wrote:
>
> > Thanks Larry -- I'm sorry for not mentioning in the original thread
> > but basically miniPCI and USB is what we can slap onto our nodes so
> > far. We'll have to figure something out for Cardbus.. I searched and
> > it seems there some miniPCI bcm4306. I'll see if we can come up with a
> > cardbus solution though as I'm sure there's gotta be some card which
> > don't ship in other form factors. Will get back to you on that.
>
> I'd say most cards come at least in USB or miniPCI as they are/were
> mostly for use in laptops. bcm43xx certainly does, we still have some
> funds that were donated so we could probably fund a few bcm43xx cards
> for the testbed.
>
Excellent, will make arrangements with you off the list.
Luis
^ permalink raw reply
* 2.6.17-mm2: no QLA3YYY_NAPI help text
From: Adrian Bunk @ 2006-06-25 16:47 UTC (permalink / raw)
To: Andrew Morton, Ron Mercer
Cc: linux-kernel, Jeff Garzik, Stephen Hemminger, netdev
In-Reply-To: <20060624061914.202fbfb5.akpm@osdl.org>
[ resent with a subject adapted to vger mail filter... ]
On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm1:
>...
> +qla3xxx-NIC-driver.patch
>...
> Net driver updates. Includes a new driver from qlogic which almost compiles.
>...
The QLA3XXX_NAPI option lacks a help text.
Please add a help text.
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* -git: Why is drivers/net/wan/hdlc_generic.c:hdlc_setup() exported?
From: Adrian Bunk @ 2006-06-25 20:51 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: Jeff Garzik, linux-kernel, netdev
Commit 4a31e348e3ecaf54c50240109ac4574b180f8840 added an
EXPORT_SYMBOL(hdlc_setup) with the justification
hdlc_setup() is now EXPORTed as per David's request.
Is a usage of this export pending for the near future or could this
export be reverted until a user is submitted for inclusion?
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
From: Harry Edmon @ 2006-06-25 21:51 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.61.0606192017370.31662@ask.diku.dk>
I understand the saying "beggars can't be choosers", but I have heard nothing on
this issue since June 19th. Does anyone have any ideas on what is going on? Is
there more information I can collect that would help diagnose this problem? And
again, thanks for any and all help!
--
Dr. Harry Edmon E-MAIL: harry@atmos.washington.edu
206-543-0547 harry@u.washington.edu
Dept of Atmospheric Sciences FAX: 206-543-0308
University of Washington, Box 351640, Seattle, WA 98195-1640
^ permalink raw reply
* Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
From: Willy Tarreau @ 2006-06-25 22:22 UTC (permalink / raw)
To: Andi Kleen; +Cc: Jesper Dangaard Brouer, Harry Edmon, linux-kernel, netdev
In-Reply-To: <200606191724.31305.ak@suse.de>
Hi Andi,
On Mon, Jun 19, 2006 at 05:24:31PM +0200, Andi Kleen wrote:
>
> > If you use "pmtmr" try to reboot with kernel option "clock=tsc".
>
> That's dangerous advice - when the system choses not to use
> TSC it often has a reason.
>
> >
> > On my Opteron AMD system i normally can route 400 kpps, but with
> > timesource "pmtmr" i could only route around 83 kpps. (I found the timer
> > to be the issue by using oprofile).
>
> Unless you're using packet sniffing or any other application
> that requests time stamps on a socket then the timer shouldn't
> make much difference. Incoming packets are only time stamped
> when someone asks for the timestamps.
I encountered the same problem on a dual core opteron equipped with a
broadcom NIC (tg3) under 2.4. It could receive 1 Mpps when using TSC
as the clock source, but the time jumped back and forth, so I changed
it to 'notsc', then the performance dropped dramatically to around the
same value as above with one CPU saturated. I suspect that the clock
precision is needed by the tg3 driver to correctly decide to switch to
polling mode, but unfortunately, the performance drop rendered the
solution so much unusable that I finally decided to use it only in
uniprocessor with TSC enabled.
> -Andi
Regards,
Willy
^ permalink raw reply
* [PATCH]NET: Fix GSO problems in dev_hard_start_xmit()
From: Michael Chan @ 2006-06-25 22:38 UTC (permalink / raw)
To: herbert, davem; +Cc: netdev
Fix 2 problems in dev_hard_start_xmit():
1. nskb->next needs to link back to skb->next if hard_start_xmit()
returns non-zero.
2. Since the total number of GSO fragments may exceed MAX_SKB_FRAGS + 1,
it needs to stop transmitting if the netif_queue is stopped.
Signed-off-by: Michael Chan <mchan@broadcom.com>
diff --git a/net/core/dev.c b/net/core/dev.c
index d293e0f..84e06ae 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1325,9 +1325,12 @@ int dev_hard_start_xmit(struct sk_buff *
nskb->next = NULL;
rc = dev->hard_start_xmit(nskb, dev);
if (unlikely(rc)) {
+ nskb->next = skb->next;
skb->next = nskb;
return rc;
}
+ if (unlikely(netif_queue_stopped(dev) && skb->next))
+ return NETDEV_TX_BUSY;
} while (skb->next);
skb->destructor = DEV_GSO_CB(skb)->destructor;
^ permalink raw reply related
* [2.6 patch] make net/core/dev.c:netdev_nit static
From: Adrian Bunk @ 2006-06-25 23:13 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, linux-kernel
netdev_nit can now become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
include/linux/netdevice.h | 1 -
net/core/dev.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.17-mm2-full/include/linux/netdevice.h.old 2006-06-25 23:30:55.000000000 +0200
+++ linux-2.6.17-mm2-full/include/linux/netdevice.h 2006-06-25 23:31:02.000000000 +0200
@@ -699,7 +699,6 @@
extern void dev_init(void);
-extern int netdev_nit;
extern int netdev_budget;
/* Called by rtnetlink.c:rtnl_unlock() */
--- linux-2.6.17-mm2-full/net/core/dev.c.old 2006-06-25 23:31:08.000000000 +0200
+++ linux-2.6.17-mm2-full/net/core/dev.c 2006-06-25 23:31:19.000000000 +0200
@@ -230,7 +230,7 @@
* For efficiency
*/
-int netdev_nit;
+static int netdev_nit;
/*
* Add a protocol ID to the list. Now that the input handler is
^ permalink raw reply
* Re: [patch 1/2] tulip: fix for 64-bit mips
From: Grant Grundler @ 2006-06-25 23:44 UTC (permalink / raw)
To: Martin Michlmayr
Cc: akpm, val_henson, jeff, netdev, maillist, grundler, pdh,
Kyle McMartin
In-Reply-To: <20060625093108.GA29132@unjust.cyrius.com>
On Sun, Jun 25, 2006 at 10:31:08AM +0100, Martin Michlmayr wrote:
> * akpm@osdl.org <akpm@osdl.org> [2006-06-25 01:45]:
> > Cc: Valerie Henson <val_henson@linux.intel.com>
> >
> > [akpm: this is a previously-nacked patch, but the problem is real]
ia64 and parisc need the changes to tulip_select_media() too.
> And, for the record, Jeff's suggestion as to how to rework the patch:
>
> | Answer hasn't changed since this was last discussed: sleep, rather than
> | delay for an extra-long time. That's the only hurdle for the tulip
> | patches you keep resending.
>
> | Francois Romieu even had an untested patch that attempted this,
> | somewhere.
>
> Now we just need someone to complete this work...
Kyle McMartin has the work queue patch merged into the cvs.parisc-linux.org
CVS tree. It would be easiest to accept this patch and then add the
tulip work queue patch next.
Note that the work queue does NOT solve all of the "spin delay with
interrupts blocked" problems. tulip_stop_rxtx() polls for nearly as long
and tulip_select_media().
thanks,
grant
> --
> Martin Michlmayr
> tbm@cyrius.com
^ permalink raw reply
* Re: [PATCH]NET: Fix GSO problems in dev_hard_start_xmit()
From: Herbert Xu @ 2006-06-25 23:36 UTC (permalink / raw)
To: Michael Chan; +Cc: davem, netdev
In-Reply-To: <1151275085.4468.2.camel@rh4>
On Sun, Jun 25, 2006 at 03:38:05PM -0700, Michael Chan wrote:
> Fix 2 problems in dev_hard_start_xmit():
>
> 1. nskb->next needs to link back to skb->next if hard_start_xmit()
> returns non-zero.
>
> 2. Since the total number of GSO fragments may exceed MAX_SKB_FRAGS + 1,
> it needs to stop transmitting if the netif_queue is stopped.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Good catch.
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Russell Stuart @ 2006-06-26 0:45 UTC (permalink / raw)
To: Patrick McHardy
Cc: hadi, Alan Cox, Stephen Hemminger, netdev, Jesper Dangaard Brouer
In-Reply-To: <449C06E3.3090406@trash.net>
On Fri, 2006-06-23 at 17:21 +0200, Patrick McHardy wrote:
> Not really. The randomization doesn't happen by default, but it doesn't
> influence this anyway. SFQ allows flows to send up to "quantum" bytes
> at a time before moving on to the next one. A flow that sends 75 * 20
> byte will in the eyes of SFQ use 1500bytes, on the (ethernet) wire it
> needs 4800bytes. A flow that sents 1500byte packets will only need
> 1504 bytes on the wire, but will be treated equally. So it does make
> a different for SFQ.
I hadn't even thought to check. My bad. The S in SFQ stands
for stochastic, so something that does without randomisation
the algorithm implemented couldn't really be called SFQ -
particularly as it weakens the algorithm considerably. I
hope that most users do specify a perturb.
Your 20 byte example is hardly realistic. skb->len includes
the 14 byte ethernet header, so there is a total of 6 data
bytes in a 20 byte packet. The IP header alone is 20 bytes.
TCP as implemented on Linux adds another 32 bytes (20 + the
rtt option). In other words I agree with Jamal's comments
elsewhere - optimising for MPU sized packets doesn't seem
like a win.
> Not a problem as long as the new stuff doesn't break anything existing.
> My patch introduces a TCA_STAB (for size table), similar to the _RTAB
> attributes. Old iproute with new kernel and new iproute with old kernel
> both work fine.
OK, good.
> Its not about cleanup, its about providing the same capabilities
> to all qdiscs instead of just a few selected ones and generalizing
> it so it is also usable for non-ATM overhead calculations.
Perhaps I chose my words poorly.
My intent was to contrast the size and goals of the two
proposed patches. The ATM patch is a 37 line patch. It
includes some minor cleanups. From the pseudo code you
have posted what you are proposing is a more ambitious and
much larger patch that moves a chunk of user space code
into the kernel. I am a complete newbie when it comes to
getting code into the kernel, but that strikes me as
contentious. I would rather not have the ATM patch
depend on it.
By the by, here are a couple of observations:
1. The entries in the current rtab are already very closely
related to packet lengths. They are actually the packet
length multiplied by a constant that converts the units
from "bytes" to "jiffies". The constant is the same for
all entries in the table.
2. As such, the current rtab could already be used by SFQ
and any other qdisc that needs to know the packet length.
That SFQ doesn't do this is probably because it doesn't
effect its performance overly.
3. Be that as it may, the current RTAB isn't in the most
convenient form for SFQ, and I am guessing it is in a
very inconvenient form for HFSC. Adding a new version
that is identical except that it contains the raw packet
length would be a simple change. In that format it
could be used by all qdiscs. The users of the existing
rtab would have to do the multiplication that converts
the packet length to jiffies in the kernel. This means
the conceptually at least, should the gootput change
you need to change this one constant, not the entire
table.
4. Much as you seem to dislike having the rate / packet length
calculations in user space, having them there makes it easy
to add new technologies such as ATM. You just have to
change a user space tool - not the kernel.
5. We still did have to modify the kernel for ATM. That was
because of its rather unusual characteristics. However,
it you look at the size of modifications made to the kernel
verses the size made to the user space tool, (37 lines
versus 303 lines,) the bulk of the work was does in user
space.
^ permalink raw reply
* bcm43xx: "transmit timed out" and apparent hang with "preemptible periodic work" patches
From: Paul Collins @ 2006-06-26 2:28 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, netdev
With the bcm43xx periodic work patches that recently made it into
Linus's tree, my PowerBook does not survive running overnight.
Yesterday I reverted
91769e7dd9cef7988dc4280f74ed168351beb5b8 [PATCH] bcm43xx: preemptible periodic work
78ff56a06edc3407996173daf63e48f6b90c7062 [PATCH] bcm43xx: redesign locking
and it was still alive this morning.
The following is logged, but that may not be all since the screen was
turned off and kern.log was marked for no-fsync.
Jun 24 06:53:41 briny kernel: NETDEV WATCHDOG: eth1: transmit timed out
Jun 24 06:53:41 briny kernel: bcm43xx: Controller RESET (TX timeout) ...
Jun 24 06:53:41 briny kernel: bcm43xx: Chip ID 0x4306, rev 0x3
Jun 24 06:53:41 briny kernel: bcm43xx: Number of cores: 5
Jun 24 06:53:41 briny kernel: bcm43xx: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled
Jun 24 06:53:41 briny kernel: bcm43xx: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled
Jun 24 06:53:41 briny kernel: bcm43xx: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled
Jun 24 06:53:41 briny kernel: bcm43xx: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled
Jun 24 06:53:41 briny kernel: bcm43xx: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled
Jun 24 06:53:41 briny kernel: bcm43xx: PHY connected
Jun 24 06:53:41 briny kernel: bcm43xx: Detected PHY: Version: 2, Type 2, Revision 2
Jun 24 06:53:41 briny kernel: bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off
Jun 24 06:53:41 briny kernel: bcm43xx: Radio turned off
Jun 24 06:53:41 briny kernel: bcm43xx: Controller restarted
Config options:
CONFIG_BCM43XX=m
CONFIG_BCM43XX_DEBUG=y
CONFIG_BCM43XX_DMA=y
CONFIG_BCM43XX_PIO=y
CONFIG_BCM43XX_DMA_AND_PIO_MODE=y
# CONFIG_BCM43XX_DMA_MODE is not set
# CONFIG_BCM43XX_PIO_MODE is not set
And "preemptible" made me check for PREEMPT options:
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
--
Paul Collins
Melbourne, Australia
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* [PATCH] Convert bcm43xx-softmac to use the ieee80211_is_valid_channel routine
From: Larry Finger @ 2006-06-26 2:32 UTC (permalink / raw)
To: netdev, Bcm43xx-dev, John Linville
The current version of bcm43xx-softmac uses local routines to check if a channel is valid. As noted
in the comments, these routines do not take any regulatory information into account. This patch
converts the code to use the equivalent routine in ieee80211, which is being converted to know about
regulatory information.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.h b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
index 30a202b..1164936 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
@@ -112,30 +112,6 @@ int bcm43xx_channel_to_freq(struct bcm43
return bcm43xx_channel_to_freq_bg(channel);
}
-/* Lightweight function to check if a channel number is valid.
- * Note that this does _NOT_ check for geographical restrictions!
- */
-static inline
-int bcm43xx_is_valid_channel_a(u8 channel)
-{
- return (channel >= IEEE80211_52GHZ_MIN_CHANNEL
- && channel <= IEEE80211_52GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel_bg(u8 channel)
-{
- return (channel >= IEEE80211_24GHZ_MIN_CHANNEL
- && channel <= IEEE80211_24GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel(struct bcm43xx_private *bcm,
- u8 channel)
-{
- if (bcm43xx_current_phy(bcm)->type == BCM43xx_PHYTYPE_A)
- return bcm43xx_is_valid_channel_a(channel);
- return bcm43xx_is_valid_channel_bg(channel);
-}
-
void bcm43xx_tsf_read(struct bcm43xx_private *bcm, u64 *tsf);
void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
index af5c0bf..3900753 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1594,11 +1594,11 @@ int bcm43xx_radio_selectchannel(struct b
u16 r8, tmp;
u16 freq;
- if ((radio->manufact == 0x17F) &&
+ if (!ieee80211_is_valid_channel(bcm->ieee, channel))
+ return -EINVAL;
+ if ((radio->manufact == 0x17F) &&
(radio->version == 0x2060) &&
(radio->revision == 1)) {
- if (channel > 200)
- return -EINVAL;
freq = channel2freq_a(channel);
r8 = bcm43xx_radio_read16(bcm, 0x0008);
@@ -1651,9 +1651,6 @@ int bcm43xx_radio_selectchannel(struct b
TODO(); //TODO: TSSI2dbm workaround
bcm43xx_phy_xmitpower(bcm);//FIXME correct?
} else {
- if ((channel < 1) || (channel > 14))
- return -EINVAL;
-
if (synthetic_pu_workaround)
bcm43xx_synth_pu_workaround(bcm, channel);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index c35cb3a..5c36e29 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -119,7 +119,7 @@ static int bcm43xx_wx_set_channelfreq(st
channel = bcm43xx_freq_to_channel(bcm, data->freq.m);
freq = data->freq.m;
}
- if (!bcm43xx_is_valid_channel(bcm, channel))
+ if (!ieee80211_is_valid_channel(bcm->ieee, channel))
goto out_unlock;
if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) {
//ieee80211softmac_disassoc(softmac, $REASON);
^ permalink raw reply related
* Fresh stuff Surely you only dream of it Revel in
From: Evangeline @ 2006-06-26 2:32 UTC (permalink / raw)
To: netdev
Dear client.
Achieve astounding results in bed with these products designed to make any man a winner
You are just a couple of clicks away from our great prices and handy shipment
Many people worldwide have been enjoying goods from these top brands for many years
Check up here: http://www.lutetiaaj.com
We offer reliable service and 5 years expirience on the marcket!
^ permalink raw reply
* [RFC] cirrus ep93xx ethernet driver
From: Lennert Buytenhek @ 2006-06-26 2:59 UTC (permalink / raw)
To: netdev
The cirrus ep93xx is an ARM SoC that includes an ethernet MAC --
this patch adds a driver for that ethernet MAC.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
(This is, unfortunately, probably too late for 2.6.18, so I'm sending
it just for feedback.)
Index: linux-2.6.17-git5/drivers/net/arm/Kconfig
===================================================================
--- linux-2.6.17-git5.orig/drivers/net/arm/Kconfig
+++ linux-2.6.17-git5/drivers/net/arm/Kconfig
@@ -39,3 +39,10 @@ config ARM_AT91_ETHER
help
If you wish to compile a kernel for the AT91RM9200 and enable
ethernet support, then you should always answer Y to this.
+
+config EP93XX_ETH
+ tristate "EP93xx Ethernet support"
+ depends on NET_ETHERNET && ARM && ARCH_EP93XX
+ help
+ This is a driver for the ethernet hardware included in EP93xx CPUs.
+ Say Y if you are building a kernel for EP93xx based devices.
Index: linux-2.6.17-git5/drivers/net/arm/Makefile
===================================================================
--- linux-2.6.17-git5.orig/drivers/net/arm/Makefile
+++ linux-2.6.17-git5/drivers/net/arm/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_ARM_ETHERH) += etherh.o
obj-$(CONFIG_ARM_ETHER3) += ether3.o
obj-$(CONFIG_ARM_ETHER1) += ether1.o
obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
+obj-$(CONFIG_EP93XX_ETH) += ep93xx_eth.o
Index: linux-2.6.17-git5/drivers/net/arm/ep93xx_eth.c
===================================================================
--- /dev/null
+++ linux-2.6.17-git5/drivers/net/arm/ep93xx_eth.c
@@ -0,0 +1,672 @@
+/*
+ * EP93xx ethernet network device driver
+ * Copyright (C) 2006 Lennert Buytenhek <buytenh@wantstofly.org>
+ * Dedicated to Marija Kulikova.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/dma-mapping.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/init.h>
+#include <linux/moduleparam.h>
+#include <linux/platform_device.h>
+#include <asm/arch/ep93xx-regs.h>
+#include <asm/arch/platform.h>
+#include <asm/io.h>
+#include "ep93xx_eth.h"
+
+#define DRV_MODULE_VERSION "0.1"
+
+#define RX_QUEUE_ENTRIES 64
+#define TX_QUEUE_ENTRIES 8
+
+struct ep93xx_descs
+{
+ struct ep93xx_rdesc rdesc[RX_QUEUE_ENTRIES];
+ struct ep93xx_tdesc tdesc[TX_QUEUE_ENTRIES];
+ struct ep93xx_rstat rstat[RX_QUEUE_ENTRIES];
+ struct ep93xx_tstat tstat[TX_QUEUE_ENTRIES];
+};
+
+struct ep93xx_priv
+{
+ struct resource *res;
+ void *base_addr;
+ int irq;
+
+ struct ep93xx_descs *descs;
+ dma_addr_t descs_dma_addr;
+
+ void *rx_buf[RX_QUEUE_ENTRIES];
+ void *tx_buf[TX_QUEUE_ENTRIES];
+
+ int rx_pointer;
+ int tx_clean_pointer;
+ int tx_pointer;
+ int tx_pending;
+
+ struct net_device_stats stats;
+};
+
+#define rdb(ep, off) __raw_readb((ep)->base_addr + (off))
+#define rdw(ep, off) __raw_readw((ep)->base_addr + (off))
+#define rdl(ep, off) __raw_readl((ep)->base_addr + (off))
+#define wrb(ep, off, val) __raw_writeb((val), (ep)->base_addr + (off))
+#define wrw(ep, off, val) __raw_writew((val), (ep)->base_addr + (off))
+#define wrl(ep, off, val) __raw_writel((val), (ep)->base_addr + (off))
+
+static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ int entry;
+
+ if (unlikely(skb->len) > PAGE_SIZE) {
+ ep->stats.tx_dropped++;
+ dev_kfree_skb(skb);
+ return 0;
+ }
+
+ entry = ep->tx_pointer;
+ ep->tx_pointer = (ep->tx_pointer + 1) % TX_QUEUE_ENTRIES;
+
+ ep->descs->tdesc[entry].tdesc1 =
+ TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
+ skb_copy_and_csum_dev(skb, ep->tx_buf[entry]);
+ dma_sync_single(NULL, ep->descs->tdesc[entry].buf_addr,
+ skb->len, DMA_TO_DEVICE);
+ dev_kfree_skb(skb);
+
+ dev->trans_start = jiffies;
+
+ local_irq_disable();
+ ep->tx_pending++;
+ if (ep->tx_pending == TX_QUEUE_ENTRIES)
+ netif_stop_queue(dev);
+ local_irq_enable();
+
+ wrl(ep, 0x00bc, 1);
+
+ return 0;
+}
+
+static int ep93xx_rx(struct net_device *dev, int *budget)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ int tail_offset;
+ int rx_done;
+ int processed;
+
+ tail_offset = rdl(ep, 0x00a8) - ep->descs_dma_addr;
+
+ rx_done = 0;
+ processed = 0;
+ while (*budget > 0) {
+ int entry;
+ struct ep93xx_rstat *rstat;
+ u32 rstat0;
+ u32 rstat1;
+ int length;
+ struct sk_buff *skb;
+
+ entry = ep->rx_pointer;
+ rstat = ep->descs->rstat + entry;
+ if ((void *)rstat - (void *)ep->descs == tail_offset) {
+ rx_done = 1;
+ break;
+ }
+
+ rstat0 = rstat->rstat0;
+ rstat1 = rstat->rstat1;
+ rstat->rstat0 = 0;
+ rstat->rstat1 = 0;
+
+ if (!(rstat0 & RSTAT0_RFP)) {
+ printk(KERN_CRIT "ep93xx_rx: buffer not done "
+ " %.8x %.8x\n", rstat0, rstat1);
+ BUG();
+ }
+ if (!(rstat0 & RSTAT0_EOF)) {
+ printk(KERN_CRIT "ep93xx_rx: not end-of-frame "
+ " %.8x %.8x\n", rstat0, rstat1);
+ BUG();
+ }
+ if (!(rstat0 & RSTAT0_EOB)) {
+ printk(KERN_CRIT "ep93xx_rx: not end-of-buffer "
+ " %.8x %.8x\n", rstat0, rstat1);
+ BUG();
+ }
+ if (!(rstat1 & RSTAT1_RFP)) {
+ printk(KERN_CRIT "ep93xx_rx: buffer1 not done "
+ " %.8x %.8x\n", rstat0, rstat1);
+ BUG();
+ }
+ if ((rstat1 & RSTAT1_BUFFER_INDEX) >> 16 != entry) {
+ printk(KERN_INFO "ep93xx_rx: entry mismatch "
+ " %.8x %.8x\n", rstat0, rstat1);
+ BUG();
+ }
+
+ if (!(rstat0 & RSTAT0_RWE)) {
+ printk(KERN_NOTICE "ep93xx_rx: receive error "
+ " %.8x %.8x\n", rstat0, rstat1);
+
+ ep->stats.rx_errors++;
+ if (rstat0 & RSTAT0_OE)
+ ep->stats.rx_fifo_errors++;
+ if (rstat0 & RSTAT0_FE)
+ ep->stats.rx_frame_errors++;
+ if (rstat0 & (RSTAT0_RUNT | RSTAT0_EDATA))
+ ep->stats.rx_length_errors++;
+ if (rstat0 & RSTAT0_CRCE)
+ ep->stats.rx_crc_errors++;
+ goto err;
+ }
+
+ length = rstat1 & RSTAT1_FRAME_LENGTH;
+ if (length < 4 || length > PAGE_SIZE) {
+ printk(KERN_NOTICE "ep93xx_rx: invalid length "
+ " %.8x %.8x\n", rstat0, rstat1);
+ goto err;
+ }
+
+ /* Strip FCS. */
+ if (rstat0 & RSTAT0_CRCI)
+ length -= 4;
+
+ skb = dev_alloc_skb(length + 2);
+ if (likely(skb != NULL)) {
+ skb->dev = dev;
+ skb_reserve(skb, 2);
+ dma_sync_single(NULL, ep->descs->rdesc[entry].buf_addr,
+ length, DMA_FROM_DEVICE);
+ eth_copy_and_sum(skb, ep->rx_buf[entry], length, 0);
+ skb_put(skb, length);
+ skb->protocol = eth_type_trans(skb, dev);
+
+ dev->last_rx = jiffies;
+
+ netif_receive_skb(skb);
+
+ ep->stats.rx_packets++;
+ ep->stats.rx_bytes += length;
+ } else {
+ ep->stats.rx_dropped++;
+ }
+
+err:
+ ep->rx_pointer = (entry + 1) % RX_QUEUE_ENTRIES;
+ processed++;
+ dev->quota--;
+ (*budget)--;
+ }
+
+ if (processed) {
+ wrw(ep, 0x009c, processed);
+ wrw(ep, 0x00ac, processed);
+ }
+
+ return !rx_done;
+}
+
+static int ep93xx_have_more_rx(struct ep93xx_priv *ep)
+{
+ struct ep93xx_rstat *rstat;
+ int tail_offset;
+
+ rstat = ep->descs->rstat + ep->rx_pointer;
+ tail_offset = rdl(ep, 0x00a8) - ep->descs_dma_addr;
+
+ return !((void *)rstat - (void *)ep->descs == tail_offset);
+}
+
+static int ep93xx_poll(struct net_device *dev, int *budget)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+
+ /* @@@ Have to stop polling when device is downed while we
+ * are polling. */
+
+ wrl(ep, 0x0028, 0x00000004);
+
+poll_some_more:
+ if (ep93xx_rx(dev, budget))
+ return 1;
+
+ netif_rx_complete(dev);
+
+ local_irq_disable();
+ wrl(ep, 0x0024, 0x0000000f);
+ if (ep93xx_have_more_rx(ep)) {
+ wrl(ep, 0x0024, 0x00000008);
+ wrl(ep, 0x0028, 0x00000004);
+ local_irq_enable();
+
+ if (netif_rx_reschedule(dev, 0))
+ goto poll_some_more;
+
+ return 0;
+ }
+ local_irq_enable();
+
+ return 0;
+}
+
+static void ep93xx_tx_complete(struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ int tail_offset;
+ int wake;
+
+ tail_offset = rdl(ep, 0x00c8) - ep->descs_dma_addr;
+
+ wake = 0;
+ while (1) {
+ int entry;
+ struct ep93xx_tstat *tstat;
+ u32 tstat0;
+
+ entry = ep->tx_clean_pointer;
+ tstat = ep->descs->tstat + entry;
+ if ((void *)tstat - (void *)ep->descs == tail_offset)
+ break;
+
+ tstat0 = tstat->tstat0;
+ tstat->tstat0 = 0;
+
+ if (!(tstat0 & TSTAT0_TXFP)) {
+ printk(KERN_CRIT "ep93xx_tx_complete: buffer not done "
+ " %.8x\n", tstat0);
+ BUG();
+ }
+ if (tstat0 & TSTAT0_FA) {
+ printk(KERN_CRIT "ep93xx_tx_complete: frame aborted "
+ " %.8x\n", tstat0);
+ BUG();
+ }
+ if ((tstat0 & TSTAT0_BUFFER_INDEX) != entry) {
+ printk(KERN_INFO "ep93xx_tx_complete: entry mismatch "
+ " %.8x\n", tstat0);
+ BUG();
+ }
+
+ if (tstat0 & TSTAT0_TXWE) {
+ int length = ep->descs->tdesc[entry].tdesc1 & 0xfff;
+
+ ep->stats.tx_packets++;
+ ep->stats.tx_bytes += length;
+ } else {
+ ep->stats.tx_errors++;
+ }
+ if (tstat0 & TSTAT0_LCRS)
+ ep->stats.tx_carrier_errors++;
+ if (tstat0 & TSTAT0_OW)
+ ep->stats.tx_window_errors++;
+ if (tstat0 & TSTAT0_TXU)
+ ep->stats.tx_fifo_errors++;
+ ep->stats.collisions += (tstat0 >> 16) & 0x1f;
+
+ ep->tx_clean_pointer = (entry + 1) % TX_QUEUE_ENTRIES;
+ if (ep->tx_pending == TX_QUEUE_ENTRIES)
+ wake = 1;
+ ep->tx_pending--;
+ }
+
+ if (wake)
+ netif_wake_queue(dev);
+}
+
+static irqreturn_t ep93xx_irq(int irq, void *dev_id, struct pt_regs *regs)
+{
+ struct net_device *dev = dev_id;
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ u32 status;
+
+ status = rdl(ep, 0x0028);
+ if (status == 0)
+ return IRQ_NONE;
+
+ if (status & 0x00000004) {
+ if (likely(__netif_rx_schedule_prep(dev))) {
+ wrl(ep, 0x0024, 0x00000008);
+ __netif_rx_schedule(dev);
+ }
+ }
+
+ if (status & 0x00000008) {
+ wrl(ep, 0x0028, 0x00000008);
+ ep93xx_tx_complete(dev);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static void ep93xx_free_buffers(struct ep93xx_priv *ep)
+{
+ int i;
+
+ for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
+ dma_addr_t d;
+
+ d = ep->descs->rdesc[i].buf_addr;
+ if (d)
+ dma_unmap_single(NULL, d, PAGE_SIZE, DMA_FROM_DEVICE);
+
+ if (ep->rx_buf[i] != NULL)
+ free_page((unsigned long)ep->rx_buf[i]);
+ }
+
+ for (i = 0; i < TX_QUEUE_ENTRIES; i++) {
+ dma_addr_t d;
+
+ d = ep->descs->tdesc[i].buf_addr;
+ if (d)
+ dma_unmap_single(NULL, d, PAGE_SIZE, DMA_TO_DEVICE);
+
+ if (ep->tx_buf[i] != NULL)
+ free_page((unsigned long)ep->tx_buf[i]);
+ }
+
+ dma_free_coherent(NULL, sizeof(struct ep93xx_descs), ep->descs,
+ ep->descs_dma_addr);
+}
+
+static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
+{
+ int i;
+
+ ep->descs = dma_alloc_coherent(NULL, sizeof(struct ep93xx_descs),
+ &ep->descs_dma_addr, GFP_KERNEL | GFP_DMA);
+ if (ep->descs == NULL)
+ return 1;
+
+ for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
+ void *page;
+ dma_addr_t d;
+
+ page = (void *)get_zeroed_page(GFP_KERNEL | GFP_DMA);
+ if (page == NULL)
+ goto err;
+
+ d = dma_map_single(NULL, page, PAGE_SIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(d)) {
+ free_page((unsigned long)page);
+ goto err;
+ }
+
+ ep->rx_buf[i] = page;
+ ep->descs->rdesc[i].buf_addr = d;
+ ep->descs->rdesc[i].rdesc1 = (i << 16) | PAGE_SIZE;
+ }
+
+ for (i = 0; i < TX_QUEUE_ENTRIES; i++) {
+ void *page;
+ dma_addr_t d;
+
+ page = (void *)get_zeroed_page(GFP_KERNEL | GFP_DMA);
+ if (page == NULL)
+ goto err;
+
+ d = dma_map_single(NULL, page, PAGE_SIZE, DMA_TO_DEVICE);
+ if (dma_mapping_error(d)) {
+ free_page((unsigned long)page);
+ goto err;
+ }
+
+ ep->tx_buf[i] = page;
+ ep->descs->tdesc[i].buf_addr = d;
+ }
+
+ return 0;
+
+err:
+ ep93xx_free_buffers(ep);
+ return 1;
+}
+
+static void ep93xx_start_hw(struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ unsigned long addr;
+
+ wrl(ep, 0x0020, 0x00000001);
+ while (rdl(ep, 0x0020) & 0x00000001)
+ ;
+
+ /* Receive descriptor ring. */
+ addr = ep->descs_dma_addr + offsetof(struct ep93xx_descs, rdesc);
+ wrl(ep, 0x0090, addr);
+ wrl(ep, 0x0098, addr);
+ wrw(ep, 0x0094, RX_QUEUE_ENTRIES * sizeof(struct ep93xx_rdesc));
+
+ /* Receive status ring. */
+ addr = ep->descs_dma_addr + offsetof(struct ep93xx_descs, rstat);
+ wrl(ep, 0x00a0, addr);
+ wrl(ep, 0x00a8, addr);
+ wrw(ep, 0x00a4, RX_QUEUE_ENTRIES * sizeof(struct ep93xx_rstat));
+
+ /* Transmit descriptor ring. */
+ addr = ep->descs_dma_addr + offsetof(struct ep93xx_descs, tdesc);
+ wrl(ep, 0x00b0, addr);
+ wrl(ep, 0x00b8, addr);
+ wrw(ep, 0x00b4, TX_QUEUE_ENTRIES * sizeof(struct ep93xx_tdesc));
+
+ /* Transmit status ring. */
+ addr = ep->descs_dma_addr + offsetof(struct ep93xx_descs, tstat);
+ wrl(ep, 0x00c0, addr);
+ wrl(ep, 0x00c8, addr);
+ wrw(ep, 0x00c4, TX_QUEUE_ENTRIES * sizeof(struct ep93xx_tstat));
+
+ wrl(ep, 0x0080, 0x00000101); // bmctl
+ wrl(ep, 0x0024, 0x0000000f); // inten
+ wrl(ep, 0x0064, 0x00000000); // gintmask
+ while (!(rdl(ep, 0x0084) & 0x00000008))
+ cpu_relax();
+ wrl(ep, 0x009c, RX_QUEUE_ENTRIES);
+ wrl(ep, 0x00ac, RX_QUEUE_ENTRIES);
+
+ wrb(ep, 0x0050, dev->dev_addr[0]);
+ wrb(ep, 0x0051, dev->dev_addr[1]);
+ wrb(ep, 0x0052, dev->dev_addr[2]);
+ wrb(ep, 0x0053, dev->dev_addr[3]);
+ wrb(ep, 0x0054, dev->dev_addr[4]);
+ wrb(ep, 0x0055, dev->dev_addr[5]);
+ wrl(ep, 0x004c, 0x00000000);
+
+ wrl(ep, 0x0000, 0x00073800);
+ wrl(ep, 0x0004, 0x00000001);
+}
+
+static void ep93xx_stop_hw(struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+
+ wrl(ep, 0x0020, 0x00000001);
+ while (rdl(ep, 0x0020) & 0x00000001)
+ ;
+}
+
+static int ep93xx_open(struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ int err;
+
+ if (ep93xx_alloc_buffers(ep))
+ return -ENOMEM;
+
+ ep93xx_start_hw(dev);
+ ep->rx_pointer = 0;
+ ep->tx_clean_pointer = 0;
+ ep->tx_pointer = 0;
+ ep->tx_pending = 0;
+
+ err = request_irq(ep->irq, ep93xx_irq, SA_SHIRQ, "ep93xx_eth", dev);
+ if (err) {
+ ep93xx_stop_hw(dev);
+ ep93xx_free_buffers(ep);
+ return err;
+ }
+
+ wrl(ep, 0x0064, 0x00008000); // gintmask
+
+ netif_start_queue(dev);
+
+ return 0;
+}
+
+static int ep93xx_close(struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+
+ netif_stop_queue(dev);
+
+ wrl(ep, 0x0064, 0x00000000); // gintmask
+ free_irq(ep->irq, dev);
+ ep93xx_stop_hw(dev);
+ ep93xx_free_buffers(ep);
+
+ return 0;
+}
+
+static struct net_device_stats *ep93xx_get_stats(struct net_device *dev)
+{
+ struct ep93xx_priv *ep = netdev_priv(dev);
+ return &(ep->stats);
+}
+
+struct net_device *ep93xx_dev_alloc(struct ep93xx_eth_data *data)
+{
+ struct net_device *dev;
+ struct ep93xx_priv *ep;
+
+ dev = alloc_etherdev(sizeof(struct ep93xx_priv));
+ if (dev == NULL)
+ return NULL;
+ ep = netdev_priv(dev);
+
+ memcpy(dev->dev_addr, data->dev_addr, ETH_ALEN);
+
+ dev->hard_start_xmit = ep93xx_xmit;
+ dev->poll = ep93xx_poll;
+ dev->open = ep93xx_open;
+ dev->stop = ep93xx_close;
+ dev->get_stats = ep93xx_get_stats;
+
+ dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->weight = 64;
+
+ return dev;
+}
+
+
+static int ep93xx_eth_remove(struct platform_device *pdev)
+{
+ struct net_device *dev;
+ struct ep93xx_priv *ep;
+
+ dev = platform_get_drvdata(pdev);
+ if (dev == NULL)
+ return 0;
+ platform_set_drvdata(pdev, NULL);
+
+ ep = netdev_priv(dev);
+
+ // @@@ force down
+ unregister_netdev(dev);
+ ep93xx_free_buffers(ep);
+
+ if (ep->base_addr != NULL)
+ iounmap(ep->base_addr);
+
+ if (ep->res != NULL) {
+ release_resource(ep->res);
+ kfree(ep->res);
+ }
+
+ free_netdev(dev);
+
+ return 0;
+}
+
+static int ep93xx_eth_probe(struct platform_device *pdev)
+{
+ struct ep93xx_eth_data *data;
+ struct net_device *dev;
+ struct ep93xx_priv *ep;
+ int err;
+
+ data = pdev->dev.platform_data;
+ if (pdev == NULL)
+ return -ENODEV;
+
+ printk(KERN_INFO "ep93xx-eth " DRV_MODULE_VERSION " loading\n");
+
+ dev = ep93xx_dev_alloc(data);
+ if (dev == NULL) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+ ep = netdev_priv(dev);
+
+ platform_set_drvdata(pdev, dev);
+
+ ep->res = request_mem_region(pdev->resource[0].start,
+ pdev->resource[0].end - pdev->resource[0].start + 1,
+ pdev->dev.bus_id);
+ if (ep->res == NULL) {
+ dev_err(&pdev->dev, "Could not reserve memory region\n");
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ ep->base_addr = ioremap(pdev->resource[0].start,
+ pdev->resource[0].end - pdev->resource[0].start);
+ if (ep->base_addr == NULL) {
+ dev_err(&pdev->dev, "Failed to ioremap ethernet registers\n");
+ err = -EIO;
+ goto err_out;
+ }
+ ep->irq = pdev->resource[1].start;
+
+ err = register_netdev(dev);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to register netdev\n");
+ goto err_out;
+ }
+
+ return 0;
+
+err_out:
+ ep93xx_eth_remove(pdev);
+ return err;
+}
+
+
+static struct platform_driver ep93xx_eth_driver = {
+ .probe = ep93xx_eth_probe,
+ .remove = ep93xx_eth_remove,
+ .driver = {
+ .name = "ep93xx-eth",
+ },
+};
+
+static int __init ep93xx_eth_init_module(void)
+{
+ return platform_driver_register(&ep93xx_eth_driver);
+}
+
+static void __exit ep93xx_eth_cleanup_module(void)
+{
+ platform_driver_unregister(&ep93xx_eth_driver);
+}
+
+module_init(ep93xx_eth_init_module);
+module_exit(ep93xx_eth_cleanup_module);
+MODULE_LICENSE("GPL");
Index: linux-2.6.17-git5/drivers/net/arm/ep93xx_eth.h
===================================================================
--- /dev/null
+++ linux-2.6.17-git5/drivers/net/arm/ep93xx_eth.h
@@ -0,0 +1,75 @@
+/*
+ * EP93xx ethernet network device driver
+ * Copyright (C) 2006 Lennert Buytenhek <buytenh@wantstofly.org>
+ * Dedicated to Marija Kulikova.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __EP93XX_ETH_H
+#define __EP93XX_ETH_H
+
+struct ep93xx_rdesc
+{
+ u32 buf_addr;
+ u32 rdesc1;
+};
+
+#define RDESC1_NSOF 0x80000000
+#define RDESC1_BUFFER_INDEX 0x7fff0000
+#define RDESC1_BUFFER_LENGTH 0x0000ffff
+
+struct ep93xx_rstat
+{
+ u32 rstat0;
+ u32 rstat1;
+};
+
+#define RSTAT0_RFP 0x80000000
+#define RSTAT0_RWE 0x40000000
+#define RSTAT0_EOF 0x20000000
+#define RSTAT0_EOB 0x10000000
+#define RSTAT0_AM 0x00c00000
+#define RSTAT0_RX_ERR 0x00200000
+#define RSTAT0_OE 0x00100000
+#define RSTAT0_FE 0x00080000
+#define RSTAT0_RUNT 0x00040000
+#define RSTAT0_EDATA 0x00020000
+#define RSTAT0_CRCE 0x00010000
+#define RSTAT0_CRCI 0x00008000
+#define RSTAT0_HTI 0x00003f00
+#define RSTAT1_RFP 0x80000000
+#define RSTAT1_BUFFER_INDEX 0x7fff0000
+#define RSTAT1_FRAME_LENGTH 0x0000ffff
+
+struct ep93xx_tdesc
+{
+ u32 buf_addr;
+ u32 tdesc1;
+};
+
+#define TDESC1_EOF 0x80000000
+#define TDESC1_BUFFER_INDEX 0x7fff0000
+#define TDESC1_BUFFER_ABORT 0x00008000
+#define TDESC1_BUFFER_LENGTH 0x00000fff
+
+struct ep93xx_tstat
+{
+ u32 tstat0;
+};
+
+#define TSTAT0_TXFP 0x80000000
+#define TSTAT0_TXWE 0x40000000
+#define TSTAT0_FA 0x20000000
+#define TSTAT0_LCRS 0x10000000
+#define TSTAT0_OW 0x04000000
+#define TSTAT0_TXU 0x02000000
+#define TSTAT0_ECOLL 0x01000000
+#define TSTAT0_NCOLL 0x001f0000
+#define TSTAT0_BUFFER_INDEX 0x00007fff
+
+
+#endif
Index: linux-2.6.17-git5/include/asm-arm/arch-ep93xx/ep93xx-regs.h
===================================================================
--- linux-2.6.17-git5.orig/include/asm-arm/arch-ep93xx/ep93xx-regs.h
+++ linux-2.6.17-git5/include/asm-arm/arch-ep93xx/ep93xx-regs.h
@@ -27,6 +27,7 @@
#define EP93XX_DMA_BASE (EP93XX_AHB_VIRT_BASE + 0x00000000)
#define EP93XX_ETHERNET_BASE (EP93XX_AHB_VIRT_BASE + 0x00010000)
+#define EP93XX_ETHERNET_PHYS_BASE (EP93XX_AHB_PHYS_BASE + 0x00010000)
#define EP93XX_USB_BASE (EP93XX_AHB_VIRT_BASE + 0x00020000)
#define EP93XX_USB_PHYS_BASE (EP93XX_AHB_PHYS_BASE + 0x00020000)
Index: linux-2.6.17-git5/include/asm-arm/arch-ep93xx/platform.h
===================================================================
--- linux-2.6.17-git5.orig/include/asm-arm/arch-ep93xx/platform.h
+++ linux-2.6.17-git5/include/asm-arm/arch-ep93xx/platform.h
@@ -16,5 +16,10 @@ struct ep93xx_i2c_pins {
unsigned long scl_pin;
};
+struct ep93xx_eth_data
+{
+ unsigned char dev_addr[6];
+};
+
#endif
^ permalink raw reply
* Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
From: Bill Fink @ 2006-06-26 4:20 UTC (permalink / raw)
To: Harry Edmon; +Cc: linux-kernel, netdev
In-Reply-To: <449F0570.2090001@atmos.washington.edu>
On Sun, 25 Jun 2006, Harry Edmon wrote:
> I understand the saying "beggars can't be choosers", but I have heard nothing on
> this issue since June 19th. Does anyone have any ideas on what is going on? Is
> there more information I can collect that would help diagnose this problem? And
> again, thanks for any and all help!
Harry,
I'd suggest checking all the ethtool configuration settings
(ethtool -a, -c, -g, -k) and statistics (ethtool -S) for both
the working and problematic kernels, and then comparing them
to see if anything jumps out at you. Also compare ifconfig
settings and dmesg output. Check /proc/interrupts to see if
there is any difference with the interrupt routing. Check
sysctl.conf and rc.local for any special system configuration
or device settings that might differ between the systems.
The one thing that has caused me a lot of network performance
issues on e1000 is having TSO enabled, so if that is enabled
(check with ethtool -k), then I'd try disabling it to see if
that helps.
-Hope this helps
-Bill
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: Russell Stuart @ 2006-06-26 4:23 UTC (permalink / raw)
To: hadi
Cc: Russell Stuart, Jesper Dangaard Brouer, netdev, Stephen Hemminger,
Alan Cox, Patrick McHardy
In-Reply-To: <1151158431.6716.95.camel@jzny2>
On 25/06/2006 12:13 AM, jamal wrote:
> You can actually stop reading here if you have gathered the view at
> this point that i am not objecting to the simple approach Patrick is
> going with...
Perhaps this is my problem. I am not sure I understand
what Patrick is proposing. I can wait for his patch, I
guess.
> Indeed and i referred to it in the exchanges.
> And yes, I was arguing that the tc scheme you describe would not be so
> bad either if the cost of making a generic change is expensive.
OK. I take it from this you think there is merit in
the idea of adding code so the kernel can calculate
the ATM link speeds correctly. The discussion is
really about the best way to go about it?
If so, excellent. I am not really too fussy about how
it is achieved, I just want my VOIP connections to
work well on stock kernels.
> There are a lot of link layer issues that you may end up knowing of
> (other than the ATM fragmentation overhead) in regards to something
> downstream and you keep adding knobs is just adding more bloat.
> Example: If that 3rd hop was wireless that happened to be doing CDMA RLP
> with a lot of retransmits, or wireless that varied its throughput from
> 1-3Mbps at any point in time or it was a satellite link that had a lot
> of latency etc etc. You could always have some way to tweak these via
> the kernel. In-fact people have written schedulers specifically for
> these sorts of link layer problems (I think even some of the IEEE 802.11
> or wimax folks have standardized specific schedulers). You basically
> have to draw a line somewhere. My line was "can it be done via user
> space? yes - do it there".
If you mean by adding lots of knobs, you mean we need a knob
for 802.11, a knob for ATM, a knob for ethernet and so on,
then we do need lots of knobs. And you need to know which
of those layers is the bottle neck, so you know what knob to
fit. But you only ever need one knob on a given link.
I can only think of two ways out of needing lots of knobs.
One is to have a qdisc that doesn't need to know the link
speed in order to shape traffic to it gets to the scheduling
and not someone upstream. Sounds like black magic to me,
but perhaps HFSC does this - I have not read the papers
yet, but I plan to do so soon.
The second way is to automatically calculate the link speed,
using a daemon perhaps :). Again it sounds like black
magic. Note that there is already code in the kernel that
does this, but it lives in the layers above - in TCP and
DCCP. I am referring to Westwood, and friends. These
algorithms live in the layers above because the need feed
back from the network - which can only come from the other
end of connection unless ECN is working.
I have not been able to figure out how Patrick intends to
solve these problems from his posts so far, so I am waiting
for his code. Hopefully it will include a lot of comments.
> Patrick seems to have a simple way to compensate generically for link
> layer fragmentation, so i will not argue the practically; hopefully that
> settles it? ;->
Yes, it does. It will be interesting to see what Patrick
comes up with.
^ permalink raw reply
* Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
From: Andi Kleen @ 2006-06-26 5:23 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Jesper Dangaard Brouer, Harry Edmon, linux-kernel, netdev
In-Reply-To: <20060625222243.GJ13255@w.ods.org>
> I encountered the same problem on a dual core opteron equipped with a
> broadcom NIC (tg3) under 2.4. It could receive 1 Mpps when using TSC
> as the clock source, but the time jumped back and forth, so I changed
> it to 'notsc', then the performance dropped dramatically to around the
> same value as above with one CPU saturated. I suspect that the clock
> precision is needed by the tg3 driver to correctly decide to switch to
> polling mode, but unfortunately, the performance drop rendered the
> solution so much unusable that I finally decided to use it only in
> uniprocessor with TSC enabled.
2.6 is more clever at this than 2.4. In particular it does the timestamp
for each packet only when actually needed, which is relativelt rare.
Old experiences do not always apply to new kernels.
-Andi
^ 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