On Mon, Mar 16, 2015 at 12:44 AM, NeilBrown wrote:
> On Sat, 14 Mar 2015 21:16:51 +0100 Torsten Kaiser
> wrote:
>> udisksd now again behaves normal, but I'm not sending this change as a
>> patch, because I do not know about the locking and livetime of these
>
On Mon, Mar 16, 2015 at 12:44 AM, NeilBrown ne...@suse.de wrote:
On Sat, 14 Mar 2015 21:16:51 +0100 Torsten Kaiser
just.for.l...@googlemail.com wrote:
udisksd now again behaves normal, but I'm not sending this change as a
patch, because I do not know about the locking and livetime
On Mon, Mar 9, 2015 at 12:30 AM, NeilBrown wrote:
> On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor wrote:
>
>> Hi,
>>
>> I noticed the udisks daemon (version 2.1.4) suddenly started using high
>> cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:
>>
>>
On Mon, Mar 9, 2015 at 12:30 AM, NeilBrown ne...@suse.de wrote:
On Sun, 08 Mar 2015 18:14:39 +0100 Prakash Punnoor prak...@punnoor.de wrote:
Hi,
I noticed the udisks daemon (version 2.1.4) suddenly started using high
cpu (one core at 100%) with linux 4.0 git kernel. I bisected it to:
t; builds.
>
> Reported-by: Ronald
> Reported-by: Torsten Kaiser
> Signed-off-by: Michal Marek
> ---
>
> Can you try this patch?
Works fine for me.
Thanks for the quick patch!
Torsten
> Ronald, can you tell me your full name for the Reported-by: line?
>
> Tha
...@gmail.com
Reported-by: Torsten Kaiser just.for.l...@googlemail.com
Signed-off-by: Michal Marek mma...@suse.cz
---
Can you try this patch?
Works fine for me.
Thanks for the quick patch!
Torsten
Ronald, can you tell me your full name for the Reported-by: line?
Thanks.
---
firmware/Makefile
On Wed, Jun 18, 2014 at 6:25 PM, Ronald wrote:
> From my .config
>
> ==> cat /usr/src/config | grep -i b43
> CONFIG_EXTRA_FIRMWARE="b43/ucode5.fw b43/b0g0initvals5.fw
> b43/b0g0bsinitvals5.fw b43/pcm5.fw"
> ... snip ...
That might be rather later, but I seem to have the same problem:
CHK
On Wed, Jun 18, 2014 at 6:25 PM, Ronald ronald...@gmail.com wrote:
From my .config
== cat /usr/src/config | grep -i b43
CONFIG_EXTRA_FIRMWARE=b43/ucode5.fw b43/b0g0initvals5.fw
b43/b0g0bsinitvals5.fw b43/pcm5.fw
... snip ...
That might be rather later, but I seem to have the same problem:
Commit-ID: d982057f631df04f8d78321084a1a71ca51f3364
Gitweb: http://git.kernel.org/tip/d982057f631df04f8d78321084a1a71ca51f3364
Author: Torsten Kaiser
AuthorDate: Tue, 23 Jul 2013 22:58:23 +0200
Committer: H. Peter Anvin
CommitDate: Wed, 31 Jul 2013 08:37:14 -0700
x86, amd, microcode
Commit-ID: d982057f631df04f8d78321084a1a71ca51f3364
Gitweb: http://git.kernel.org/tip/d982057f631df04f8d78321084a1a71ca51f3364
Author: Torsten Kaiser just.for.l...@googlemail.com
AuthorDate: Tue, 23 Jul 2013 22:58:23 +0200
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Wed
On Wed, Jul 24, 2013 at 4:19 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
>> > The other problem I see is not updating c->microcode since it is going
>> > to be overwritten by smp_store_cpu_info, which is unfortunate.
>>
On Wed, Jul 24, 2013 at 3:56 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
>> >> * Save the amd_bsp_mpb on apply, not on load. Otherwise someone could
>> >> later load an older microcode file that would overwrite a
On Wed, Jul 24, 2013 at 3:41 PM, Borislav Petkov wrote:
> Let me try to answer this as well as I can, peacemeal-wise.
>
> On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
>> On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
>> > On Tue, Jul 23,
On Wed, Jul 24, 2013 at 3:41 PM, Borislav Petkov b...@alien8.de wrote:
Let me try to answer this as well as I can, peacemeal-wise.
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov b...@alien8.de wrote:
On Tue, Jul 23, 2013 at 01
On Wed, Jul 24, 2013 at 3:56 PM, Borislav Petkov b...@alien8.de wrote:
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
* Save the amd_bsp_mpb on apply, not on load. Otherwise someone could
later load an older microcode file that would overwrite amd_bsp_mpb,
but would
On Wed, Jul 24, 2013 at 4:19 PM, Borislav Petkov b...@alien8.de wrote:
On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
The other problem I see is not updating c-microcode since it is going
to be overwritten by smp_store_cpu_info, which is unfortunate.
And I don't see where
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
>> Fixup the early AMD microcode loading.
>>
>> * load_microcode_amd() (and the helper its using) should not have an
>> cpu parameter.
>
&g
of collect_cpu_info_amd_early() into load_ucode_amd_ap(), because
its
only used at one place and without the cpuinfo_x86 accesses it was not much
left.
Signed-off-by: Torsten Kaiser
---
One effect of this early, partly initialisation of cpu_info was, that the
fallback
logic in cpu_has_amd_erratum() did not use
saved and would be lost on resume.
* apply_ucode_in_initrd() now also needs to save amd_bsp_mbp, because
load_microcode_amd() its no longer doing this and its not using
apply_microcode_amd().
Signed-off-by: Torsten Kaiser
---
Removing this hunk from load_microcode_amd() also allows me to kill
, because without load_microcode_amd()
getting called apply_microcode_amd() could not do anything.
Signed-off-by: Torsten Kaiser
--- a/arch/x86/kernel/microcode_amd_early.c 2013-07-22 06:22:32.0
+0200
+++ b/arch/x86/kernel/microcode_amd_early.c 2013-07-23 20:00:04.889508712
Don't lose the error return.
This was lost when early amd microcode loading was added in
757885e94a22bcc82beb9b1445c95218cb20ceab
Signed-off-by: Torsten Kaiser
--- a/arch/x86/kernel/microcode_core_early.c2013-07-23 19:44:05.509516795
+0200
+++ b/arch/x86/kernel/microcode_core_early.c
Return -1 (like Intels apply_microcode) when the loading fails, also
do not set the active microcode level on failure.
Signed-off-by: Torsten Kaiser
--- a/arch/x86/kernel/microcode_amd.c 2013-07-23 19:42:16.089517717 +0200
+++ b/arch/x86/kernel/microcode_amd.c 2013-07-23 19:43:30.359517091
t been silent this bug
would have been much more obvious.
V2: At request of Borislav Petkov: BUG_ON -> WARN_ON and subject change
Signed-off-by: Torsten Kaiser
--- a/arch/x86/kernel/cpu/amd.c 2013-07-22 06:33:10.027931005 +0200
+++ b/arch/x86/kernel/cpu/amd.c 2013-07-22 06:35:15.757931265 +0200
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov wrote:
> On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
>> Fixup the early AMD microcode loading.
>>
>> * load_microcode_amd() (and the helper its using) should not have an
>> cpu parameter.
>
&g
)->microcode, but I see no good way to remove that there,
because
for not-early microcode updates that is exactly the right place for that update.
Signed-off-by: Torsten Kaiser
---
This alone also fixes the hang-on-boot I experienced with 3.11-rc1 even
if the fix for cpu_has_amd_erra
t been silent this bug
would have been much more obvious.
Signed-off-by: Torsten Kaiser
--- a/arch/x86/kernel/cpu/amd.c 2013-07-22 06:33:10.027931005 +0200
+++ b/arch/x86/kernel/cpu/amd.c 2013-07-22 06:35:15.757931265 +0200
@@ -512,7 +512,7 @@ static void early_init_amd(struct cpuinf
static con
this bug
would have been much more obvious.
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
--- a/arch/x86/kernel/cpu/amd.c 2013-07-22 06:33:10.027931005 +0200
+++ b/arch/x86/kernel/cpu/amd.c 2013-07-22 06:35:15.757931265 +0200
@@ -512,7 +512,7 @@ static void early_init_amd(struct
)-microcode, but I see no good way to remove that there,
because
for not-early microcode updates that is exactly the right place for that update.
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
---
This alone also fixes the hang-on-boot I experienced with 3.11-rc1 even
if the fix
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov b...@alien8.de wrote:
On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
Fixup the early AMD microcode loading.
* load_microcode_amd() (and the helper its using) should not have an
cpu parameter.
Hmm, I don't think so - we get
this bug
would have been much more obvious.
V2: At request of Borislav Petkov: BUG_ON - WARN_ON and subject change
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
--- a/arch/x86/kernel/cpu/amd.c 2013-07-22 06:33:10.027931005 +0200
+++ b/arch/x86/kernel/cpu/amd.c 2013-07-22 06:35
Return -1 (like Intels apply_microcode) when the loading fails, also
do not set the active microcode level on failure.
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
--- a/arch/x86/kernel/microcode_amd.c 2013-07-23 19:42:16.089517717 +0200
+++ b/arch/x86/kernel/microcode_amd.c
Don't lose the error return.
This was lost when early amd microcode loading was added in
757885e94a22bcc82beb9b1445c95218cb20ceab
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
--- a/arch/x86/kernel/microcode_core_early.c2013-07-23 19:44:05.509516795
+0200
+++ b/arch/x86/kernel
, because without load_microcode_amd()
getting called apply_microcode_amd() could not do anything.
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
--- a/arch/x86/kernel/microcode_amd_early.c 2013-07-22 06:22:32.0
+0200
+++ b/arch/x86/kernel/microcode_amd_early.c 2013-07
saved and would be lost on resume.
* apply_ucode_in_initrd() now also needs to save amd_bsp_mbp, because
load_microcode_amd() its no longer doing this and its not using
apply_microcode_amd().
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
---
Removing this hunk from load_microcode_amd
of collect_cpu_info_amd_early() into load_ucode_amd_ap(), because
its
only used at one place and without the cpuinfo_x86 accesses it was not much
left.
Signed-off-by: Torsten Kaiser just.for.l...@googlemail.com
---
One effect of this early, partly initialisation of cpu_info was, that the
fallback
logic
On Tue, Jul 23, 2013 at 5:15 PM, Borislav Petkov b...@alien8.de wrote:
On Tue, Jul 23, 2013 at 01:58:53PM +0200, Torsten Kaiser wrote:
Fixup the early AMD microcode loading.
* load_microcode_amd() (and the helper its using) should not have an
cpu parameter.
Hmm, I don't think so - we get
On Sun, Jul 21, 2013 at 12:59 AM, Borislav Petkov wrote:
> On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
>> On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov wrote:
>> > On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
>> >> config i
On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov wrote:
> On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
>> config is attached
>
> Ok, I can reproduce the hang with your config but even with:
>
> $ grep MICROCODE .config
> # CONFIG_MICROCODE is not set
> #
On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
config is attached
Ok, I can reproduce the hang with your config but even with:
$ grep MICROCODE .config
# CONFIG_MICROCODE is not set
#
On Sun, Jul 21, 2013 at 12:59 AM, Borislav Petkov b...@alien8.de wrote:
On Sat, Jul 20, 2013 at 09:01:33PM +0200, Torsten Kaiser wrote:
On Tue, Jul 16, 2013 at 7:00 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Jul 11, 2013 at 11:05:25PM +0200, Johannes Hirte wrote:
config is attached
From: Torsten Kaiser
Commit fb59581404ab7ec5075299065c22cb211a9262a9 removed
xfs_flushinval_pages() and changed its callers to use
filemap_write_and_wait() and truncate_pagecache_range() directly.
But in xfs_swap_extents() this change accidental switched the argument
for 'tip' to 'ip
From: Torsten Kaiser just.for.l...@googlemail.com
Commit fb59581404ab7ec5075299065c22cb211a9262a9 removed
xfs_flushinval_pages() and changed its callers to use
filemap_write_and_wait() and truncate_pagecache_range() directly.
But in xfs_swap_extents() this change accidental switched
On Tue, Nov 27, 2012 at 8:08 AM, Torsten Kaiser
wrote:
> On Tue, Nov 27, 2012 at 2:05 AM, NeilBrown wrote:
>> Can you test to see if this fixes it?
>
> Patch applied, I will try to get it stuck again.
> I don't have a reliable reproducers, but if the problem persists I
>
On Tue, Nov 27, 2012 at 8:08 AM, Torsten Kaiser
just.for.l...@googlemail.com wrote:
On Tue, Nov 27, 2012 at 2:05 AM, NeilBrown ne...@suse.de wrote:
Can you test to see if this fixes it?
Patch applied, I will try to get it stuck again.
I don't have a reliable reproducers, but if the problem
On Tue, Nov 27, 2012 at 2:05 AM, NeilBrown wrote:
> On Sat, 24 Nov 2012 10:18:44 +0100 Torsten Kaiser
> wrote:
>
>> After my system got stuck with 3.7.0-rc2 as reported in
>> http://marc.info/?l=linux-kernel=135142236520624 LOCKDEP seem to
>> blame XFS, because it
On Tue, Nov 27, 2012 at 2:05 AM, NeilBrown ne...@suse.de wrote:
On Sat, 24 Nov 2012 10:18:44 +0100 Torsten Kaiser
just.for.l...@googlemail.com wrote:
After my system got stuck with 3.7.0-rc2 as reported in
http://marc.info/?l=linux-kernelm=135142236520624 LOCKDEP seem to
blame XFS, because
After my system got stuck with 3.7.0-rc2 as reported in
http://marc.info/?l=linux-kernel=135142236520624 LOCKDEP seem to
blame XFS, because it found 2 possible deadlocks. But after these
locking issues where fixed, my system got stuck again with 3.7.0-rc6
as reported in
After my system got stuck with 3.7.0-rc2 as reported in
http://marc.info/?l=linux-kernelm=135142236520624 LOCKDEP seem to
blame XFS, because it found 2 possible deadlocks. But after these
locking issues where fixed, my system got stuck again with 3.7.0-rc6
as reported in
On Tue, Nov 20, 2012 at 12:53 AM, Dave Chinner wrote:
> On Mon, Nov 19, 2012 at 07:50:06AM +0100, Torsten Kaiser wrote:
> So, both lockdep thingy's are the same:
I suspected this, but as the reports where slightly different I
attached bith of them, as I couldn't decide witch one was the
On Tue, Nov 20, 2012 at 12:53 AM, Dave Chinner da...@fromorbit.com wrote:
On Mon, Nov 19, 2012 at 07:50:06AM +0100, Torsten Kaiser wrote:
So, both lockdep thingy's are the same:
I suspected this, but as the reports where slightly different I
attached bith of them, as I couldn't decide witch one
On Mon, Nov 19, 2012 at 12:51 AM, Dave Chinner wrote:
> On Sun, Nov 18, 2012 at 04:29:22PM +0100, Torsten Kaiser wrote:
>> On Sun, Nov 18, 2012 at 11:24 AM, Torsten Kaiser
>> wrote:
>> > On Tue, Oct 30, 2012 at 9:37 PM, Torsten Kaiser
>> > wrote:
>> >&g
On Sun, Nov 18, 2012 at 11:24 AM, Torsten Kaiser
wrote:
> On Tue, Oct 30, 2012 at 9:37 PM, Torsten Kaiser
> wrote:
>> I will keep LOCKDEP enabled on that system, and if there really is
>> another splat, I will report back here. But I rather doubt that this
>> will be nee
On Tue, Oct 30, 2012 at 9:37 PM, Torsten Kaiser
wrote:
> I will keep LOCKDEP enabled on that system, and if there really is
> another splat, I will report back here. But I rather doubt that this
> will be needed.
After the patch, I did not see this problem again, but today I foun
On Tue, Oct 30, 2012 at 9:37 PM, Torsten Kaiser
just.for.l...@googlemail.com wrote:
I will keep LOCKDEP enabled on that system, and if there really is
another splat, I will report back here. But I rather doubt that this
will be needed.
After the patch, I did not see this problem again
On Sun, Nov 18, 2012 at 11:24 AM, Torsten Kaiser
just.for.l...@googlemail.com wrote:
On Tue, Oct 30, 2012 at 9:37 PM, Torsten Kaiser
just.for.l...@googlemail.com wrote:
I will keep LOCKDEP enabled on that system, and if there really is
another splat, I will report back here. But I rather doubt
On Mon, Nov 19, 2012 at 12:51 AM, Dave Chinner da...@fromorbit.com wrote:
On Sun, Nov 18, 2012 at 04:29:22PM +0100, Torsten Kaiser wrote:
On Sun, Nov 18, 2012 at 11:24 AM, Torsten Kaiser
just.for.l...@googlemail.com wrote:
On Tue, Oct 30, 2012 at 9:37 PM, Torsten Kaiser
just.for.l
On Wed, Oct 31, 2012 at 6:55 AM, Daniel J Blueman
wrote:
> As the AMD64 last-level-cache ID is 16-bits and federated systems
> eg using Numascale's NumaConnect/NumaChip can have more than 255 memory
> controllers, use 16-bits to store the ID.
>
> Signed-off-by: Daniel J Blueman
> ---
>
On Wed, Oct 31, 2012 at 6:55 AM, Daniel J Blueman
dan...@numascale-asia.com wrote:
As the AMD64 last-level-cache ID is 16-bits and federated systems
eg using Numascale's NumaConnect/NumaChip can have more than 255 memory
controllers, use 16-bits to store the ID.
Signed-off-by: Daniel J
On Mon, Oct 29, 2012 at 11:26 PM, Dave Chinner wrote:
> On Mon, Oct 29, 2012 at 09:03:15PM +0100, Torsten Kaiser wrote:
>> After experiencing a hang of all IO yesterday (
>> http://marc.info/?l=linux-kernel=135142236520624=2 ), I turned on
>> LOCKDEP after upgrading to -rc
On Mon, Oct 29, 2012 at 11:26 PM, Dave Chinner da...@fromorbit.com wrote:
On Mon, Oct 29, 2012 at 09:03:15PM +0100, Torsten Kaiser wrote:
After experiencing a hang of all IO yesterday (
http://marc.info/?l=linux-kernelm=135142236520624w=2 ), I turned on
LOCKDEP after upgrading to -rc3.
I
After experiencing a hang of all IO yesterday (
http://marc.info/?l=linux-kernel=135142236520624=2 ), I turned on
LOCKDEP after upgrading to -rc3.
I then tried to replicate the load that hung yesterday and got the
following lockdep report, implicating XFS instead of by stacking swap
onto dm-crypt
After experiencing a hang of all IO yesterday (
http://marc.info/?l=linux-kernelm=135142236520624w=2 ), I turned on
LOCKDEP after upgrading to -rc3.
I then tried to replicate the load that hung yesterday and got the
following lockdep report, implicating XFS instead of by stacking swap
onto
While 3.7.0-rc1 and -rc2 otherwise worked fine for me, today my system
experienced a hang, trying to write to its disks.
Source of the problem seems to be a hang in kswapd0, after that many
more processes got stuck trying to do IO. Even an emergency sync via
SysRq+S did no longer complete.
The
While 3.7.0-rc1 and -rc2 otherwise worked fine for me, today my system
experienced a hang, trying to write to its disks.
Source of the problem seems to be a hang in kswapd0, after that many
more processes got stuck trying to do IO. Even an emergency sync via
SysRq+S did no longer complete.
The
On Feb 19, 2008 5:20 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So:
> - it might be something else entirely
> - it might still be the local cmpxchg, just Torsten didn't happen to
>notice it until later.
My new hackbench-testcase also killed 2.6.24-rc2-mm1, so I really
noticed to late.
On Feb 19, 2008 5:20 PM, Linus Torvalds [EMAIL PROTECTED] wrote:
So:
- it might be something else entirely
- it might still be the local cmpxchg, just Torsten didn't happen to
notice it until later.
My new hackbench-testcase also killed 2.6.24-rc2-mm1, so I really
noticed to late.
-
On Feb 19, 2008 7:11 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > On Feb 15, 2008 10:23 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > >
> > > Ok,
> > > this kernel is a winner.
> >
>
On Feb 19, 2008 12:54 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 16 Feb 2008, Torsten Kaiser wrote:
> >
> > [ 5282.056415] [ cut here ]
> > [ 5282.059757] kernel BUG at lib/list_debug.c:33!
>
> Is there any chance tha
On Feb 19, 2008 12:54 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
On Sat, 16 Feb 2008, Torsten Kaiser wrote:
[ 5282.056415] [ cut here ]
[ 5282.059757] kernel BUG at lib/list_debug.c:33!
Is there any chance that you could try to bisect this, if it's repeatable
On Feb 19, 2008 7:11 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Torsten Kaiser [EMAIL PROTECTED] wrote:
On Feb 15, 2008 10:23 PM, Linus Torvalds [EMAIL PROTECTED] wrote:
Ok,
this kernel is a winner.
Sadly not for me:
[ 5282.056415] [ cut here
On Feb 17, 2008 9:25 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> There's the Bugzilla entry for it at
> http://bugzilla.kernel.org/show_bug.cgi?id=9973
Thank you.
> Please update it with the current information.
Crash for 2.6.25-rc2-mm1 added. That one had a complete stacktrace,
but the
On Feb 17, 2008 9:25 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
There's the Bugzilla entry for it at
http://bugzilla.kernel.org/show_bug.cgi?id=9973
Thank you.
Please update it with the current information.
Crash for 2.6.25-rc2-mm1 added. That one had a complete stacktrace,
but the trace
On Feb 15, 2008 10:23 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Ok,
> this kernel is a winner.
Sadly not for me:
[ 5282.056415] [ cut here ]
[ 5282.059757] kernel BUG at lib/list_debug.c:33!
[ 5282.062055] invalid opcode: [1] SMP
[ 5282.062055] CPU 3
[
On Feb 15, 2008 10:23 PM, Linus Torvalds [EMAIL PROTECTED] wrote:
Ok,
this kernel is a winner.
Sadly not for me:
[ 5282.056415] [ cut here ]
[ 5282.059757] kernel BUG at lib/list_debug.c:33!
[ 5282.062055] invalid opcode: [1] SMP
[ 5282.062055] CPU 3
[
On Feb 11, 2008 11:15 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Feb 2008 22:46:18 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Feb 11, 2008 1:44 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > So give it all
On Feb 11, 2008 11:15 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 11 Feb 2008 22:46:18 +0100
Torsten Kaiser [EMAIL PROTECTED] wrote:
On Feb 11, 2008 1:44 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
So give it all a good testing.
My mm-mystery-crash has now sneaked into mainline
On Feb 11, 2008 1:44 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> So give it all a good testing.
My mm-mystery-crash has now sneaked into mainline:
[ 1463.829078] BUG: unable to handle kernel NULL pointer dereference
at 0378
[ 1463.832141] IP: [] ether1394_dg_complete+0x28/0xa0
[
On Feb 11, 2008 1:44 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
So give it all a good testing.
My mm-mystery-crash has now sneaked into mainline:
[ 1463.829078] BUG: unable to handle kernel NULL pointer dereference
at 0378
[ 1463.832141] IP: [8047af18]
On Jan 17, 2008 11:35 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
I'm still seeing my mystery-crash that I had since 2.6.24-rc3-mm2.
The crashed kernel was 2.6.24-rc8-mm1 with the following patches:
*
Sorry for the *really* late answer, but I did not have any time to do
linux things the last weeks. :-(
On Jan 7, 2008 7:16 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 21:03:42 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > On Ja
On Jan 17, 2008 11:35 AM, Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/
I'm still seeing my mystery-crash that I had since 2.6.24-rc3-mm2.
The crashed kernel was 2.6.24-rc8-mm1 with the following patches:
*
Sorry for the *really* late answer, but I did not have any time to do
linux things the last weeks. :-(
On Jan 7, 2008 7:16 AM, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Sun, 6 Jan 2008 21:03:42 +0100
Torsten Kaiser [EMAIL PROTECTED] wrote:
On Jan 6, 2008 2:33 PM, FUJITA Tomonori [EMAIL
On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 12:35:35 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > On Sun, 6 Jan 2
On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sun, 6 Jan 2008 11:41:10 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > I will applie your patch and see if this hunk from
> > find_next_zero_area() makes a dif
On Jan 6, 2008 4:28 AM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> On Sat, 5 Jan 2008 17:25:24 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sat, 5 Jan 2008 23:10:17 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> >
On Jan 6, 2008 9:27 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
> ...
> > So my personal conclusion would be, that someone is writing to memory
> > that he no longer owns. Most probably 0-bytes. (the
On Jan 6, 2008 9:27 AM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
...
So my personal conclusion would be, that someone is writing to memory
that he no longer owns. Most probably 0-bytes. (the complete_routine
got NULLed
On Jan 6, 2008 4:28 AM, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Sat, 5 Jan 2008 17:25:24 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Sat, 5 Jan 2008 23:10:17 +0100 Torsten Kaiser [EMAIL PROTECTED]
wrote:
But the cause of my mail is the following question:
Regarding my iommu-sg
On Jan 6, 2008 12:23 PM, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Sun, 6 Jan 2008 11:41:10 +0100
Torsten Kaiser [EMAIL PROTECTED] wrote:
I will applie your patch and see if this hunk from
find_next_zero_area() makes a difference:
end = index + nr;
- if (end size
On Jan 6, 2008 2:33 PM, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Sun, 6 Jan 2008 12:35:35 +0100
Torsten Kaiser [EMAIL PROTECTED] wrote:
On Jan 6, 2008 12:23 PM, FUJITA Tomonori [EMAIL PROTECTED] wrote:
On Sun, 6 Jan 2008 11:41:10 +0100
Torsten Kaiser [EMAIL PROTECTED] wrote:
I
On Jan 5, 2008 11:10 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> 2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
> git-netdev-all) worked for 110 packages, then I proclaimed it good.
> 2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
> getting
On Jan 5, 2008 3:52 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 5, 2008 11:13 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> > > On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL P
On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
> > On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > The only thing that is sadly not practical is bisecting t
On Jan 5, 2008 1:07 AM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
On Jan 4, 2008 2:30 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
The only thing that is sadly not practical is bisecting the borkenout
mm-patches, as triggering
On Jan 5, 2008 11:10 PM, Torsten Kaiser [EMAIL PROTECTED] wrote:
2.6.24-rc6 + mm-patches up to git.battery (includes git-net and
git-netdev-all) worked for 110 packages, then I proclaimed it good.
2.6.24-rc6 + mm-patches up to (including) git.nfsd is currently
getting testet (9 packages done
On Jan 4, 2008 4:21 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > - above git-nfsd and git-net tests should be probably repeated with
> > -rc6-mm1 git versions: so vanilla rc6 plus both these -mm p
On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On 04-01-2008 11:23, Torsten Kaiser wrote:
> > On Jan 2, 2008 10:51 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> >> On Wed, Jan 02, 2008 at 07:29:59PM +0100, Torsten Kaiser wrote:
> >>&
On Jan 2, 2008 10:51 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 2008 at 07:29:59PM +0100, Torsten Kaiser wrote:
> >
> > Vanilla 2.6.24-rc6 seems stable. I did not see any crash or warnings.
>
> OK that's great. The next step would be to try excluding s
On Jan 2, 2008 10:51 PM, Herbert Xu [EMAIL PROTECTED] wrote:
On Wed, Jan 02, 2008 at 07:29:59PM +0100, Torsten Kaiser wrote:
Vanilla 2.6.24-rc6 seems stable. I did not see any crash or warnings.
OK that's great. The next step would be to try excluding specific git
trees from mm to see
On Jan 4, 2008 2:30 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On 04-01-2008 11:23, Torsten Kaiser wrote:
On Jan 2, 2008 10:51 PM, Herbert Xu [EMAIL PROTECTED] wrote:
On Wed, Jan 02, 2008 at 07:29:59PM +0100, Torsten Kaiser wrote:
Vanilla 2.6.24-rc6 seems stable. I did not see any crash
1 - 100 of 368 matches
Mail list logo
