From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 16:31:04 +1000
> [IPV4]: Restore old behaviour of default config values
>
> Previously inet devices were only constructed when addresses are added
> (or rarely in ipmr). Therefore the default config values they get are
> the ones at the
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 16:31:03 +1000
> [IPV4]: Add default config support after inetdev_init
>
> Previously once inetdev_init has been called on a device any changes made
> to ipv4_devconf_dflt would have no effect on that device's configuration.
>
> This cr
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 16:31:02 +1000
> [IPV4]: Convert IPv4 devconf to an array
>
> This patch converts the ipv4_devconf config members (everything except
> sysctl) to an array. This allows easier manipulation which will be
> needed later on to provide bette
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 05 Jun 2007 16:31:01 +1000
> [IPV4]: Only panic if inetdev_init fails for loopback
>
> When I made the inetdev_init call work on all devices I incorrectly
> left in the panic call as well. It is obviously undesirable to
> panic on an allocation fai
[IPV4]: Add default config support after inetdev_init
Previously once inetdev_init has been called on a device any changes made
to ipv4_devconf_dflt would have no effect on that device's configuration.
This creates a problem since we have moved the point where inetdev_init
is called from when an
[IPV4]: Convert IPv4 devconf to an array
This patch converts the ipv4_devconf config members (everything except
sysctl) to an array. This allows easier manipulation which will be
needed later on to provide better management of default config values.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
[IPV4]: Restore old behaviour of default config values
Previously inet devices were only constructed when addresses are added
(or rarely in ipmr). Therefore the default config values they get are
the ones at the time of these operations.
Now that we're creating inet devices earlier, this changes
[IPV4]: Only panic if inetdev_init fails for loopback
When I made the inetdev_init call work on all devices I incorrectly
left in the panic call as well. It is obviously undesirable to
panic on an allocation failure for a normal network device. This
patch moves the panic call under the loopback
On Mon, Jun 04, 2007 at 11:17:54PM -0700, David Miller wrote:
>
> These array indexes are off by one.
Good catch. I'll repost this.
> This is the danger in using this "x-1" indexing style.
> Such a mistake is way too easy to make.
Yes, unfortunately the NET_IPV4_* constants are exposed to user
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 2 Jun 2007 20:02:52 +1000
> @@ -64,20 +64,26 @@
> #include
>
> struct ipv4_devconf ipv4_devconf = {
> - .accept_redirects = 1,
> - .send_redirects = 1,
> - .secure_redirects = 1,
> - .shared_media = 1,
> + .data = {
> +
I hope soon to add suspend/resume to the network device class
and remove driver specific suspend/resume from lots of devices.
The class suspend routine would just be:
pci_save_state
dev->stop
resume is
pci_restore_state
dev->open
for many devices that is all they
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 04 Jun 2007 17:01:18 -0700
> [BNX2]: Update version and reldate.
>
> Update to version 1.5.11.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Also applied.
I'd like to note in passing since I saw it in the context of this diff
that I fin
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 04 Jun 2007 17:01:08 -0700
> [BNX2]: Fix occasional counter corruption on 5708.
>
> The statistics block DMA on 5708 can be messed up occasionally on the
> average of about once per hour. If the user is reading the counters
> within one second
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 04 Jun 2007 17:00:48 -0700
> [BNX2]: Enable DMA on 5709.
>
> Add missing code to enable DMA on 5709 A1. The bit is a no-op on
> A0 and therefore can be set on all 5709 chips.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Applied, thanks
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Mon, 4 Jun 2007 21:23:51 -0400
> On Mon, Jun 04, 2007 at 05:58:49PM -0700, Michael Chan wrote:
> > [BNX2]: Add missing wait in bnx2_init_5709_context().
> >
> > For correctness, we need to wait for the MEM_INIT bit to be cleared
> > in the BNX2_CTX_COMM
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Mon, 04 Jun 2007 17:00:03 -0700
> [BNX2]: Fix netdev watchdog on 5708.
>
> There's a bug in the driver that only initializes half of the context
> memory on the 5708. Surprisingly, this works most of the time except
> for some occasional netdev watc
On Mon, 4 Jun 2007 21:00:18 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> > diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
> > index 544098d..9ec38e3 100644
> > --- a/drivers/usb/serial/io_ti.c
> > +++ b/drivers/usb/serial/io_ti.c
> > @@ -2351,7 +2351,7 @@ static int resta
On Mon, 04 Jun 2007 18:25:28 +0200 Yoann Padioleau <[EMAIL PROTECTED]> wrote:
>
> In a few files a function such as usb_submit_urb is taking GFP_KERNEL
> as an argument whereas this function call is inside a
> spin_lock_irqsave region of code. Documentation says that it must be
> GFP_ATOMIC inste
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
Search PHY address form 0, only for device ID 0x0200 (IP100A). Other device are
from PHY address 1.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
a093
From: Jesse Huang <[EMAIL PROTECTED]>
Change Logs:
Search PHY address form 0, only for device ID 0x0200 (IP100A). Other device are
from PHY address 1.
Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
---
drivers/net/sundance.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
a093
On Mon, Jun 04, 2007 at 05:58:49PM -0700, Michael Chan wrote:
> [BNX2]: Add missing wait in bnx2_init_5709_context().
>
> For correctness, we need to wait for the MEM_INIT bit to be cleared
> in the BNX2_CTX_COMMAND register before proceeding.
>
> [Added return -EBUSY when the MEM_INIT bit doesn'
On Sun, Jun 03, 2007 at 12:37:35PM +0200, Rafael J. Wysocki wrote:
> 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:
Enable support for Yukon EX chipset (88e8071).
Most of changes are related to new commands to chip for transmit,
and change in status and checksumming.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 176 +++--
driver
New version because of new chip support.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/sky2.c2007-05-31 11:27:07.0 -0700
+++ b/drivers/net/sky2.c2007-05-31 11:27:08.0
Need to setup more PCI control control registers are on Yukon EX.
Some of these also exist on Yukon EC-U as well.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 18
drivers/net/sky2.h | 77 +
2 fi
This register is more of a test and control register on Yukon2.
So rename it to Q_TEST and give some bit definitions.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |2 +-
drivers/net/sky2.h | 29 +++--
2 files changed, 12 insertions(+),
Catch-22: On Yukon EX (88E8071) need to have internal clocks enabled
before reading chip id. It is harmless on other chips.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/net/sky2.c
The General Purpose I/O register is yet another hardware workaround
catchall. Enable workaround that vendor driver does to stay
but for bug compatiable.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |5 +
drivers/net/sky2.h | 14 ++
2 files cha
These changes are to enable the Yukon Extreme (88e8071)
chipset. This chip is similar to earlier chip but has a different
set of offloading operations and some other minor quirks.
Marvell has given me some evaluation boards with the 88e8071
chip set. The chip is available now, but haven't seen a s
On Yukon EX reading some of the undocumented places in the
memory space will cause a hang. Since they don't provide useful
information, just skip the reserved areas.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 14 +-
1 file changed, 9 insertions(+)
[BNX2]: Add missing wait in bnx2_init_5709_context().
For correctness, we need to wait for the MEM_INIT bit to be cleared
in the BNX2_CTX_COMMAND register before proceeding.
[Added return -EBUSY when the MEM_INIT bit doesn't clear, suggested
by Jeff Garzik.]
Signed-off-by: Michael Chan <[EMAIL P
ple/francois/backport/r8169/20070604-00
Could you do a binary search of the patch which breaks the link detection ?
From a different report that I have received, the current testing branch of
the 8169 driver would improve things for MTU beyond 1500 bytes: nailing down
your broken link regression wou
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 4 Jun 2007 19:13:10 -0400 (EDT)
> I've applied this patch to
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-davem
>
>
> Dave, feel free to pull from that branch.
Thanks James, I'll pull that in for my next round
On Mon, Jun 04, 2007 at 05:00:35PM -0700, Michael Chan wrote:
> [BNX2]: Add missing wait in bnx2_init_5709_context().
>
> For correctness, we need to wait for the MEM_INIT bit to be cleared
> in the BNX2_CTX_COMMAND register before proceeding.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
>
On Mon, Jun 04, 2007 at 05:00:03PM -0700, Michael Chan wrote:
> [BNX2]: Fix netdev watchdog on 5708.
>
> There's a bug in the driver that only initializes half of the context
> memory on the 5708. Surprisingly, this works most of the time except
> for some occasional netdev watchdogs when sending
[BNX2]: Add missing wait in bnx2_init_5709_context().
For correctness, we need to wait for the MEM_INIT bit to be cleared
in the BNX2_CTX_COMMAND register before proceeding.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 5d69e5b..daa62d
[BNX2]: Fix occasional counter corruption on 5708.
The statistics block DMA on 5708 can be messed up occasionally on the
average of about once per hour. If the user is reading the counters
within one second after the corruption, the counters will be all
messed up. One second later, the counters
[BNX2]: Update version and reldate.
Update to version 1.5.11.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 58e6f49..a9b833b 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -54,8 +54,8 @@
#define DRV_MODULE_NAME
[BNX2]: Fix netdev watchdog on 5708.
There's a bug in the driver that only initializes half of the context
memory on the 5708. Surprisingly, this works most of the time except
for some occasional netdev watchdogs when sending a lot of 64-byte
packets. The fix is to add the missing code to initia
[BNX2]: Enable DMA on 5709.
Add missing code to enable DMA on 5709 A1. The bit is a no-op on
A0 and therefore can be set on all 5709 chips.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index daa62d9..c03282c 100644
--- a/drivers/net/bnx2.c
I've applied this patch to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-davem
Dave, feel free to pull from that branch.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [E
Hi.
On Tue, 2007-06-05 at 00:53 +0200, Pavel Machek wrote:
> On Tue 2007-06-05 08:49:04, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2007-06-05 at 00:41 +0200, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > > +#endif /* CONFIG_PM */
> > > > > >
> > > > > > > @@ -1689,6 +1775,10 @@ static s
On Tue 2007-06-05 08:49:04, Nigel Cunningham wrote:
> Hi.
>
> On Tue, 2007-06-05 at 00:41 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > > +#endif /* CONFIG_PM */
> > > > >
> > > > > > @@ -1689,6 +1775,10 @@ static struct pci_driver uli526x_driver
> > > > > > .id_table = uli526x_pci
Hi.
On Tue, 2007-06-05 at 00:41 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > +#endif /* CONFIG_PM */
> > > >
> > > > > @@ -1689,6 +1775,10 @@ static struct pci_driver uli526x_driver
> > > > > .id_table = uli526x_pci_tbl,
> > > > > .probe = uli526x_init_one,
> > > > >
Hi!
> > > > +#endif /* CONFIG_PM */
> > >
> > > > @@ -1689,6 +1775,10 @@ static struct pci_driver uli526x_driver
> > > > .id_table = uli526x_pci_tbl,
> > > > .probe = uli526x_init_one,
> > > > .remove = __devexit_p(uli526x_remove_one),
> > > > +#ifd
e1000_{read,write}_pci_cfg() are no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.h |2 --
drivers/net/e1000/e1000_main.c |4
2 files changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.22-rc3-mm1/drivers/net/e1000/e1000_hw.h.old
Waskiewicz Jr, Peter P wrote:
is it possible to set the skb->priority on arp packets
generated by the kernel?
I want to to set the 802.1p priority on arp and ip packets on
an interface. On ip packets, this can be done by the iptables
CLASSIFY target and the
skb->priority mapping from the vlan
> is it possible to set the skb->priority on arp packets
> generated by the kernel?
> I want to to set the 802.1p priority on arp and ip packets on
> an interface. On ip packets, this can be done by the iptables
> CLASSIFY target and the
> skb->priority mapping from the vlan implementation.
>
On Mon, Jun 04, 2007 at 01:25:36PM -0700, Stephen Hemminger wrote:
> While researching why the wired networking was so slow
> on my laptop (not a driver problem); spotted these small
> changes to b44 driver. Nothing urgent, maybe 2.6.23
> or later material.
ACK to the lot
John
--
John W. Linvill
Rolf Eike Beer <[EMAIL PROTECTED]> :
[...]
> I just had another freeze using your patches. After 512kB over smb it was
> dead.
In-kernel smb/cifs ?
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Add tc support for the sch_rr qdisc. This qdisc supports multiple queues
on hardware. The syntax for sch_rr is the same as sch_prio.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
include/linux/pkt_sched.h | 11
tc/Makefile |1
tc/q_rr.c
This patch is to support the new sch_rr (round-robin) qdisc being proposed
in NET for multiqueue network device support in the Linux network stack.
It uses q_prio.c as the template, since the qdiscs are nearly identical,
outside of the ->dequeue() routine.
I'm soliciting feedback for a 2.6.23 mult
API added to support multiple hardware queues on an ethernet device.
Round-robin scheduler added (sch_rr) to provide a no-scheduling policy
qdisc for hardware with multiple queues.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
include/linux/etherdevice.h |3
inclu
This patchset is an updated version of previous multiqueue network device
support patches. The general approach of introducing a new API for multiqueue
network devices to register with the stack has remained. The changes include
adding a round-robin qdisc, heavily based on sch_prio, which will al
hi @all,
is it possible to set the skb->priority on arp packets generated by the
kernel?
I want to to set the 802.1p priority on arp and ip packets on an interface. On
ip packets, this can be done by the iptables CLASSIFY target and the
skb->priority mapping from the vlan implementation.
any i
Hi,
On Monday, 4 June 2007 23:16, Nigel Cunningham wrote:
> Hi.
>
> On Mon, 2007-06-04 at 15:49 +0200, Rafael J. Wysocki wrote:
> > On Monday, 4 June 2007 13:11, Pavel Machek wrote:
> > > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > >
> > > > Add suspend/resume support to the uli526x netw
Hi.
On Mon, 2007-06-04 at 15:49 +0200, Rafael J. Wysocki wrote:
> On Monday, 4 June 2007 13:11, Pavel Machek wrote:
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Add suspend/resume support to the uli526x network driver (tested on
> > > x86_64,
> > > with 'Ethernet controller: ALi
On Mon, Jun 04, 2007 at 01:25:36PM -0700, Stephen Hemminger wrote:
> While researching why the wired networking was so slow
> on my laptop (not a driver problem); spotted these small
> changes to b44 driver. Nothing urgent, maybe 2.6.23
> or later material.
Seems sane to me. I'm travelling and wi
Francois Romieu <[EMAIL PROTECTED]> :
[...]
Andrew, have you had any time to do some testing with an uniform 7200
bytes MTU through your LAN ?
You will find a backport of the r8169 driver for the 2.6.18 kernel at
http://www.fr.zoreil.com/people/francois/backport/r8169/20070604-00
Could yo
On Monday 04 June 2007, Stephen Hemminger wrote:
> On Mon, 4 Jun 2007 21:47:59 +0200
>
> Maximilian Engelhardt <[EMAIL PROTECTED]> wrote:
> > On Monday 04 June 2007, Ingo Molnar wrote:
> > > * Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > > > Yes, the following patch makes iperf work better than
No need to grap full size MTU buffer for possibly small transmit
bounce buffers.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/b44.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/net/b44.c 2007-06-04 12:46:54.0 -0700
+++ b/drivers/n
Use netdev_alloc_skb rather than dev_alloc_skb when allocating
receive buffers.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/b44.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/net/b44.c 2007-06-04 12:49:11.0 -0700
+++ b/drivers/net/
The receive buffer offset is constant in this driver.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/b44.c | 29 -
drivers/net/b44.h |2 --
2 files changed, 12 insertions(+), 19 deletions(-)
Index: lifebook/drivers/net/b44.c
==
While researching why the wired networking was so slow
on my laptop (not a driver problem); spotted these small
changes to b44 driver. Nothing urgent, maybe 2.6.23
or later material.
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
t
Make the PHY and statistic timer run on one second boundary
for powersaving.
On resume, the driver should check for link up immediately, to
get online faster (rather than waiting for the next second).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/b44.c |9 -
On Mon, 4 Jun 2007 21:47:59 +0200
Maximilian Engelhardt <[EMAIL PROTECTED]> wrote:
> On Monday 04 June 2007, Ingo Molnar wrote:
> > * Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > > Yes, the following patch makes iperf work better than ever. But are
> > > other broken applications going to have
On Monday 04 June 2007, Ingo Molnar wrote:
> * Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > Yes, the following patch makes iperf work better than ever. But are
> > other broken applications going to have same problem. Sounds like the
> > old "who runs first" fork() problems.
>
> this is the fir
On Mon, 4 Jun 2007, Eric Paris wrote:
> Some time ago this thread bounced back and forth and seemed to come to
> rest with the patch below, I cleaned up the comments and put all the
> ACKs it received in one place below, but so much time has passed I doubt
> if they should still count for free. I
* Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Yes, the following patch makes iperf work better than ever. But are
> other broken applications going to have same problem. Sounds like the
> old "who runs first" fork() problems.
this is the first such app and really, and even for this app: i'v
On Mon, 2007-06-04 at 21:00 +0200, Thomas Gleixner wrote:
> >
> > Yes, the following patch makes iperf work better than ever.
> > But are other broken applications going to have same problem.
> > Sounds like the old "who runs first" fork() problems.
>
> Not really. The fork() "who runs first" pro
Some time ago this thread bounced back and forth and seemed to come to
rest with the patch below, I cleaned up the comments and put all the
ACKs it received in one place below, but so much time has passed I doubt
if they should still count for free. I also rediffed the patch against
the latest mil
On Mon, 2007-06-04 at 10:51 -0700, Stephen Hemminger wrote:
> > I doubt that. This is in the iperf code itself.
> >
> > void thread_rest ( void ) {
> > #if defined( HAVE_THREAD )
> > #if defined( HAVE_POSIX_THREAD )
> > // TODO add checks for sched_yield or pthread_yield and call that
> >
On Sun, Jun 03, 2007 at 11:50:29AM -0400, Jeff Garzik wrote:
> 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]>
On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
Under 22-rc2-mm1, if my VPN connection got reset, ppp0 just quietly went away.
Under 22-rc3-mm1, it seems to end up wedged and waiting for references to
Oliver Hartkopp wrote:
> I think, it goes into the right direction to use skb->pkt_type. The flag
> should really be somewhere inside the skb as all back references into
> the sk would become sticky in the implementation.
>
> But regarding the use of skb->pkt_type i would suggest to take a closer
>
On Mon, 04 Jun 2007 19:32:48 +0200
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-06-04 at 09:59 -0700, Stephen Hemminger wrote:
> > > > gettimeofday({1180973726, 982754}, NULL) = 0
> > > > recv(4, "\0\0\0\0\0\0\0\1\0\0\23\211\0\0\0\0\0\0\0\0\377\377\364"...,
> > > > 8192, 0) = 8192
>
On Mon, 2007-06-04 at 09:59 -0700, Stephen Hemminger wrote:
> > > gettimeofday({1180973726, 982754}, NULL) = 0
> > > recv(4, "\0\0\0\0\0\0\0\1\0\0\23\211\0\0\0\0\0\0\0\0\377\377\364"...,
> > > 8192, 0) = 8192
> > > gettimeofday({1180973726, 983790}, NULL) = 0
> >
> > Well, gettimeofday() is not a
On Mon, 04 Jun 2007 18:35:58 +0200
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-06-04 at 09:09 -0700, Stephen Hemminger wrote:
> > > > I did the test with an 2.6.22-rc3-git4 kernel and the p54 driver built
> > > > external as module.
> > >
> > > Can you look at iperf to figure out,
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).
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myr
Jeff Garzik wrote:
> 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
On Mon, 2007-06-04 at 09:09 -0700, Stephen Hemminger wrote:
> > > I did the test with an 2.6.22-rc3-git4 kernel and the p54 driver built
> > > external as module.
> >
> > Can you look at iperf to figure out, whether it does some weird timer
> > stuff (high frequency interval timer or such) ? Eit
Urs Thuermann wrote:
> Oliver Hartkopp <[EMAIL PROTECTED]> writes:
>
>
>> 2. The loopback indication is done by using the unused skb->protocol in
>> the tx path.
>>
>
> I don't think we should (mis-)use skb->protocol as a loopback flag.
>
Yep! After reading the comments from Patrick and
On Mon, 04 Jun 2007 08:39:48 +0200
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> 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
On Mon, 04 Jun 2007 17:04:39 -0400 Jesse Huang wrote:
> From: Jesse Huang <[EMAIL PROTECTED]>
>
> Change Logs:
> Search PHY address form 0, only for device ID 0x0200 (IP100A). Other device
> are from PHY address 1.
>
> Signed-off-by: Jesse Huang <[EMAIL PROTECTED]>
> ---
>
> drivers/net/sunda
I was out of town last week and did not have a chance to respond. Yes,
qla3xxx is (before Stephen's fix) broken on IPV6. I will review the
changes and post a patch if necessary.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Hemminger
>
Patrick McHardy wrote:
> [TCP]: Honour sk_bound_dev_if in tcp_v4_send_ack
>
> A time_wait socket inherits sk_bound_dev_if from the original socket,
> but it is not used when sending ACK packets using ip_send_reply.
>
> Fix by passing the oif to ip_send_reply in struct ip_reply_arg and
> use it fo
On Mon, May 07, 2007 at 01:45:11PM -0400, Lennart Sorensen wrote:
> Hmm, I thought I saw it on two systems already, but I should go try that
> again.
Hmm, still haven't figured this out. I just saw this one this morning:
BUG: soft lockup detected on CPU#0!
[] dump_stack+0x24/0x30
[] softlockup
[EMAIL PROTECTED] writes:
> Please note first that I want to address physical failures by
> the failover-capable network devices, which are increasingly
> becoming important as Xen-based VM systems are getting popular.
> Reducing a single-point-of-failure (physical device) is vital on
> such VM sy
Hi,
On Monday, 4 June 2007 13:11, Pavel Machek wrote:
> Hi!
>
> > 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').
> >
> > Sign
Rolf Eike Beer wrote:
> Francois Romieu wrote:
> > Rolf Eike Beer <[EMAIL PROTECTED]> :
> > [...]
>
> Ok, just tested. I used a file of 200MB and copied it to another host on
> the LAN. If I used our 100 MBit switch nothing happened. When I put a 10
> MBit hub in the middle it died at 77 MB.
I jus
Hi all,
I would like to hear comments on how TCP retransmission can be
done better on failover-capable network devices, such as an
active-backup bonding device.
Premise
===
Please note first that I want to address physical failures by
the failover-capable network devices, which are increasi
Patrick McHardy <[EMAIL PROTECTED]> writes:
> I was thinking about this, don't CAN frames include the identity
> of the sender? That would be the easiest way to determine whether
> the frame needs to be delivered.
No, CAN is quite a broken networking technology (at least in my view,
coming from t
Christoph Hellwig wrote on 31.05.2007 15:41:18:
> I'm still very unhappy with having all this in various drivers. There's
> a lot of code that can be turned into generic library functions, and even
> more code that could be made generic with some amount of refactoring.
Yes, we'd also prefer to
Stephen Hemminger wrote on 31.05.2007 18:37:03:
>
> >
> >
> > +static int try_get_ip_tcp_hdr(struct ehea_cqe *cqe, struct sk_buff
*skb,
> > + struct iphdr **iph, struct tcphdr **tcph)
> > +{
> > + int ip_len;
> > +
> > + /* non tcp/udp packets */
> > + if (!cqe->header_lengt
Hi
Thank you for your comments!
It seems to be pretty preferable we make the driver wpa_supplicant
compatible, I'll plan to rework and resubmit the patch (to
linux-wireless)
On Fri, 01 Jun 2007 12:35:49 -0400
Dan Williams <[EMAIL PROTECTED]> wrote:
> There are a few basic
> issues, rehashed her
Oliver Hartkopp <[EMAIL PROTECTED]> writes:
> 2. The loopback indication is done by using the unused skb->protocol in
> the tx path.
I don't think we should (mis-)use skb->protocol as a loopback flag.
As the name says, it's the protocol number and not a flag whether
loopback is to be done by the
Oliver Hartkopp wrote:
> 1. The needed skb->sk is preserved for the rx path (the way 'up').
I was thinking about this, don't CAN frames include the identity
of the sender? That would be the easiest way to determine whether
the frame needs to be delivered.
> 2. The loopback indication is done by
On Mon, 2007-06-04 at 00:06 +0200, David Lamparter wrote:
> Fix signedness mixup making mac addresses show up strangely
> (like 00:11:22:33:44:ffaa) in /sys/class/ieee80211/*/macaddress.
Huh, my mistake, patch looks good. Do we care for this in .22 still?
Acked-by: Johannes Berg <[EMAIL PROTE
Hi!
> 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]>
Looks ok to me.
> +#if
(resend, sorry, fscked up the address list)
> A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
> send()+close() on the peer, causing recv() to return zero, even though
> the sent data should be received.
>
> This happens if the send() and the close() is performed between
> skb_dequeue()
1 - 100 of 104 matches
Mail list logo
