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
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 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
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
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
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
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 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, 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 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 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 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 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
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
#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
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(
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
#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 +
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
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
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
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
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
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
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: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 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 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 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 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 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 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.
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
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 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: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 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 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 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 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 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 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 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 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 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 10/1/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> On 9/30/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> > On 9/30/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> > > Torsten Kaiser wrote:
> To make that comment "cmd part of the output was always the
)
Oct 3 16:56:46 treogen [ 63.32] ata2.00: status: {DRDY }
Resetting the sata link fails, the drive is no longer reachable until a reboot.
I then bisected the mm-patches from 2.6.23-rc4-mm1 with the following result:
On 10/3/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> I'm now
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
> > This patch removes clear_refs_smap() from fs/proc/task_mmu.c by moving
> > its code to a new function. But during the move the main for-loop from
&g
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
> > Of note might be, that at the time of this error init has not been
> > started. I'm using a program from initramfs to start the RAID.
> > T
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> Well I can see no reason why the vma we just got to by the mm->mmap
> would have a vm_mm != mm, but I've certainly been wrong before.
>
> Try changing it to:
>
> for (vma = mm->mmap; vma; vma = vma->vm_next)
> if (!is_vm_
On 10/4/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 04, 2007 at 07:32:52AM +0200, Torsten Kaiser wrote:
> > So now I'm rather out of ideas what to test... :(
>
> I'd give your previous bisect step another try.
Yes, I thought about that too. But I nev
On 10/5/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> So I will use the weekend to see if I can find out who issues this
> command and add more debug to that place...
I added some DPRINTK to sil24_qc_issue and sil24_fill_sg, but I only
found one suspicious thing.
My sil24_fill_
[Adding Jens Axboe, the author of what looks like the probable cause]
On 10/7/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> My sil24_fill_sg now looks like this:
> static inline void sil24_fill_sg(struct ata_queued_cmd *qc,
> struct
On 10/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> > Looking closer at
> > http://git.kernel.org/?p=linux/kernel/git/axboe/linux-2.6-block.git;a=commitdiff;h=ec6fdded4d76aa54aa57341e5dfdd61c507b1dcd
> > the change to libata.h seems bogus :
On 10/11/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Torsten Kaiser wrote:
> >>> That missing +1 would explain, why the SGE_TRM never gets set.
> >> Thanks a lot for tracking this down. Does changing the above code fix
> >> your problem?
> >
> >
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
[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 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
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 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 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 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: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 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 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 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 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 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 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 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:
> 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
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 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
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 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 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
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 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
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 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 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 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 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
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 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 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 #
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 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 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 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 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 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 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 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
1 - 100 of 185 matches
Mail list logo
