On Tue, May 15, 2007 at 10:47:25PM -0700, David Miller wrote:
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Wed, 16 May 2007 07:40:00 +0200
After initializing dev-_xmit_lock register_netdevice()
sets lockdep class according to dev-type.
Idea of this patch - by David Miller.
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Wed, 16 May 2007 08:17:32 +0200
BTW - I think some patch on vlan cannot do any harm (at
least like this previous of mine - with only ppp
considered), and maybe this all could be forgotten.
Let's wait to see if any new messages show up.
I think
Hi Sangtae,
On Sat, 12 May 2007, Sangtae Ha wrote:
Hi Bill,
This is the small patch that has been applied to 2.6.22.
Also, there is limited slow start, which is an experimental RFC
(RFC3742), to surmount this large increase during slow start.
But, your kernel might not have this. Please
Hi all!
The following defines are incorrect (include/linux/mii.h):
#define BMSR_100FULL2 0x0200 /* Can do 100BASE-T2 HDX */
#define BMSR_100HALF2 0x0400 /* Can do 100BASE-T2 FDX */
it must be
#define BMSR_100HALF2 0x0200 /* Can do 100BASE-T2 HDX */
#define
On Tue, May 15, 2007 at 11:17:51PM -0700, David Miller wrote:
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Wed, 16 May 2007 08:17:32 +0200
BTW - I think some patch on vlan cannot do any harm (at
least like this previous of mine - with only ppp
considered), and maybe this all could be
On Tue, May 08, 2007 at 10:29:03AM +0200, Tomasz Chmielewski wrote:
Michael Jones wrote:
+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif
Personally I'm less fussed about WAN / LE support. Anyone with any
sense will run ixp4xx boards doing such a specialised
On Fri, 11 May 2007, Satyam Sharma wrote:
(later)
I Googled a bit to see if this problem was faced elsewhere in the kernel
too. Saw the following commit by Ingo Molnar
(9883a13c72dbf8c518814b6091019643cdb34429):
- lock_sock(sock-sk);
+ local_bh_disable();
+
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:
+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif
Personally I'm less fussed about WAN / LE support. Anyone with any
sense will run ixp4xx boards doing such a specialised network
operation as
On 16 May 2007, at 10:41, Lennert Buytenhek wrote:
Making a driver work in both modes
of operation is generally not just an issue of adding a couple of
be32_to_cpu()s in the right places.
While this comment is technically correct, Christian's driver
achieves endian agnostic operation with
I found in function [ip_send_reply] and [icmp_reply], we
use such code to get the destination address of our
packet:
struct rtable *rt = (struct rtable *)skb-dst;
..
daddr = ipc.addr = rt-rt_src;
I have a question here:
Is there any special reason for using rt-rt_src as destination address?
Lots of people wrote:
Lots of huffing and puffing about endian support by this driver ...
For what it's worth, the NSLU2-Linux project (which has over 10,000
known users of our custom ixp4xx firmware, most of which will eventually
be users of this new driver) is *endian-neutral*.
We support
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
The NSLU2 people are the
This patch fixes a bug where the link speed change was not
detected correctly. This occured on a 440SPe (EMAC4) system
where the old link speed was 100Mbps and the new link speed
is 1000Mbps.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
commit 1e2a6085bbb6bd384e0812b6e9c62d18d14e1c0f
tree
[R8169] Add endianess annotations to [RT]xDesc
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
---
commit 8b36037f072047e61557506ee917dcc25680bd69
tree faafe5e664affabef85ff4dcab280338fd528fae
parent b26c4a9f50ccfade25e3699f616ce97590dc2cb7
author Rolf Eike Beer [EMAIL PROTECTED] Wed, 16 May
Hi Jiri,
On 5/16/07, Jiri Kosina [EMAIL PROTECTED] wrote:
On Fri, 11 May 2007, Satyam Sharma wrote:
(later)
I Googled a bit to see if this problem was faced elsewhere in the kernel
too. Saw the following commit by Ingo Molnar
(9883a13c72dbf8c518814b6091019643cdb34429):
-
Lennert Buytenhek wrote:
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
Hi Satayam,
(later)
I Googled a bit to see if this problem was faced elsewhere in the kernel
too. Saw the following commit by Ingo Molnar
(9883a13c72dbf8c518814b6091019643cdb34429):
- lock_sock(sock-sk);
+ local_bh_disable();
+ bh_lock_sock_nested(sock-sk);
Hi Marcel,
On 5/16/07, Marcel Holtmann [EMAIL PROTECTED] wrote:
Hi Satayam,
(later)
I Googled a bit to see if this problem was faced elsewhere in the kernel
too. Saw the following commit by Ingo Molnar
(9883a13c72dbf8c518814b6091019643cdb34429):
- lock_sock(sock-sk);
+
On 5/16/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hi Marcel,
[...]
(later)
I Googled a bit to see if this problem was faced elsewhere in the kernel
too. Saw the following commit by Ingo Molnar
(9883a13c72dbf8c518814b6091019643cdb34429):
- lock_sock(sock-sk);
+
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
The NSLU2 people
Hi Satyam,
(later)
I Googled a bit to see if this problem was faced elsewhere in the
kernel
too. Saw the following commit by Ingo Molnar
(9883a13c72dbf8c518814b6091019643cdb34429):
- lock_sock(sock-sk);
+ local_bh_disable();
+
On Wed, 16 May 2007, Marcel Holtmann wrote:
since Jiri has a good test case for it, I leave it to him for testing.
If he confirms that this fixes the locking issues, then this is
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
I will verify later this evening and will let you know. I am
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/Documentation/networking/netdevices.txt
===
--- linux-2.6.orig/Documentation/networking/netdevices.txt 2007-01-04
19:38:05.0 +0100
+++
Spidernet was the driver I original did all the node-aware netdevice
allocation for, but after a year it still hasn't hit mainline.
So here's the patch again:
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/spider_net.c
Dear Community,
I was wondering what the purpose of the bit shifts in tcp_get_info
right after the jiffies conversion might be. What's the time unit
after that shift?
info-tcpi_rtt = jiffies_to_usecs(tp-srtt)3;
info-tcpi_rttvar = jiffies_to_usecs(tp-mdev)2;
[...]
Christoph Hellwig [EMAIL PROTECTED] writes:
Not even trying to support LE is a clear merge blocker. Maybe Krzysztof
can't actually test it himself, which is fine - but not even pretending
to be endian clean is not what proper Linux drivers do.
The drivers can only work with IXP4xx CPU and
Rod Whitby [EMAIL PROTECTED] writes:
Please let's just stop arguing about it. If a patch appears before it
gets merged, then great. If it doesn't then it will appear at a later date.
Sure. The swapping patch is trivial and I can add it if needed
at some point but I hope we can do that data
This patch series applies against linux-2.6.22-rc1-git4. It adds a new
protocol family to Linux for communication on the CAN (Controller Area
Network) using the socket API.
The current implementation supports two protocols in the family, a raw
protocol for sending and receiving raw CAN frames,
This patch adds entries in the CREDITS and MAINTAINERS file for CAN.
Signed-Off-By: Oliver Hartkopp [EMAIL PROTECTED]
Signed-Off-By: Urs Thuermann [EMAIL PROTECTED]
---
CREDITS | 16
MAINTAINERS |9 +
2 files changed, 25 insertions(+)
Index:
This patch adds a protocol/address family number, ARP hardware type,
ethernet packet type, and a line discipline number for the SocketCAN
implementation.
Signed-Off-By: Oliver Hartkopp [EMAIL PROTECTED]
Signed-Off-By: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/if_arp.h |1 +
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-Off-By: Oliver Hartkopp [EMAIL PROTECTED]
Signed-Off-By: Urs Thuermann [EMAIL PROTECTED]
---
drivers/net/Makefile |1
Jeff Garzik wrote:
H. Peter Anvin wrote:
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 637ae8f..089ae3f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -307,7 +307,7 @@ static int e1000_request_irq(struct e1000_adapter
This patch adds the CAN raw protocol.
Signed-Off-By: Oliver Hartkopp [EMAIL PROTECTED]
Signed-Off-By: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/can/raw.h | 31 ++
net/can/Kconfig | 26 +
net/can/Makefile|3
net/can/raw.c | 703
This patch adds documentation for the PF_CAN protocol family.
Signed-Off-By: Oliver Hartkopp [EMAIL PROTECTED]
Signed-Off-By: Urs Thuermann [EMAIL PROTECTED]
---
Documentation/networking/can.txt | 635 +++
1 file changed, 635 insertions(+)
Index:
pci_enable_msi failure is a normal event so we should not print any error.
Going over the code I spotted a missing pci_disable_msi() leak when irq
allocation fails. The whole code also needed a cleanup, so I combined the
two different calls to pci_request_irq into a single call making this
look a
Auke Kok wrote:
pci_enable_msi failure is a normal event so we should not print any error.
Going over the code I spotted a missing pci_disable_msi() leak when irq
allocation fails. The whole code also needed a cleanup, so I combined the
two different calls to pci_request_irq into a single call
Jeff Garzik wrote:
Auke Kok wrote:
pci_enable_msi failure is a normal event so we should not print any error.
Going over the code I spotted a missing pci_disable_msi() leak when irq
allocation fails. The whole code also needed a cleanup, so I combined the
two different calls to pci_request_irq
Hi Hugh,
It's interesting that compat_core_sys_select() shows this kmalloc(0)
failure but core_sys_select() does not. That's because core_sys_select()
avoids kmalloc by using a buffer on the stack for small allocations (and
0 sure is small). Shouldn't compat_core_sys_select() do just the
pci_enable_msi failure is a normal event so we should not print any error.
Going over the code I spotted a missing pci_disable_msi() leak when irq
allocation fails. The whole code also needed a cleanup, so I combined the
two different calls to pci_request_irq into a single call making this
look a
Our 82571 (first PCI-E hardware) causes P-Series hardware to throw
issues. Disabling PCI-E completion timeouts in our NIC resolves
the issue.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Cc: Wen Xiong [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 10 ++
1 files changed, 10
On 5/16/07, Urs Thuermann [EMAIL PROTECTED] wrote:
This patch adds the CAN core functionality but no protocols or drivers.
No protocol implementations are included here. They come as separate
patches. Protocol numbers are already in include/linux/can.h.
Signed-Off-By: Oliver Hartkopp [EMAIL
On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
This patch fixes a bug where the link speed change was not
detected correctly. This occured on a 440SPe (EMAC4) system
where the old link speed was 100Mbps and the new link speed
is 1000Mbps.
Good catch, Stefan. Unfortunately, I
Arnaldo Carvalho de Melo wrote:
SNIP
+
+/**
+ * struct sockaddr_can - the sockaddr structure for CAN sockets
+ * @can_family: address family number AF_CAN.
+ * @can_ifindex: CAN network interface index.
+ * @can_addr:transport protocol specific address, mostly CAN IDs.
+ */
Some more of my paranoid questions :)
So, if a driver tries to enable MSI and that is unsuccessful (I'll try to avoid
using the possibly loaded term fails) shouldn't that show-up _somewhere_?
Just how normal is an attempt to enable MSI not succeding going to remain over
time and aren't there
On Wednesday 16 May 2007, Eugene Surovegin wrote:
On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
This patch fixes a bug where the link speed change was not
detected correctly. This occured on a 440SPe (EMAC4) system
where the old link speed was 100Mbps and the new link speed
Fix Section mismatch warnings
Signed-off-by: Eugene Surovegin [EMAIL PROTECTED]
---
drivers/net/ibm_emac/ibm_emac_mal.c |3 +--
drivers/net/ibm_emac/ibm_emac_mal.h |3 +--
drivers/net/ibm_emac/ibm_emac_rgmii.c |2 +-
drivers/net/ibm_emac/ibm_emac_rgmii.h |2 +-
Original patch is from Jeff Haran [EMAIL PROTECTED] with my minor style
fixes. His comments follow:
The first problem was in the function that configures the PHY for
autonegotiation, genmii_setup_aneg(). The original code does a
read/modify/write of the autonegotiation advertizement register
Fix link speed detection change.
Thanks to Stefan Roese [EMAIL PROTECTED] for finding this bug.
CC: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Eugene Surovegin [EMAIL PROTECTED]
---
drivers/net/ibm_emac/ibm_emac_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Rick Jones wrote:
Some more of my paranoid questions :)
So, if a driver tries to enable MSI and that is unsuccessful (I'll try
to avoid using the possibly loaded term fails) shouldn't that show-up
_somewhere_?
It already does -- in /proc/interrupts.
Just how normal is an attempt to enable
Rick Jones wrote:
So, if a driver tries to enable MSI and that is unsuccessful (I'll try
to avoid using the possibly loaded term fails) shouldn't that show-up
_somewhere_? Just how normal is an attempt to enable MSI not succeding
going to remain over time and aren't there times when it does
From: Rick Jones [EMAIL PROTECTED]
Date: Wed, 16 May 2007 11:41:15 -0700
Some more of my paranoid questions :)
So, if a driver tries to enable MSI and that is unsuccessful (I'll try to
avoid
using the possibly loaded term fails) shouldn't that show-up _somewhere_?
Just how normal is an
When attempting to activate additional rx buffer pools on an ibmveth interface
that
was not yet up, the error below was seen. The patch fixes this by only closing
and opening the interface to activate the resize if the interface is already
opened.
(drivers/net/ibmveth.c:597 ua:3004) ERROR:
Currently, ibmveth maintains several rx buffer pools, which can
be modified through sysfs. By default, pools are not allocated by
default such that jumbo frames cannot be supported without first
activating larger rx buffer pools. This results in failures when attempting
to change the mtu. This
Jeff Garzik wrote:
Rick Jones wrote:
But that is rather incidental isn't it? Would some sort of system
health monitor be likely to be checking that for interrupt flavors? And
Well, that's where the information is exported in a standard way. I
hope you're not suggesting that a system
The hardware must not see that is given ownership of a buffer until it is
completely written, and when the driver receives ownership of a buffer,
it must ensure that any other reads to the buffer reflect its final
state. Thus, I/O barriers are added where required.
Without this patch, I have
Hi all,
Here is a list of some known regressions in 2.6.22-rc1.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Timers/NOHZ
Subject: 2.6.21-git4 BUG: soft lockup detected on CPU#1!
References : http://lkml.org/lkml/2007/5/2/511
Submitter :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240190
drivers/net/netxen/netxen_nic_init.c:
if (ADDR_IN_WINDOW1(off)) {
writel(buf[i].data,
NETXEN_CRB_NORMALIZE(adapter, off));
On 16 May 2007 21:14:20 +0200, Urs Thuermann [EMAIL PROTECTED] wrote:
Arnaldo Carvalho de Melo [EMAIL PROTECTED] writes:
Can can_ifindex be turned into a unsigned short? That way we would
have it nicely packed, avoiding this hole:
Since dev-ifindex is int and we have many assignments between
In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
skb is dereferenced after being passed to netif_rx (called from
libertas_upload_rx_packet). Spotted by Coverity (1658, 1659).
Also, libertas_upload_rx_packet() unconditionally returns 0 so the error
check is dead code -
Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as
soon as the first received packet comes in via the sis900 ethernet
interface. The machine is locked up and part of the kernel panic message
is lost as it has scrolled off the screen and the virtual terminal has
crashed as
Jeff,
Please apply forward upstream the following patch series.
There's a variety of fixes cleanups in here; the key fix
is a rather hard-to-reproduce bug where the hardware runs out
of ram, resulting in corruption of some sequencer. The only fix
is to reset the card. v-v Unfortunately,
From: Christoph Hellwig [EMAIL PROTECTED]
Spidernet was the driver I original did all the node-aware netdevice
allocation for, but after a year it still hasn't hit mainline.
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Add more comments to describe our version of tcp_slow_start().
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/ipv4/tcp_cong.c | 40 ++--
1 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
Make error messages print which interface they apply to.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 10 ++
drivers/net/spider_net.h |2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
Index: linux-2.6.22-rc1/drivers/net/spider_net.c
Rick Jones wrote:
Agreed. But is the PCI (?) subsystem doing something in that regard or
is this a hole?
Depends on your platform, your BIOS, your kernel command line, ... :)
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Put the enable and disable routines next to one-another,
as this makes verifying thier symmetry that much easier.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
Index:
Invalidate a pointer as its pci_unmap'ed; this is a bit of
paranoia to make sure hardware doesn't continue trying to
DMA to it.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index:
Jamal,
Here are some comments i have on your patch.
See them inline.
Thanks
Sridhar
+static int try_get_tx_pkts(struct net_device *dev, struct Qdisc *q, int count)
+{
+ struct sk_buff *skb;
+ struct sk_buff_head *skbs = dev-blist;
+ int tdq = count;
+
+ /*
+*
If the ethernet interface is brought down while there is still
RX traffic in flight, the device shutdown routine can end up
trying to double-free an skb, leading to a crash in mm/slab.c
Avoid the double-free by nulling out the skb pointer.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
There is no real reason to terminate the RX ring; it
doesn't make the operation any smooother, and it does
require an extra sync. So don't do it.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 18 +-
1 file changed, 9 insertions(+), 9
Crazy device problems are hard to debug, when one does not have
good trace info. This patch makes a major enhancement to the
device dump routine.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 62 ---
1 file changed,
On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote:
Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as
soon as the first received packet comes in via the sis900 ethernet
interface. The machine is locked up and part of the kernel panic message
is lost as it has
Some versions of the spider have a firmware bug, where the
RX ring sequencer goes crazy when the RX RAM on the device
fills up. Appearently the only viable wrkaround is a soft
reset of the card.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c | 14 +++---
When entering the netdev poll routine, empty out the RX
chain first, before cleaning up the TX chain. This should
help avoid RX buffer overflows.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
Another way of minimizing the likelyhood of RX ram from overflowing
is to empty out the entire rx ring every chance we get. Change
the crazy watchdog timeout from 50 seconds to 3 seconds, while
we're here.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.h |9
On Wed, 2007-16-05 at 15:12 -0700, Sridhar Samudrala wrote:
Jamal,
Here are some comments i have on your patch.
See them inline.
Thanks for taking the time Sridhar.
try_tx_pkts() is directly calling the device's batch xmit routine.
Don't we need to call dev_hard_start_xmit() to handle
From: jamal [EMAIL PROTECTED]
Date: Wed, 16 May 2007 18:55:04 -0400
On Mon, 2007-14-05 at 09:30 -0400, jamal wrote:
Incoporating last comments from Patrick.
Dave, I think this is ready to apply - against net-2.6 from this
morning.
Dave - hold onto this patch - Sridhar Samudrala [EMAIL
On Wed, 16 May 2007, Jiri Kosina wrote:
since Jiri has a good test case for it, I leave it to him for testing.
If he confirms that this fixes the locking issues, then this is
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
I will verify later this evening and will let you know. I am
On Wed, May 16, 2007 at 06:17:04PM -0400, Dave Jones wrote:
On Wed, May 16, 2007 at 02:33:18PM -0700, - wrote:
Kernel version 2.6.20.4 works. What I'm experiencing is a kernel panic as
soon as the first received packet comes in via the sis900 ethernet
interface. The machine is locked
On Wed, 2007-05-16 at 18:55 -0400, jamal wrote:
On Mon, 2007-14-05 at 09:30 -0400, jamal wrote:
Incoporating last comments from Patrick.
Dave, I think this is ready to apply - against net-2.6 from this
morning.
Dave - hold onto this patch - Sridhar Samudrala [EMAIL PROTECTED] caught
a
From: Jiri Kosina [EMAIL PROTECTED]
Date: Thu, 17 May 2007 01:03:55 +0200 (CEST)
On Wed, 16 May 2007, Jiri Kosina wrote:
since Jiri has a good test case for it, I leave it to him for testing.
If he confirms that this fixes the locking issues, then this is
Signed-off-by: Marcel
On Wed, 16 May 2007, David Miller wrote:
I have just verified that this locking scheme is indeed correct. So you
can add
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
if you wish to, and submit the patch to Andrew.
I guess I don't get sent networking patches any more?
:-)
On Wed, 2007-05-16 at 17:09 -0500, Linas Vepstas wrote:
Invalidate a pointer as its pci_unmap'ed; this is a bit of
paranoia to make sure hardware doesn't continue trying to
DMA to it.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
drivers/net/spider_net.c |7 +--
1 file
On Wed, 2007-05-16 at 17:23 -0500, Linas Vepstas wrote:
Another way of minimizing the likelyhood of RX ram from overflowing
is to empty out the entire rx ring every chance we get. Change
the crazy watchdog timeout from 50 seconds to 3 seconds, while
we're here.
Signed-off-by: Linas Vepstas
Hi,
On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote:
I encountered the following error when doing netperf from other machine
to Celleb running RT kernel. PREEPT_NONE kernel works just fine as well.
Hrm...
(resending , Owa-san was cut from cc list!??)
Hi,
On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote:
I encountered the following error when doing netperf from other machine
to Celleb running RT kernel.
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Wed, 16 May 2007 19:18:02 -0500
Hi,
On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote:
I encountered the following error when doing netperf from other machine
to
On May 16, 2007, at 3:53 AM, Auke Kok wrote:
Our 82571 (first PCI-E hardware) causes P-Series hardware to throw
issues. Disabling PCI-E completion timeouts in our NIC resolves
the issue.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Cc: Wen Xiong [EMAIL PROTECTED]
---
I do not know why sk_buff-head would be null, or
would be set in a racy kind of way, or why the rt patches
would cause this. But the evidence implicates that.
Would it be possible that a locking bug in spidernet would cause it
under some circumstances to get a stale skb pointer ?
Ben.
-
To
On Wed, 2007-05-16 at 10:37 -0500, Anton Blanchard wrote:
Hi Hugh,
It's interesting that compat_core_sys_select() shows this kmalloc(0)
failure but core_sys_select() does not. That's because core_sys_select()
avoids kmalloc by using a buffer on the stack for small allocations (and
0
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
It looks like the problems of Gigabyte 88E8056 are unique to that chip
motherboard and maybe fixable by EEPROM update.
So, drop the Gigabyte hunks in the original patch...ok, thanks.
-chris
-
To unsubscribe from this list: send the line unsubscribe
* Stephen Hemminger ([EMAIL PROTECTED]) wrote:
- { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
+// { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x436B) }, /* 88E8071 */
Where-o-where are the CodingStyle police? ;-)
-
To unsubscribe from this list: send the line unsubscribe netdev in
The stats update code in spider_net_pass_skb_up() is touching the skb
after it's been passed up to the stack. To avoid that, just update the
stats first.
Signed-off-by: Florin Malita [EMAIL PROTECTED]
---
spider_net.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
* Dave Jones ([EMAIL PROTECTED]) wrote:
You need this..
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=dc5a144991ba803bc8afded105c9db1dea0e57ab
Which is queued for -stable afaik, but no sign of 2.6.21.2 yet. Greg/Chris?
Yes, it is queued,
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote:
In article [EMAIL PROTECTED] (at Fri, 11 May 2007 09:22:43 -0700), Chris
Wright [EMAIL PROTECTED] says:
* YOSHIFUJI Hideaki / 吉藤英明 ([EMAIL PROTECTED]) wrote:
The fix for emerging security threats was overkill and it broke
basic
Stephen Hemminger wrote:
It looks like these users aren't using MSI?
Possible. Want me to find out?
I just ask as I note yesterday's -stable patch where you remove the
#ifdef completely. Is that going to go upstream into 2.6.22 or do you
want to continue pursuing the DMI matching path?
On Wed, 2007-16-05 at 16:15 -0700, Sridhar Samudrala wrote:
I think your qdisc_restart() cleanup patch is OK. There you are
still calling dev_hard_start_xmit() and GSO should work fine.
Sorry, you are right - I thought i cutnpasted from it.
So Dave, false alarm ;- That patch is clean.
But
* David Miller ([EMAIL PROTECTED]) wrote:
We're not pushing this in, even the ipv6 working group is unsure
how this should be handled and one of the possibilities they might
choose matches how things currently are.
Alright, I'll drop this one from the -stable radar, thanks.
-chris
-
To
Daniel Drake wrote:
Stephen Hemminger wrote:
It looks like these users aren't using MSI?
Possible. Want me to find out?
I just ask as I note yesterday's -stable patch where you remove the
#ifdef completely. Is that going to go upstream into 2.6.22 or do you
want to continue pursuing the
Jeff Garzik wrote:
Stephen has some sky2 patches I need to push. I accidentally filed them
until 'Pending: SATA', and they got missed in my most recent net driver
push.
Thanks, that clears it up, forgot to check netdev before asking. Looks
like the 2.6.22 plans are to drop the machine
1 - 100 of 104 matches
Mail list logo
