Begin forwarded message:
Date: Thu, 4 May 2006 23:15:56 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
http://bugzilla.kernel.org/show_bug.cgi?id=6495
Summary: Vlan MTU Fragmentation
Kernel Version: 2.6.16.12
I don't know if
http://bugzilla.kernel.org/show_bug.cgi?id=4615
has been solved yet, but I'm seeing a similar thing with 2.6.17-rc1 and a ppp
connection over ssh.
Earlier kernels (at least linux-2.6.14-rc4) did not show this with the
exactly same settings.
How it happens:
- open up the ppp con
> The actual problem is with receiving. ACK frames need to be sent exactly
> after SIFS interval (10 or 16 microseconds depending on a PHY, +/- 10%)
> after last bit of the frame was received. This means it cannot be done in a
> software. You need to tell the hardware about MAC address you are usin
I noticed the same behaviour, i.e. can not use both MSI and MSIX without
rebooting.
I had sent a message to the maintainer of the MSI/MSIX source a few
months ago and got a response that they were working on fixing it. Not
sure what the progress is on it.
Ayaz
nvpublic
-Original Message-
YOSHIFUJI Hideaki / <[EMAIL PROTECTED]> wrote:
>
> @@ -2291,10 +2287,9 @@ static int addrconf_ifdown(struct net_de
> Do not dev_put!
> */
>if (how == 1) {
> - write_lock_bh(&addrconf_lock);
> - dev->ip6_ptr = NULL;
> -
On Thu, May 04, 2006 at 10:51:11PM -0400, Andy Gospodarek wrote:
> On Fri, May 05, 2006 at 09:47:56AM +0900, Horms wrote:
> > On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
> > >
> > > Instead of using the default timeout of 3 minutes, this uses the timeout
> > > specific to the
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 750e250..74dca37 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -127,20 +127,18 @@ extern int unregister_inet6addr_notifier
static inline struct inet6_dev *
On Fri, May 05, 2006 at 09:47:56AM +0900, Horms wrote:
> On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
> >
> > Instead of using the default timeout of 3 minutes, this uses the timeout
> > specific to the protocol used for the connection. The 3 minute timeout
> > seems somewhat a
On Friday 05 May 2006 09:11, David S. Miller wrote:
> I very much fear abuse of the inet_hashes[] array. So I'd rather
> hide it behind a programmatic interface, something like:
done! I will continue with implementation of default netchannel for now.
> Thanks!
anytime =)
Cheers,
K
I'm using the latest wireless dev git. wireless tools version 28.
wpa_supplicant 0.4.8 .
Here's the output of iwconfig wlan0:
wlan0 IEEE 802.11g ESSID:"mysid"
Mode:Managed Frequency:2.437 GHz Access Point: xx:xx.
RTS thr:off Fragment thr=2346 B
Encrypt
This makes the current hack used to prevent 802.11g cards from scanning with
802.11b channels not break scanning in 802.11b drivers.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 2720f1d..5c8fe22 100644
--- a/net/d80211/i
On Thu, 2006-05-04 at 16:22 -0700, David S. Miller wrote:
> From: Kelly Daly <[EMAIL PROTECTED]>
> Date: Thu, 4 May 2006 12:59:23 +1000
>
> > We DID write an infrastructure to resolve this issue, although it is more
> > complex than the dynamic descriptor scheme for userspace. And we want to
>
On Thu, May 04, 2006 at 04:11:16PM -0400, Andy Gospodarek wrote:
>
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs cod
On Fri, 5 May 2006 02:58:29 +0200
Stefano Brivio <[EMAIL PROTECTED]> wrote:
> This applies to 2.6.17-rc3.
Heh, sorry. It's PATCH 1/2, not 0/2. :)
--
Ciao
Stefano
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
This applies to 2.6.17-rc3.
--
Fix whitespace.
Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-
bcm4319 is reported to work. This applies to 2.6.17-rc3.
--
Add PCI ID for bcm4319.
Signed-off-by: Stefano Brivio <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/w
On May 3, 2006, at 11:34, Herbert Valerio Riedel wrote:
hello *
On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote:
At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote:
On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote:
The Cogent CSB655 used the Broadcom Dual Phy. They eventually
David Vrabel <[EMAIL PROTECTED]> :
[...]
> >ipg: replace #define with enum
> >
> >Added some underscores to improve readability.
> >
> >Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
>
> Nack. Register names in code should match those used in the
> documentation (even if
Pekka Enberg <[EMAIL PROTECTED]> :
[...]
> My initial patches are here:
>
> http://www.cs.helsinki.fi/u/penberg/linux/ip1000/
Nice. Thanks.
> I consider your tree the master now. Please let me know when you have
> recreated the history, so I can clone your tree. Thanks.
The new serie is availab
On Thu, May 04, 2006 at 04:25:46PM -0700, David S. Miller wrote:
> That being said, the first thing that should be tried is reverting
> the above mentioned change and see if the problem goes away. If
> so, then we need to investigate what the bandwidth delay product is
> for the connection, a
It makes sense to add this simple statistic to keep track of received
multicast packets.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- bridge.orig/net/bridge/br_input.c 2006-04-21 14:28:55.0 -0700
+++ bridge/net/bridge/br_input.c2006-05-04 16:07:24.0 -0700
@@
where did you send this patch?
I don't think I ever got it
> Loss was broken, patch sent.
>
> The following works now:
>
> # tc qdisc add dev eth1 root handle 1:0 netem loss 20%
>
> # tc qdisc add dev eth1 parent 1:1 handle 10: tbf \ rate 256kbit buffer
> 1600 limit 3000 # ping -f -c 1000 shel
On Thu, May 04, 2006 at 04:25:46PM -0700, David S. Miller wrote:
>
> That being said, the first thing that should be tried is reverting
> the above mentioned change and see if the problem goes away. If
> so, then we need to investigate what the bandwidth delay product is
> for the connection, and
Please apply to 2.6.17, as it fixes a problem that prevents bcm43xx devices
which support 802.11a in addition to 802.11b/g from working, as the MAC
address isn't detected correctly. This applies to 2.6.17-rc3.
--
Check for valid MAC address in SPROM fields instead of relying on PHY type
while set
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Thu, 4 May 2006 13:59:04 +1200
> Wouldn't it be more likely commit 5d0b6f2bdaf7e016e750cd24164a241512d968a3
>
> as this touches net/ipv4/tcp_output.c and is also in same general area?
This commit makes us account transmit memory properly. Previousl
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Thu, 4 May 2006 12:59:23 +1000
> We DID write an infrastructure to resolve this issue, although it is more
> complex than the dynamic descriptor scheme for userspace. And we want to
> keep this simple - right?
Yes.
I wonder if it is possible to manag
Hi,
I am seeing the following problem with MSI/MSI-X.
Note: I am copying netdev since other network drivers use
this feature and somebody on the list could throw light.
Our 10G network card(Xframe II) supports MSI and MSI-X.
When I load/unload the driver with MSI support followed
by an attempt to
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Thu, 4 May 2006 17:28:27 +1000
> On Wednesday 26 April 2006 17:59, David S. Miller wrote:
> > Next, you can't even begin to work on the protocol channels before you
> > do one very important piece of work. Integration of all of the ipv4
> > and ipv6 prot
From: Alex Aizman <[EMAIL PROTECTED]>
Date: Thu, 04 May 2006 15:49:11 -0700
> So, what are the requirements?
I will say it a 10th time, "we simply don't know yet."
Please be patient and let us design the net channel infrastructure
properly, then we can think clearly about how hardware might supp
So, what are the requirements? The hardware already parses L2, L3, L4 headers,
and for the future generation we could add to the set of already supported
steering/filtering criteria. Having some discussion on the essential vs.
optional requirements seems like the right thing at this point.
On
Thu, 4 May 2006 22:55:58 +0200, Ivo van Doorn pise:
> On Thursday 4 May 2006 21:26, Marcus Better wrote:
> > I wonder what exactly is causing this limitation? Why isn't it just a
> > matter of software support?
>
> Hardware limitations probably. For example the Ralink devices.
> The MAC address mu
On Thursday 4 May 2006 21:26, Marcus Better wrote:
> Jiri Benc wrote:
> > This is unnecessary. AFAIK bcm43xx hardware doesn't support more than one
> > interface at a time (not counting monitor interfaces as those are somewhat
> > special).
>
> I wonder what exactly is causing this limitation? Why
Instead of using the default timeout of 3 minutes, this uses the timeout
specific to the protocol used for the connection. The 3 minute timeout
seems somewhat arbitrary (though I know it is used other places in the
ipvs code) and when failing over it would be much nicer to use one of
the configure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jiri Benc wrote:
> This is unnecessary. AFAIK bcm43xx hardware doesn't support more than one
> interface at a time (not counting monitor interfaces as those are somewhat
> special).
I wonder what exactly is causing this limitation? Why isn't it just a
Xiaoliang (David) Wei wrote:
Hi gurus,
I am reading the code of tcp_highspeed.c in the kernel and have a
question on the hstcp_cong_avoid function, specifically the following
AI part (line 136~143 in net/ipv4/tcp_highspeed.c ):
/* Do additive increase */
if (tp-
Jesse Brandeburg wrote:
My personal preference is to set a flag in the skb struct indicating
whether
or not the crc is appended (and skb_put). Then, bridging code can
ignore it if needed,
and sniffers and such can get the CRC in user-land. To remain
backwards compat,
at least the skb-put of
On Thu, May 04, 2006 at 11:00:28AM +0200, Jiri Benc wrote:
> Ok. So what about PRISM2_HOSTAPD_MGMT_IF ioctl that will add management
> interface (if not added yet) and return its ifindex? It would accept a
> boolean parameter (like PRISM2_PARAM_HOSTAPD) to add/remove that
> interface. If you agree
Hello, Jean!
I'm converting Orinoco to the dBm reporting, and it turns out that the
best signal iwconfig will report is -1dBm (0.8mW). This would happen if
qual->level has its highest value of 255. Please see this code from
wireless_tools.29.pre10:
len = snprintf(buffer, buflen, "Signal level%c
On 5/3/06, Ben Greear <[EMAIL PROTECTED]> wrote:
Jesse Brandeburg wrote:
> On 5/2/06, Ben Greear <[EMAIL PROTECTED]> wrote:
>
>> In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f
>> to e1000_main.c, there is the change below.
>>
>> I am curious why the skb_put no longer subtracts ETHERNET_FCS_
On 5/4/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
On Wed, May 03, 2006 at 11:32:23PM -0700, David S. Miller wrote:
>
> Ok, it took me a while to review this one as verifying such
> a set of changes is always tricky, but looks good!
Thanks. It took me quite a while to assure myself that it was OK
Hi,
I try to run the following code in kernel (which is similar to apm() function)
but it does not seem to work...
if (smp_processor_id() != cpu) {
current->cpus_allowed = (1UL << cpu);
schedule();
if (smp_processor_id() != cpu) {
BUG();
}
}
Any idea why?
Ben
Hi,
I try to run the following code in kernel (which is similar to apm() function)
but it does not seem to work...
if (smp_processor_id() != cpu) {
current->cpus_allowed = (1UL << cpu);
schedule();
if (smp_processor_id() != cpu) {
BUG();
}
}
Any idea why?
Ben
Hi gurus,
I am reading the code of tcp_highspeed.c in the kernel and have a
question on the hstcp_cong_avoid function, specifically the following
AI part (line 136~143 in net/ipv4/tcp_highspeed.c ):
/* Do additive increase */
if (tp->snd_cwnd < tp->snd_cwnd_clamp
Pekka J Enberg <[EMAIL PROTECTED]> :
> [...]
> > maintain the tree, I can send you my patches so you can recreate the full
> > history. The first steps were produced by quilt on the original
> > out-of-tree driver, though, so they're probably not helpful.
On Thu, 2006-05-04 at 01:35 +0200, Franc
On Thu, 2006-05-04 at 14:33 +0200, Jiri Benc wrote:
> TSF is set to a value sent by an AP. Is there anything that prevents
> that AP to send you e.g. 0xf0?
Ah, good point, I didn't think of stupid APs. Yeah, it should handle it
I guess.
johannes
signature.asc
Description: This is a
On Thu, 04 May 2006 14:22:20 +0200, Johannes Berg wrote:
> Probably. And yes, it should still work since stop>start at all times.
Are you sure you can guarantee that stop > start when these values come
from hardware you don't have specification for?
> Yes, if the card has been up for like 459148
On Wed, 2006-05-03 at 09:44 -0700, Jouni Malinen wrote:
> But there is.. I committed changes to the wpa_supplicant devel branch
> for this yesterday. It seems to work fine with net/d80211 and bcm43xx
> with this small patch to d80211 to allow the functionality to be moved
> into user space.
Cool,
Some modules depend on that value, although it was initially introduced
for in-kernel static build.
No in-kernel users require it to be exported, so if you do think it
should not be exported I will force external module changes.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
--- a/drivers/c
On Thu, 2006-05-04 at 11:11 +0200, Jiri Benc wrote:
> I think some safety fallback would be better. Like
> if (stop - start < SOME_MIN_VALUE) channel_change_time = SOME_MIN_VALUE
> (of course, this won't work because stop and start are unsigned, but you
> probably got the idea).
Probably. And yes
Stefano Cavallari <[EMAIL PROTECTED]> :
> I sent this to netdev@vger.kernel.org, but I got no replies.
I am subscribed to netdev but the original has not landed in
my mailbox yet.
Can you try the patch available in:
http://bugzilla.kernel.org/show_bug.cgi?id=6032
--
Ueimor
-
To unsubscribe from
From: Jens Osterkamp <[EMAIL PROTECTED]>
A newer board revision changed the type of ethernet phy.
Moreover, this generalizes the way that a phy gets switched
into fiber mode when autodetection is not available.
Signed-off-by: Jens Osterkamp <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL
From: Jens Osterkamp <[EMAIL PROTECTED]>
We found a new chip setting that we need in order
to make the driver work more reliable.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Index: linux-2.6.17-rc3/drivers/net/spider_net.c
===
The first patch introduces a new PHY BCM5461 as the BCM5421 will be no
longer produced. Besides that it generalizes the way, PHYs are
switched into fiber mode.
The second introduces a new setting that we need to make the driver
work more reliable.
Please apply.
Jens
-
To unsubscribe from this li
On Wed, 3 May 2006 21:05:53 +0200, Michael Buesch wrote:
> @@ -354,6 +354,33 @@
> bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
> }
>
> +static void bcm43xx_measure_channel_change_time(struct bcm43xx_private *bcm)
> +{
> + struct bcm43xx_radioinfo *radio;
> + u64 star
On Wed, 3 May 2006 17:11:28 +0200 (CEST), Jiri Benc wrote:
> Default management interface (wmasterXap) confuses users. It is only needed
> for AP mode (and only until the new netlink interface between kernel and
> hostapd is implemented).
Please don't apply this patch.
Thanks,
Jiri
--
Jiri B
On Wed, 3 May 2006 11:35:24 -0700, Jouni Malinen wrote:
> I think it would be nice to get this in so that both client and AP modes
> can use the same mechanism (user space MLME); hostapd already needs this
> wmaster0ap interface. In other words, if we do not want to see that
> interface by default,
On Wednesday 26 April 2006 17:59, David S. Miller wrote:
> Next, you can't even begin to work on the protocol channels before you
> do one very important piece of work. Integration of all of the ipv4
> and ipv6 protocol hash tables into a central code, it's a total
> prerequisite. Then you modify
On Wed, May 03, 2006 at 11:32:23PM -0700, David S. Miller wrote:
>
> Ok, it took me a while to review this one as verifying such
> a set of changes is always tricky, but looks good!
Thanks. It took me quite a while to assure myself that it was OK
as well :)
Anyway, the same issue affects DCCP (
58 matches
Mail list logo
