the initialization as well as the vlan
> registration.
Sure, not having this hardware I didn't want to attempt a complicated
change. I'll let you take care of this.
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
s it's not clear exactly what
change is needed:
drivers/net/amd8111e.c
drivers/net/cxgb3/*
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
= drivers/net/acenic.c 1.77 vs edited =
--- 1.77/drivers/net/acenic.c 2007-07-24 16:28:41 -04:00
+++ edited/drivers/net/acenic.c 2007-
or devices that
cannot do this the change will ensure tagged packets remain tagged in
the network stack.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
---
Note, __vlan_hwaccel_rx() needed to move below __vlan_put_tag() so the
change really isn't as big as it may look below.
= in
Dave Johnson writes:
> Ben Greear writes:
> > Currently, VLAN devices offer the ability to 'reorder' the header
> > and explicitly remove the VLAN header. I assume we keep this
> > feature and have the AF_PACKET logic check the device flags to see
> > if it
would only go
to the vlan device not the base device. Not sure of an easy fix for
this as af_packet can specifically bind to a specified base device. I
don't this this would be much of an issue and probably doesn't need
fixing.
--
Dave Johnson
Starent Networks
-
To unsubscribe fro
vior for these? Should
vlan_hwaccel_receive_skb() shim a vlan tag back on the packet and send
it to the base device if there is no vlan device to send to? Also, is
it up to the individual driver to have a vlan tag on the packet if it
uses netif_receive_skb() as in case 1 above?
--
Dave Johnson
Hiroshi Shimamoto writes:
> Dave Johnson wrote:
> > mach_prepare_counter();
>
> It's a really rare case, but if SMI interrupt takes CPU here, just after
> prepare and before rdtscll, it makes delta64 shorter than expected one.
> Is it possible? And how a
Daniel Walker writes:
> Can you tell us what type of machine this was? I've seen complaints
> where the SMI's can cause some other funny stuff with calibration , be
> no one can every reproduce anything..
Xeon LV (Sossaman) based custom board. BIOS is GenSW.
--
Dave Johns
From: Dave Johnson <[EMAIL PROTECTED]>
The previous patch wasn't correctly handling the 'count' variable. If
a CPU gave bad results on the 1st or 2nd run but good results on the
3rd, it wouldn't do the correct thing. No idea if any such CPU
exists, but the patch
From: Dave Johnson <[EMAIL PROTECTED]>
I ran into this problem on a system that was unable to obtain NTP sync
because the clock was running very slow (over 1ppm slow). ntpd had
declared all of its peers 'reject' with 'peer_dist' reason.
On investigation
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]>
= net/sctp/ipv6.c 1.108 vs edited =
--- 1.108/net/sctp/ipv6.c 2007-07-05 20:40:15 -04:00
+++ edited/net/sctp/ipv6.c 2007-07-25 16:30:41 -04:00
@@ -641,6 +641,8 @@
re, your patch to __sctp_connect()
fixes calls to getpeername() after connect() just fine.
I'll post a patch for the accept()/getpeername() case in a bit.
Acked-by: Dave Johnson <[EMAIL PROTECTED]>
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line &
and your patch, connect and accept
both work with v4 mapped addresses.
Note instead of:
> + af = sctp_get_af_specific(sa_addr->sa.sa_family);
> + af->to_sk_daddr(sa_addr, sk);
you should have:
> + af = sctp_get_af_specific(sa_addr->sa_family);
> + af-&g
nnect+0x8b/0xd0
[] sys_socketcall+0xb1/0x260
[] syscall_call+0x7/0xb
I'm unsure if there is a path to call sctp_v4_to_sk_saddr() but it was
added just to be complete.
v4mapped in sctp_v4_create_accept_sk() probably isn't needed, but
since v4mapped is in sctp_sock not sctp6_sock copying
are not limited by ambiguity like the site-local addresses defined in
>[ADDARCH].
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
t/sctp/ipv6.c:sctp_v6_available()
net/sctp/ipv6.c:sctp_v6_addr_valid()
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
well as a missing check for INET6 socket type in
sctp_v4_to_sk_*addr().
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]>
= net/sctp/ipv6.c 1.108 vs edited =
--- 1.108/net/sctp/ipv6.c 2007-07-05 20:40:15 -04:00
+++ edited/net/sctp/
93 addresses if listening on IPV6_ADDR_ANY.
There may be other users of ipv6_addr_type() that could also have
problems.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
Cc: Srinivas Akkipeddi <[EMAIL PROTECTED]>
= net/ipv6/addrconf_core.c 1.2 vs edited =
--- 1.2/net/ipv6/addrconf_cor
there is a small change in that rt_free() is called while the
lock is held where before it was called without the lock held. I
don't think this should be an issue.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
= net/ipv4/route.c 1.162 vs edited =
--- 1.162/net/ipv4/route.c
occur because do_tty_write() isn't checking for
O_NONBLOCK when taking the tty's write mutex.
Signed-off-by: Dave Johnson <[EMAIL PROTECTED]>
= drivers/char/tty_io.c 1.237 vs edited =
--- 1.237/drivers/char/tty_io.c 2007-03-18 16:40:06 -04:00
+++ edited/drivers/char/tty_io.
Dave Johnson writes:
> Phillip Lougher writes:
> > Doesn't iget_locked() assume inode numbers are unique?
> >
> > In Cramfs inode numbers are set to 1 for non-data inodes (fifos,
> > sockets, devices, empty directories), i.e
> >
> > %stat device na
0/root)
> Access: 1970-01-01 01:00:00.0 +0100
> Modify: 1970-01-01 01:00:00.0 +0100
> Change: 1970-01-01 01:00:00.0 +0100
>
> Should iget5_locked() be used here?
Yep, that was busted. Below patch should be better.
--
Dave Johnson
Starent Networks
===
file as the old buffer cache is now orphaned as well.
Patch below fixes this by making get_cramfs_inode() use the inode
cache before blindly creating a new entry every time. This eliminates
the duplicate inodes and duplicate buffer cache.
--
Dave Johnson
Starent Networks
= fs/cramfs/in
minutes or even longer if the peers remain active due
to arriving packets while the loop is occurring.
Bug is present in both 2.4 and 2.6. Same patch will apply to both just
fine.
--
Dave Johnson
Starent Networks
= net/ipv4/inetpeer.c 1.12 vs edited =
--- 1.12/net/ipv4/inetpeer.c20
otherwise).
Programs that make use of sendmsg/recvmsg with a large iovec will
cause the leak. The below test program will cause a OOM DoS rather
quickly.
My original post to linux-mips mailing list follows.
--
Dave Johnson
Starent Networks
sendmsg()/recvmsg() syscalls from o32/n32
25 matches
Mail list logo
