On Sun, 2007-06-03 at 18:26 +0200, Maximilian Engelhardt wrote:
> > Is there any other strange behavior of the high res enabled kernel than
> > the b44 problem ?
>
> I didn't notice anything in the past (as I wrote). But today I did some tests
> for an updated version of the p54 mac80211 wlan dri
I know, I misunderstand the iph->tot_len, the ICMP payload is not
contained a valid ipv4 packet.
I do this under IPv6, it has no problem because IPv6 does not check
this. ^_^
Thank you very much.
But this is not the old_mtu field that we were talking about. The
old_mtu field comes from iph->t
On Mon, Jun 04, 2007 at 12:32:49PM +0800, Wei Yongjun wrote:
>
> The latest kernel 2.6.21.3 also doing so. The rule to send ICMP message
> limit this.
> Ref to net/ipv4/icmp.c
> line 433 void icmp_send(struct sk_buff *skb_in, int type, int code,
> __be32 info)
> line 434 {
> ...
> line 572/*
On Mon, Jun 04, 2007 at 12:03:57PM +0800, Wei Yongjun wrote:
So I want to know how the route announce a MTU larger then 576, such as
1280? RFC says ICMP error message return as much as we can without
exceeding 576 bytes.
I think there is a misunderstanding here. The RFC is talking a
On Mon, Jun 04, 2007 at 12:03:57PM +0800, Wei Yongjun wrote:
>
> So I want to know how the route announce a MTU larger then 576, such as
> 1280? RFC says ICMP error message return as much as we can without
> exceeding 576 bytes.
I think there is a misunderstanding here. The RFC is talking about
On Mon, Jun 04, 2007 at 08:39:21AM +0800, Wei Yongjun wrote:
Huh? The test new_mtu >= old_mtu should only hold if the sending router
is buggy which is what the hack is for.
Note here old_mtu is not the real old mtu, is the received message's size:
unsigned short old_mtu = ntohs(iph-
On Mon, Jun 04, 2007 at 08:39:21AM +0800, Wei Yongjun wrote:
>
> >Huh? The test new_mtu >= old_mtu should only hold if the sending router
> >is buggy which is what the hack is for.
>
> Note here old_mtu is not the real old mtu, is the received message's size:
> unsigned short old_mtu = ntohs(iph->
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Sun, 3 Jun 2007 18:50:59 -0700
> On Sun, 03 Jun 2007 18:00:51 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> >
> > I don't think it's %100 right, I'm referring specifically to
> >
> > e68a8c10c4c5daf363e946d10c1a5cba77d7f92c
> >
> >
On Sun, 03 Jun 2007 18:00:51 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
>
> I don't think it's %100 right, I'm referring specifically to
>
> e68a8c10c4c5daf363e946d10c1a5cba77d7f92c
>
> Sure, qla3xxx is only handling ipv4 in that ql_hw_csum_setup()
> function, but if you check the call
I don't think it's %100 right, I'm referring specifically to
e68a8c10c4c5daf363e946d10c1a5cba77d7f92c
Sure, qla3xxx is only handling ipv4 in that ql_hw_csum_setup()
function, but if you check the call site it really wants
CHECKSUM_PARTIAL skb's to work on. And CHECKSUM_PARTIAL skbs are only
set
When received ICMP Fragmentation Needed message, PATH MTU is always set
to the 576 even if MTU in ICMP message is lager then 576. This is
because of error condition in function ip_rt_frag_needed(), now if
packet size of that ICMP message is less then new MTU, packet size will
be used ,but RFC
On Mon, Jun 04, 2007 at 08:52:07AM +1000, Mick McCreath wrote:
>
> Which traceroute are you using??
>
> I am using version 1.4a12 by Van Jacobson downloaded from Lawrence
> Berkeley Labs.
The one from Debian which is based on the same source. Hmm, it
looks like I came to the same conclusion tha
Hi Herbet,
Thanks for the feedback.
On Sat, 2007-06-02 at 21:07 +1000, Herbert Xu wrote:
> Mick McCreath <[EMAIL PROTECTED]> wrote:
> >
> > When I run traceroute -i eth1 5.4.3.2, the UDP packets are routed out
> > eth2.
> >
> > Has anybody seen this behaviour with traceroute??
>
> Well the ver
Oliver Hartkopp wrote:
> The more i was thinking about my own suggested solution the more it
> turned out to be ugly for me ...
>
> Summarizing we have two problems to solve:
>
> 1. Identify the originating sk to potentially trash my own sent messages.
> 2. Indicate a requested local loopback to th
From: James Chapman <[EMAIL PROTECTED]>
Date: Sun, 03 Jun 2007 18:17:03 +0100
> I've had no comments on the latest version of my L2TP driver which I
> posted a month ago. Can someone review it or accept/reject it, please? I
> have a pppd plugin that uses this driver and I'm eager to push it
> u
Urs Thuermann wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>And it allows you have both loopback and non-loopback devices
>>in case that would be useful.
>
>
> That sounds very promising. I also was unhappy with the fixed number
> of vcan devices at module load time and have thought
Strobl Anton wrote:
> Patch for sch_cbq.c works perfect - no more kernel panic!
> (sch_atm.c => im not able to test atm shaping, sorry)
Thanks Anton. Dave, please apply.
[NET_SCHED]: Fix filter double free
cbq and atm destroy their filters twice when destroying inner classes
during qdisc destru
Patch for sch_cbq.c works perfect - no more kernel panic!
(sch_atm.c => im not able to test atm shaping, sorry)
Thank you for the fast response to my request!
Strobl Anton
Zitat von Patrick McHardy <[EMAIL PROTECTED]>:
Michal Piotrowski wrote:
Strobl Anton pisze:
While trying to stop qd
I've had no comments on the latest version of my L2TP driver which I
posted a month ago. Can someone review it or accept/reject it, please? I
have a pppd plugin that uses this driver and I'm eager to push it
upstream for inclusion in the pppd distribution as soon as possible. But
first, this L2
Michal Piotrowski wrote:
> Strobl Anton pisze:
>
>> While trying to stop qdisc/cbq with command
>>
>>tc qdisc del dev eth1 root
>>
>> EIP is at u32_destroy+0x52/0xd8 [cls_u32]
Please try this patch.
[NET_SCHED]: Fix filter double free
cbq and atm destroy their filters twice when destroying
On Monday 28 May 2007, Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
> > > following combinations on the kernel command line:
> > >
> > > 1) highres=off nohz=off (should be the sa
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
MAINTAINERS |9 ++-
drivers/net/8139cp.c | 17 +++---
drivers/net/acenic.c
Brice Goglin wrote:
Limit the number of recoveries from a NIC hw watchdog reset to 1 by default.
It enables detection of defective NICs immediately since these memory parity
errors are expected to happen very rarely (less than once per century*NIC).
However, a defective NIC (very rare, fortunatel
Mithlesh Thukral wrote:
NetXen: Correct link status messages.
This patch will fix the problem of wrong link status messages
that were reported.
Signed-off by: Wen Xiong <[EMAIL PROTECTED]>
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |1 +
Mithlesh Thukral wrote:
NetXen: Fix initialization and subsequent ping issue
This patch will fix the initialization and ping issues seen on
certain PPC architecture blades.
Signed-off by: Wen Xiong <[EMAIL PROTECTED]>
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/n
Mithlesh Thukral wrote:
NetXen: Add multicast filter code
This patch will add manage the multicast filter from driver.
It will add capability to write multicast addresses to hardware.
Signed-by: Mithlesh Thukral <[EMAIL PROTECTED]>
as has been repeatedly noted, there are endianness bugs. Firs
Mithlesh Thukral wrote:
NetXen: Add NETXEN prefix to a macro
This patch will add the "NETXEN" prefix to "USER_START" macro.
Signed-off by: Wen Xiong <[EMAIL PROTECTED]>
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |4 ++--
drivers/net/netx
Brice Goglin wrote:
Report link up/down in standard ethtool way
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.c |1 +
1 file changed, 1 insertion(+)
applied to #upstream-fixes
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
Li Yang wrote:
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
MAINTAINERS |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
applied, w/ Kim's ack
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Mithlesh Thukral wrote:
NetXen: Removal of redundant free_irq
This patch removes a redundant free_irq() call from remove() routine.
This will also eliminate a warning during unload of driver.
Signed-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic_main.c |2 --
1
Auke Kok wrote:
To assure the symmetry of poll enable/disable in up/down, we should
initialize the netdevice to be poll_disabled at load time. Doing
this after register_netdevice leaves us open to another race, so
lets move all the netif_* calls above register_netdevice so the
stack starts out ho
Stephen Hemminger wrote:
The interface for network device VLAN extension was confusing.
The kill_vid function is only really useful for devices that do
hardware filtering. Devices that only do VLAN receiption without
filtering were being forced to provide the hook, and there were
bugs in those de
Stephen Hemminger wrote:
Reading the code for ql_hw_csum_setup(), it is obvious that
this driver is broken for IPV6. The driver sets the NETIF_F_HW_SUM
flag, but the code for checksum setup only deals with IPV4.
Compile tested only, no hardware available.
Signed-off-by: Stephen Hemminger <[EMAI
-
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
[netdev added to CC]
Strobl Anton pisze:
While trying to stop qdisc/cbq with command
tc qdisc del dev eth1 root
using iproute2-2.6.20-070313, i get following kernel panic:
Oops: [#1]
Modules linked in: cls_route cls_u32 cls_fw sch_prio sch_sfq sch_tbf
sch_cbq ipt_MASQUERADE xt_TCPMSS
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Add suspend/resume support to the uli526x network driver (tested on x86_64,
with 'Ethernet controller: ALi Corporation M5263 Ethernet Controller, rev 40').
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
drivers/net/tulip/uli526x.c | 120 +++
36 matches
Mail list logo
