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 "[RTN
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
d just creating 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
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
On Mon, 22 Oct 2007 01:31:05 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
>
> On fast paths we aren't going to add things like get_unaligned()
> calls.
>
> Every architecture should handle unaligned accesses properly, and for
> the fast paths the network driver should provide the packet f
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 ar
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 compi
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 sur
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 po
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/ne
f
[ 174.237999] EIP: [] sk_filter_delayed_uncharge+0x1/0x20 SS:ESP
0068:c3e05edc
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
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 n
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
[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 int
Francois Romieu wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=5681 suggests that
> suspend/resume support is broken in 8139cp but I have some
> code to test (see above).
>
Seems to solve the problem. Good work! :)
Once this gets merged then Andrew should drop the hack that's in -mm.
R
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 unconditi
Pierre Ossman wrote:
> 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 do
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 su
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
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
suspend-to-
20 matches
Mail list logo
