Hi Dave:
[ETHTOOL]: Fix UFO typo
The function ethtool_get_ufo was referring to ETHTOOL_GTSO instead of
ETHTOOL_GUFO.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apa
On Thu, Jun 15, 2006 at 10:30:17PM +0200, Francois Romieu wrote:
> Afaik free_irq() on a shared irq does not touch the hardware and
> irqs are anything but synchronous. If free_irq() is issued before
> the device is idle and its irq are not acked, it's wrong.
Correct. Before calling free_irq(), pa
Arjan van de Ven wrote:
On Wed, 2006-06-14 at 16:22 -0700, Randy Dunlap wrote:
From: Matthew Garrett <[EMAIL PROTECTED]>
Broadcom wireless patch, PCIE/Mactel support
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
My apologies for not looking at this earlier I had an email
hickup so I'm having to recreate the context from email archives,
and you didn't copy me.
Have you seen my previous work in this direction?
I know I had a much much more complete implementation. The only part
I had not completed was ip
On Wed, 2006-06-14 at 16:22 -0700, Randy Dunlap wrote:
> From: Matthew Garrett <[EMAIL PROTECTED]>
>
> Broadcom wireless patch, PCIE/Mactel support
>
> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
>
> This patch
Why does net/core/dev.c: dev_queue_transmit not pass back the actual
status from hard_start_xmit in the case of a virtual device, and why is
an error return considered a critical kernel error?
ie why:
if (!dev->hard_start_xmit(skb, dev)) {
...
rc = -ENETDOWN;
[SCTP]: Reject sctp packets with broadcast addresses.
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
include/net/sctp/structs.h |3 ++-
net/sctp/input.c |3 ++-
net/sctp/ipv6.c|6 --
net/sctp/protoc
Dave,
Please apply the following 6 SCTP patches to 2.6 tree.
Thanks
Sridhar
-
[SCTP]: Limit association max_retrans setting in setsockopt.
When using ASSOCINFO socket option, we need to limit the number of
maximum association re
[SCTP] Reset rtt_in_progress for the chunk when processing its sack.
Signed-off-by: Vlad Yasevich <[EMAIL PROTECTED]>
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
include/net/sctp/sctp.h |2 +-
net/sctp/outqueue.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff
[SCTP]: Send only 1 window update SACK per message.
Right now, every time we increase our rwnd by more then MTU bytes, we
trigger a SACK. When processing large messages, this will generate a
SACK for almost every other SCTP fragment. However since we are freeing
the entire message at the same tim
[SCTP]: Don't do CRC32C checksum over loopback.
Signed-off-by: Sridhar Samudrala <[EMAIL PROTECTED]>
---
net/sctp/input.c |3 ++-
net/sctp/output.c | 48 +++-
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/net/sctp/input.c b/n
[SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.
In the event that our entire receive buffer is full with a series of
chunks that represent a single gap-ack, and then we accept a chunk
(or chunks) that fill in the gap between the ctsn and the first gap,
we renege chunks f
If you can send me (or post) the program, I may be able to help.
+-DLS
-
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
> > Now that I've looked more into this, I'm not sure there's a
> > simple way for the IWCM to copy the pdata on the upcall.
> > Currently, the IWCM's event upcall, cm_event_handler(),
> > simply queues the work for processing on a workqueue thread.
> > So there's no per-event logic at all there.
>
[EMAIL PROTECTED] wrote:
> On Thu, 2006-06-15 at 08:41 -0500, Steve Wise wrote:
>> On Wed, 2006-06-14 at 20:35 -0500, Bob Sharp wrote:
>>
+void c2_ae_event(struct c2_dev *c2dev, u32 mq_index) {
+
>>
>>
>>
+ case C2_RES_IND_EP:{
+
+ struct c2wr_ae_connection_re
On Wed, 14 Jun 2006 22:10:26 +0100
Sitsofe Wheeler <[EMAIL PROTECTED]> wrote:
> Hello,
>
> We have a bunch of PCI D-Link System Inc DGE-530T Gigabit Ethernet cards
> which use the skge driver. However, the link light for a given card goes
> off at the switch during a suspend to ram or power down
Please pull from branch 'upstream' to get the change below:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
Patch applies both to jeff#upstream and jeff#upstream-fixes
Shortlog
Pedro Alejandro López-Valencia:
sundance: PCI ID for ip100a
Patch
-
diff --git a/driv
The following changes since commit bff7c0afa5a40acf518ae9fbf67e5f93ff9107bc:
John W. Linville:
Merge branch 'from-linus'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git
Jiri Benc:
d80211: deinit sysfs in case of an err
Hi!
> Pavel Machek wrote:
> >if you plug zd1201 into USB, it starts jamming radio,
> >immediately. Enable/disable, or iwlist wlan0 scan, or basically any
> >operation unjams the radio. This patch works it around:
>
> Can we be any more specific?
>
> At which precise point does the interference s
On Tue, 13 Jun 2006 21:25:43 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Hi:
>
> [BRIDGE]: Add support for NETIF_F_HW_CSUM devices
>
> As it is the bridge will only ever declare NETIF_F_IP_CSUM even if all
> its constituent devices support NETIF_F_HW_CSUM. This patch fixes this
> by supportin
On Thursday 15 June 2006 22:12, Florian Fainelli wrote:
> Hello Michael,
>
> I think these are really interesting functions. Currently I scripted a bit to
> do module unloading/loading on suspend/resume requests plus supplicant
> context saving and restart.
>
> Of course, if the driver is able
Hi!
> > > Which operation is the one which stops the interference, the enable or
> > > the disable?
> >
> > Disable alone was not enough to stop interference.
>
> I'm going to drop this patch for now, in the hopes that with Daniel's
> ZyDas contacts you can devise a more palatable solution.
I'
Andy Grover <[EMAIL PROTECTED]> is the guy. I'm not sure when he'll
be working on this; it's somewhere in his TODO pile.
On Thu, 15 Jun 2006, John W. Linville wrote:
>
> On Wed, Jun 14, 2006 at 04:44:56PM -0700, Mitch Williams wrote:
>
> > One of our engineers (on the I/O AT team) has been taske
On Thursday 15 June 2006 22:27, Jiri Benc wrote:
> Thu, 15 Jun 2006 18:55:11 +0200, Michael Buesch pise:
> > Please also merge the other patch. It is too hard to figure out
> > the dependencies for me now. So simply merge it and I will submit
> > a fixup patch later, after you pushed it out.
> > Th
Grant Grundler <[EMAIL PROTECTED]> :
[shared irq]
> I thought we've worked through that already:
> http://www.spinics.net/lists/netdev/msg05902.html
>
> Patch v3 takes care of that problem.
> The first step in the sequence is to mask IRQs on the tulip.
> The "neighbor" device sharing the IRQ
Thu, 15 Jun 2006 18:55:11 +0200, Michael Buesch pise:
> Please also merge the other patch. It is too hard to figure out
> the dependencies for me now. So simply merge it and I will submit
> a fixup patch later, after you pushed it out.
> The Subject was:
> [incomplete 2/5] bcm43xx-d80211: per-queue
Hi,
> I am currently thinking about the best way to correctly
> implement PM suspending for wireless drivers.
> Currently, the 802.11 stack is not suspend aware (if I talk
> about "stack" here, I mostly mean devicescape).
> For example, if we suspend the bcm43xx driver, we don't
> notify the stack
On Sat, Jun 10, 2006 at 12:38:04AM +0200, Pavel Machek wrote:
> > Which operation is the one which stops the interference, the enable or
> > the disable?
>
> Disable alone was not enough to stop interference.
I'm going to drop this patch for now, in the hopes that with Daniel's
ZyDas contacts y
On Thu, Jun 15, 2006 at 08:15:10AM +0300, Faidon Liambotis wrote:
> Regarding the disabling of IDs, I could prepare a patch for orinoco_cs
> that would disable Prism2 support via a configuration option. Would that
> be helpful/acceptable?
I'm going to 'officially' drop this patch, while you and P
The following changes since commit 76df73ff90e99681a99e457aec4cfe0a240b7982:
John W. Linville:
Merge branch 'from-linus' into upstream
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Jiri Slaby:
pci: bcm43xx
Hi,
I am currently thinking about the best way to correctly
implement PM suspending for wireless drivers.
Currently, the 802.11 stack is not suspend aware (if I talk
about "stack" here, I mostly mean devicescape).
For example, if we suspend the bcm43xx driver, we don't
notify the stack before doin
This adds netpoll support for things like netconsole/kgdboe to the s2io
10GbE driver.
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 79208f4..f2b8dba 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -2575,6 +2575,50 @@ no_rx:
On Monday 12 June 2006 21:35, Michael Buesch wrote:
> On Monday 12 June 2006 21:16, Jiri Benc wrote:
> > This makes fragmentation work with bcm43xx.
> >
> > Signed-off-by: Jiri Benc <[EMAIL PROTECTED]>
>
> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
>
> The other patch will get my sign-off
Could some one who has used HTB fix this bug? Looks like a simple use after
free.
http://bugzilla.kernel.org/show_bug.cgi?id=6681
-
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/majordo
Stefano Brivio wrote:
On Wed, 14 Jun 2006 16:22:39 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
From: Matthew Garrett <[EMAIL PROTECTED]>
Broadcom wireless patch, PCIE/Mactel support
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f
On Thursday 15 June 2006 13:32, Stefano Brivio wrote:
> On Wed, 14 Jun 2006 16:22:39 -0700
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > From: Matthew Garrett <[EMAIL PROTECTED]>
> >
> > Broadcom wireless patch, PCIE/Mactel support
> >
> > http://www.kernel.org/git/?p=linux/kernel/git/bcollins
On Wed, 2006-06-14 at 20:41 -0700, Jouni Malinen wrote:
> On Mon, Jun 12, 2006 at 03:13:02PM -0400, Kyle McMartin wrote:
>
> > Most user don't want their kern.log/dmesg filled with
> > debugging gibberish, and could turn it on if prompted.
> >
> > ( Example:
> > wifi0: TXEXC - status=0x0004 ([Di
On Thu, 2006-06-15 at 08:41 -0500, Steve Wise wrote:
> On Wed, 2006-06-14 at 20:35 -0500, Bob Sharp wrote:
>
> > > +void c2_ae_event(struct c2_dev *c2dev, u32 mq_index)
> > > +{
> > > +
>
>
>
> > > + case C2_RES_IND_EP:{
> > > +
> > > + struct c2wr_ae_connection_request *req =
> > > +
On Wed, 2006-06-14 at 20:35 -0500, Bob Sharp wrote:
> > +void c2_ae_event(struct c2_dev *c2dev, u32 mq_index)
> > +{
> > +
> > + case C2_RES_IND_EP:{
> > +
> > + struct c2wr_ae_connection_request *req =
> > + &wr->ae.ae_connection_request;
> > + struct iw
Hello,
I wrote a program that uses multicasting to send data.
It works great on HP-UX but does not work on Fedora
Core 5. I emailed the fedora list but they were of
little to no help.
Does the kernel support SO_REUSEPORT? If so can
anyone give me some suggestions why my program does
not work
On Wed, 2006-14-06 at 14:55 +0200, Jesper Dangaard Brouer wrote:
> On Wed, 2006-06-14 at 08:06 -0400, jamal wrote:
> > - Have you tried to do a long-lived session such as a large FTP and
> > seen how far off the deviation was? That would provide some interesting
> > data point.
>
> The deviation
On Thu, 2006-15-06 at 10:47 +1000, Russell Stuart wrote:
> On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> > The other problem I see with this code is it is very tightly tied to ATM
> > cell sizes, not to solving the generic question of packetisation.
>
> Others have made this point also. I
On Wed, 2006-14-06 at 14:55 +0200, Jesper Dangaard Brouer wrote:
> On Wed, 2006-06-14 at 08:06 -0400, jamal wrote:
> > - Have you tried to do a long-lived session such as a large FTP and
> > seen how far off the deviation was? That would provide some interesting
> > data point.
>
> The deviation
On Wed, Jun 14, 2006 at 04:44:56PM -0700, Mitch Williams wrote:
> One of our engineers (on the I/O AT team) has been tasked with modifying
> the Linux kernel to properly support multiple hardware queues (both TX and
> RX). We'll make sure that he looks at the netpoll interface as part of
> that p
On Wed, 14 Jun 2006 16:22:39 -0700
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> From: Matthew Garrett <[EMAIL PROTECTED]>
>
> Broadcom wireless patch, PCIE/Mactel support
>
> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8
* Heiko Carstens <[EMAIL PROTECTED]> wrote:
> How about the patch below? The warning goes away and I assume
> "tmp_list" needs lockdep_reinit_key too, since it should have the same
> locking rules as the rest of qeth's skb-queue management.
yeah, looks good.
Ingo
-
To unsubscribe from
Russell Stuart wrote:
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chap
Thanks for critique.
>Please read Documentation/SubmittingPatches (and CodingStyle) and submit your
>kernel patch to netdev.
OK.
>1) why wasn't it possible to use the PPPoX infrastructure of the kernel which
>is already being used by PPPoE ? Or at least model it somehow similar to the
>exis
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp
51 matches
Mail list logo