strange tcp behavior
1186035057.207629127.0.0.1 -> 127.0.0.1TCP 5 > smtp [SYN]
Seq=0 Len=0
1186035057.207632127.0.0.1 -> 127.0.0.1TCP smtp > 5 [SYN, ACK]
Seq=0 Ack=1 Win=32792 Len=0 MSS=16396
1186035057.207666127.0.0.1 -> 127.0.0.1TCP 5 > smtp [ACK]
Seq=1 Ack=1 Win=1500 Len=0
1186035057.207699127.0.0.1 -> 127.0.0.1SMTP Command: EHLO localhost
1186035057.207718127.0.0.1 -> 127.0.0.1TCP smtp > 5 [ACK]
Seq=1 Ack=17 Win=32792 Len=0
1186035057.207736127.0.0.1 -> 127.0.0.1TCP 5 > smtp [RST]
Seq=17 Len=0
1186035057.223934127.0.0.1 -> 127.0.0.1TCP 33787 > 5 [RST,
ACK] Seq=0 Ack=0 Win=32792 Len=0
Can someone please comment as to why, tcp stack sends rst packet from the
wrong source port in this situation.
This is the same problem that was described in my first two posts, witch
unfortunately nobody seemed to notice.
Here is source code witch can reproduce the behavior described, the client
side code is a complete mess but with a little bit it works.
Server:
#include
#include
#include
#include
#include
void main(void) {
int ms;
int ss;
struct sockaddr_in sa;
char *str = "HELLO FRIEND";
struct pollfd fd;
int flags;
ms = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
flags = fcntl(ms, F_GETFL, 0);
fcntl(ms, F_SETFL, flags | O_NONBLOCK);
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = htonl(INADDR_ANY);
sa.sin_port = htons(25);
bind(ms, (struct sockaddr *) &sa, sizeof(sa));
listen(ms, 0);
fd.fd = ms;
fd.events = POLLIN;
while(poll(&fd, 1, -1)) {
ss = accept(ms, NULL, NULL);
usleep(1);
send(ss, str, strlen(str), MSG_NOSIGNAL);
close(ss);
memset(&fd, 0, sizeof(fd));
fd.fd = ms;
fd.events = POLLIN;
}
}
Client:
#include
#include
#include
#include
#include
#include
//#include
//#include
struct sockaddr_in localaddr;
struct sockaddr_in remoteaddr;
struct sockaddr rawaddr;
int sdl, sdr;
struct tcphdr header;
struct pheader_t {
uint32_t saddr;
uint32_t daddr;
uint8_t r;
uint8_t protocol;
uint16_t length;
};
struct pheader_t pheader;
unsigned short tbuf[2048];
unsigned char buf[2048];
char *msg = "EHLO localhost\r\n";
unsigned char *p;
char *src_addr = "127.0.0.1";
char *dst_addr = "127.0.0.1";
unsigned short sprt = 5;
unsigned short dprt = 25;
struct timeval tv;
unsigned seq, ack_seq;
int data;
void mysend(void) {
int i, sum;
int len;
if(data) {
len = strlen(msg);
memcpy((char *) tbuf + sizeof(pheader) + sizeof(header),
msg, len);
} else
len = 0;
bzero(&pheader, sizeof(pheader));
pheader.saddr = (in_addr_t) inet_addr(src_addr);
pheader.daddr = (in_addr_t) inet_addr(dst_addr);
pheader.protocol = 6;
pheader.length = htons(sizeof(header) + len);
memcpy(tbuf, &pheader, sizeof(pheader));
memcpy((char *) tbuf + sizeof(pheader), &header, sizeof(header));
sum = 0;
for(i = 0; i < (sizeof(pheader) + sizeof(header)) / 2 + len / 2;
i++) {
sum += tbuf[i];
sum = (sum & 0x) + (sum >> 16);
}
header.check = ~sum;
memcpy((char *) tbuf + sizeof(pheader), &header, sizeof(header));
sendto(sdr, (char *) tbuf + sizeof(pheader), sizeof(header) +
len, 0, (struct sockaddr *) &remoteaddr, sizeof(remoteaddr));
}
void main(void)
{
gettimeofday(&tv, NULL);
srand(tv.tv_sec & tv.tv_usec);
remoteaddr.sin_family = AF_INET;
remoteaddr.sin_addr.s_addr = (in_addr_t) inet_addr(dst_addr);
sdl = socket(PF_INET, SOCK_PACKET, htons(ETH_P_ALL));
strcpy(rawaddr.sa_data, "lo");
bind(sdl, (struct sockaddr *) &rawaddr, sizeof(rawaddr));
sdr = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
bzero(&header, sizeof(header));
header.source = htons(sprt);
header.dest = htons(dprt);
seq = rand();
ack_seq = 0;
header.seq = htonl(seq);
header.ack_seq = htonl(ack_seq);
header.doff = sizeof(header) / 4;
header.syn = 1;
header.window = htons(1500);
mysend();
while(1) {
recvfrom(sdl, buf, sizeof(buf), 0, NULL, NULL);
// p = buf + (*buf & 0x0f) * 4;
p = (buf + 14) + (*(buf + 14) & 0x0f) * 4;
if(ntohs(((struct tcphdr *)p)->source) == dprt &&
ntohs(((struct tcphdr *)p)->dest) == sprt && ((struct
tcphdr *)p)->syn == 1 && ((struct tcphdr *)p)->ack == 1)
break;
}
bzero(&header, sizeof(header));
header.source = htons(sprt);
header.dest = htons(dpr
Re: [PATCH 67] net/ipv4/route.c: mostly kmalloc + memset conversion to k[cz]alloc
From: Mariusz Kozlowski <[EMAIL PROTECTED]> Date: Tue, 31 Jul 2007 23:55:02 +0200 > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 66] net/ipv4/raw.c: kmalloc + memset conversion to kzalloc
From: Mariusz Kozlowski <[EMAIL PROTECTED]> Date: Tue, 31 Jul 2007 23:54:00 +0200 > Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23-rc1][NETFILTER] nf_conntrack_reasm: adding icmpv6_send code(TIME EXCEEDED).
Hi, From: Masayuki Nakagawa <[EMAIL PROTECTED]> Date: Wed, 01 Aug 2007 19:53:20 -0700 > I ran the TAHI conformance test on a kernel, which CONFIG_NF_CONNTRACK_IPV6 > is enabled. And then it showed a result including a couple of failure. > The all of failed items are related to TIME EXCEEDED. > > The test procedure is here. > Tester Target > | | > |-->| > | Echo Request| > | (1st fragment) | > | | > | wait for 65 sec. | > | | > |<--| > |ICMPv6 Error | > > (1) Tester sends a first fragment of ICMPv6 echo request to Target. > (2) Wait for over 60 sec. > (3) If target replies a ICMPv6 error message(Time Exceeded) to Tester, > then this test is success, otherwise it's failure. > > The reason of the failure is very simple, it's because icmpv6_send code are > missing in nf_ct_frag6_expire function(nf_conntrack_reasm.c). > The change is to add the missing code. > > In RFC2460, the specification regarding Time Exceeded is described, > but it's defined as "should". So, there is no specification violation here. > Therefore I'm not sure whether this change is appropriate or not. > > I will appreciate any comments. Thanks. Main usage of nf_conntrack_ipv6 is for firewall today. I think that silently sending error is not preferable. Moreover, RFC2460 says 4.5 Fragment Header The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.) This means that IPv6 router doesn't send Too Big error for forwarded packets. At least it's better to be configurable if people want to do that. Second idea is to pass such fragments to next network processing instead of dropping them. But I'm not sure that it is possible. -- Yasuyuki Kozakai - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] Removal of duplicated include net/wanrouter/wanmain.c
From: Michal Piotrowski <[EMAIL PROTECTED]> Date: Wed, 01 Aug 2007 19:58:53 +0200 > Hi, > > There is no need to include linux/init.h twice ... > Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> Patch applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23-rc1][NETFILTER] nf_conntrack_reasm: adding icmpv6_send code(TIME EXCEEDED).
Please make sure to CC: netfilter patches to [EMAIL PROTECTED] and [EMAIL PROTECTED] as is listed in the linux/MAINTAINERS file. Thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.23-rc1][NETFILTER] nf_conntrack_reasm: adding icmpv6_send code(TIME EXCEEDED).
I ran the TAHI conformance test on a kernel, which CONFIG_NF_CONNTRACK_IPV6
is enabled. And then it showed a result including a couple of failure.
The all of failed items are related to TIME EXCEEDED.
The test procedure is here.
Tester Target
| |
|-->|
| Echo Request|
| (1st fragment) |
| |
| wait for 65 sec. |
| |
|<--|
|ICMPv6 Error |
(1) Tester sends a first fragment of ICMPv6 echo request to Target.
(2) Wait for over 60 sec.
(3) If target replies a ICMPv6 error message(Time Exceeded) to Tester,
then this test is success, otherwise it's failure.
The reason of the failure is very simple, it's because icmpv6_send code are
missing in nf_ct_frag6_expire function(nf_conntrack_reasm.c).
The change is to add the missing code.
In RFC2460, the specification regarding Time Exceeded is described,
but it's defined as "should". So, there is no specification violation here.
Therefore I'm not sure whether this change is appropriate or not.
I will appreciate any comments. Thanks.
Signed-off-by: Masayuki Nakagawa <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv6/netfilter/nf_conntrack_reasm.c
===
--- linux-2.6.orig/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ linux-2.6/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -76,6 +76,7 @@ struct nf_ct_frag6_queue
struct sk_buff *fragments;
int len;
int meat;
+ int iif;
ktime_t stamp;
unsigned intcsum;
__u8last_in;/* has first/last segment
arrived? */
@@ -279,6 +280,7 @@ static void nf_ct_frag6_evictor(void)
static void nf_ct_frag6_expire(unsigned long data)
{
struct nf_ct_frag6_queue *fq = (struct nf_ct_frag6_queue *) data;
+ struct net_device *dev = NULL;
spin_lock(&fq->lock);
@@ -287,7 +289,26 @@ static void nf_ct_frag6_expire(unsigned
fq_kill(fq);
+ dev = dev_get_by_index(fq->iif);
+ if (!dev)
+ goto out;
+
+ /* Don't send error if the first segment did not arrive. */
+ if (!(fq->last_in&FIRST_IN) || !fq->fragments)
+ goto out;
+
+ /*
+ But use as source device on which LAST ARRIVED
+ segment was received. And do not use fq->dev
+ pointer directly, device might already disappeared.
+*/
+ fq->fragments->dev = dev;
+ icmpv6_send(fq->fragments, ICMPV6_TIME_EXCEED, ICMPV6_EXC_FRAGTIME, 0,
dev);
+
out:
+ if (dev)
+ dev_put(dev);
+
spin_unlock(&fq->lock);
fq_put(fq, NULL);
}
@@ -534,6 +555,9 @@ static int nf_ct_frag6_queue(struct nf_c
else
fq->fragments = skb;
+ if (skb->dev)
+ fq->iif = skb->dev->ifindex;
+
skb->dev = NULL;
fq->stamp = skb->tstamp;
fq->meat += skb->len;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Wed, Aug 01, 2007 at 11:59:21AM +0200, Jarek Poplawski wrote: > On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote: > > Jarek Poplawski wrote: > > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote: > > >> Jarek Poplawski wrote: > > >>> On 28-07-2007 20:42, Gabriel C wrote: > > Andrew Morton wrote: > > > On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[EMAIL PROTECTED]> > > > wrote: > > > > > >> Hi, > > >> > > >> I got this compile error with a randconfig ( > > >> http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). > > >> > > >> ... > > >> > > >> net/core/netpoll.c: In function 'netpoll_poll': > > >> net/core/netpoll.c:155: error: 'struct net_device' has no member > > >> named 'poll_controller' > > >> net/core/netpoll.c:159: error: 'struct net_device' has no member > > >> named 'poll_controller' > > >> net/core/netpoll.c: In function 'netpoll_setup': > > >> net/core/netpoll.c:670: error: 'struct net_device' has no member > > >> named 'poll_controller' > > >> make[2]: *** [net/core/netpoll.o] Error 1 > > >> make[1]: *** [net/core] Error 2 > > >> make: *** [net] Error 2 > > >> make: *** Waiting for unfinished jobs > > >> > > >> ... > > >> > > >> > > >> I think is because KGDBOE selects just NETPOLL. > > >> > > > Looks like it. > > > > > > Select went and selected NETPOLL and NETPOLL_TRAP but things like > > > CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. > > > `select' > > > remains evil. > > >>> ... > > I think there may be a logical issue ( again if I got it right ). > > We need some ethernet card to work with kgdboe right ? but we don't > > have any if !NETDEVICES && !NET_ETHERNET. > > > > So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' > > is needed too ? > > >>> IMHO, the only logical issue here is netpoll.c mustn't use > > >>> CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't > > >>> add this dependency itself. > > >>> > > >> Well it does if NETDEVICES && if NET_ETHERNET which booth are N when > > >> !NETDEVICES is why KGDBOE uses select and not depends on. > > > > > > "does if XXX" means may "use if XXX". > > > > From what I know means only use "if xxx" on !xxx everything inside the "if > > xxx" is n and "depends on > > does not work. > > > > ... > > > > menuconfig FOO > > bool "FOO" > > depends on BAR > > default y > > -- help -- > > something > > if FOO > > > > config BAZ > > depends on WHATEVR && !NOT_THIS > > > > menuconfig SOMETHING_ELSE > > > > if SOMETHING_ELSE > > > > config BLUBB > > depends on PCI && WHATNOT > > > > endif # SOMETHING_ELSE > > > > config NETPOLL > > def_bool NETCONSOLE > > > > config NETPOLL_TRAP > > bool "Netpoll traffic trapping" > > default n > > depends on NETPOLL > > > > config NET_POLL_CONTROLLER > > def_bool NETPOLL > > > > endif # FOO > > > > Now if you set FOO=n all is gone and your driver have to select whatever it > > needs from there. > > Probably not exactly so... > > >From drivers/net/Kconfig: > > > # All the following symbols are dependent on NETDEVICES - do not repeat > > # that for each of the symbols. > > if NETDEVICES > > So, according to this netpoll could presume NETDEVICES and > NET_POLL_CONTROLLER are always on. > > But, as you've found, it's possible to select NETPOLL and !NETDEVICES, > so this comment is at least not precise. > > On the other side something like this: > > ... > endif # NETDEVICES > > config NETPOLL > depends on NETDEVICES > def_bool NETCONSOLE > > config NETPOLL_TRAP > bool "Netpoll traffic trapping" > default n > depends on NETPOLL > > config NET_POLL_CONTROLLER > def_bool NETPOLL > depends on NETPOLL > > > seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but > still doesn't check for NETDEVICES dependency. That's odd. Adding Sam to the cc:. > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. > > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the > > >> question is does it work without any ethernet card ? > > > > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding > > > this select under config NETPOLL. On the other hand, if NETPOLL should > > > depend on NET_POLL_CONTROLLER there is probably no reason to have them > > > both. > > > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES . > > > > Net peoples ping ?:) How about cc:ing the netpoll maintainer? > OK, I wasn't right here: there is no visible reason for both in the > kernel code, but I can imagine there could be some external users of > NET_POLL_CONTROLLER without NETPOLL. I don't know of any. As far as I can tell at this point, NET_POLL_CONTROLLER == NETPOLL.
Re: [PATCH 2/2] NET: fix memory leaks from security_secid_to_secctx()
Both patches applied to: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][BNX2X]: New driver for Broadcom 10Gb Ethernet.
Roland Dreier wrote:
> > +{ PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_NX2_5710,
> > +PCI_ANY_ID, PCI_ANY_ID, 0, 0, BCM5710 },
FWIW, this could be neater as
{ PCI_VDEVICE(BROADCOM, PCI_DEVICE_ID_NX2_5710), BCM5710 }
Yes. And additionally, I prefer (but not require) that people directly
use a hexidecimal constant in the PCI ID table for device ID, if that is
the only place in the entire codebase referring to that PCI device ID.
Using a named constant for a single-use PCI device ID merely aggrevates
include/linux/pci_ids.h patching headache for what is ultimately an
arbitrary number [usually] picked out of thin air by the hw vendor.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][BNX2X]: New driver for Broadcom 10Gb Ethernet.
> > + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_NX2_5710,
> > + PCI_ANY_ID, PCI_ANY_ID, 0, 0, BCM5710 },
FWIW, this could be neater as
{ PCI_VDEVICE(BROADCOM, PCI_DEVICE_ID_NX2_5710), BCM5710 }
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SMSC LAN911x and LAN921x vendor driver
> "Steve" == Steve Glendinning <[EMAIL PROTECTED]> writes: Hi, >> What's the problem with Dustin's driver? It seems to work fine here >> with a lan9117. Why not just add lan921x support to the existing >> driver? Steve> I have heard Dustin's driver works very well on PXA, but on Steve> others it doesn't even compile (hence why it depends on Steve> ARCH_PXA). I'm using it on PPC. Steve> Dustin's driver was based on the smc91x code, but these two Steve> ethernet devices share nothing other than a similar name. Steve> smsc911x is a new, completely platform-independent driver with Steve> workarounds for several hardware issues, and it doesn't suffer Steve> from quite as much macro abuse :-) The macros are not that bad as the hw people sligtly misconnected the chip, so I need special access routines (enable the big endian mode, not byteswap on normal registar access and byteswap on fifo access). I'll give your driver a try and report back. -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][BNX2X]: New driver for Broadcom 10Gb Ethernet.
On Wednesday 01 August 2007 10:31:17 Michael Chan wrote:
> +typedef struct {
> + u8 reserved[64];
> +} license_key_t;
No typedef.
What is a "license key" used for, anyway?
> +#define RUN_AT(x)(jiffies + (x))
That macro does only obfuscate code, in my opinion.
If you want jiffies+x, better opencode it.
> +typedef enum {
> + BCM5710 = 0,
> +} board_t;
No typedef. Do
enum bnx2x_board {
BCM5710 = 0,
};
Or something like that.
> +static struct pci_device_id bnx2x_pci_tbl[] = {
static const struct...
> + { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_NX2_5710,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0, BCM5710 },
> + { 0 }
> +};
> +static inline u32 bnx2x_bits_en(struct bnx2x *bp, u32 block, u32 reg,
> + u32 bits)
Does that really need to be inline? I'd suggest dropping inline.
> +{
> + u32 val = REG_RD(bp, block, reg);
> +
> + val |= bits;
> + REG_WR(bp, block, reg, val);
> + return val;
> +}
> +
> +static inline u32 bnx2x_bits_dis(struct bnx2x *bp, u32 block, u32 reg,
> + u32 bits)
Same here.
> +{
> + u32 val = REG_RD(bp, block, reg);
> +
> + val &= ~bits;
> + REG_WR(bp, block, reg, val);
> + return val;
> +}
> +
> +static int bnx2x_mdio22_write(struct bnx2x *bp, u32 reg, u32 val)
> +{
> + int rc;
> + u32 tmp, i;
> + int port = bp->port;
> + u32 emac_base = port ? GRCBASE_EMAC1 : GRCBASE_EMAC0;
> +
> + if (bp->phy_flags & PHY_INT_MODE_AUTO_POLLING_FLAG) {
> +
> + tmp = REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_MODE);
> + tmp &= ~EMAC_MDIO_MODE_AUTO_POLL;
> + EMAC_WR(EMAC_REG_EMAC_MDIO_MODE, tmp);
> + REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_MODE);
> + udelay(40);
> + }
> +
> + tmp = ((bp->phy_addr << 21) | (reg << 16) |
> +(val & EMAC_MDIO_COMM_DATA) |
> +EMAC_MDIO_COMM_COMMAND_WRITE_22 |
> +EMAC_MDIO_COMM_START_BUSY);
> + EMAC_WR(EMAC_REG_EMAC_MDIO_COMM, tmp);
> +
> + for (i = 0; i < 50; i++) {
> + udelay(10);
> +
> + tmp = REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_COMM);
> + if (!(tmp & EMAC_MDIO_COMM_START_BUSY)) {
> + udelay(5);
> + break;
> + }
> + }
> +
> + if (tmp & EMAC_MDIO_COMM_START_BUSY) {
> + BNX2X_ERR("write phy register failed\n");
> +
> + rc = -EBUSY;
> + } else {
> + rc = 0;
> + }
> +
> + if (bp->phy_flags & PHY_INT_MODE_AUTO_POLLING_FLAG) {
> +
> + tmp = REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_MODE);
> + tmp |= EMAC_MDIO_MODE_AUTO_POLL;
> + EMAC_WR(EMAC_REG_EMAC_MDIO_MODE, tmp);
> + }
> +
> + return rc;
> +}
> +
> +static int bnx2x_mdio22_read(struct bnx2x *bp, u32 reg, u32 *ret_val)
> +{
> + int rc;
> + u32 val, i;
> + int port = bp->port;
> + u32 emac_base = port ? GRCBASE_EMAC1 : GRCBASE_EMAC0;
> +
> + if (bp->phy_flags & PHY_INT_MODE_AUTO_POLLING_FLAG) {
> +
> + val = REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_MODE);
> + val &= ~EMAC_MDIO_MODE_AUTO_POLL;
> + EMAC_WR(EMAC_REG_EMAC_MDIO_MODE, val);
> + REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_MODE);
> + udelay(40);
> + }
> +
> + val = ((bp->phy_addr << 21) | (reg << 16) |
> +EMAC_MDIO_COMM_COMMAND_READ_22 |
> +EMAC_MDIO_COMM_START_BUSY);
> + EMAC_WR(EMAC_REG_EMAC_MDIO_COMM, val);
> +
> + for (i = 0; i < 50; i++) {
> + udelay(10);
> +
> + val = REG_RD(bp, emac_base, EMAC_REG_EMAC_MDIO_COMM);
> + if (!(val & EMAC_MDIO_COMM_START_BUSY)) {
No udelay(5) here, like in write above?
> + val &= EMAC_MDIO_COMM_DATA;
> + break;
> + }
> + }
> +static int bnx2x_mdio45_vwrite(struct bnx2x *bp, u32 reg, u32 addr, u32 val)
> +{
> + int i;
> + u32 rd_val;
> +
> + for (i = 0; i < 10; i++) {
> + bnx2x_mdio45_write(bp, reg, addr, val);
> + mdelay(5);
Can you msleep(5) here?
> + bnx2x_mdio45_read(bp, reg, addr, &rd_val);
> + /* if the read value is not the same as the value we wrote,
> +we should write it again */
> + if (rd_val == val) {
> + return 0;
> + }
> + }
> + BNX2X_ERR("MDIO write in CL45 failed\n");
> + return -EBUSY;
> +}
> +/* DMAE command positions used
> + * Port0 14
> + * Port1 15
> + */
> +static void bnx2x_wb_write_dmae(struct bnx2x *bp, u32 wb_addr, u32 *wb_write,
> + u32 wb_len)
> +{
> + struct dmae_command *dmae = &bp->dmae;
> + int port = bp->port;
> + u32 *wb_comp = bnx2x_sp(bp, wb_comp);
> +
> + memcpy(bnx2x_sp(bp, wb_write[0]), wb_write, wb_len * 4);
> + memset(dmae, 0, sizeof(struct dmae_command));
> +
Re: [PATCH]: Fix sk_buff page offsets and lengths.
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Tue, 31 Jul 2007 10:52:15 +0200 > I understand ifdefs are ugly, but in the common case > (PAGE_SIZE<64K), this change seems very unfortunate. If this bothers you so much start where the real problems are and advocate on linux-kernel for descreasing the type size of "offset" and "length" in struct scatterlist. It's a bit on the hypocritical side to complain about this skb_frag_t change when I've never seen a peep out of you about scatterlist doing the same thing :-) Otherwise, we're better off with the types being the same so that we can use scatterlist in skb_frag_t and therefore kill serious performance problems with DMA mapping of sk_buff objects that exists today on platforms such as powerpc. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ibmveth: Fix rx pool deactivate oops
This fixes the following oops which can occur when trying to deallocate
receive buffer pools using sysfs with the ibmveth driver.
NIP: d024f954 LR: d024fa58 CTR: c00d7478
REGS: cffef9f0 TRAP: 0300 Not tainted (2.6.22-ppc64)
MSR: 80009032 CR: 24242442 XER: 0010
DAR: 07f0, DSISR: 4200
TASK = c2f91360[2967] 'bash' THREAD: c0001398c000 CPU: 2
GPR00: cffefc70 d0262d30 c0001c4087a0
GPR04: 000300fe 000f c0579d80
GPR08: 00365688 c0001c408998 07f0
GPR12: d0251e88 c0579d80 200957ec
GPR16: 100b8808 100feb30 10084828
GPR20: 1014d4d0 0010 cffefeb0
GPR24: c0001c408000 c0001c408000 b054
GPR28: 00fe 0003 d0262700 c0001c4087a0
NIP [d024f954] .ibmveth_remove_buffer_from_pool+0x38/0x108 [ibmveth]
LR [d024fa58] .ibmveth_rxq_harvest_buffer+0x34/0x78 [ibmveth]
Call Trace:
[cffefc70] [c00280a8] .dma_iommu_unmap_single+0x14/0x28
(unreliable)
[cffefd00] [d024fa58] .ibmveth_rxq_harvest_buffer+0x34/0x78
[ibmveth]
[cffefd80] [d0250e40] .ibmveth_poll+0xd8/0x434 [ibmveth]
[cffefe40] [c032da8c] .net_rx_action+0xdc/0x248
[cffefef0] [c0068b4c] .__do_softirq+0xa8/0x164
[cffeff90] [c002789c] .call_do_softirq+0x14/0x24
[c0001398f6f0] [c000c04c] .do_softirq+0x68/0xac
[c0001398f780] [c0068ca0] .irq_exit+0x54/0x6c
[c0001398f800] [c000c8e4] .do_IRQ+0x170/0x1ac
[c0001398f890] [c0004790] hardware_interrupt_entry+0x18/0x1c
Exception: 501 at .plpar_hcall_norets+0x24/0x94
LR = .veth_pool_store+0x15c/0x298 [ibmveth]
[c0001398fb80] [d0250b2c] .veth_pool_store+0x5c/0x298 [ibmveth]
(unreliable)
[c0001398fc30] [c0145530] .sysfs_write_file+0x140/0x1d8
[c0001398fcf0] [c00de89c] .vfs_write+0x120/0x208
[c0001398fd90] [c00df2c8] .sys_write+0x4c/0x8c
[c0001398fe30] [c00086ac] syscall_exit+0x0/0x40
Instruction dump:
fba1ffe8 fbe1fff8 789d0022 f8010010 f821ff71 789c0020 1d3d00a8 7b8a1f24
3800 7c7f1b78 7d291a14 e9690128 <7c0a592a> e803 e9690120 80a90100
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 24 ++--
linux-2.6-bjking1/drivers/net/ibmveth.h |3 ---
2 files changed, 14 insertions(+), 13 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_fixup_pool_deactivate
drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_fixup_pool_deactivate
2007-08-01 10:22:37.0 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-01 10:23:20.0
-0500
@@ -1280,24 +1280,28 @@ const char * buf, size_t count)
int i;
/* Make sure there is a buffer pool with buffers that
can hold a packet of the size of the MTU */
- for(i = 0; irx_buff_pool[i])
continue;
if (!adapter->rx_buff_pool[i].active)
continue;
- if (mtu < adapter->rx_buff_pool[i].buff_size) {
- pool->active = 0;
- h_free_logical_lan_buffer(adapter->
- vdev->
- unit_address,
- pool->
- buff_size);
- }
+ if (mtu <= adapter->rx_buff_pool[i].buff_size)
+ break;
}
- if (pool->active) {
+
+ if (i == IbmVethNumBufferPools) {
ibmveth_error_printk("no active pool >= MTU\n");
return -EPERM;
}
+
+ pool->active = 0;
+ if (netif_running(netdev)) {
+ adapter->pool_config = 1;
+ ibmveth_close(netdev);
+ adapter->pool_config = 0;
+ if ((rc = ibmveth_open(netdev)))
+ return rc;
+ }
}
} else if (attr == &veth_num_attr) {
if (value <= 0 || value > IBMVETH_MAX_POOL_COUNT)
diff -puN drivers/net/ibmveth.h~ibmveth_fixu
Re: [REGRESSION] tg3 dead after s2ram
On Wed, 2007-08-01 at 10:47 -0700, Michael Chan wrote: > You have 2 Broadcom devices in your system. 07:00.0 is a wireless > device, I think. 8:4.0 is the tg3 device. > > It's clear that the tg3 device is still in D3 state after resume and > that explains why all register accesses fail. tg3_resume() should put > the device back in D0 state in a very straight forward way and I don't > see how that can fail. It worked for me when I tested it last night. > Can you add some printk() to tg3_resume() to see what's happening? Let > me know if you want me to send you some debug patches to do that. I misread the PCI registers below. The power state was ok. The problem is that memory enable and bus master were not set in PCI register 4 after resume. This also explains the register access failures. In tg3_resume(), we call pci_restore_state() which should re-enable those 2 bits in PCI register 4. Can you add some printk() to see why those bits are not restored after pci_restore_state()? Thanks. > > Here's the before and after for 8:4.0: > > > > > Before > > > > 08:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit > > Ethernet (rev 03) > > Subsystem: Acer Incorporated [ALI] Unknown device 010e > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > > Stepping- > > SERR- FastB2B- > > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > > > SERR- > Latency: 0 (16000ns min) > > Interrupt: pin A routed to IRQ 22 > > Region 0: Memory at d030 (32-bit, non-prefetchable) [size=64K] > > Expansion ROM at [disabled] > > Capabilities: [48] Power Management version 2 > > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > > PME(D0-,D1-,D2-,D3hot+,D3cold+) > > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > > Capabilities: [50] Vital Product Data > > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 > > Enable- > > Address: 6bfe7fb8 Data: fec7 > > 00: e4 14 9c 16 06 00 b0 02 03 00 00 02 00 00 00 00 > > 10: 00 00 30 d0 00 00 00 00 00 00 00 00 00 00 00 00 > > 20: 00 00 00 00 00 00 00 00 07 00 00 00 25 10 0e 01 > > 30: 00 00 ff ff 48 00 00 00 00 00 00 00 0a 01 40 00 > > 40: 00 00 00 00 00 00 00 00 01 50 02 c0 00 20 00 00 > > 50: 03 58 fc 00 6f bf be 7f 05 00 86 00 b8 ff ff 7f > > 60: fe 6b ff ff c7 fe 00 00 98 00 03 30 00 00 3f 76 > > 70: f6 10 00 00 20 00 00 80 14 04 00 00 00 00 00 00 > > 80: 85 6b d0 36 03 40 00 0c 34 00 13 04 82 90 09 04 > > 90: 09 97 00 01 00 00 00 00 00 00 00 00 eb 01 00 00 > > a0: 00 00 00 00 23 01 00 00 00 00 00 00 cb 00 00 00 > > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > > > After > > > > 08:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit > > Ethernet (rev 03) > > Subsystem: Acer Incorporated [ALI] Unknown device 010e > > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > > Stepping- > > SERR- FastB2B- > > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > > > SERR- > Interrupt: pin A routed to IRQ 22 > > Region 0: Memory at d030 (32-bit, non-prefetchable) [disabled] > > [size=64K] > > Expansion ROM at [disabled] > > Capabilities: [48] Power Management version 2 > > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > > PME(D0-,D1-,D2-,D3hot+,D3cold+) > > Status: D0 PME-Enable+ DSel=0 DScale=1 PME- > > Capabilities: [50] Vital Product Data > > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 > > Enable- > > Address: 6bfe7fb8 Data: fec7 > > 00: e4 14 9c 16 00 00 b0 02 03 00 00 02 00 00 00 00 > > 10: 00 00 30 d0 00 00 00 00 00 00 00 00 00 00 00 00 > > 20: 00 00 00 00 00 00 00 00 07 00 00 00 25 10 0e 01 > > 30: 00 00 ff ff 48 00 00 00 00 00 00 00 0a 01 40 00 > > 40: 00 00 00 00 00 00 00 00 01 50 02 c0 00 21 00 64 > > 50: 03 58 fc 00 6f bf be 7f 05 00 86 00 b8 ff ff 7f > > 60: fe 6b ff ff c7 fe 00 00 9a 00 03 30 00 00 00 00 > > 70: 76 10 00 00 40 00 00 00 50 00 00 00 00 00 00 00 > > 80: 03 58 fc 00 00 00 00 00 00 00 00 00 fe 90 09 04 > > 90: 01 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Inconsistent behaviour at AF_PACKET
Hello folks,
Timestamps should be usually requested explicitly by setting the
SOL_SOCKET/SO_TIMESTAMP option to 1. But if you setup a reception ring
with the SOL_PACKET/PACKET_RX_RING option, timestamps are automatically
enabled at the next packet recepcion.
I think that is a bug so I have written a patch that corrects it.
Thanks.
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 1322d62..a4f2da3 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -640,10 +640,6 @@ static int tpacket_rcv(struct sk_buff *skb, struct
net_device *dev, struct packe
h->tp_snaplen = snaplen;
h->tp_mac = macoff;
h->tp_net = netoff;
- if (skb->tstamp.tv64 == 0) {
- __net_timestamp(skb);
- sock_enable_timestamp(sk);
- }
tv = ktime_to_timeval(skb->tstamp);
h->tp_sec = tv.tv_sec;
h->tp_usec = tv.tv_usec;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] tg3 dead after s2ram
On Wed, 2007-08-01 at 10:01 +0200, Joachim Deguara wrote: > Here are the lspci outputs for the tg3 You have 2 Broadcom devices in your system. 07:00.0 is a wireless device, I think. 8:4.0 is the tg3 device. It's clear that the tg3 device is still in D3 state after resume and that explains why all register accesses fail. tg3_resume() should put the device back in D0 state in a very straight forward way and I don't see how that can fail. It worked for me when I tested it last night. Can you add some printk() to tg3_resume() to see what's happening? Let me know if you want me to send you some debug patches to do that. Thanks. Here's the before and after for 8:4.0: > > Before > > 08:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit > Ethernet (rev 03) > Subsystem: Acer Incorporated [ALI] Unknown device 010e > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- > SERR- FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR-Latency: 0 (16000ns min) > Interrupt: pin A routed to IRQ 22 > Region 0: Memory at d030 (32-bit, non-prefetchable) [size=64K] > Expansion ROM at [disabled] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [50] Vital Product Data > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 > Enable- > Address: 6bfe7fb8 Data: fec7 > 00: e4 14 9c 16 06 00 b0 02 03 00 00 02 00 00 00 00 > 10: 00 00 30 d0 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 07 00 00 00 25 10 0e 01 > 30: 00 00 ff ff 48 00 00 00 00 00 00 00 0a 01 40 00 > 40: 00 00 00 00 00 00 00 00 01 50 02 c0 00 20 00 00 > 50: 03 58 fc 00 6f bf be 7f 05 00 86 00 b8 ff ff 7f > 60: fe 6b ff ff c7 fe 00 00 98 00 03 30 00 00 3f 76 > 70: f6 10 00 00 20 00 00 80 14 04 00 00 00 00 00 00 > 80: 85 6b d0 36 03 40 00 0c 34 00 13 04 82 90 09 04 > 90: 09 97 00 01 00 00 00 00 00 00 00 00 eb 01 00 00 > a0: 00 00 00 00 23 01 00 00 00 00 00 00 cb 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > After > > 08:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit > Ethernet (rev 03) > Subsystem: Acer Incorporated [ALI] Unknown device 010e > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- > SERR- FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR-Interrupt: pin A routed to IRQ 22 > Region 0: Memory at d030 (32-bit, non-prefetchable) [disabled] > [size=64K] > Expansion ROM at [disabled] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable+ DSel=0 DScale=1 PME- > Capabilities: [50] Vital Product Data > Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 > Enable- > Address: 6bfe7fb8 Data: fec7 > 00: e4 14 9c 16 00 00 b0 02 03 00 00 02 00 00 00 00 > 10: 00 00 30 d0 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 07 00 00 00 25 10 0e 01 > 30: 00 00 ff ff 48 00 00 00 00 00 00 00 0a 01 40 00 > 40: 00 00 00 00 00 00 00 00 01 50 02 c0 00 21 00 64 > 50: 03 58 fc 00 6f bf be 7f 05 00 86 00 b8 ff ff 7f > 60: fe 6b ff ff c7 fe 00 00 9a 00 03 30 00 00 00 00 > 70: 76 10 00 00 40 00 00 00 50 00 00 00 00 00 00 00 > 80: 03 58 fc 00 00 00 00 00 00 00 00 00 fe 90 09 04 > 90: 01 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8808] New: Large file transfer causes kernel panic showing b44_poll
On Wed, 2007-07-25 at 11:54 -0700, Andrew Morton wrote:
> On Wed, 25 Jul 2007 04:29:33 -0700 (PDT)
> [EMAIL PROTECTED] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=8808
> >
> >Summary: Large file transfer causes kernel panic showing b44_poll
> >Product: Drivers
> >Version: 2.5
> > KernelVersion: 2.6.22.1
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: blocking
> > Priority: P1
> > Component: Network
> > AssignedTo: [EMAIL PROTECTED]
> > ReportedBy: [EMAIL PROTECTED]
> >
> >
> > Most recent kernel where this bug did not occur: /
> > Distribution: ttylinux
> > Hardware Environment: Dell Inspiron 1300
> > Problem Description:
> >
> > A large file transfer (6.5GB) (tried http with wget and plain netcat)
> > causes a
> > kernel panic after more than several GB have been transferred. However,
> > kernel
> > panic does not occur consistently. That is, it has occurred after 1.2GB,
> > 1.8GB,
> > 2.3GB and even 3.4GB transferred. Transfer never finished though.
> >
I could not repro the problem, but please give this patch a try:
diff -rup a/b44.c b/b44.c
--- a/b44.c 2007-07-31 15:31:08.0 -0700
+++ b/b44.c 2007-08-01 08:03:08.0 -0700
@@ -792,15 +792,15 @@ static int b44_rx(struct b44 *bp, int bu
goto next_pkt;
}
- if (len == 0) {
+ if (len < 5) {
int i = 0;
do {
udelay(2);
barrier();
len = le16_to_cpu(rh->len);
- } while (len == 0 && i++ < 5);
- if (len == 0)
+ } while (len < 5 && i++ < 5);
+ if (len < 5)
goto drop_it;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [TCP]: DSACK signals data receival, be conservative
In case a DSACK is received, it's better to lower cwnd as it's
a sign of data receival.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c3124e6..f030435 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -103,6 +103,7 @@ int sysctl_tcp_abc __read_mostly;
#define FLAG_SLOWPATH 0x100 /* Do not skip RFC checks for window
update.*/
#define FLAG_ONLY_ORIG_SACKED 0x200 /* SACKs only non-rexmit sent before RTO
*/
#define FLAG_SND_UNA_ADVANCED 0x400 /* Snd_una was changed (!=
FLAG_DATA_ACKED) */
+#define FLAG_DSACKING_ACK 0x800 /* SACK blocks contained DSACK info */
#define FLAG_ACKED (FLAG_DATA_ACKED|FLAG_SYN_ACKED)
#define FLAG_NOT_DUP (FLAG_DATA|FLAG_WIN_UPDATE|FLAG_ACKED)
@@ -966,12 +967,14 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff
*ack_skb, u32 prior_snd_
/* Check for D-SACK. */
if (before(ntohl(sp[0].start_seq), TCP_SKB_CB(ack_skb)->ack_seq)) {
+ flag |= FLAG_DSACKING_ACK;
found_dup_sack = 1;
tp->rx_opt.sack_ok |= 4;
NET_INC_STATS_BH(LINUX_MIB_TCPDSACKRECV);
} else if (num_sacks > 1 &&
!after(ntohl(sp[0].end_seq), ntohl(sp[1].end_seq)) &&
!before(ntohl(sp[0].start_seq),
ntohl(sp[1].start_seq))) {
+ flag |= FLAG_DSACKING_ACK;
found_dup_sack = 1;
tp->rx_opt.sack_ok |= 4;
NET_INC_STATS_BH(LINUX_MIB_TCPDSACKOFORECV);
@@ -1858,7 +1861,7 @@ static void tcp_cwnd_down(struct sock *sk, int flag)
struct tcp_sock *tp = tcp_sk(sk);
int decr = tp->snd_cwnd_cnt + 1;
- if ((flag&FLAG_ANY_PROGRESS) ||
+ if ((flag&(FLAG_ANY_PROGRESS|FLAG_DSACKING_ACK)) ||
(IsReno(tp) && !(flag&FLAG_NOT_DUP))) {
tp->snd_cwnd_cnt = decr&1;
decr >>= 1;
--
1.5.0.6
[PATCH 1/2] [TCP]: Also handle snd_una changes in tcp_cwnd_down
tcp_cwnd_down must check for it too as it should be conservative
in case of collapse stuff and also when receiver is trying to
lie (though that wouldn't be very successful/useful anyway).
Note:
- Separated also is_dupack and do_lost in fast_retransalert
* Much cleaner look-and-feel now
* This time it really fixes cumulative ACK with many new
SACK blocks recovery entry (I claimed this fixes with
last patch but it wasn't). TCP will now call
tcp_update_scoreboard regardless of is_dupack when
in recovery as long as there is enough fackets_out.
- Introduce FLAG_SND_UNA_ADVANCED
* Some prior_snd_una arguments are unnecessary after it
- Added helper FLAG_ANY_PROGRESS to avoid long FLAG...|FLAG...
constructs
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
Dave, BEWARE, I wasn't able to do anything else but compile test
because Linus' tree didn't seem to boot on the machine I was
trying to test it... :-(
I think that to stable version only a small part of this change
is necessary, not the full changeset. That should keep stable
folks much happier... :-) I'll soon put my reduced proposal to:
http://www.cs.helsinki.fi/u/ijjarvin/patches/stable-0001.patch
The other patch (DSACK) can go to stable as is.
net/ipv4/tcp_input.c | 34 ++
1 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 378ca8a..c3124e6 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -102,11 +102,13 @@ int sysctl_tcp_abc __read_mostly;
#define FLAG_DATA_LOST 0x80 /* SACK detected data lossage.
*/
#define FLAG_SLOWPATH 0x100 /* Do not skip RFC checks for window
update.*/
#define FLAG_ONLY_ORIG_SACKED 0x200 /* SACKs only non-rexmit sent before RTO
*/
+#define FLAG_SND_UNA_ADVANCED 0x400 /* Snd_una was changed (!=
FLAG_DATA_ACKED) */
#define FLAG_ACKED (FLAG_DATA_ACKED|FLAG_SYN_ACKED)
#define FLAG_NOT_DUP (FLAG_DATA|FLAG_WIN_UPDATE|FLAG_ACKED)
#define FLAG_CA_ALERT (FLAG_DATA_SACKED|FLAG_ECE)
#define FLAG_FORWARD_PROGRESS (FLAG_ACKED|FLAG_DATA_SACKED)
+#define FLAG_ANY_PROGRESS (FLAG_FORWARD_PROGRESS|FLAG_SND_UNA_ADVANCED)
#define IsReno(tp) ((tp)->rx_opt.sack_ok == 0)
#define IsFack(tp) ((tp)->rx_opt.sack_ok & 2)
@@ -1856,7 +1858,7 @@ static void tcp_cwnd_down(struct sock *sk, int flag)
struct tcp_sock *tp = tcp_sk(sk);
int decr = tp->snd_cwnd_cnt + 1;
- if ((flag&FLAG_FORWARD_PROGRESS) ||
+ if ((flag&FLAG_ANY_PROGRESS) ||
(IsReno(tp) && !(flag&FLAG_NOT_DUP))) {
tp->snd_cwnd_cnt = decr&1;
decr >>= 1;
@@ -2107,15 +2109,13 @@ static void tcp_mtup_probe_success(struct sock *sk,
struct sk_buff *skb)
* tcp_xmit_retransmit_queue().
*/
static void
-tcp_fastretrans_alert(struct sock *sk, u32 prior_snd_una,
- int prior_packets, int flag)
+tcp_fastretrans_alert(struct sock *sk, int prior_packets, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- int is_dupack = (tp->snd_una == prior_snd_una &&
-(!(flag&FLAG_NOT_DUP) ||
- ((flag&FLAG_DATA_SACKED) &&
- (tp->fackets_out > tp->reordering;
+ int is_dupack = !(flag&(FLAG_SND_UNA_ADVANCED|FLAG_NOT_DUP));
+ int do_lost = is_dupack || ((flag&FLAG_DATA_SACKED) &&
+ (tp->fackets_out > tp->reordering));
/* Some technical things:
* 1. Reno does not count dupacks (sacked_out) automatically. */
@@ -2192,14 +2192,14 @@ tcp_fastretrans_alert(struct sock *sk, u32
prior_snd_una,
/* F. Process state. */
switch (icsk->icsk_ca_state) {
case TCP_CA_Recovery:
- if (prior_snd_una == tp->snd_una) {
+ if (!(flag & FLAG_SND_UNA_ADVANCED)) {
if (IsReno(tp) && is_dupack)
tcp_add_reno_sack(sk);
} else {
int acked = prior_packets - tp->packets_out;
if (IsReno(tp))
tcp_remove_reno_sacks(sk, acked);
- is_dupack = tcp_try_undo_partial(sk, acked);
+ do_lost = tcp_try_undo_partial(sk, acked);
}
break;
case TCP_CA_Loss:
@@ -2215,7 +2215,7 @@ tcp_fastretrans_alert(struct sock *sk, u32 prior_snd_una,
/* Loss is undone; fall through to processing in Open state. */
default:
if (IsReno(tp)) {
- if (tp->snd_una != prior_snd_una)
+ if (flag & FLAG_SND_UNA_ADVANCED)
tcp_reset_reno_sack(tp);
if (is_dupack)
tcp_add_reno_sack(sk);
@@
[RFC][PATCH] Removal of duplicated include net/wanrouter/wanmain.c
Hi, There is no need to include linux/init.h twice Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]> --- linux-mm-clean/net/wanrouter/wanmain.c 2007-07-09 01:32:17.0 +0200 +++ linux-mm/net/wanrouter/wanmain.c2007-08-01 18:14:22.0 +0200 @@ -46,7 +46,6 @@ #include #include/* return codes */ #include -#include #include /* support for loadable modules */ #include /* kmalloc(), kfree() */ #include - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Wed, 1 Aug 2007 11:33:36 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > yup, it's `select': > > > > Selected by: B44 && NETDEVICES && NET_ETHERNET || BCM43XX_MAC80211 && > > NETDEVICES && !S390 && MAC80211 && WLAN_80211 && EXPERIMENTAL > > > > > > Look. Kconfig's `select' Just. Does. Not. Work. If you find yourself > > contemplating using it, please, don sackcloth, take a cold shower and > > several analgesics, then have another go, OK? > > > > ho hum. > > Ah, yeah. Crap select not caring about dependencies... > The problem is that people will kill me, if they don't find > bcm43xx in the kconfig anymore, as they have to enable ssb > before that. Ya know the flame with Uwe Bugla going crazy > about that? :D > Same goes for b44. It was always there in kconfig without > additional deps, but now (when we merge the b44 port) we would > need ssb selected before we see b44. We just don't have a good solution to this. `select' is bust and it's unobvious how it can _not_ be bust. If you're selecting something whose dependencies aren't met, what can we do? Maybe select the thing it depends on as well? What if it depends on (A||B)? Which one do we force on? Screwed. And hiding options from the users until theyve gone elsewher and selected something else is most user-hostile. At least we have menuconfig's "/" command, so if you know the option's name you can work out why it isn't appearing. I think what we should do is to continue to offer the unselectable option in manuconfig and friends, only "greyed out" in some fashion. So the user can still navigate to it and select the "what do you depend on" button. > Maybe default SSB to M? People would complain about that too. I don't know what to do, sorry. Muddle through :( - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
> Quoting Moni Shoua <[EMAIL PROTECTED]>: > Subject: Re: [ofa-general] Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB > support for?the bonding driver > > > > It's always wrong to copy symbols from another module without > > referencing it. > > Michael, > It seems like the preferred approach is to prevent ib_ipoib from being > unloaded while bonding is on top it, right? > It seems like it would handle all safety issues (not just neigh cleanup). Donnu about preferred, but that'll work I think. -- MST - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] sis190 check for ISA bridge on SiS966
From: Neil Muller <[EMAIL PROTECTED]>
sis190 driver assumes to find ISA only on SiS965.
similar fix is in sis900 driver, see bug report
http://bugs.debian.org/435547
Signed-off-by: maximilian attems <[EMAIL PROTECTED]>
---
drivers/net/sis190.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index ec2ad9f..d470b19 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1593,6 +1593,9 @@ static int __devinit sis190_get_mac_addr_from_apc(struct
pci_dev *pdev,
pci_name(pdev));
isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0965, NULL);
+ if (!isa_bridge)
+ isa_bridge = pci_get_device(PCI_VENDOR_ID_SI, 0x0966, NULL);
+
if (!isa_bridge) {
net_probe(tp, KERN_INFO "%s: Can not find ISA bridge.\n",
pci_name(pdev));
--
maks
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Small memory-leak patchset
While doing some other work I found some small memory leaks with the way we are using security_secid_to_secctx() in some of the auditing code paths. We also had a redundant NULL pointer check in the SELinux function which frees the leaked memory. This patchset fixes both of these issues. This patchset is backed against Linus' tree from this morning and has been lightly tested. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] SELinux: remove redundant pointer checks before calling kfree()
We don't need to check for NULL pointers before calling kfree().
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
security/selinux/hooks.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6_secctx-leaks/security/selinux/hooks.c
===
--- linux-2.6_secctx-leaks.orig/security/selinux/hooks.c
+++ linux-2.6_secctx-leaks/security/selinux/hooks.c
@@ -4658,8 +4658,7 @@ static int selinux_secid_to_secctx(u32 s
static void selinux_release_secctx(char *secdata, u32 seclen)
{
- if (secdata)
- kfree(secdata);
+ kfree(secdata);
}
#ifdef CONFIG_KEYS
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] NET: fix memory leaks from security_secid_to_secctx()
The security_secid_to_secctx() function returns memory that must be freed
by a call to security_release_secctx() which was not always happening. This
patch fixes two of these problems (all that I could find in the kernel source
at present).
Signed-off-by: Paul Moore <[EMAIL PROTECTED]>
---
net/netlabel/netlabel_user.c |4 +++-
net/xfrm/xfrm_policy.c |5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
Index: linux-2.6_secctx-leaks/net/netlabel/netlabel_user.c
===
--- linux-2.6_secctx-leaks.orig/net/netlabel/netlabel_user.c
+++ linux-2.6_secctx-leaks/net/netlabel/netlabel_user.c
@@ -113,8 +113,10 @@ struct audit_buffer *netlbl_audit_start_
if (audit_info->secid != 0 &&
security_secid_to_secctx(audit_info->secid,
&secctx,
-&secctx_len) == 0)
+&secctx_len) == 0) {
audit_log_format(audit_buf, " subj=%s", secctx);
+ security_release_secctx(secctx, secctx_len);
+ }
return audit_buf;
}
Index: linux-2.6_secctx-leaks/net/xfrm/xfrm_policy.c
===
--- linux-2.6_secctx-leaks.orig/net/xfrm/xfrm_policy.c
+++ linux-2.6_secctx-leaks/net/xfrm/xfrm_policy.c
@@ -2195,9 +2195,10 @@ void xfrm_audit_log(uid_t auid, u32 sid,
}
if (sid != 0 &&
- security_secid_to_secctx(sid, &secctx, &secctx_len) == 0)
+ security_secid_to_secctx(sid, &secctx, &secctx_len) == 0) {
audit_log_format(audit_buf, " subj=%s", secctx);
- else
+ security_release_secctx(secctx, secctx_len);
+ } else
audit_log_task_context(audit_buf);
if (xp) {
--
paul moore
linux security @ hp
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remove get_perm_addr from ucc_geth_ethtool.c
Remove get_perm_addr from ucc_geth_ethtool.c This is needed because commit 313674afa8fdced2fe79f50f38e1c387b63d8790 inlines the generic function to the caller. Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]> --- drivers/net/ucc_geth_ethtool.c |1 - 1 file changed, 1 deletion(-) Index: linux-2.6/drivers/net/ucc_geth_ethtool.c === --- linux-2.6.orig/drivers/net/ucc_geth_ethtool.c +++ linux-2.6/drivers/net/ucc_geth_ethtool.c @@ -379,7 +379,6 @@ static const struct ethtool_ops uec_etht .get_stats_count= uec_get_stats_count, .get_strings= uec_get_strings, .get_ethtool_stats = uec_get_ethtool_stats, - .get_perm_addr = ethtool_op_get_perm_addr, }; void uec_set_ethtool_ops(struct net_device *netdev) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prevent SSB compilation on s390 part 2
On Wednesday 01 August 2007, Heiko Carstens wrote: > On Wed, Aug 01, 2007 at 11:34:04AM +0200, Heiko Carstens wrote: > > From: Heiko Carstens <[EMAIL PROTECTED]> > > > > drivers/ssb/Kconfig has already a depends on HAS_IOMEM which should > > prevent SSB from being selected. But appearantly it looks like this > > doesn't matter at all if it gets selected from somewhere else. > > So add an explicit depends on HAS_IOMEM to the Broadcom driver to > > prevent selection on s390. > > > > Cc: "John W. Linville" <[EMAIL PROTECTED]> > > Cc: Michael Buesch <[EMAIL PROTECTED]> > > Cc: Martin Schwidefsky <[EMAIL PROTECTED]> > > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> > > --- > > drivers/net/Kconfig |1 + > > 1 files changed, 1 insertion(+) > > > > Index: linux-2.6.22/drivers/net/Kconfig > > === > > --- linux-2.6.22.orig/drivers/net/Kconfig > > +++ linux-2.6.22/drivers/net/Kconfig > > @@ -1434,6 +1434,7 @@ config APRICOT > > > > config B44 > > tristate "Broadcom 440x/47xx ethernet support" > > + depends on HAS_IOMEM > > select SSB > > select MII > > help > > By the way.. wouldn't something like depends on NET_PCI or something > similar more correct for this driver? Just wondering... > > No, B44 does not depend on PCI. It does depend on the SSB bus. (Of course the SSB PCI parts do depend on PCI) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prevent SSB compilation on s390 part 2
On Wed, Aug 01, 2007 at 11:34:04AM +0200, Heiko Carstens wrote: > From: Heiko Carstens <[EMAIL PROTECTED]> > > drivers/ssb/Kconfig has already a depends on HAS_IOMEM which should > prevent SSB from being selected. But appearantly it looks like this > doesn't matter at all if it gets selected from somewhere else. > So add an explicit depends on HAS_IOMEM to the Broadcom driver to > prevent selection on s390. > > Cc: "John W. Linville" <[EMAIL PROTECTED]> > Cc: Michael Buesch <[EMAIL PROTECTED]> > Cc: Martin Schwidefsky <[EMAIL PROTECTED]> > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> > --- > drivers/net/Kconfig |1 + > 1 files changed, 1 insertion(+) > > Index: linux-2.6.22/drivers/net/Kconfig > === > --- linux-2.6.22.orig/drivers/net/Kconfig > +++ linux-2.6.22/drivers/net/Kconfig > @@ -1434,6 +1434,7 @@ config APRICOT > > config B44 > tristate "Broadcom 440x/47xx ethernet support" > + depends on HAS_IOMEM > select SSB > select MII > help By the way.. wouldn't something like depends on NET_PCI or something similar more correct for this driver? Just wondering... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Fix sk_buff page offsets and lengths.
On Mon, 30 Jul 2007 18:50:28 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > > Stephen Rothwell pointed out to me that the skb_frag_struct > is broken on platforms using 64K or larger page sizes, it > even generates warnings when (for example) the myri10ge driver > tries to assign PAGE_SIZE into frag->size. > > I've thus increased page offset and size to __u32 in the patch below. > > I made this change much to even my own chagrin, but this is the > most direct fix and the ifdefs we could put here are both ugly > and also not something that we do with struct scatterlist so > no reason to do it in a place like this. > > Actually, the cost on 64-bit is zero because there existed 4 bytes of > alignment padding for skb_frag_struct because of the page pointer. > On 32-bit the cost is up to 64-bytes :-/ > > Stephen, this opens up the doors a bit for the scatterlist work > you wanted to do in sk_buff. > Ouch... sizeof(struct skb_shared_info) is enlarged by 18*4 bytes on i386, a litle bit more than 64 bytes :( I understand ifdefs are ugly, but in the common case (PAGE_SIZE<64K), this change seems very unfortunate. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: specifying scopid's for link-local IPv6 addrs
Rick Jones wrote: >> Rick, >> >> I don't see any way around this. For example, on one of my test >> systems, I have the following link local routes: >> >> chance% netstat -A inet6 -rn | grep fe80::/64 >> fe80::/64 >> :: U 25600 eth0 >> fe80::/64 >> :: U 25600 eth2 >> fe80::/64 >> :: U 25600 eth3 >> fe80::/64 >> :: U 25600 eth4 >> fe80::/64 >> :: U 25600 eth5 >> fe80::/64 >> :: U 25600 eth6 >> >> So if I want to run a link local test to fe80::202:b3ff:fed4:cd1, >> the system has no way to choose which is the correct interface to >> use for the test, and will give an error if the interface isn't >> specified. > > Yeah, I was wondering about that. I'm not sure if the attempts on > "those other OSes" happened to involve multiple interfaces or not. Yes, there have been attempts. BSD has a concept of default interface. The default interface is used when the user did not specify the interface/ scope_id. Other OSs do different things. For example, Tru64 (to pick on a dead system) would try to find the right interface base on the preferences you could set up. But, in the end the whole thing is really utterly broken since no-one has truly implemented scoped address architecture for link-local addresses. The concept of the link is so closely tied to the 'interface' that I don't know anyone who has separated the two. > Even > so, it "feels" unpleasant for an application to deal with and I wonder > if there is a way for a stack to deal with it on the application's > behalf. I guess that might involve some sort of layer violation between > neightbor discovery and routing (typing while I think about things I > know little about...) > > Is there RFC chapter and verse I might read about routing with multiple > link-local's on a system? See RFC 4007 for the concepts. > >> You must explicitly specify the desired interface. For example, >> on my test system, the correct interface is eth6 which is interface 8 >> (lo eth0 eth1 eth2 ... eth5 eth6). Here is an example nuttcp test >> specifying interface 8: >> >> chance% nuttcp -P5100 fe80::202:b3ff:fed4:cd1%8 >> 1178.5809 MB / 10.02 sec = 986.2728 Mbps 12 %TX 15 %RX >> >> nuttcp uses getaddrinfo() which parses the "%" field, >> and then copies the sin6_scope_id from the res structure to the >> server's sockaddr_in6 structure before initiating the connect(). > > OK, I'll give that a quick try with netperf: > > [EMAIL PROTECTED] ~]# netperf -H 192.168.2.107 -c -C -i 30,3 -- -s 1M -S 1M > -m 64K -H fe80::207:43ff:fe05:9d%2 > TCP STREAM TEST from ::0 (::) port 0 AF_INET6 to > fe80::207:43ff:fe05:9d%2 (fe80::207:43ff:fe05:9d) port 0 AF_INET6 : > +/-2.5% @ 99% conf. > > Cool - it establishes the data connection just fine. > > > To further demonstrate my ignorance :) is that %n suffix something one > might expect in most/all getaddrinfo()'s or is that unique to the one in > Linux? This is becoming more generic. I believe HP-UX supports it (if the don't you should kick them :). -vlad - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
> It's always wrong to copy symbols from another module without > referencing it. Michael, It seems like the preferred approach is to prevent ib_ipoib from being unloaded while bonding is on top it, right? It seems like it would handle all safety issues (not just neigh cleanup). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
This is a little better.
One suggestion. The new function you create is almost exactly like
sctp_sf_violation_chunklen() with the exception of the error string.
Can you extract the common parts into a single function so that
we don't have duplication of code.
Thanks
-vlad
Wei Yongjun wrote:
>>
>> This is an interesting case, but I am not sure that simply discarding
>> the SACK is the right thing.
>>
>> The peer in this case is violating the protocol whereby he is trying to
>> advance the cumulative tsn ack to a point beyond the max tsn currently
>> sent. I would vote for terminating the association in this case since
>> either the peer is a mis-behaved implementation, or the association is
>> under attack.
> I have modify the patch to abort the association with protocol violation
> error cause, and new patch is come on. May be this patch is correct.^_^
>
> Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
>
> --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.0 -0400
> +++ net/sctp/sm_statefuns.c 2007-07-31 00:29:16.0 -0400
> @@ -104,6 +104,13 @@ static sctp_disposition_t sctp_sf_violat
>void *arg,
>sctp_cmd_seq_t *commands);
>
> +static sctp_disposition_t sctp_sf_violation_ctsn(
> + const struct sctp_endpoint *ep,
> + const struct sctp_association *asoc,
> + const sctp_subtype_t type,
> + void *arg,
> + sctp_cmd_seq_t *commands);
> +
> /* Small helper function that checks if the chunk length
> * is of the appropriate length. The 'required_length' argument
> * is set to be the size of a specific chunk we are testing.
> @@ -2880,6 +2887,13 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
> return SCTP_DISPOSITION_DISCARD;
> }
>
> + /* If Cumulative TSN Ack beyond the max tsn currently
> + * send, terminating the association and respond to the
> + * sender with an ABORT.
> + */
> + if (!TSN_lt(ctsn, asoc->next_tsn))
> + return sctp_sf_violation_ctsn(ep, asoc, type, arg, commands);
> +
> /* Return this SACK for further processing. */
> sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
>
> @@ -3756,6 +3770,68 @@ nomem:
> return SCTP_DISPOSITION_NOMEM;
> }
>
> +/*
> + * Handle a protocol violation when the peer trying to advance the
> + * cumulative tsn ack to a point beyond the max tsn currently sent.
> + *
> + * We inform the other end by sending an ABORT with a Protocol Violation
> + * error code.
> + *
> + * Section: Not specified
> + * Verification Tag: Nothing to do
> + * Inputs
> + * (endpoint, asoc, chunk)
> + *
> + * Outputs
> + * (reply_msg, msg_up, counters)
> + *
> + * Generate an ABORT chunk and terminate the association.
> + */
> +static sctp_disposition_t sctp_sf_violation_ctsn(
> + const struct sctp_endpoint *ep,
> + const struct sctp_association *asoc,
> + const sctp_subtype_t type,
> + void *arg,
> + sctp_cmd_seq_t *commands)
> +{
> + struct sctp_chunk *chunk = arg;
> + struct sctp_chunk *abort = NULL;
> + char err_str[] = "The cumulative tsn ack beyond the max tsn currently
> sent:";
> +
> + /* Make the abort chunk. */
> + abort = sctp_make_abort_violation(asoc, chunk, err_str,
> + sizeof(err_str));
> + if (!abort)
> + goto nomem;
> +
> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
> + SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> +
> + if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
> + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
> + SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ECONNREFUSED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
> + SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + } else {
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ECONNABORTED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
> + SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
> + }
> +
> + sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET, SCTP_NULL());
> +
> + SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
> +
> + return SCTP_DISPOSITION_ABORT;
> +
> +nomem:
> + return SCTP_DISPOSITION_NOMEM;
> +}
> +
> /***
> * These are the state functions for handling primitive (Se
Re: [PATCH] prevent SSB compilation on s390 part 2
On Wed, Aug 01, 2007 at 11:34:04AM +0200, Heiko Carstens wrote: > From: Heiko Carstens <[EMAIL PROTECTED]> > > drivers/ssb/Kconfig has already a depends on HAS_IOMEM which should > prevent SSB from being selected. But appearantly it looks like this > doesn't matter at all if it gets selected from somewhere else. > So add an explicit depends on HAS_IOMEM to the Broadcom driver to > prevent selection on s390. > > Cc: "John W. Linville" <[EMAIL PROTECTED]> > Cc: Michael Buesch <[EMAIL PROTECTED]> > Cc: Martin Schwidefsky <[EMAIL PROTECTED]> > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> Note to reviewers: this is only relevant to -mm and wireless-dev at the moment, AFAIK... John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
netconf 2007
Hello, - I used to follow the slides of netconf in recent years (2004-2006). - I found quite an interest in the slides. - I was just wondering: is there going to be netconf in 2007 ? I could not find any info about it. Regards, JA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
On Wed, Aug 01, 2007 at 11:01:21AM +0200, Michael Tuexen wrote: > Hi Wei, > > see my comments in-line. > > Best regards > Michael > > > >(*1) At this point ctsn_ack_point=0,next_tsn=2, ctsn=1, SACK is > >accept. > >After accept SACK, ctsn_ack_point=1. > >(*2) At this point ctsn_ack_point=1,next_tsn=6, ctsn=5,TSN_lt(ctsn, > >ctsn_ack_point) is ture, so accept SACK, and then ctsn_ack_point=5 > >(*3) At this point SACK is a dup SACK, ctsn_ack_point=5,next_tsn=6, > >ctsn=1000,TSN_lt(ctsn, ctsn_ack_point) is ture, so accept SACK, and > >then > >ctsn_ack_point=1000 > I would not consider it a duplicate SACK. RFC 4460, section 2.37.2 says > that an implementation SHOULD abort the association when receiving a > SACK acknowledging unsent data. So I would suggest to send an ABORT > chunk. +1. I didn't notice the ctsn value before. We can't safely accept that a peer pre-acks data we haven't sent. Too many security holes. Neil -- /*** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
Sorry, coming in late due to list issues... Wei Yongjun wrote: On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote: On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote: If SCTP data sender received a SACK which contains Cumulative TSN Ack is not less than the Cumulative TSN Ack Point, and if this Cumulative TSN Ack is not used by the data sender, SCTP data sender still accept this SACK , and next SACK which send correctly to DATA sender be dropped, because it is less than the new Cumulative TSN Ack Point. After received this SACK, data will be retrans again and again even if correct SACK is received. So I think this SACK must be dropped to let data transmit correctly. Following is the tcpdump of my test. And patch in this mail can avoid this problem. 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040] 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100] 02:19:39.798583 sctp (1) [COOKIE ECHO] 02:19:40.082125 sctp (1) [COOKIE ACK] 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b] 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007] 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a] 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979] 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f] 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d] 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423] 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645] 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150] 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f] 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129] 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423] 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423] 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423] 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423] 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423] 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0] This is an interesting case, but I am not sure that simply discarding the SACK is the right thing. The peer in this case is violating the protocol whereby he is trying to advance the cumulative tsn ack to a point beyond the max tsn currently sent. I would vote for terminating the association in this case since either the peer is a mis-behaved implementation, or the association is under attack. I have modify the patch to abort the association with protocol violation error cause, and new patch is come on. May be this patch is correct.^_^ Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]> --- net/sctp/sm_statefuns.c.orig2007-07-29 18:11:01.0 -0400 +++ net/sctp/sm_statefuns.c 2007-07-31 00:29:16.0 -0400 @@ -104,6 +1
Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Tue, Jul 31, 2007 at 05:05:00PM +0200, Gabriel C wrote: > Jarek Poplawski wrote: > > On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote: > >> Jarek Poplawski wrote: > >>> On 28-07-2007 20:42, Gabriel C wrote: > Andrew Morton wrote: > > On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[EMAIL PROTECTED]> wrote: > > > >> Hi, > >> > >> I got this compile error with a randconfig ( > >> http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). > >> > >> ... > >> > >> net/core/netpoll.c: In function 'netpoll_poll': > >> net/core/netpoll.c:155: error: 'struct net_device' has no member named > >> 'poll_controller' > >> net/core/netpoll.c:159: error: 'struct net_device' has no member named > >> 'poll_controller' > >> net/core/netpoll.c: In function 'netpoll_setup': > >> net/core/netpoll.c:670: error: 'struct net_device' has no member named > >> 'poll_controller' > >> make[2]: *** [net/core/netpoll.o] Error 1 > >> make[1]: *** [net/core] Error 2 > >> make: *** [net] Error 2 > >> make: *** Waiting for unfinished jobs > >> > >> ... > >> > >> > >> I think is because KGDBOE selects just NETPOLL. > >> > > Looks like it. > > > > Select went and selected NETPOLL and NETPOLL_TRAP but things like > > CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' > > remains evil. > >>> ... > I think there may be a logical issue ( again if I got it right ). > We need some ethernet card to work with kgdboe right ? but we don't have > any if !NETDEVICES && !NET_ETHERNET. > > So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' is > needed too ? > >>> IMHO, the only logical issue here is netpoll.c mustn't use > >>> CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't > >>> add this dependency itself. > >>> > >> Well it does if NETDEVICES && if NET_ETHERNET which booth are N when > >> !NETDEVICES is why KGDBOE uses select and not depends on. > > > > "does if XXX" means may "use if XXX". > > From what I know means only use "if xxx" on !xxx everything inside the "if > xxx" is n and "depends on > does not work. > > ... > > menuconfig FOO > bool "FOO" > depends on BAR > default y > -- help -- > something > if FOO > > config BAZ > depends on WHATEVR && !NOT_THIS > > menuconfig SOMETHING_ELSE > > if SOMETHING_ELSE > > config BLUBB > depends on PCI && WHATNOT > > endif # SOMETHING_ELSE > > config NETPOLL > def_bool NETCONSOLE > > config NETPOLL_TRAP > bool "Netpoll traffic trapping" > default n > depends on NETPOLL > > config NET_POLL_CONTROLLER > def_bool NETPOLL > > endif # FOO > > Now if you set FOO=n all is gone and your driver have to select whatever it > needs from there. Probably not exactly so... >From drivers/net/Kconfig: > # All the following symbols are dependent on NETDEVICES - do not repeat > # that for each of the symbols. > if NETDEVICES So, according to this netpoll could presume NETDEVICES and NET_POLL_CONTROLLER are always on. But, as you've found, it's possible to select NETPOLL and !NETDEVICES, so this comment is at least not precise. On the other side something like this: ... endif # NETDEVICES config NETPOLL depends on NETDEVICES def_bool NETCONSOLE config NETPOLL_TRAP bool "Netpoll traffic trapping" default n depends on NETPOLL config NET_POLL_CONTROLLER def_bool NETPOLL depends on NETPOLL seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but still doesn't check for NETDEVICES dependency. > > > > >> Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. > >> Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the > >> question is does it work without any ethernet card ? > > > > Why kgdboe should care what netpoll needs? So, I hope, you are adding > > this select under config NETPOLL. On the other hand, if NETPOLL should > > depend on NET_POLL_CONTROLLER there is probably no reason to have them > > both. > > NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES . > > Net peoples ping ?:) OK, I wasn't right here: there is no visible reason for both in the kernel code, but I can imagine there could be some external users of NET_POLL_CONTROLLER without NETPOLL. > > > > > The "does it work" question isn't logical issue, so it's irrelevant > > here... > > Right irrelevant for the compile error but relevant for the fix in my opinion. This was kind of joking, but since some people prefer things to work, and it's hard to do this right (logical) way, some strange (unlogical) measures have to be done like repeating dependencies here. Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Tue, 2007-07-31 at 20:26 -0700, Andrew Morton wrote: > Look. Kconfig's `select' Just. Does. Not. Work. If you find > yourself contemplating using it, please, don sackcloth, take a cold > shower and several analgesics, then have another go, OK? Amen. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] prevent SSB compilation on s390 part 2
From: Heiko Carstens <[EMAIL PROTECTED]> drivers/ssb/Kconfig has already a depends on HAS_IOMEM which should prevent SSB from being selected. But appearantly it looks like this doesn't matter at all if it gets selected from somewhere else. So add an explicit depends on HAS_IOMEM to the Broadcom driver to prevent selection on s390. Cc: "John W. Linville" <[EMAIL PROTECTED]> Cc: Michael Buesch <[EMAIL PROTECTED]> Cc: Martin Schwidefsky <[EMAIL PROTECTED]> Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- drivers/net/Kconfig |1 + 1 files changed, 1 insertion(+) Index: linux-2.6.22/drivers/net/Kconfig === --- linux-2.6.22.orig/drivers/net/Kconfig +++ linux-2.6.22/drivers/net/Kconfig @@ -1434,6 +1434,7 @@ config APRICOT config B44 tristate "Broadcom 440x/47xx ethernet support" + depends on HAS_IOMEM select SSB select MII help - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Wednesday 01 August 2007, Andrew Morton wrote: > On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > > > The Sonics Silicon Backplane is a mini-bus used on > > various Broadcom chips and embedded devices. > > Sigh. > > s390: > > drivers/ssb/main.c: In function 'ssb_ssb_read16': > drivers/ssb/main.c:489: error: implicit declaration of function 'readw' > drivers/ssb/main.c: In function 'ssb_ssb_read32': > drivers/ssb/main.c:497: error: implicit declaration of function 'readl' > drivers/ssb/main.c: In function 'ssb_ssb_write16': > drivers/ssb/main.c:505: error: implicit declaration of function 'writew' > drivers/ssb/main.c: In function 'ssb_ssb_write32': > drivers/ssb/main.c:513: error: implicit declaration of function 'writel' > > > we shouldn't be compiling SSB on s390, because: > > config SSB > tristate "Sonics Silicon Backplane support" > depends on EXPERIMENTAL && HAS_IOMEM > > and > > akpm2:/usr/src/25> grep IOMEM .config > CONFIG_NO_IOMEM=y > akpm2:/usr/src/25> > > but > > akpm2:/usr/src/25> grep SSB .config > CONFIG_DCSSBLK=m > CONFIG_SSB=m > CONFIG_SSB_SILENT=y > > well, how did that come about? > > It _has_ to be `select'. It's _always_ `select'. > > yup, it's `select': > > Selected by: B44 && NETDEVICES && NET_ETHERNET || BCM43XX_MAC80211 && > NETDEVICES && !S390 && MAC80211 && WLAN_80211 && EXPERIMENTAL > > > Look. Kconfig's `select' Just. Does. Not. Work. If you find yourself > contemplating using it, please, don sackcloth, take a cold shower and > several analgesics, then have another go, OK? > > ho hum. Ah, yeah. Crap select not caring about dependencies... The problem is that people will kill me, if they don't find bcm43xx in the kconfig anymore, as they have to enable ssb before that. Ya know the flame with Uwe Bugla going crazy about that? :D Same goes for b44. It was always there in kconfig without additional deps, but now (when we merge the b44 port) we would need ssb selected before we see b44. Maybe default SSB to M? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
Hi Wei,
see my comments in-line.
Best regards
Michael
On Aug 1, 2007, at 3:06 AM, Wei Yongjun wrote:
On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
If SCTP data sender received a SACK which contains Cumulative
TSN Ack is
not less than the Cumulative TSN Ack Point, and if this
Cumulative TSN
Ack is not used by the data sender, SCTP data sender still
accept this
SACK , and next SACK which send correctly to DATA sender be
dropped,
because it is less than the new Cumulative TSN Ack Point.
After received this SACK, data will be retrans again and again
even if
correct SACK is received.
So I think this SACK must be dropped to let data transmit
correctly.
Following is the tcpdump of my test. And patch in this mail can
avoid
this problem.
02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd:
54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784]
[OS: 100] [MIS: 65535] [init TSN: 100]
02:19:39.798583 sctp (1) [COOKIE ECHO]
02:19:40.082125 sctp (1) [COOKIE ACK]
02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0]
[SSEQ 0] [PPID 0xf192090b]
02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0]
[SSEQ 1] [PPID 0x3e467007]
02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0]
[SSEQ 2] [PPID 0x11b12a0a]
02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0]
[SSEQ 3] [PPID 0x30e7d979]
02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0]
[SSEQ 4] [PPID 0x251ff86f]
02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0]
[SSEQ 5] [PPID 0xe5d5da5d]
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
[SSEQ 6] [PPID 0x87d8b423]
02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0]
[SSEQ 7] [PPID 0xca47e645]
02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0]
[SSEQ 8] [PPID 0x6c0ea150]
02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0]
[SSEQ 9] [PPID 0x9cc1994f]
02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0]
[SSEQ 10] [PPID 0xb1df4129]
02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
[SSEQ 6] [PPID 0x87d8b423]
02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
[SSEQ 6] [PPID 0x87d8b423]
02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
[SSEQ 6] [PPID 0x87d8b423]
02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
[SSEQ 6] [PPID 0x87d8b423]
02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
[SSEQ 6] [PPID 0x87d8b423]
02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
54784] [#gap acks 0] [#dup tsns 0]
Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
--- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.0
-0400
+++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.0 -0400
@@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack is not less than the Cumulative TSN
+* Ack which will be send in the next data, drop the SACK.
+*/
+ if (!TSN_lt(ctsn, asoc->next_tsn)) {
+ SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
+ SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
+ return SCTP_DISPOSITION_DISCARD;
+ }
+
/* Retur
Re: Removing the prism54 module
With pleasure: lsmod Module Size Used by tun 7680 1 snd_seq_oss26816 0 snd_seq_device 5288 1 snd_seq_oss snd_seq_midi_event 5408 1 snd_seq_oss snd_seq39856 4 snd_seq_oss,snd_seq_midi_event snd_pcm_oss37344 0 snd_mixer_oss 13504 1 snd_pcm_oss pcmcia 33184 0 snd_intel8x0 27108 2 snd_ac97_codec 88836 1 snd_intel8x0 ac97_bus1824 1 snd_ac97_codec snd_pcm62896 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 17064 2 snd_seq,snd_pcm prism5448848 0 snd_page_alloc 7080 2 snd_intel8x0,snd_pcm yenta_socket 22140 1 rsrc_nonstatic 8580 1 yenta_socket Edward On Tue, 31 Jul 2007 21:20:57 -0400 "Luis R. Rodriguez" <[EMAIL PROTECTED]> wrote: > On 7/28/07, Edward Ando <[EMAIL PROTECTED]> wrote: > > Dear All, > > I am trying to set up software suspend 2 (TuxOnIce now it seems). > > This has decided it wants to remove the prism54 module before > > starting the hibernate process. > > > > When it tries to do this, (or when I manually do: "ifconfig eth1 > > down"), I start getting these messages on all terminals, ad > > infinitum: > > > > kernel: unregister_netdevice: waiting for eth1 to become free. Usage > > count = 4 > > Hmm... can you show lsmod output please? > > Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATA over ethernet swapping
I've been working on this for quite some time. And should post again soon. Please see the patches: http://programming.kicks-ass.net/kernel-patches/vm_deadlock/current/ For now it requires one uses SLUB, I hope that SLAB will go away (will save me the trouble of adding support) and I guess I ought to do SLOB some time (if that does stay). You'd need the first 22 patches of that series, and then call sk_set_memalloc(sk) on the proper socket, and do some fiddling with the reconnect logic. See nfs-swapfile.patch for examples. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20->2.6.21 - networking dies after random time
* Marcin Ślusarz <[EMAIL PROTECTED]> wrote:
> > ei_outb_p(ENISR_ALL, e8390_base + EN0_IMR);
> > + /* force POST: */
> > + ei_inb_p(e8390_base + EN0_IMR);
> >
> > spin_unlock(&ei_local->page_lock);
> > enable_irq_lockdep_irqrestore(dev->irq, &flags);
> >
>
> Bad news. It doesn't fix the problem.
ok, it wasnt supposed to be _that_ easy i guess :-) Can you please
(re-)confirm that the workaround below indeed fixes the hung card
problem? (after producing a single WARN_ON message into the syslog)
also, does removing the ne2k-pci module and reinserting it again solve
the problem too, or is your network card stuck forever once it got into
that state?
Ingo
--->
From: Thomas Gleixner <[EMAIL PROTECTED]>
Subject: genirq: temporary fix for level-triggered IRQ resend
delayed disable relies on the ability to re-trigger the interrupt in the
case that a real interrupt happens after the software disable was set.
In this case we actually disable the interrupt on the hardware level
_after_ it occurred.
On enable_irq, we need to re-trigger the interrupt. On i386 this relies
on a hardware resend mechanism (send_IPI_self()).
Actually we only need the resend for edge type interrupts. Level type
interrupts come back once enable_irq() re-enables the interrupt line.
I assume that the interrupt in question is level triggered because it is
shared and above the legacy irqs 0-15:
17: 12 IO-APIC-fasteoi eth1, eth0
Looking into the IO_APIC code, the resend via send_IPI_self() happens
unconditionally. So the resend is done for level and edge interrupts.
This makes the problem more mysterious.
The code in question lib8390.c does
disable_irq();
fiddle_with_the_network_card_hardware()
enable_irq();
The fiddle_with_the_network_card_hardware() might cause interrupts,
which are cleared in the same code path again,
Marcin found that when he disables the irq line on the hardware level
(removing the delayed disable) the card is kept alive.
So the difference is that we can get a resend on enable_irq, when an
interrupt happens during the time, where we are in the disabled region.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
kernel/irq/resend.c |9 +
1 file changed, 9 insertions(+)
Index: linux/kernel/irq/resend.c
===
--- linux.orig/kernel/irq/resend.c
+++ linux/kernel/irq/resend.c
@@ -62,6 +62,15 @@ void check_irq_resend(struct irq_desc *d
*/
desc->chip->enable(irq);
+ /*
+* Temporary hack to figure out more about the problem, which
+* is causing the ancient network cards to die.
+*/
+ if (desc->handle_irq != handle_edge_irq) {
+ WARN_ON_ONCE(1);
+ return;
+ }
+
if ((status & (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
desc->status = (status & ~IRQ_PENDING) | IRQ_REPLAY;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20->2.6.21 - networking dies after random time
2007/7/30, Ingo Molnar <[EMAIL PROTECTED]>: > (..) > does the patch below fix those timeouts? It tests the theory whether any > POST latency could expose this problem. > > Ingo > > Index: linux/drivers/net/lib8390.c > === > --- linux.orig/drivers/net/lib8390.c > +++ linux/drivers/net/lib8390.c > @@ -375,6 +375,8 @@ static int ei_start_xmit(struct sk_buff > /* Turn 8390 interrupts back on. */ > ei_local->irqlock = 0; > ei_outb_p(ENISR_ALL, e8390_base + EN0_IMR); > + /* force POST: */ > + ei_inb_p(e8390_base + EN0_IMR); > > spin_unlock(&ei_local->page_lock); > enable_irq_lockdep_irqrestore(dev->irq, &flags); > Bad news. It doesn't fix the problem. Marcin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
