I'm having problem with the interrupt getting killed after suspend with
my 8139cp controller. The problem only appears if the cable is connected
during resume (before suspend is irrelevant) and the interface is down.
Both suspend-to-disk and suspend-to-ram exhibit the error. dmesg from
John W. Linville wrote:
On Mon, Jul 04, 2005 at 12:22:53AM +0200, Pierre Ossman wrote:
After suspend the driver needs to retest link status in case the cable
has been inserted or removed during the suspend.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
Please copy netdev
Pierre Ossman wrote:
I'm having problem with the interrupt getting killed after suspend with
my 8139cp controller. The problem only appears if the cable is connected
during resume (before suspend is irrelevant) and the interface is down.
Both suspend-to-disk and suspend-to-ram exhibit
Register interrupt handler when net device is registered. Avoids missing
interrupts if the interrupt mask gets out of sync.
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
The reason this patch is needed for me is that the resume function is
broken. It enables interrupts unconditionally
Ehm... why am I included in this? :)
-
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
Francois Romieu wrote:
Pierre Ossman [EMAIL PROTECTED] :
Ehm... why am I included in this? :)
To preserve an happy 8139cp user :o)
A noble endeavor. Carry on. ;)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED
[EMAIL PROTECTED] wrote:
From: Pierre Ossman [EMAIL PROTECTED]
Avoids missing interrupts if the interrupt mask gets out of sync.
The reason this patch is needed for me is that the resume function is
broken. It enables interrupts unconditionally, but the interrupt handler
is only
4a
04 89 e5 8d 0c cd 10 00 00 00 29 48 5c 8d 42 08 ba 40 6f
[ 174.237999] EIP: [c05b6ed1] sk_filter_delayed_uncharge+0x1/0x20 SS:ESP
0068:c3e05edc
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http
Structure assignment have to be aligned just like any assignment, and the skb
could point to anything. So take the safe route and use a memcpy().
Signed-off-by: Pierre Ossman [EMAIL PROTECTED]
---
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 272c69e..a7e2ec9 100644
--- a/net/ipv4/icmp.c
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Pierre Ossman [EMAIL PROTECTED]
Date: Sat, 20 Oct 2007 23:35:40 +0200
Structure assignment have to be aligned just like any assignment, and the
skb could point to anything. So take the safe route and use
On Sun, 21 Oct 2007 12:48:14 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
You are missing a crucial point.
The compiler may emit the same exact loads and stores when it inlines
memcpy() if it knows the objects are aligned properly. And it very
much will do this.
Not sure that
On Sun, 21 Oct 2007 16:02:15 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Pierre Ossman [EMAIL PROTECTED]
Date: Sun, 21 Oct 2007 23:21:13 +0200
Not sure that would be valid. memcpy() is defined as having void*
arguments, and the compiler cannot just ignore that if it chooses
On Sun, 21 Oct 2007 22:15:24 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
Sure. But the language defines that the types in question
must be 64-bit aligned, so it is legal for the compiler to
emit this code.
It's not a GCC bug.
I've confirmed this behaviour on the AVR32 arch, and
On Mon, 22 Oct 2007 02:05:38 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Pierre Ossman [EMAIL PROTECTED]
Date: Mon, 22 Oct 2007 10:42:08 +0200
This seems like a rather evil layering violation.
This has a 10+ year precedence and it's why the Linux networking stack
is so fast
another vt with chvt 2, but that is insufficient to
trigger the bug.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
--
To unsubscribe
On Mon, 18 Feb 2008 20:50:01 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 18 of February 2008, Pierre Ossman wrote:
The patch [RTNETLINK]: Send a single notification on device state
changes. kills (at least)
the keyboard here. Everything seems to work fine in single user
On Mon, 18 Feb 2008 21:50:12 +0100
Pierre Ossman [EMAIL PROTECTED] wrote:
On Mon, 18 Feb 2008 20:50:01 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Monday, 18 of February 2008, Pierre Ossman wrote:
The patch [RTNETLINK]: Send a single notification on device state
changes
17 matches
Mail list logo
