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
>> ob
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:
>>
>> 750f199ee8b578062341e6d
n non-O
> 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?
>
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 k
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
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 amd_bsp_
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 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.
>
> H
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
thing, 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.8895
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_ea
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
#x27;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 +
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.
>
> H
a(cpu)->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_erratum(
#x27;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
stati
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
> # CONFIG_MICROCODE_INTEL_E
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
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 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&m=135142236520624 LOCKDEP seem to
>> blame XFS, becaus
After my system got stuck with 3.7.0-rc2 as reported in
http://marc.info/?l=linux-kernel&m=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 http://marc.info/?l=linux-
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 on
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 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
> ---
> drivers/e
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&m=135142236520624&w=2 ), I turned on
>> LOCKDEP after up
After experiencing a hang of all IO yesterday (
http://marc.info/?l=linux-kernel&m=135142236520624&w=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-cr
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 ha
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 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 t
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
[ 5282.06
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 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
[ 14
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:
* p
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 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 difference:
> &g
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 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 PROT
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 b
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 exclud
On Jan 2, 2008 10:57 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 03, 2008 at 08:51:54AM +1100, Herbert Xu wrote:
> > The two specific trees of interest would be git-nfsd and git-net.
>
> Also, if it's git-nfsd, it'd be useful to test with the current git-nfsd
> from the for-mm bran
On Jan 2, 2008 10:57 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 03, 2008 at 08:51:54AM +1100, Herbert Xu 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 cra
On Jan 2, 2008 10:12 PM, Russell Leidich <[EMAIL PROTECTED]> wrote:
> On Jan 2, 2008 12:00 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 02, 2008 at 11:43:08AM -0800, Russell Leidich wrote:
> > > likelihood, will extend to some future CPUs). Indeed, as far as my
> > > testing has deter
On Jan 2, 2008 9:51 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Jan 2008, Torsten Kaiser wrote:
>
> > I just tested something with vanilla 2.6.24-rc6 and had the same problem.
> > Should this patch, or something similar be included for 2.6.24?
>
> Su
CC's somewhat trimmed...
On Nov 18, 2007 12:00 AM, root <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 17, 2007 at 07:09:46PM +0100, Ingo Molnar wrote:
> > * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> >
> > > Sadly lockdep does not work for me, as it g
On Jan 1, 2008 1:04 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> In any case, I suspect the cause of your problem is that somebody
> somewhere is doing a double-free on an skb.
>
> Since you're the only person who can reproduce this, we really need
> your help to track this down. Since bisecting th
On Jan 1, 2008 1:59 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Jan 1, 2008 1:04 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > On Mon, Dec 31, 2007 at 09:15:19PM +0100, Torsten Kaiser wrote:
> > >
> > > I then tried to "fix" it with this susp
On Jan 1, 2008 1:04 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 31, 2007 at 09:15:19PM +0100, Torsten Kaiser wrote:
> >
> > I then tried to "fix" it with this suspect.
> > I changed "skb_release_all(dst);" back to "skb_relea
On Dec 30, 2007 4:34 AM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Dec 30, 2007 2:30 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > On Sat, Dec 29, 2007 at 05:51:13PM +0100, Torsten Kaiser wrote:
> > >
> > > > > The cause, why I am resending this:
On Dec 31, 2007 6:18 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Monday 31 December 2007 17:38:03 Alan Cox wrote:
> > On Mon, 31 Dec 2007 17:17:19 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> >
> > > a) this could be disabl
On Dec 31, 2007 5:01 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > I'd say the practical advantage to the user would be almost zero.
> > Which distribution is going to enable this option and defacto
> > banning external modules?
>
> It would be a real nuisance for developing code let alone for using
On Dec 31, 2007 4:59 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote:
> > One thing I always wondered about in this discussion about wasted
> > EXPORT_SYMBOL's:
> > Shouldn't it be possible to garbage
On Dec 31, 2007 3:42 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> of memory.
One thing I always wondered about in this discussion about wasted
EXPORT_SYMBOL's:
On Dec 30, 2007 10:35 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Dec 30, 2007 10:24 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> > From: Tom Tucker <[EMAIL PROTECTED]>
> > Date: Sun, 30 Dec 2007 10:07:17 -0600
> >
> > Bruce/Aime:
> &g
On Dec 30, 2007 10:57 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > what's exactly in the hibernation image? Dirty data i suppose
> >
> > No, everything, including the kernel code, page tables etc. :-)
> >
> > > - but what about kernel-interna
On Dec 30, 2007 10:24 PM, J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> On Fri, Dec 28, 2007 at 03:07:46PM -0800, Andrew Morton wrote:
> > On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On
On Dec 30, 2007 2:30 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 29, 2007 at 05:51:13PM +0100, Torsten Kaiser wrote:
> >
> > > > The cause, why I am resending this: I just got a crash with
> > > > 2.6.24-rc6-mm1, again looking network related:
>
On Dec 29, 2007 12:07 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Dec 2007 23:53:49 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
[snip]
> > [ 7620.708561] Pid: 5698,
On Dec 23, 2007 5:27 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
> I have finally given up on using
[author CCed]
On Dec 27, 2007 12:42 PM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Dec 23, 2007 9:39 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, 23 Dec 2007 17:27:12 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]>
> > wrote:
> &g
On Dec 23, 2007 9:39 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Sun, 23 Dec 2007 17:27:12 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > >
On Dec 23, 2007 8:30 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
[snip]
> +agk-dm-dm-snapshot-use-uninitialized_var.patch
> +agk-dm-dm-raid1-handle-write-failures.patch
> +agk-dm-dm-raid1-report-fault-stat
On Nov 29, 2007 10:07 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Nov 2007 21:58:16 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > But after ~1h of usage I got two different crashes on my x86_64 box.
>
> Nice, thanks. By finding
On Nov 28, 2007 12:41 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm2/
>
> - All patches against subsystem trees were recently sent to the relevant
> maintainers. Many (probably most) were ignored. I don't
triggered on every boot, this can't prove anything.
But if it happens again, I will notify you.
Torsten
> Torsten Kaiser wrote:
> >
> > static inline int in_range(const void *start, const void *addr, const void
> > *end)
> > {
> > return addr >= s
On Nov 24, 2007 4:49 AM, Alasdair G Kergon <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 23, 2007 at 11:42:36PM +0100, Torsten Kaiser wrote:
> > ... or I just don't see the bug.
>
> See my earlier post in this thread: there's a race in the write loop
> where a work
On Nov 19, 2007 10:00 PM, Milan Broz <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > On Nov 19, 2007 8:56 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> ...
> > Above this acquire/release
On Nov 20, 2007 7:55 AM, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On Nov 19, 2007 10:00 PM, Milan Broz <[EMAIL PROTECTED]> wrote:
> > Please could you try which patch from the dm-crypt series cause this ?
> > (agk-dm-dm-crypt* names.)
> >
> > I suspect
On Nov 21, 2007 8:22 PM, Len Brown <[EMAIL PROTECTED]> wrote:
> On Wednesday 21 November 2007 01:18, Andrew Morton wrote:
> > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > wrote:
>
> > > SMP alternatives: switching to UP code
> > > ACPI: Core revision 20070126
> > > .
On Nov 21, 2007 10:29 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Nov 2007 14:52:26 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > On Wed, 21 Nov 2007 11:41:23 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > > wrote:
> > >> ACPI: Core revision 20070
On Nov 19, 2007 10:00 PM, Milan Broz <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > Anything I could try, apart from more boots with slub_debug=F?
One time it triggered with slub_debug=F, but no additional output.
With slub_debug=FP I have not seen it again, so I can'
On Nov 19, 2007 8:56 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
>
> > Trying the last NFSv4 patch (but that patch is only the cause, why I
> > had lockdep enabled) I got this:
>
On Nov 19, 2007 10:00 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Nov 2007 08:15:48 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > On Nov 18, 2007 8:18 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > > I had already fixed that o
Trying the last NFSv4 patch (but that patch is only the cause, why I
had lockdep enabled) I got this:
[ 64.550203]
[ 64.550205] =
[ 64.552213] [ BUG: held lock freed! ]
[ 64.553633] -
[ 64.555055] kcryptd/1022 is freeing memory
81011EBEF
On Nov 18, 2007 8:18 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
> > NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
> > unlink and sillyrename logic.
> > But they do not share nfs_init_ser
On Nov 18, 2007 12:05 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> I've been staring at this NFS code for a while an can't make any sense
> out of it. It seems to correctly initialize the waitqueue. So this would
> indicate corruption of some sort.
No, it does not "correctly" initialize the wai
On Nov 18, 2007 12:05 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Sat, Nov 17, 2007 at 08:40:22PM +0100, Torsten Kaiser wrote:
>
> > Lockdep triggers immedetly before the freeze, but the result is still
> > not helpful:
> >
> > [ 221.565011]
On Nov 17, 2007 8:33 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 17 Nov 2007, Andrew Morton wrote:
>
> > That's slub. It appears that list_lock is being taken from process context
> > in one place and from softirq in another.
>
> I kicked out some weird interrupt disable code in mm
On Nov 17, 2007 7:19 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Sat, 17 Nov 2007 19:09:46 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> >
> > > Sadly lockdep does not work fo
On Nov 17, 2007 7:58 PM, Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-11-17 at 18:53 +0100, Torsten Kaiser wrote:
> > On Nov 16, 2007 3:15 PM, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > > Hi Andrew,
> > >
> > > The kernel
On Nov 16, 2007 3:15 PM, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The kernel enters the xmon state while running the file system
> stress on nfs v4 mounted partition.
[snip]
> 0:mon> t
> [c000dbd4fb50] c0069768 .__wake_up+0x54/0x88
> [c000dbd4fc00] d086b8
On Nov 16, 2007 3:03 PM, Jan Blunck <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 15, Torsten Kaiser wrote:
> > The only thing that looks suspicious to me in that patch is the
> > following change in nfs4_atomic_open(), nfs4_open_revalidate() and
> > nfs4_proc_create()
>
On Nov 15, 2007 10:34 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 15 Nov 2007 22:24:12 +0100
> "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > The problem with the first bisect-try was, that everything between
> > bisect-good: r-o-bi
On Nov 15, 2007 6:36 PM, Jan Blunck <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 14, Torsten Kaiser wrote:
>
> > > > So I can create new directories, but not new files. Reading files works
> > > > normal.
> > > >>
> > > > The client is 2
On Nov 15, 2007 6:36 PM, Jan Blunck <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 14, Torsten Kaiser wrote:
>
> > > > So I can create new directories, but not new files. Reading files works
> > > > normal.
> > > >>
> > > > The client is 2
On Nov 14, 2007 9:29 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Nov 2007 20:16:09 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Nov 14, 2007 2:59 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > ftp
On Nov 14, 2007 9:29 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 14 Nov 2007 20:16:09 +0100 "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
>
> > On Nov 14, 2007 2:59 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > ftp
On Nov 14, 2007 2:59 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x
treogen x # touch bla
touch: cannot touch `bla': File exists
treogen x #
leased to note that this is now much faster again.
Thanks!
Tested-by: Torsten Kaiser <[EMAIL PROTECTED]>
CC's please note: It looks like this was really a different problem
then the 100% iowait that was seen with reiserfs.
Also the one complete stall I have seen is probably something else
1 - 100 of 185 matches
Mail list logo
