* [patch 1/8] myri10ge: alpha build fix
From: akpm @ 2006-06-09 5:19 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, brice
From: Andrew Morton <akpm@osdl.org>
drivers/net/myri10ge/myri10ge.c: In function 'myri10ge_submit_8rx':
drivers/net/myri10ge/myri10ge.c:772: error: 'DMA_32BIT_MASK' undeclared (first use in this function)
drivers/net/myri10ge/myri10ge.c:772: error: (Each undeclared identifier is reported only once
drivers/net/myri10ge/myri10ge.c:772: error: for each function it appears in.)
drivers/net/myri10ge/myri10ge.c: In function 'myri10ge_probe':
drivers/net/myri10ge/myri10ge.c:2607: error: 'DMA_64BIT_MASK' undeclared (first use in this function)
drivers/net/myri10ge/myri10ge.c:2612: error: 'DMA_32BIT_MASK' undeclared (first use in this function)
Cc: Brice Goglin <brice@myri.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/myri10ge/myri10ge.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN drivers/net/myri10ge/myri10ge.c~myri10ge-alpha-build-fix drivers/net/myri10ge/myri10ge.c
--- devel/drivers/net/myri10ge/myri10ge.c~myri10ge-alpha-build-fix 2006-06-03 21:13:30.000000000 -0700
+++ devel-akpm/drivers/net/myri10ge/myri10ge.c 2006-06-03 21:13:43.000000000 -0700
@@ -59,6 +59,8 @@
#include <linux/crc32.h>
#include <linux/moduleparam.h>
#include <linux/io.h>
+#include <linux/dma-mapping.h>
+
#include <net/checksum.h>
#include <asm/byteorder.h>
#include <asm/io.h>
_
^ permalink raw reply
* [patch 2/8] smc911x Kconfig fix
From: akpm @ 2006-06-09 5:19 UTC (permalink / raw)
To: jeff; +Cc: netdev, akpm, dustin
From: Andrew Morton <akpm@osdl.org>
In file included from drivers/net/smc911x.c:84:
drivers/net/smc911x.h:46:9: warning: "SMC_USE_16BIT" is not defined
drivers/net/smc911x.h:60:9: warning: "SMC_USE_32BIT" is not defined
drivers/net/smc911x.h:73:10: warning: "SMC_USE_PXA_DMA" is not defined
drivers/net/smc911x.c: In function `smc911x_reset':
drivers/net/smc911x.c:247: warning: implicit declaration of function `SMC_inl'
drivers/net/smc911x.c:249: warning: implicit declaration of function `SMC_outl'
Cc: Dustin McIntire <dustin@sensoria.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/net/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/Kconfig~smc911x-Kconfig-fix drivers/net/Kconfig
--- devel/drivers/net/Kconfig~smc911x-Kconfig-fix 2006-04-26 20:42:30.000000000 -0700
+++ devel-akpm/drivers/net/Kconfig 2006-04-26 20:42:56.000000000 -0700
@@ -869,7 +869,7 @@ config SMC911X
tristate "SMSC LAN911[5678] support"
select CRC32
select MII
- depends on NET_ETHERNET
+ depends on NET_ETHERNET && ARCH_PXA
help
This is a driver for SMSC's LAN911x series of Ethernet chipsets
including the new LAN9115, LAN9116, LAN9117, and LAN9118.
_
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Auke Kok @ 2006-06-09 5:13 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <4488D4DE.3000100@goop.org>
Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
>> That's odd. Netpoll holds a reference to the device, of course, but so
>> does a normal "up" interface. So that shouldn't be the problem.
>> Another possibility is that outgoing packets from printks in the
>> driver are causing difficulty. Not sure what can be done about that.
>>
> I only tried once; maybe I misunderstood what was going on. I'll try
> again tonight.
>
> Oh, I think I see what's happening. The e1000 suspend routine does this:
>
> if (netif_running(netdev))
> e1000_down(adapter);
>
> This leaves the interface up, but it stops the queue. Then
> netpoll_send_skb() has this loop:
>
> do {
> npinfo->tries--;
> spin_lock(&np->dev->xmit_lock);
> np->dev->xmit_lock_owner = smp_processor_id();
>
> /*
> * network drivers do not expect to be called if the queue is
> * stopped.
> */
> if (netif_queue_stopped(np->dev)) {
> np->dev->xmit_lock_owner = -1;
> spin_unlock(&np->dev->xmit_lock);
> netpoll_poll(np);
> udelay(50);
> continue;
> }
> /* ... */
> again: /* proposed */
> } while (npinfo->tries > 0);
>
>
> so this will end up in an infinite loop, since netif_queue_stopped()
> will always return true, and it never looks at npinfo->tries. Should
> the "continue" be "goto again"?
netconsole should retry. There is no timeout programmed here since that might
lose important information, and you rather want netconsole to survive an odd
unplugged cable then to lose vital debugging information when the system is
busy for instance. (losing link will cause the interface to be down and thus
the queue to be stopped)
> Also, e1000_down does a netif_poll_disable(), but I'm not sure what that
> actually does... Should it prevent netpoll from even trying to send?
polling is for receives. We're basically telling the stack not to poll our
interface anymore.
>> It's generally going to suck, because unlike a polled serial port, the
>> device needs to be put to sleep. But if you're doing suspend to RAM,
>>
> I'm interested in suspend-to-ram. I presume that with suspend-to-disk,
> booting with built-in netconsole will tell me useful stuff; that'll be
> the next experiment.
>
>> you might be able to do something like this:
>>
>> - unhook net device from suspend machinery (possibly just return success)
>> - bounce out of suspend before the final call to ACPI is made
>>
>> Net effect is you do OS-level suspend and resume of everything but the
>> NIC without actually powering down the core. Which should let you
>> debug just about everything.
>
> Well, the machine has to really suspend so that I can see (and debug) a
> mostly normal resume. In particular, I need the hardware to be zapped
> so I can see if it is being restarted properly.
>
> What might work is to change the e1000 suspend routine to save enough
> state for resume to work, but keep the interface up so that netconsole
> can keep transmitting all the way up to the point that the final acpi
> call powers off the machine.
e1000_suspend saves the entire configuration of the device and puts it in
Wake-on-Lan mode, allowing it to be waken up by your 'zap' in the proper way.
> Then the e1000 would resume normally, including restarting the xmit
> queue so that netconsole can start again immediately; any netconsole
> output before the e1000 resume would be lost, of course (I guess it
> could be buffered). That would suit me for now.
after coming out of suspend, e1000_resume is called which basically
reinitializes the entire device. In the entire sequence it is unlikely that
you'll actually be able to maintain netconsole in the first boot stage - the
network device will not be initialized by the kernel yet, and obviously will
be useless until e1000_resume is called!
I'm not sure that tweaking e1000 to survive longer is the answer here, and you
might be better off trying to have netconsole graciously wait
(msleep_interruptable instead of udelay?) In any case, I see the biggest
problem in the early boot stage when all nics are basically uninitialized
until resume starts. You just can't assign it an IP address for instance that
easy, and even resume causes the device to reset and thus link renegotiation,
adding crucial seconds to the time that the link is down, in which time you're
stacking up netconsole messages, or worse, fail to initialize netconsole
I hope this helps - I can't help but thinking that netconsole definately
wasn't designed with this in mind.
Cheers,
Auke
^ permalink raw reply
* Re: Netchannels: netchannel vs. socket. 2:0.
From: Evgeniy Polyakov @ 2006-06-09 5:09 UTC (permalink / raw)
To: Hans Henrik Happe; +Cc: netdev
In-Reply-To: <200606090100.24827.hhh@imada.sdu.dk>
On Fri, Jun 09, 2006 at 01:00:24AM +0200, Hans Henrik Happe (hhh@imada.sdu.dk) wrote:
> On Thursday 08 June 2006 19:15, you wrote:
> > After some enhancements made for netchannel subsystem I'm pleased to
> > announce, that netchannel subsystem outperforms existing layered design
> > both in CPU usage and network speed.
> >
> > Well, after such pretentious introduction I want to cool things down.
> > CPU usage is about 1-2% less for netchannels and network performance is
> > about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think,
> > is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU).
>
> I have followed your work closely and have wondered how it affects latency?
> I have somewhat limited knowledge about TCP and how the kernel handles it, but
> I guess the path from NIC to userspace hasn't increased. What about syscall
> overhead caused by userspace TCP processing?
Path from NIC to userspace was decreased in that way that there are less
number of context switches, much smaller amount of work being done in
softirq (I have not modified driver and still use NAPI), less cache
thrashing due to work ping-ponging and less number of locks.
Number of syscalls is still the same - either one recv() or one
netchannel_control() to read the same block of data.
But since existing socket code is used, gain is not that big, since
sockets are locked, although they should not, skbs are requeued, ACKs
are scheduled, although all that could be changed.
At least receiving part of the netchannel TCP processing could be
different. And my thoughts move in that direction.
> H³
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [patch 06/17] neighbour.c, pneigh_get_next() skips published entry
From: Herbert Xu @ 2006-06-09 4:52 UTC (permalink / raw)
To: Jari Takkala; +Cc: davem, akpm, netdev
In-Reply-To: <413FEEF1743111439393FB76D0221E4804A56900@leopard.zoo.q9networks.com>
Jari Takkala <Jari.Takkala@q9.com> wrote:
>
> I have not checked neigh seqfile iterators, the problem may exist in
> there as well. My patch solves this issue for us, however a more elegant
> solution would be most welcome. Could the root of the problem be that
> *pos is off by one when pneigh_get_idx() is called?
Could you post an exact sequence of commands that reproduces the bug?
That would help us in verifying your fix.
Thanks,
--
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: Fw: [Bugme-new] [Bug 6666] New: invalid tcp socket connection to windows stacks
From: Herbert Xu @ 2006-06-09 4:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, technik, bugme-daemon, davem
In-Reply-To: <20060608103627.23cfc83a.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> If it's buggy you get :
>
> 11:24:15.021572 d59.x-mailer.de.59959 >
> cust.static.212-90-215-40.cybernet.ch.smtp: S 2028538653:2028538653(0) win 5840
> <mss 1460,sackOK,timestamp 243108498 0,nop,wscale 7> (DF)
> 11:24:15.076329 cust.static.212-90-215-40.cybernet.ch.smtp >
> d59.x-mailer.de.59959: S 2328498080:2328498080(0) ack 2028538654 win 16384 <mss
> 1400,nop,wscale 0,nop,nop,timestamp 0
> 0,nop,nop,sackOK>
> 11:24:15.076352 d59.x-mailer.de.59959 >
> cust.static.212-90-215-40.cybernet.ch.smtp: . ack 1 win 46 <nop,nop,timestamp
> 243108503 0> (DF)
...
> ### you should get kind of this:
>
> 13:56:37.203297 d59.x-mailer.de.43286 >
> cust.static.212-90-215-40.cybernet.ch.smtp: S 1489507409:1489507409(0) win 5840
> <mss 1460,sackOK,timestamp 16627469 0,nop,wscale 2> (DF)
> 13:56:37.250827 cust.static.212-90-215-40.cybernet.ch.smtp >
> d59.x-mailer.de.43286: S 783498912:783498912(0) ack 1489507410 win 16384 <mss
> 1400,nop,wscale 0,nop,nop,timestamp 0 0,nop,nop,sackOK>
> 13:56:37.250888 d59.x-mailer.de.43286 >
> cust.static.212-90-215-40.cybernet.ch.smtp: . ack 1 win 1460 <nop,nop,timestamp
> 16627473 0> (DF)
Looks like the problem is window scaling.
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: netif_tx_disable vs netif_stop_queue (possible races?)
From: Herbert Xu @ 2006-06-09 4:41 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev, david-b
In-Reply-To: <4488AF3D.2040601@gentoo.org>
Daniel Drake <dsd@gentoo.org> wrote:
>
> More specifically, we're talking about drivers/usb/net/usbnet.c and the
> usbnet_disconnect() function. The race I am highlighting is that
> usbnet's hard_start_xmit handler (usbnet_start_xmit) may be running when
> the disconnect happens.
>
> Is this a possible scenario?
It should be safe, if only because of the synchronize_net that occurs
before a netdev can be freed.
However, there is definitely room for clean-ups. In particular, LLTX
drivers have changed the meaning of xmit_lock so things like dev_deactivate
no longer carries the same power they used to.
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 RFC] netpoll: don't spin forever sending to stopped queues
From: Jeremy Fitzhardinge @ 2006-06-09 2:15 UTC (permalink / raw)
To: Matt Mackall; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20060608210702.GD24227@waste.org>
Matt Mackall wrote:
> That's odd. Netpoll holds a reference to the device, of course, but so
> does a normal "up" interface. So that shouldn't be the problem.
> Another possibility is that outgoing packets from printks in the
> driver are causing difficulty. Not sure what can be done about that.
>
Here's a patch. I haven't tested it beyond compiling it, and I don't
know if it is actually correct. In this case, it seems pointless to
spin waiting for an even which will never happen. Should
netif_poll_disable() cause netpoll_send_skb() (or something) to not even
bother trying to send? netif_poll_disable seems mysteriously simple to me.
J
--
Subject: netpoll: don't spin forever sending to stopped queues
When transmitting a skb in netpoll_send_skb(), only retry a limited
number of times if the device queue is stopped.
Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org>
diff -r aac813f54617 net/core/netpoll.c
--- a/net/core/netpoll.c Wed Jun 07 14:53:40 2006 -0700
+++ b/net/core/netpoll.c Thu Jun 08 19:00:29 2006 -0700
@@ -280,15 +280,10 @@ static void netpoll_send_skb(struct netp
* network drivers do not expect to be called if the queue is
* stopped.
*/
- if (netif_queue_stopped(np->dev)) {
- np->dev->xmit_lock_owner = -1;
- spin_unlock(&np->dev->xmit_lock);
- netpoll_poll(np);
- udelay(50);
- continue;
- }
-
- status = np->dev->hard_start_xmit(skb, np->dev);
+ status = NETDEV_TX_BUSY;
+ if (!netif_queue_stopped(np->dev))
+ status = np->dev->hard_start_xmit(skb, np->dev);
+
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Jeremy Fitzhardinge @ 2006-06-09 1:56 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <200606082240.31473.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> Please try doing "echo 8 > /proc/sys/kernel/printk" before suspend.
>
Um, why? That would increase the amount of log output, but I don't see
how it would help with netconsole preventing suspend, or not being able
to see console messages on a blank screen after resume.
J
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Jeremy Fitzhardinge @ 2006-06-09 1:54 UTC (permalink / raw)
To: Matt Mackall; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20060608210702.GD24227@waste.org>
Matt Mackall wrote:
> That's odd. Netpoll holds a reference to the device, of course, but so
> does a normal "up" interface. So that shouldn't be the problem.
> Another possibility is that outgoing packets from printks in the
> driver are causing difficulty. Not sure what can be done about that.
>
I only tried once; maybe I misunderstood what was going on. I'll try
again tonight.
Oh, I think I see what's happening. The e1000 suspend routine does this:
if (netif_running(netdev))
e1000_down(adapter);
This leaves the interface up, but it stops the queue. Then
netpoll_send_skb() has this loop:
do {
npinfo->tries--;
spin_lock(&np->dev->xmit_lock);
np->dev->xmit_lock_owner = smp_processor_id();
/*
* network drivers do not expect to be called if the queue is
* stopped.
*/
if (netif_queue_stopped(np->dev)) {
np->dev->xmit_lock_owner = -1;
spin_unlock(&np->dev->xmit_lock);
netpoll_poll(np);
udelay(50);
continue;
}
/* ... */
again: /* proposed */
} while (npinfo->tries > 0);
so this will end up in an infinite loop, since netif_queue_stopped()
will always return true, and it never looks at npinfo->tries. Should
the "continue" be "goto again"?
Also, e1000_down does a netif_poll_disable(), but I'm not sure what that
actually does... Should it prevent netpoll from even trying to send?
> It's generally going to suck, because unlike a polled serial port, the
> device needs to be put to sleep. But if you're doing suspend to RAM,
>
I'm interested in suspend-to-ram. I presume that with suspend-to-disk,
booting with built-in netconsole will tell me useful stuff; that'll be
the next experiment.
> you might be able to do something like this:
>
> - unhook net device from suspend machinery (possibly just return success)
> - bounce out of suspend before the final call to ACPI is made
>
> Net effect is you do OS-level suspend and resume of everything but the
> NIC without actually powering down the core. Which should let you
> debug just about everything.
Well, the machine has to really suspend so that I can see (and debug) a
mostly normal resume. In particular, I need the hardware to be zapped
so I can see if it is being restarted properly.
What might work is to change the e1000 suspend routine to save enough
state for resume to work, but keep the interface up so that netconsole
can keep transmitting all the way up to the point that the final acpi
call powers off the machine.
Then the e1000 would resume normally, including restarting the xmit
queue so that netconsole can start again immediately; any netconsole
output before the e1000 resume would be lost, of course (I guess it
could be buffered). That would suit me for now.
J
^ permalink raw reply
* [PATCH] wan/sdla section fixes
From: Randy.Dunlap @ 2006-06-09 3:36 UTC (permalink / raw)
To: netdev; +Cc: mike.mclagan, khc, akpm
From: Randy Dunlap <rdunlap@xenotime.net>
Priority: tossup.
netdev->set_config can be called at any time, so these references
to __initdata would be a real problem.
However, problem has not been observed AFAIK.
Fix section mismatch warnings:
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data: from .text between 'sdla_set_config' (at offset 0x1b8e) and 'sdla_stats'
WARNING: drivers/net/wan/sdla.o - Section mismatch: reference to .init.data: from .text between 'sdla_set_config' (at offset 0x1e76) and 'sdla_stats'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/net/wan/sdla.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2617-rc6.orig/drivers/net/wan/sdla.c
+++ linux-2617-rc6/drivers/net/wan/sdla.c
@@ -60,9 +60,9 @@
static const char* version = "SDLA driver v0.30, 12 Sep 1996, mike.mclagan@linux.org";
-static unsigned int valid_port[] __initdata = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360, 0x380, 0x390};
+static unsigned int valid_port[] = { 0x250, 0x270, 0x280, 0x300, 0x350, 0x360, 0x380, 0x390};
-static unsigned int valid_mem[] __initdata = {
+static unsigned int valid_mem[] = {
0xA0000, 0xA2000, 0xA4000, 0xA6000, 0xA8000, 0xAA000, 0xAC000, 0xAE000,
0xB0000, 0xB2000, 0xB4000, 0xB6000, 0xB8000, 0xBA000, 0xBC000, 0xBE000,
0xC0000, 0xC2000, 0xC4000, 0xC6000, 0xC8000, 0xCA000, 0xCC000, 0xCE000,
---
^ permalink raw reply
* Re: Using netconsole for debugging suspend/resume
From: Andi Kleen @ 2006-06-09 3:46 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Matt Mackall, Linux Kernel Mailing List, netdev
In-Reply-To: <44886381.9050506@goop.org>
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
> I've been trying to get suspend/resume working well on my new laptop.
> In general, netconsole has been pretty useful for extracting oopses and
> other messages, but it is of more limited help in debugging the actual
> suspend/resume cycle. The problem looks like the e1000 driver won't
> suspend while netconsole is using it, so I have to rmmod/modprobe
> netconsole around the actual suspend/resume.
If your laptop has firewire you can also use firescope.
(ftp://ftp.suse.com/pub/people/ak/firescope/)
> This is a big problem during resume because the screen is also blank, so
> I get no useful clue as to what went wrong when things go wrong. I'm
> wondering if there's some way to keep netconsole alive to the last
> possible moment during suspend, and re-woken as soon as possible during
> resume. It would be nice to have a clean solution, but I'm willing to
> use a bletcherous hack if that's what it takes.
FW keeps running as long as nobody resets the ieee1394 chip.
Networking is much more complex and will likely never work well for such
low level debug situations. Netconsole is mostly useful to catch the
odd oops during runtime.
-Andi
^ permalink raw reply
* Re: Firewall question
From: Andi Kleen @ 2006-06-09 3:43 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Alex Davis, netfilter, netdev
In-Reply-To: <20060608192628.GA561@csclub.uwaterloo.ca>
> Well the DSL modem only transfers whatever data the ISP end sends to it,
> which in your case is just PPP packets (LCC or LCP I think). No one out
> on the internet
No one out on the internet, but it would be trivial for someone outside
his house. All his traffic will be on a long unsecured cable.
That is why I would never bridge home ethernet traffic onto a DSL line.
-Andi
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Randy.Dunlap @ 2006-06-09 2:49 UTC (permalink / raw)
To: Jeff Garzik; +Cc: dsd, netdev
In-Reply-To: <4488DF85.3090901@garzik.org>
On Thu, 08 Jun 2006 22:40:05 -0400 Jeff Garzik wrote:
> Randy.Dunlap wrote:
> > Conversely, any reason to use the RealTek r1000 driver?
>
> FWIW, RealTek emailed me about merging r1000. I suggested that, if the
> register sets were similar, that r8169 should be updated instead, to
> preserve compatibility with existing users (and not lose existing work).
Sounds good to me. I'm not terribly interested in seeing
multiple drivers for the same hardware in the kernel tree.
---
~Randy
^ permalink raw reply
* Re: [RFT] Realtek 8168 ethernet support
From: Jeff Garzik @ 2006-06-09 2:40 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Daniel Drake, netdev
In-Reply-To: <20060608143133.7e36a0b7.rdunlap@xenotime.net>
Randy.Dunlap wrote:
> Conversely, any reason to use the RealTek r1000 driver?
FWIW, RealTek emailed me about merging r1000. I suggested that, if the
register sets were similar, that r8169 should be updated instead, to
preserve compatibility with existing users (and not lose existing work).
Jeff
^ permalink raw reply
* Re: [IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-06-09 2:23 UTC (permalink / raw)
To: kaber, davem; +Cc: netdev
In-Reply-To: <4488AB2E.3030301@trash.net>
Hello.
In article <4488AB2E.3030301@trash.net> (at Fri, 09 Jun 2006 00:56:46 +0200), Patrick McHardy <kaber@trash.net> says:
Okay, thanks.
I think it is better to eliminate these magic numbers.
How about this?
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..b5267c6 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2860,6 +2860,11 @@ inet6_rtm_newaddr(struct sk_buff *skb, s
return inet6_addr_add(ifm->ifa_index, pfx, ifm->ifa_prefixlen);
}
+/* Maximum length of ifa_cacheinfo attributes */
+#define INET6_IFADDR_RTA_SPACE \
+ RTA_SPACE(16) /* IFA_ADDRESS */ + \
+ RTA_SPACE(sizeof(struct ifa_cacheinfo)) /* CACHEINFO */
+
static int inet6_fill_ifaddr(struct sk_buff *skb, struct inet6_ifaddr *ifa,
u32 pid, u32 seq, int event, unsigned int flags)
{
@@ -3092,7 +3097,7 @@ static int inet6_dump_ifacaddr(struct sk
static void inet6_ifa_notify(int event, struct inet6_ifaddr *ifa)
{
struct sk_buff *skb;
- int size = NLMSG_SPACE(sizeof(struct ifaddrmsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifaddrmsg) + INET6_IFADDR_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
@@ -3142,6 +3147,16 @@ static void inline ipv6_store_devconf(st
#endif
}
+/* Maximum length of ifinfomsg attributes */
+#define INET6_IFINFO_RTA_SPACE \
+ RTA_SPACE(IFNAMSIZ) /* IFNAME */ + \
+ RTA_SPACE(MAX_ADDR_LEN) /* ADDRESS */ + \
+ RTA_SPACE(sizeof(u32)) /* MTU */ + \
+ RTA_SPACE(0) /* PROTINFO */ + \
+ RTA_SPACE(sizeof(u32)) /* FLAGS */ + \
+ RTA_SPACE(sizeof(struct ifla_cacheinfo)) /* CACHEINFO */ + \
+ RTA_SPACE(sizeof(__s32[DEVCONF_MAX])) /* CONF */
+
static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev,
u32 pid, u32 seq, int event, unsigned int flags)
{
@@ -3235,8 +3250,7 @@ static int inet6_dump_ifinfo(struct sk_b
void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
{
struct sk_buff *skb;
- /* 128 bytes ?? */
- int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifinfomsg) + INET6_IFINFO_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
@@ -3252,6 +3266,11 @@ void inet6_ifinfo_notify(int event, stru
netlink_broadcast(rtnl, skb, 0, RTNLGRP_IPV6_IFINFO, GFP_ATOMIC);
}
+/* Maximum length of prefix_cacheinfo attributes */
+#define INET6_PREFIX_RTA_SPACE \
+ RTA_SPACE(sizeof(((struct prefix_info *)NULL)->prefix)) /* ADDRESS */ + \
+ RTA_SPACE(sizeof(struct prefix_cacheinfo)) /* CACHEINFO */
+
static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev,
struct prefix_info *pinfo, u32 pid, u32 seq,
int event, unsigned int flags)
@@ -3296,7 +3315,7 @@ static void inet6_prefix_notify(int even
struct prefix_info *pinfo)
{
struct sk_buff *skb;
- int size = NLMSG_SPACE(sizeof(struct prefixmsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct prefixmsg) + INET6_PREFIX_RTA_SPACE);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
--
YOSHIFUJI Hideaki @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply related
* Re: [RFT] Realtek 8168 ethernet support
From: Francois Romieu @ 2006-06-08 23:41 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Daniel Drake, netdev
In-Reply-To: <20060608143133.7e36a0b7.rdunlap@xenotime.net>
Randy.Dunlap <rdunlap@xenotime.net> :
[...]
> static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
> { 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> {0,}
> };
>
> Any reason not to include all of those?
Nothing worrying:
- 0x8167 and 0x8168 use a different PCI region;
- some phy differences. They appear when the r1000 driver is
compared to the previous r8169 driver from realtek.
I'll pack it with other changes.
> Conversely, any reason to use the RealTek r1000 driver?
Feel free to read it and make your own mind.
--
Ueimor
^ permalink raw reply
* netif_tx_disable vs netif_stop_queue (possible races?)
From: Daniel Drake @ 2006-06-08 23:14 UTC (permalink / raw)
To: netdev; +Cc: David Brownell
Hi,
In order to avoid disconnect races in ZD1211, I'm trying to convince
myself that other USB network drivers are race-free (and why).
I brought up a possible issue in usbnet with David Brownell, but it
appears neither of us are 100% clear on the details, so it would be good
to get some extra clarification.
USB devices can be yanked out by the user at *any* time, and typically
free_netdev is called in the disconnect handler, which frees all
device-specific structures.
The issue I brought up is that code using these structures may be
running concurrently on another CPU when the disconnect handler is
invoked, resulting in access to freed data.
More specifically, we're talking about drivers/usb/net/usbnet.c and the
usbnet_disconnect() function. The race I am highlighting is that
usbnet's hard_start_xmit handler (usbnet_start_xmit) may be running when
the disconnect happens.
Is this a possible scenario?
My thoughts on avoiding this are to ensure that the TX queue is stopped
and all current transmissions in usbnet_stop (the netdev->stop hook). I
understand that the stop function is called during disconnect, because
usbnet_disconnect() calls unregister_netdev(). The stop function already
has a call to netif_stop_queue but (based on my knowledge from LDD3)
this is not enough.
My understanding is that netif_stop_queue() should be used only inside a
hard_start_xmit function, when it wants to make sure that no more
transmissions are started until the queue is reopened.
I suggested that we use netif_tx_disable here, which is effectively the
same but because it takes the lock, it guarantees that no
hard_start_xmit transmissions are running on any CPU when it returns.
David pointed out that netif_tx_disable is rarely used, and a large
number of drivers call netif_stop_queue in their stop function, so if
what I suggest is true, there may be many such potential races
elsewhere. Am I missing something simple?
Thanks,
Daniel
^ permalink raw reply
* Re: Netchannels: netchannel vs. socket. 2:0.
From: Hans Henrik Happe @ 2006-06-08 23:00 UTC (permalink / raw)
To: netdev
In-Reply-To: <20060608171555.GA10273@2ka.mipt.ru>
On Thursday 08 June 2006 19:15, you wrote:
> After some enhancements made for netchannel subsystem I'm pleased to
> announce, that netchannel subsystem outperforms existing layered design
> both in CPU usage and network speed.
>
> Well, after such pretentious introduction I want to cool things down.
> CPU usage is about 1-2% less for netchannels and network performance is
> about 1-2 MB higher and sometimes exceeds 84 MB/sec which, I think,
> is maximum for given network setup (e1000 receive, r8169 send, 1500 MTU).
I have followed your work closely and have wondered how it affects latency?
I have somewhat limited knowledge about TCP and how the kernel handles it, but
I guess the path from NIC to userspace hasn't increased. What about syscall
overhead caused by userspace TCP processing?
H³
^ permalink raw reply
* [IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
From: Patrick McHardy @ 2006-06-08 22:56 UTC (permalink / raw)
To: David S. Miller; +Cc: Kernel Netdev Mailing List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1090 bytes --]
[IPV6]: Fix RTNLGRP_IPV6_IFINFO netlink notifications
The allocated skb is too small for the message, which results in an EINVAL
getting reported to the (innocent) multicast listeners.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit f71bc8ace692302ad3a80d84b8cbccbb14e88fe5
tree 21ccfa89e911ff8e6bda04ab817367f2ac4e3173
parent 1def630a6a49dda5bc89dfbd86656293640456f0
author Patrick McHardy <kaber@trash.net> Wed, 07 Jun 2006 09:25:26 +0200
committer Patrick McHardy <kaber@trash.net> Wed, 07 Jun 2006 09:25:26 +0200
net/ipv6/addrconf.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 445006e..cc81cab 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3235,8 +3235,7 @@ static int inet6_dump_ifinfo(struct sk_b
void inet6_ifinfo_notify(int event, struct inet6_dev *idev)
{
struct sk_buff *skb;
- /* 128 bytes ?? */
- int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128);
+ int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+172);
skb = alloc_skb(size, GFP_ATOMIC);
if (!skb) {
^ permalink raw reply related
* Re: [PATCH 2.6.17-rc6-mm1 ] net: RFC 3828-compliant UDP-Lite support
From: David Miller @ 2006-06-08 22:13 UTC (permalink / raw)
To: gerrit; +Cc: jmorris, alan, kuznet, pekkas, yoshfuji, kaber, linux-kernel,
netdev
In-Reply-To: <200606082109.34338.gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 8 Jun 2006 21:09:33 +0100
> That is why I held back regarding the IPv6 port: I can ensure that
> this (IPv4) code is up to standard and to date, but am lacking the
> required additional time to implement the same for IPv6. I am
> trying to contact people to help with the port, but for the moment I
> will take responsibility only for the IPv4 version.
It's not like an ipv6 port is such a big pile of work.
I'd say it would take you an afternoon, max.
You don't have to test it to the point where it is ISO9000 compliant,
that's not what is being asked of you.
^ permalink raw reply
* [PATCH 8/10] Add Vitesse 8244 PHY for MPC8641 HPCN platform.
From: Jon Loeliger @ 2006-06-08 22:02 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, netdev, jeff
Signed-off-by: Kriston Carson <KristonCarson@freescale.com>
Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
---
drivers/net/Kconfig | 6 +-
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1
drivers/net/phy/vitesse.c | 112 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index bdaaad8..c1c2758 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2179,11 +2179,11 @@ config SPIDER_NET
config GIANFAR
tristate "Gianfar Ethernet"
- depends on 85xx || 83xx
+ depends on 85xx || 83xx || PPC_86xx
select PHYLIB
help
- This driver supports the Gigabit TSEC on the MPC85xx
- family of chips, and the FEC on the 8540
+ This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
+ and MPC86xx family of chips, and the FEC on the 8540.
config GFAR_NAPI
bool "NAPI Support"
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index fa39b94..76e51b1 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -44,6 +44,11 @@ config CICADA_PHY
depends on PHYLIB
---help---
Currently supports the cis8204
+config VITESSE_PHY
+ tristate "Drivers for the Vitesse PHYs"
+ depends on PHYLIB
+ ---help---
+ Currently supports the vsc8244
endmenu
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e4116a5..a8d066e 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_DAVICOM_PHY) += davicom.o
obj-$(CONFIG_CICADA_PHY) += cicada.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
+obj-$(CONFIG_VITESSE_PHY) += vitesse.o
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
new file mode 100644
index 0000000..ffd215d
--- /dev/null
+++ b/drivers/net/phy/vitesse.c
@@ -0,0 +1,112 @@
+/*
+ * Driver for Vitesse PHYs
+ *
+ * Author: Kriston Carson
+ *
+ * Copyright (c) 2005 Freescale Semiconductor, Inc.
+ *
+ * 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/kernel.h>
+#include <linux/module.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+
+/* Vitesse Extended Control Register 1 */
+#define MII_VSC8244_EXT_CON1 0x17
+#define MII_VSC8244_EXTCON1_INIT 0x0000
+
+/* Vitesse Interrupt Mask Register */
+#define MII_VSC8244_IMASK 0x19
+#define MII_VSC8244_IMASK_IEN 0x8000
+#define MII_VSC8244_IMASK_SPEED 0x4000
+#define MII_VSC8244_IMASK_LINK 0x2000
+#define MII_VSC8244_IMASK_DUPLEX 0x1000
+#define MII_VSC8244_IMASK_MASK 0xf000
+
+/* Vitesse Interrupt Status Register */
+#define MII_VSC8244_ISTAT 0x1a
+#define MII_VSC8244_ISTAT_STATUS 0x8000
+#define MII_VSC8244_ISTAT_SPEED 0x4000
+#define MII_VSC8244_ISTAT_LINK 0x2000
+#define MII_VSC8244_ISTAT_DUPLEX 0x1000
+
+/* Vitesse Auxiliary Control/Status Register */
+#define MII_VSC8244_AUX_CONSTAT 0x1c
+#define MII_VSC8244_AUXCONSTAT_INIT 0x0004
+#define MII_VSC8244_AUXCONSTAT_DUPLEX 0x0020
+#define MII_VSC8244_AUXCONSTAT_SPEED 0x0018
+#define MII_VSC8244_AUXCONSTAT_GBIT 0x0010
+#define MII_VSC8244_AUXCONSTAT_100 0x0008
+
+MODULE_DESCRIPTION("Vitesse PHY driver");
+MODULE_AUTHOR("Kriston Carson");
+MODULE_LICENSE("GPL");
+
+static int vsc824x_config_init(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_write(phydev, MII_VSC8244_AUX_CONSTAT,
+ MII_VSC8244_AUXCONSTAT_INIT);
+ if (err < 0)
+ return err;
+
+ err = phy_write(phydev, MII_VSC8244_EXT_CON1,
+ MII_VSC8244_EXTCON1_INIT);
+ return err;
+}
+
+static int vsc824x_ack_interrupt(struct phy_device *phydev)
+{
+ int err = phy_read(phydev, MII_VSC8244_ISTAT);
+
+ return (err < 0) ? err : 0;
+}
+
+static int vsc824x_config_intr(struct phy_device *phydev)
+{
+ int err;
+
+ if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
+ err = phy_write(phydev, MII_VSC8244_IMASK,
+ MII_VSC8244_IMASK_MASK);
+ else
+ err = phy_write(phydev, MII_VSC8244_IMASK, 0);
+ return err;
+}
+
+/* Vitesse 824x */
+static struct phy_driver vsc8244_driver = {
+ .phy_id = 0x000fc6c2,
+ .name = "Vitesse VSC8244",
+ .phy_id_mask = 0x000fffc0,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &vsc824x_config_init,
+ .config_aneg = &genphy_config_aneg,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &vsc824x_ack_interrupt,
+ .config_intr = &vsc824x_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+static int __init vsc8244_init(void)
+{
+ return phy_driver_register(&vsc8244_driver);
+}
+
+static void __exit vsc8244_exit(void)
+{
+ phy_driver_unregister(&vsc8244_driver);
+}
+
+module_init(vsc8244_init);
+module_exit(vsc8244_exit);
^ permalink raw reply related
* [git patches] net driver fixes
From: Jeff Garzik @ 2006-06-08 21:39 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Just got back from travelling, and am catching up. Thanks to Andrew for
working with me via email while I was on the road, he pushed a couple
patches already for me.
Here are the netdev fixes that were in my 'Pending' folder. I've got a
couple libata fixes to push as well, those may not come until tomorrow.
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/e1000/e1000_ethtool.c | 5 +++-
drivers/net/e1000/e1000_main.c | 8 +------
drivers/net/wireless/bcm43xx/bcm43xx_dma.c | 31 ++++++++++++++++++++---------
3 files changed, 28 insertions(+), 16 deletions(-)
Auke Kok:
e1000: fix ethtool test irq alloc as "probe"
e1000: remove risky prefetch on next_skb->data
Michael Buesch:
bcm43xx: add DMA rx poll workaround to DMA4
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index ecccca3..d1c705b 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -870,13 +870,16 @@ e1000_intr_test(struct e1000_adapter *ad
*data = 0;
/* Hook up test interrupt handler just for this test */
- if (!request_irq(irq, &e1000_test_intr, 0, netdev->name, netdev)) {
+ if (!request_irq(irq, &e1000_test_intr, SA_PROBEIRQ, netdev->name,
+ netdev)) {
shared_int = FALSE;
} else if (request_irq(irq, &e1000_test_intr, SA_SHIRQ,
netdev->name, netdev)){
*data = 1;
return -1;
}
+ DPRINTK(PROBE,INFO, "testing %s interrupt\n",
+ (shared_int ? "shared" : "unshared"));
/* Disable all the interrupts */
E1000_WRITE_REG(&adapter->hw, IMC, 0xFFFFFFFF);
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ed15fca..97e71a4 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3519,7 +3519,7 @@ #endif
buffer_info = &rx_ring->buffer_info[i];
while (rx_desc->status & E1000_RXD_STAT_DD) {
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
u8 status;
#ifdef CONFIG_E1000_NAPI
if (*work_done >= work_to_do)
@@ -3537,8 +3537,6 @@ #endif
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
@@ -3668,7 +3666,7 @@ #endif
struct e1000_buffer *buffer_info, *next_buffer;
struct e1000_ps_page *ps_page;
struct e1000_ps_page_dma *ps_page_dma;
- struct sk_buff *skb, *next_skb;
+ struct sk_buff *skb;
unsigned int i, j;
uint32_t length, staterr;
int cleaned_count = 0;
@@ -3697,8 +3695,6 @@ #endif
prefetch(next_rxd);
next_buffer = &rx_ring->buffer_info[i];
- next_skb = next_buffer->skb;
- prefetch(next_skb->data - NET_IP_ALIGN);
cleaned = TRUE;
cleaned_count++;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index bbecba0..d0318e5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -624,25 +624,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -660,16 +663,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -839,8 +842,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
^ permalink raw reply related
* Re: [RFT] Realtek 8168 ethernet support
From: Randy.Dunlap @ 2006-06-08 21:31 UTC (permalink / raw)
To: Daniel Drake; +Cc: netdev
In-Reply-To: <20060601200200.A0E0689D05D@zog.reactivated.net>
On Thu, 1 Jun 2006 21:02:00 +0100 (BST) Daniel Drake wrote:
> I've produced this patch which should allow the r8169 driver to work with the
> new Realtek 8168 chips. These are found in PCI-Express form and onboard some
> newer motherboards.
>
> Does anyone own this hardware? I'm looking for someone to test it before I
> send it on.
>
> Signed-off-by: Daniel Drake <dsd@gentoo.org>
>
> Index: linux/drivers/net/r8169.c
> ===================================================================
> --- linux.orig/drivers/net/r8169.c
> +++ linux/drivers/net/r8169.c
> @@ -184,6 +184,7 @@ static const struct {
>
> static struct pci_device_id rtl8169_pci_tbl[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
> + { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
> { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
> { PCI_DEVICE(0x16ec, 0x0116), },
> { PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, 0x0024, },
The (GPL) RealTek driver (from
http://www.realtek.com.tw/downloads/downloads1-3.aspx?lineid=1&famid=4&series=2003072&Software=True)
contains this PCI device table:
static struct pci_device_id r1000_pci_tbl[] __devinitdata = {
{ 0x10ec, 0x8169, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8167, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8168, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ 0x10ec, 0x8136, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{0,}
};
Any reason not to include all of those?
Conversely, any reason to use the RealTek r1000 driver?
> @@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
> struct net_device *dev;
> struct rtl8169_private *tp;
> int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
> + u32 mmio_base = 0;
>
> assert(ioaddr_out != NULL);
>
> @@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
> }
> }
>
> - /* make sure PCI base addr 1 is MMIO */
> - if (!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
> - if (netif_msg_probe(tp)) {
> - printk(KERN_ERR PFX
> - "region #1 not an MMIO resource, aborting\n");
> - }
> - rc = -ENODEV;
> - goto err_out_mwi;
> + /* find MMIO resource: this varies between 8168 and 8169 */
> + for (i = 0; i < 5; i++) {
> + /* check resource type */
> + if (!(pci_resource_flags(pdev, i) & IORESOURCE_MEM))
> + continue;
> +
> + /* check for weird/broken PCI region reporting */
> + if (pci_resource_len(pdev, i) < R8169_REGS_SIZE)
> + continue;
> +
> + mmio_base = pci_resource_start(pdev, i);
> + break;
> }
> - /* check for weird/broken PCI region reporting */
> - if (pci_resource_len(pdev, 1) < R8169_REGS_SIZE) {
> +
> + if (mmio_base == 0) {
> if (netif_msg_probe(tp)) {
> printk(KERN_ERR PFX
> - "Invalid PCI region size(s), aborting\n");
> + "couldn't find valid MMIO resource, aborting\n");
> }
> rc = -ENODEV;
> goto err_out_mwi;
> @@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
> pci_set_master(pdev);
>
> /* ioremap MMIO region */
> - ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
> + ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
> if (ioaddr == NULL) {
> if (netif_msg_probe(tp))
> printk(KERN_ERR PFX "cannot remap MMIO, aborting\n");
> -
---
~Randy
^ permalink raw reply
* Re: New tulip maintainer...
From: Valerie Henson @ 2006-06-08 21:24 UTC (permalink / raw)
To: Grant Grundler; +Cc: Jeff Garzik, Andrew Morton, Netdev List
In-Reply-To: <20060608160639.GH8246@colo.lackof.org>
On 6/8/06, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Thu, Jun 08, 2006 at 11:41:28AM -0400, Jeff Garzik wrote:
> > Now that we have a new tulip maintainer, perhaps a resend of the
> > long-outstanding tulip phy patches could be resent?
>
> All the tulip patches I have are archived here:
> ftp://ftp.parisc-linux.org/patches/
>
> Anything else tulip I've been involved with is available
> via CVS from cvs.parisc-linux.org/linux-2.6/
>
> Thibaut Varene has also committed his changes to that CVS.
Hey folks,
Just a quick note to say that, yes, in a moment of weak-willed
delusion, I did let Jeff pressure me into becoming the tulip
maintainer. I will accept tokens of condolence in the form of beer,
money, and old tulip cards (email me for my shipping address).
I'm going to be a tiny bit busy the next couple of weeks - minor
things like running the file systems workshop and moving house - but I
am paying attention and will start testing and shipping patches as
soon as possible.
One quick note: please use my spiffy val_henson@linux.intel.com
address (see From: address) for Linux stuff. Besides giving props to
my employer, it's much easier to send/receive patches from that
account.
-VAL
^ 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