The function ipxrtr_route_packet() takes a 'len' argument of type
size_t. However, its prototype in af_ipx.c incorrectly suggests that the
corresponding argument is of type 'int' instead.
Discovered by building with --combine and letting the compiler see it
all at once.
Signed-off-by: David
On Thu, 2007-05-17 at 15:27 -0700, Andrew Morton wrote:
Lovely. So it was actually generating wrong code on all
sizeof(size_t)!=sizeof(int) architectures.
I was trying to work out which architectures would actually be affected.
Probably not many. If it's in a register it probably doesn't
On Tue, 2007-06-05 at 16:54 +0200, Michal Piotrowski wrote:
File systems
Subject: JFFS2 issues
References :
http://lists.infradead.org/pipermail/linux-mtd/2007-May/018426.html
Submitter : Haavard Skinnemoen [EMAIL PROTECTED]
Caused-By : commit
On Wed, 2007-06-13 at 11:14 -0500, Linas Vepstas wrote:
Some googling seems to show that git pull has a bug/feature of
ignoring the branch that one is working in, and pulling master
no matter what. I have no clue why; this seems broken to me.
Branches are generally a PITA -- it's probably
On Thu, 2007-06-14 at 19:01 -0400, Jeff Garzik wrote:
It makes diffing between lines of development more difficult, takes up
more overall space, less cache friendly, ...
All of which is much less true if you're sharing object directories or
even using alternates.
--
dwmw2
-
To unsubscribe
On Thu, 2007-06-14 at 19:04 -0400, Jeff Garzik wrote:
Think about the actual kernel tree source code, not just the
metadata...
Disk is cheap. Waiting for the whole damn thing to rebuild after
switching branches and back again is less so.
Besides, checking it out is optional.
--
dwmw2
-
To
/mice on my G5, while
the 'hcidump' output looks sane enough while I move it.
-
[HIDP] Fix compat HIDPGETCONNLIST ioctl.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git a/net/bluetooth/hidp/sock.c b/net/bluetooth/hidp/sock.c
index 099646e..af5a21c 100644
--- a/net/bluetooth/hidp
On Mon, 2006-09-18 at 14:25 +0100, David Woodhouse wrote:
although HIDP mouse movement doesn't seem to be appearing
in /dev/input/mice on my G5, while the 'hcidump' output looks sane
enough while I move it.
Ew, that's because struct hidp_connadd_req is similarly buggered for
compat
On Mon, 2006-09-18 at 12:38 +0200, Marcel Holtmann wrote:
it seems that HIDP and CMTP will have the same problem.
Finally, the CMTP version... this one is untested.
[CMTP] Fix compat CMTPGETCONNLIST ioctl
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git a/net/bluetooth/cmtp
On Sun, 2006-09-24 at 00:02 +, Linux Kernel Mailing List wrote:
--- a/include/linux/netfilter_ipv4/ipt_dscp.h
+++ b/include/linux/netfilter_ipv4/ipt_dscp.h
@@ -10,14 +10,12 @@
#ifndef _IPT_DSCP_H
#define _IPT_DSCP_H
-#define IPT_DSCP_MASK 0xfc/* 1100 */
-#define
changed, 33 deletions(-)
You neglected to also remove the file from include/linux/Kbuild.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -267,7 +267,6 @@ unifdef-y += netfilter_decnet.h
unifdef-y += netfilter.h
unifdef-y
Accepted connections of types other than AF_INET, AF_INET6, AF_UNIX
won't have an appropriate label derived from the peer, so don't use it.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Acked-by: Stephen Smalley [EMAIL PROTECTED]
--- linux-2.6.18.ppc/security/selinux/hooks.c~ 2006-09-28 14
On Fri, 2006-10-13 at 14:43 -0700, Andrew Morton wrote:
Problem Description:
Applying TUNSETIFF ioctl needs root permissions that wasn't needed in
previous
versions. I was using qemu 0.8.2 (a virtual machine emulator) which uses a
tap
device to emulate a network between the guest and
On Sat, 2006-12-09 at 15:58 +0100, Stefan Rompf wrote:
But when even glibc needs internal compat headers to compile with the second
kernel version that provides userspace headers, what is the long-term - even
mid-term - perspective of make headers_install then?
Bear in mind that with the
914e26379decf1fd984b22e51fd2e4209b7a7f1b
Handled-By : David Woodhouse [EMAIL PROTECTED]
Status : patch available
Linus, please pull from git://git.infradead.org/mtd-2.6.git
This fixes the above bug along with a few others. It does also contain a
small amount of new code which has been waiting for a while (including
the driver
On Fri, 2006-05-05 at 19:42 +0200, Michael Buesch wrote:
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
John, please apply. I will also send a patch for d80211.
Would be good to get this into 2.6.17 too.
--
dwmw2
-
To unsubscribe from
I've been using and testing IPv6 on a private network.
Machines have RFC1918 IPv4 addresses, with connectivity by NAT to the
outside world. They also have site-local IPv6 addresses. There is
approximately zero chance of getting corporate approval to have external
IPv6 connectivity.
Since
On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote:
I still need this hack to work around the fact that softmac doesn't
attempt to associate when we bring the device up...
It'd be quite good to get this fixed in 2.6.17 too. Otherwise, the
device doesn't manage to associate if you use
On Sat, 2006-05-06 at 11:39 +0900, YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Sat, 06 May 2006 01:53:21 +0100), David
Woodhouse [EMAIL PROTECTED] says:
There is a default route, because I believe that's the only thing that
radvd can do. I cannot advertise a route to _only_
On Sat, 2006-05-06 at 09:19 +0900, YOSHIFUJI Hideaki wrote:
You have compatible address.
Do you really use the tunnel? How did you configure it?
Sorry, I should have shown a strace from a different machine. Try this
one from an autoconfigured machine...
socket(PF_INET6, SOCK_DGRAM,
On Mon, 2006-05-08 at 09:44 -0700, Rick Jones wrote:
Or get the applications fixed no? Kludging around application bugs
sounds a bit like the Fram Oil Filter commercial where the mechanic is
grinning while he says You can pay me now, or you can pay be later. As
in pay for the slightly more
On Sun, 2006-05-07 at 15:06 +0200, Michael Buesch wrote:
On Saturday 06 May 2006 20:24, David Woodhouse wrote:
On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote:
I still need this hack to work around the fact that softmac doesn't
attempt to associate when we bring the device up
On Tue, 2006-05-30 at 17:42 -0400, Jim Gettys wrote:
As you know, we've said we were going to have a developer's program. You
can find more information, including how to apply for boards at:
http://wiki.laptop.org/index.php/Developers_Program
Note that these are bare PC prototype boards,
On Sun, 2006-06-04 at 13:17 +, Anand Kumria wrote:
One thing we really need is NAT-PT or an equivalent for allowing access
to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
with JFFS2 improvements, I plan to start looking at that.
Wouldn't miredo mostly fit the
to those users is a fairly pointless
exercise.
Signed-Off-By: David Woodhouse [EMAIL PROTECTED]
diff --git a/Documentation/networking/tuntap.txt
b/Documentation/networking/tuntap.txt
index 76750fb..9d696f2 100644
--- a/Documentation/networking/tuntap.txt
+++ b/Documentation/networking/tuntap.txt
On Tue, 2006-06-20 at 16:35 +0100, David Woodhouse wrote:
There's no reason to restrict unprivileged users from opening
the /dev/net/tun device node -- to do anything exciting requires
CAP_NET_ADMIN or a persistent device which is owned by the user in
question anyway.
Hm, I lie. Let us alter
On Tue, 2006-06-20 at 11:46 -0500, Chase Venters wrote:
Perhaps you lie again :)
Are you sure you're adding a capable(CAP_SYS_ADMIN)? :P
I'm going to go home now. G'night.
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
of their own. This patch corrects that, and
adjusts the recommended permissions for the device node accordingly.
Signed-Off-By: David Woodhouse [EMAIL PROTECTED]
diff --git a/Documentation/networking/tuntap.txt
b/Documentation/networking/tuntap.txt
index 76750fb..839cbb7 100644
--- a/Documentation
On Tue, 2006-06-20 at 21:18 -0400, Jeff Garzik wrote:
How can reviewers make an informed decision, when you completely failed
to note:
* This breaks the primary userspace user of this header, ethtool(8)
I cannot reproduce with either an ethtool-3 tarball or a fresh checkout
from your git
On Wed, 2006-01-11 at 01:37 +0100, Adrian Bunk wrote:
shadow.cabi.net does no longer exist.
Surely it would be better to point to the new home of these tools rather
than removing the reference to them entirely?
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
On Wed, 2006-01-11 at 01:08 +, Alan Cox wrote:
I don't think they have a current home as such. I've got the scarabd
tar ball here so you can archive that somewhere on infradead if you'd
rather a reference remain.
ftp.uk.linux.org would probably make more sense.
--
dwmw2
-
To unsubscribe
The ip6_xmit() function now assumes that its sk argument is non-NULL,
which isn't currently true when TCPv6 code is sending RST or ACK
packets. This fixes that code to use a socket of its own for sending
such packets, as TCPv4 does. (Thanks Andi for the pointer).
Signed-off-by: David Woodhouse
On Fri, 2006-10-06 at 17:20 +, Joseph S. Myers wrote:
The kernel headers installed by Linux 2.6.19-rc1 make
headers_install do not work for building glibc, because glibc expects
linux/rtnetlink.h to provide various definitions, some of which have
been moved to linux/if_addr.h and some of
On Mon, 2006-12-04 at 10:13 +0100, Thomas Graf wrote:
Userspace is not supposd to directly include kernel headers, instead
it has to make local copies and compile against them.
No. It was _never_ sensible to simply declare that userspace shall not
use kernel headers in the absence of any
On Wed, 2006-12-06 at 14:43 +0100, Jakub Jelinek wrote:
+/* 2.6.19 kernel headers helpfully removed some macros and
+ moved lots of stuff into new headers, some of which aren't
+ included by linux/rtnetlink.h. */
+
+#ifndef IFA_MAX
+struct ifaddrmsg
+{
+ uint8_t ifa_family;
+
On Wed, 2006-12-06 at 14:57 +0100, Jakub Jelinek wrote:
Yes, but as I said, I'd need to add configure checks for that, using
#include linux/if_addr.h
alone breaks build with older headers.
I was thinking that the #ifndef IFA_MAX you already have ought to be
sufficient for that. Or even
On Wed, 2006-12-06 at 14:59 +0100, Thomas Graf wrote:
Are you suggesting that the kernel has to keep macros around which
are of no use to the kernel itself just because glibc uses them?
No, although in fact that _is_ the only reason we use these horrid __uXX
types rather than proper C
On Thu, 2006-12-07 at 11:55 +0100, Thomas Graf wrote:
Restore API compatibility due to bits moved from rtnetlink.h to
separate headers.
For 2.6.19.1 too, please.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/include/linux/rtnetlink.h
On Wed, 2006-12-06 at 15:23 +0100, Thomas Graf wrote:
I'm suggesting that if you want to change things around as you did, you
should make sure the users of those headers adapt to cope. You did fix
the in-kernel users; you neglected to fix glibc -- and as far as I can
tell you didn't even
On Sat, 2006-12-09 at 15:58 +0100, Stefan Rompf wrote:
But when even glibc needs internal compat headers to compile with the second
kernel version that provides userspace headers, what is the long-term - even
mid-term - perspective of make headers_install then?
We've only _just_ started
On Thu, 2007-03-08 at 03:59 +, Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c7ababbdc647e67e953d153ddf62cbdc9fe3297e
Commit: c7ababbdc647e67e953d153ddf62cbdc9fe3297e
Parent:
On Wed, 2007-03-28 at 07:30 +1000, Herbert Xu wrote:
Sorry, that patch is indeed broken. We do need to set IF_READY in
the case where all addresses were deleted (including the link-local)
and then recreated. The IPv6 device will be destroyed and recreated
too in that case.
Your new patch
It currently takes something like 8 seconds to do a scan, because we
spend half a second on each channel. Reduce that time to 20ms per
channel.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_priv.h~
2006-03-21 23:50:00.0
at 11Mbps
and then tune it up or down from there, rather than starting at 54Mbps.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- linux-2.6.16.ppc/net/ieee80211/softmac/ieee80211softmac_module.c~
2006-03-21 23:50:00.0 +
+++ linux-2.6.16.ppc/net/ieee80211/softmac
After a scan, we weren't switching back to the original channel if we
were associated with an AP. So NetworkManager's periodic scans would
disrupt connectivity until the ESSID was manually set again. Fix that.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- linux-2.6.16.ppc/net/ieee80211
On Thu, 2006-03-23 at 14:40 -0500, Dan Williams wrote:
Are we talking about (1) the active probe response timeout after
transmitting the probe frame, or (2) the default passive scan channel
dwell time?
If (2), I'd have to NAK this patch, as 20ms that seems really low.
It's only (1). I
at 54M and reduce it.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git a/net/ieee80211/softmac/ieee80211softmac_module.c
b/net/ieee80211/softmac/ieee80211softmac_module.c
index 6f99f78..9ba9eec 100644
--- a/net/ieee80211/softmac/ieee80211softmac_module.c
+++ b/net/ieee80211/softmac
On Thu, 2006-03-23 at 20:16 -0500, Dan Williams wrote:
Ok, that's cool. Wasn't apparent to me from the initial message. But
does that mean that softmac is doing the scanning with _probe_ requests
on each channel? It's not doing passive scanning?
Right. It's an active scan.
--
dwmw2
-
To
On Fri, 2006-03-24 at 10:57 -0500, Dan Williams wrote:
hidden this is something that ieee80211 does that's completely
wrong. Drivers need to report the _exact_ ESSID from the air in their
scan results. It's up to the user space app to deal with ESSID length
of 0.
That makes a lot of sense.
On Fri, 2006-03-24 at 14:14 -0800, Jouni Malinen wrote:
wpa_supplicant does indeed require that the scan results are reported
correctly. I don't see much point in the results if they are not
correct.. It is unfortunate if you need to use this kind of patch since
it would not work very well in
On Fri, 2006-03-24 at 08:18 -0800, Jouni Malinen wrote:
On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote:
This patch makes us default to 11M, which ought to work for most people.
Is this code supposed to work with IEEE 802.11a (which would also use
OFDM modulation)? If yes
On Sat, 2006-07-29 at 11:45 +0400, Alexey Dobriyan wrote:
Header doesn't use anything from atomic.h.
It fixes headers_check warning:
include/linux/netfilter_bridge.h requires asm/atomic.h, which does not exist
Compile tested on
alpha arm i386-up sparcsparc64-up x86_64
On Tue, 2007-07-31 at 20:26 -0700, Andrew Morton wrote:
Look. Kconfig's `select' Just. Does. Not. Work. If you find
yourself contemplating using it, please, don sackcloth, take a cold
shower and several analgesics, then have another go, OK?
Amen.
--
dwmw2
-
To unsubscribe from this
On Wed, 2007-09-12 at 18:59 +0200, Michal Piotrowski wrote:
MTD
Subject : include/linux/mtd/map.h:128:2: error: #error No bus width
supported. What's the point?
References : http://lkml.org/lkml/2007/9/11/151
Last known good : ?
Submitter : Toralf Förster [EMAIL
On Sun, 2007-11-18 at 20:49 -0500, Jon Smirl wrote:
On 11/9/07, Grant Likely [EMAIL PROTECTED] wrote:
On 11/9/07, Domen Puncer [EMAIL PROTECTED] wrote:
On 09/11/07 00:31 -0500, Jon Smirl wrote:
This is the reason I couldn't get user space started or connect to my
nfs server. Patch
This helps to allow the Fedora installer to use the built-in Ethernet on
the Efika for a network install.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -971,6 +971,8 @@ mpc52xx_fec_probe(struct of_device *op, const struct
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 9bc1177..7c9e6e3 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -406,6 +406,9 @@ int phy_mii_ioctl(struct phy_device
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 09b4fde..a8db5d7 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -1362,7 +1362,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct
pci_device_id
-by: David Woodhouse [EMAIL PROTECTED]
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -422,7 +422,7 @@ static irqreturn_t mpc52xx_fec_rx_interrupt(int irq, void
*dev_id)
rskb = bcom_retrieve_buffer(priv-rx_dmatsk, status,
(struct bcom_bd
Oops: Exception in kernel mode, sig: 5 [#1]
nfs: server pmac not responding, still trying
SMP NR_CPUS=128 NUMA PA Semi PWRficient
Modules linked in: appletouch cbc blkcipher dm_crypt
On Tue, 2007-12-04 at 18:04 +, David Woodhouse wrote:
Oops: Exception in kernel mode, sig: 5 [#1]
nfs: server pmac not responding, still trying
Oops, sorry. That was meant to be just to Olof. And it helps if I'm
actually running the kernel
On Mon, 2007-11-26 at 15:17 -0700, Eric W. Biederman wrote:
Well I clearly goofed when I added the initial network namespace support
for /proc/net. Currently things work but there are odd details visible
to user space, even when we have a single network namespace.
Since we do not cache
--- linux-2.6.23.ppc64/drivers/net/ps3_gelic_net.c~ 2007-12-14
01:31:50.0 -0500
+++ linux-2.6.23.ppc64/drivers/net/ps3_gelic_net.c 2007-12-14
01:39:25.0 -0500
@@ -1139,7 +1139,7 @@ static irqreturn_t gelic_card_interrupt(
*
* see
On Tue, 2008-01-29 at 13:16 +, Linux Kernel Mailing List wrote:
Commit: 643a2c15a407faf08101a20e1a3461160711899d
[NETFILTER]: Introduce nf_inet_address
A few netfilter modules provide their own union of IPv4 and IPv6
address storage. Will unify that in this patch
On Tue, 2008-02-19 at 15:01 +0100, Patrick McHardy wrote:
David Woodhouse wrote:
+union nf_inet_addr {
+ u_int32_t all[4];
+ __be32 ip;
+ __be32 ip6[4];
+};
+
#ifdef __KERNEL__
#ifdef CONFIG_NETFILTER
This breaks the busybox build:
CC
On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
That would break iptables compilation, which already includes
linux/in.h in some files. I guess the best fix for now is to
include netinet/in.h in busybox and long-term clean this up
properly.
Yeah, that makes sense.
Can we push the
On Thu, 2008-02-21 at 13:00 +0100, Patrick McHardy wrote:
I already sent it to Dave for 2.6.25 (I assume that what you meant,
it was introduced after 2.6.24), its currently sitting in net-2.6
and should hit Linus' tree next time he pulls from Dave.
I actually meant 2.6.24.x, because I thought
On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
That would break iptables compilation, which already includes
linux/in.h in some files. I guess the best fix for now is to
include netinet/in.h in busybox and long-term clean this up
properly.
It looks like iptables is fairly broken
On Fri, 2008-02-22 at 16:52 +0900, David Woodhouse wrote:
It looks like iptables is fairly broken anyway:
make[1]: Entering directory
`/home/dwmw2/working/extras/iptables/devel/iptables-1.4.0'
Unable to resolve dependency on linux/compiler.h. Try 'make clean'.
And if I move away
On Fri, 2008-02-22 at 16:44 +0100, Patrick McHardy wrote:
Pablo Neira Ayuso wrote:
Patrick McHardy wrote:
Yes, that was a bug in the lastest release. We need to
release a 1.4.1 version or something like that, but I'm
not too familiar with the release process, so I haven't
done this so
On Mon, 2008-02-25 at 13:12 +0100, Patrick McHardy wrote:
Yes, the kernel headers need to be fixed as well to not include
linux/compiler.h outside of #ifdef __KERNEL__. I'll take care
of that.
No. When you run 'make headers_install' that's already taken care of.
--
dwmw2
--
To
On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote:
Right, I missed that. In that case the current headers should match
the kernel headers (with the compiler.h part removed).
They don't. When you run 'make headers_install' there are some missing.
--
dwmw2
--
To unsubscribe from this
On Mon, 2008-02-25 at 13:23 +0100, Patrick McHardy wrote:
David Woodhouse wrote:
On Mon, 2008-02-25 at 13:20 +0100, Patrick McHardy wrote:
Right, I missed that. In that case the current headers should match
the kernel headers (with the compiler.h part removed).
They don't. When you
On Wed, 2015-04-08 at 15:12 +0100, David Woodhouse wrote:
On Wed, 2015-04-08 at 15:08 +0200, Johannes Berg wrote:
Additionally, the failure mode of this was the process running out of
memory due to receiving the same results over and over again - does that
happen for you? It seems
On Wed, 2015-04-08 at 15:08 +0200, Johannes Berg wrote:
On Wed, 2015-04-08 at 13:03 +0100, David Woodhouse wrote:
I'm not sure if this is entirely fixed. In Fedora 22 (4.0.0-rc5-git4)
I'm occasionally seeing glibc deadlock in __check_pf() on a netlink
recvmsg(), here:
https
On Thu, 2015-06-11 at 01:31 +0100, David Woodhouse wrote:
On Tue, 2015-06-09 at 17:49 -0700, Eric Dumazet wrote:
I've added some debugging, and it seems that when it deadlocks, glibc
doesn't get *any* response to its RTM_GETADDR request. I know we'd get
ENOBUFS is a *response
On Thu, 2015-06-11 at 23:03 +0100, David Woodhouse wrote:
On Thu, 2015-06-11 at 01:31 +0100, David Woodhouse wrote:
On Tue, 2015-06-09 at 17:49 -0700, Eric Dumazet wrote:
I've added some debugging, and it seems that when it deadlocks,
glibc
doesn't get *any* response to its
On Tue, 2015-06-09 at 17:49 -0700, Eric Dumazet wrote:
I've added some debugging, and it seems that when it deadlocks, glibc
doesn't get *any* response to its RTM_GETADDR request. I know we'd get
ENOBUFS is a *response* was dropped... but what about when the request
itself is dropped? ...
On Wed, 2015-09-23 at 10:58 -0700, David Miller wrote:
> From: David Woodhouse <dw...@infradead.org>
> Date: Wed, 23 Sep 2015 09:14:09 +0100
>
> > But sure, for now I'll drop this from the series and I can try to
> > convince you separately.
>
> Yes, let's discu
On Mon, 2015-10-05 at 16:39 -0700, Tom Herbert wrote:
> This patch defines a helper function that drivers can call to check
> if it is able to offload the checksum for a particular packet.
It occurs to me that by itself, this doesn't actually fix the problem.
We'd then need to go over all
an implementation
which is grubbing around in the packet then at least *I* don't have to
feel dirty for it... :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote:
> it in ACPI circles
> unless we had wider agreement among OSs to use it. AFAIK PRP1 has not
> actually been approved yet in the specification forum, and that it in
> itself is more of a concern for me,as the code has been pushed
On Mon, 2013-05-20 at 17:27 -0700, Stephen Hemminger wrote:
> On Mon, 20 May 2013 23:37:28 +0200
> Francois Romieu wrote:
>
> > cp_stop_hw includes netdev_reset_queue.
> >
> > You have imho exhibited a start_xmit after cp_stop_hw race - not sure if
> > it happens in
On Wed, 2015-09-16 at 03:53 -0700, Eric Dumazet wrote:
> You should use netdev_alloc_skb() : This helper is better for rx skbs,
> as it allows for better packing of frames in GRO or TCP stack.
OK, thanks. I don't have a netdev (this is an ATM device) but I can use
dev_alloc_skb().
> Also
ags to indicate *what* kind of torture is
permissible in certain locations). And see what breaks...
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
— it means that *every* incoming
packet is going to be need to be reallocated. So let's fix that.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
Tested in the DMA code path; I don't believe the DMA-capable devices
can still be used in MMIO mode. Simon, Guy, would you be able t
— it means that *every* incoming
packet is going to be need to be reallocated. So let's fix that.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 74e18b0..3d7fb65 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm
On Wed, 2015-09-16 at 15:27 +0200, Florian Westphal wrote:
> @@ -599,7 +600,7 @@ int ip6_fragment(struct sock *sk, struct sk_buff
> *skb,
> /* Correct geometry. */
> if (frag->len > mtu ||
> ((frag->len & 7) && frag->next)
On Wed, 2015-09-16 at 15:27 +0200, Florian Westphal wrote:
>
> David, could you test this? I'd do an official patch submission
> then.
Compiles. Doesn't fix the problem.
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
On Wed, 2013-09-04 at 21:41 +0100, David Woodhouse wrote:
> On Wed, 2013-09-04 at 14:30 -0400, David Miller wrote:
> > skb_realloc_headroom() should do everything you need.
>
> Great, thanks! Something like this then... ?
>
> diff --git a/drivers/atm/solos-pci.c b/drivers/at
re are they
documented? Or is this a bug in the IPv6 fragmentation code, to make
such assumptions?
I'm not entirely sure how to interpret the above stack trace. Is the
incoming IPv6 packet being reassembled for netfilter's benefit, then re
-fragmented for transmission?
--
David Woodhous
fused that it dies on *unlock*.
_raw_spin_lock_irqrestore+0xa is the instruction after a 'popf', which
makes me wonder if it dies in an IRQ storm. Although then *some* of the
NMI watchdog invocations would surely show an IRQ on the stack, but
they
don't; they're all right on the same instruction.
92.130412] [] ? common_interrupt+0x29/0x30
[ 292.130412] [] ? remove_waiter+0x11b/0x120
[ 292.130412] [] ? _raw_spin_unlock_irqrestore+0xa/0x10
[ 292.130412] [] ? cp_tx_timeout+0x1a5/0x1c0 [8139cp]
--
David
On Wed, 2015-09-16 at 17:26 +0200, Florian Westphal wrote:
> I tested this e1000 driver hacked to not allocate additional headroom
> (we end up in slowpath, since LL_RESERVED_SPACE is 16).
And it works on the originally-offending setup too; thanks.
Tested-by: David Woodhouse <dav
On Thu, 2015-09-17 at 12:36 +0100, David Woodhouse wrote:
>
> Thanks; I'll try that. In fact since updating to 4.2 the problem has
> got worse — now the whole machine dies:
There is something very strange going on here. I've found two ways to
make it stop crashing when cp_tx_timeo
On Thu, 2015-09-17 at 22:44 +0200, Francois Romieu wrote:
> David Woodhouse <dw...@infradead.org> :
> > On Thu, 2015-09-17 at 12:36 +0100, David Woodhouse wrote:
> > >
> > > Thanks; I'll try that. In fact since updating to 4.2 the problem has
> > &
On Fri, 2015-09-18 at 01:44 +0200, Francois Romieu wrote:
> The TxDmaOkLowDesc register may tell if the Tx dma part is still
> making any progress. I have added a TxPoll request. See below.
I've just added that into the original TX timeout handler, since that
doesn't seem to be crashing the box
This can be called from cp_tx_timeout() with interrupts disabled.
Spotted by Francois Romieu <rom...@fr.zoreil.com>
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
drivers/net/ethernet/realtek/8139cp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --g
Unless we reset the RX config, on real hardware I don't seem to receive
any packets after a TX timeout.
Signed-off-by: David Woodhouse <david.woodho...@intel.com>
---
Now it does actually recover from the TX timeout, lots of the time.
Sometimes it still hits that IRQ storm, which pr
On Mon, 2015-09-28 at 12:37 -0700, Tom Herbert wrote:
> I think it's easier to just call skb_checksum_help from the driver
> when the packet is actually sent to the device (should be no cost for
> late binding).
That's true for checksum. Not for things like TSO though, and I wonder
if it's worth
1 - 100 of 178 matches
Mail list logo