Documentation/networking/ip-sysctl.txt | 7 ------ Makefile | 3 -- debian/changelog | 21 +++++++++++++++++++ drivers/net/igb/e1000_regs.h | 2 - drivers/net/igb/igb.h | 13 ++---------- drivers/net/igb/igb_ethtool.c | 16 +++++---------- drivers/net/igb/igb_main.c | 23 --------------------- drivers/video/fbmon.c | 4 +-- include/linux/ext3_fs.h | 1 include/linux/inetdevice.h | 5 +--- include/linux/sysctl.h | 3 -- kernel/sysctl_check.c | 2 - mm/madvise.c | 8 ------- net/core/scm.c | 2 - net/core/skbuff.c | 13 +++++++++--- net/ipv4/devinet.c | 2 - net/ipv4/route.c | 35 +-------------------------------- 17 files changed, 50 insertions(+), 110 deletions(-)
New commits: commit 71e96c830e37717ceda7eef5c18f548c7668df8c Author: Stephen Hemminger <[email protected]> Date: Fri Jul 24 17:00:55 2009 -0700 2.6.30-1+vyatta+13 commit 083b6457594821b153f750c8746d7575fe97a63b Author: Stephen Hemminger <[email protected]> Date: Wed Jun 17 15:17:34 2009 -0700 skbuff: don't corrupt mac_header on skb expansion The skb mac_header field is sometimes NULL (or ~0u) as a sentinel value. The places where skb is expanded add an offset which would change this flag into an invalid pointer (or offset). Signed-off-by: Stephen Hemminger <[email protected]> commit 46428e574e6dc11fd36489007400cb84f7d47142 Author: Stephen Hemminger <[email protected]> Date: Wed Jun 17 08:23:27 2009 -0700 skbuff: skb_mac_header_was_set is always true on >32 bit Looking at the crash in log_martians(), one suspect is that the check for mac header being set is not correct. The value of mac_header defaults to 0 on allocation, therefore skb_mac_header_was_set will always be true on platforms using NET_SKBUFF_USES_OFFSET. Arnaldo, is this correct? Signed-off-by: Stephen Hemminger <[email protected]> commit f455af6138a324b5070c05fa5b7121c0d30a264d Author: Stephen Hemminger <[email protected]> Date: Wed Jul 22 16:29:03 2009 -0700 Remove unused send-to-self patch This send-to-self over network patch was only for my performance testing, and is not supported by upstream so remove it. commit 8e72462b2da666f1266c6bd92df0adf6928b5a07 Author: Stephen Hemminger <[email protected]> Date: Wed Jul 22 15:27:55 2009 -0700 Use upstream version of IGB driver Beter to use 2.6.30.2 version of driver, the Vyatta changes were some statistics that are unimportant and show up in later kernels. commit 6ade6a3c3336fd4b7d1389d74234c437f25c1d0d Author: Stephen Hemminger <[email protected]> Date: Wed Jul 22 11:53:33 2009 -0700 Align vyatta kernel with upstream These files don't need to be changed from upstream commit 302ab600b70cd26301791a994ddfe173b0e8a488 Author: Greg Kroah-Hartman <[email protected]> Date: Fri Jul 24 14:47:51 2009 -0700 Linux 2.6.30.3 commit 58097be4fdef5a380212e52d5a02704fe5e26cc8 Author: Linus Torvalds <[email protected]> Date: Wed Jul 22 08:49:22 2009 -0700 fbmon: work around compiler bug in gcc-4.2.4 commit 3730793d457fed79a6d49bae72996d458c8e4f2d upstream. There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent he loop counter is of type 'unsigned char' and it should count to 128. The compiler will incorrectly decide that a trivial loop like this: unsigned char i, ... for (i = 0; i < 128; i++) { .. is endless, and will compile it to a single instruction that just branches to itself. This was triggered by the addition of '-fno-strict-overflow', and we could play games with compiler versions and go back to '-fwrapv' instead, but the trivial way to avoid it is to just make the loop induction variable be an 'int' instead. Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure for digging through assembler differences and finding it. Reported-and-tested-by: Krzysztof Oledzki <[email protected]> Found-by: Troy Moure <[email protected]> Gcc-bug-acked-by: Ian Lance Taylor <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=71e96c830e37717ceda7eef5c18f548c7668df8c http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=083b6457594821b153f750c8746d7575fe97a63b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=46428e574e6dc11fd36489007400cb84f7d47142 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=f455af6138a324b5070c05fa5b7121c0d30a264d http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=8e72462b2da666f1266c6bd92df0adf6928b5a07 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=6ade6a3c3336fd4b7d1389d74234c437f25c1d0d http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=302ab600b70cd26301791a994ddfe173b0e8a488 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=58097be4fdef5a380212e52d5a02704fe5e26cc8 _______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
