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?
>
> Such a patch is in Andrew's tree.
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?
Such a patch is in Andrew's tree.
2.6.24-rc6-mm1:
tatic struct kmem_cache_node
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 gets turned off early:
> > > [ 39.851594]
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 gets turned off early:
[ 39.851594]
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?
Such a patch is in Andrew's tree.
2.6.24-rc6-mm1:
tatic struct kmem_cache_node
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?
Such a patch is in Andrew's tree.
On 11/21/2007 01:00 AM, Rafael J. Wysocki wrote:
> On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
>> commit ce9c7b78c839a6304696d90083eac08baad524ce
>> Author: Mark M. Hoffman <[EMAIL PROTECTED]>
>> Date: Tue Nov 20 07:51:50 2007 -0500
>>
>> hwmon: (coretemp) fix suspend/resume hang
On 11/21/2007 01:00 AM, Rafael J. Wysocki wrote:
On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
commit ce9c7b78c839a6304696d90083eac08baad524ce
Author: Mark M. Hoffman [EMAIL PROTECTED]
Date: Tue Nov 20 07:51:50 2007 -0500
hwmon: (coretemp) fix suspend/resume hang
Alasdair G Kergon <[EMAIL PROTECTED]> wrote:
> Also io->pending may need better protection - atomic, but missing memory
> barriers? (May be getting away without sometimes due to side-effects of
> other function calls, but needs doing properly.)
If it's using atomic_dec_and_test then that comes
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 struct could be used twice on the
On Fri, Nov 23, 2007 at 11:42:36PM +0100, Torsten Kaiser wrote:
> Before the cleanup *all* calls to crypt_dec_pending() was via crypt_endio().
> Now there is an additional call to crypt_dec_pending() to balance the
> additional ref placed into crypt_write_io_process(). And that one is
> not called
Also io->pending may need better protection - atomic, but missing memory
barriers? (May be getting away without sometimes due to side-effects of
other function calls, but needs doing properly.)
[BTW Other device-mapper atomic_t usage also needs reviewing.]
Alasdair
--
[EMAIL PROTECTED]
-
To
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 struct could be used twice on the same queue.
(Needs data structure change to fix that, which nobody has attempted
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 sequence is the following comment:
> > #ifdef
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
Also io-pending may need better protection - atomic, but missing memory
barriers? (May be getting away without sometimes due to side-effects of
other function calls, but needs doing properly.)
[BTW Other device-mapper atomic_t usage also needs reviewing.]
Alasdair
--
[EMAIL PROTECTED]
-
To
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 struct could be used twice on the same queue.
(Needs data structure change to fix that, which nobody has attempted
On Fri, Nov 23, 2007 at 11:42:36PM +0100, Torsten Kaiser wrote:
Before the cleanup *all* calls to crypt_dec_pending() was via crypt_endio().
Now there is an additional call to crypt_dec_pending() to balance the
additional ref placed into crypt_write_io_process(). And that one is
not called
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 struct could be used twice on the same queue.
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 sequence is the following comment:
#ifdef CONFIG_LOCKDEP
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 agk-dm-dm-crypt-move-bio-submission-to-thread.patch
Alasdair G Kergon [EMAIL PROTECTED] wrote:
Also io-pending may need better protection - atomic, but missing memory
barriers? (May be getting away without sometimes due to side-effects of
other function calls, but needs doing properly.)
If it's using atomic_dec_and_test then that comes with an
On Wednesday, 21 of November 2007, Alan Stern wrote:
> On Wed, 21 Nov 2007, Rafael J. Wysocki wrote:
>
> > > Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
> >
> > No. In that case the suspend core is holding the device's mutex and your
> > attempt to unregister it will
Hi,
> > Ok, then I have question: Is the following pseudocode correct
> > (and problem is in lock validation which checks something
> > already initialized for another queue) or reusing work_struct
> > is not permitted from inside called work function ?
> >
> > (Note comment in code "It is
Alasdair G Kergon wrote:
>
> - But what happens if kcryptd_crypt_write_convert_loop() calls
> INIT_WORK/queue_work twice?
Can't find this function. But "INIT_WORK + queue_work" twice is very
wrong of course.
Milan Broz wrote:
>
> Ok, then I have question: Is the following pseudocode correct
>
On Wed, 21 Nov 2007, Rafael J. Wysocki wrote:
> > Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
>
> No. In that case the suspend core is holding the device's mutex and your
> attempt to unregister it will deadlock with it.
>
> Do you _have_ _to_ unregister the device at
On Wed, 21 Nov 2007, Rafael J. Wysocki wrote:
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
No. In that case the suspend core is holding the device's mutex and your
attempt to unregister it will deadlock with it.
Do you _have_ _to_ unregister the device at all? Why
Alasdair G Kergon wrote:
- But what happens if kcryptd_crypt_write_convert_loop() calls
INIT_WORK/queue_work twice?
Can't find this function. But INIT_WORK + queue_work twice is very
wrong of course.
Milan Broz wrote:
Ok, then I have question: Is the following pseudocode correct
(and
Hi,
Ok, then I have question: Is the following pseudocode correct
(and problem is in lock validation which checks something
already initialized for another queue) or reusing work_struct
is not permitted from inside called work function ?
(Note comment in code It is permissible to free
On Wednesday, 21 of November 2007, Alan Stern wrote:
On Wed, 21 Nov 2007, Rafael J. Wysocki wrote:
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?
No. In that case the suspend core is holding the device's mutex and your
attempt to unregister it will deadlock with
On Nov 20, 2007 5:59 PM, Dave Young <[EMAIL PROTECTED]> wrote:
>
> On Nov 20, 2007 5:56 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > > I encountered kernel warningsr. I just executed xawtv without
On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
> Hi all:
>
> * Alan Stern <[EMAIL PROTECTED]> [2007-11-19 15:27:14 -0500]:
> > On Mon, 19 Nov 2007, Rudolf Marek wrote:
> >
> > > Hello all,
> > > >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> > > >>>
On Tue, Nov 20, 2007 at 03:40:30PM +0100, Milan Broz wrote:
> (Note comment in code "It is permissible to free the struct
> work_struct from inside the function that is called from it".)
I don't understand yet how lockdep behaves if the work struct gets
reused and the reused one finishes first.
Torsten Kaiser wrote:
> 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,
Hi all:
* Alan Stern <[EMAIL PROTECTED]> [2007-11-19 15:27:14 -0500]:
> On Mon, 19 Nov 2007, Rudolf Marek wrote:
>
> > Hello all,
> > >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> > >>> platform_device_unregister, so coretemp seems to be what I have and you
> > >>> don't.
> > >
_kernel_oplock: Error
>>>> when removing kernel oplock on file p0/d3XXX
>>>> /deX/d3cX/d6eXXX/f8d,
>>>> dev = 807, inode = 30983, file
>>>> _id = 501. Error
On Nov 20, 2007 5:56 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> > I encountered kernel warningsr. I just executed xawtv without video dev
> > being found.
> >
> > like this:
> >
> > WARNING: at
On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young <[EMAIL PROTECTED]> wrote:
> Hi,
> I encountered kernel warningsr. I just executed xawtv without video dev being
> found.
>
> like this:
>
> WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask()
> []
: 2.6.24-rc2-mm1
# Tue Nov 20 17:24:16 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86
XXX/deX/d3cX/d6eXXX/f8d,
> >> dev = 807, inode = 30983, file
> >> _id = 501. Error w
> >> Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0]
> >> lib/util_sock.c:write_data(562)
> >&g
b/util_sock.c:write_data(562)
>> Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to
>> client 9.124.111.212. Error Connection reset by peer
>>
>
> So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing
> with the above message
d6eXXX/f8d,
> dev = 807, inode = 30983, file
> _id = 501. Error w
> Nov 19 18:48:04 p55lp6 smbd[3650]: [2007/11/19 18:48:04, 0]
> lib/util_sock.c:write_data(562)
> Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to
> client 9.124.111.212. Error C
Hi Andrew,
Following calltrace is seen server, while running filesystem stress on smb
mounted partition on the client machine.
Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0]
lib/util_sock.c:write_data(562)
Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing
18:48:04, 0]
lib/util_sock.c:write_data(562)
Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to
client 9.124.111.212. Error Connection reset by peer
So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing
with the above messages
smbd[3650]: [2007/11/19 18:48:04, 0]
lib/util_sock.c:write_data(562)
Nov 19 18:48:04 p55lp6 smbd[3650]: write_data: write failure in writing to
client 9.124.111.212. Error Connection reset by peer
So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing
with the above
by peer
So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing
with the above messages?
Hi Andrew,
Yes, the above messages are seen with the 2.6.24-rc2-mm1 kernel.
Oh. Well I don't know where to start looking for that one.
Maybe someone fixed it amongst all the things
On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young [EMAIL PROTECTED] wrote:
Hi,
I encountered kernel warningsr. I just executed xawtv without video dev being
found.
like this:
WARNING: at arch/x86/kernel/smp_32.c:561 native_smp_call_function_mask()
[c0118769]
Connection reset by peer
So you have samba running on a 2.6.24-rc2-mm1 machine and samba is failing
with the above messages?
Hi Andrew,
Yes, the above messages are seen with the 2.6.24-rc2-mm1 kernel.
Oh. Well I don't know where to start looking for that one.
Maybe someone fixed
Hi Andrew,
Following calltrace is seen server, while running filesystem stress on smb
mounted partition on the client machine.
Nov 19 18:45:52 p55lp6 smbd[3304]: [2007/11/19 18:45:52, 0]
lib/util_sock.c:write_data(562)
Nov 19 18:45:52 p55lp6 smbd[3304]: write_data: write failure in writing
[c01042da] syscall_call+0x7/0xb
[c040] xfrm_notify_sa+0x110/0x290
===
config files :
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2-mm1
# Tue Nov 20 17:24:16 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
On Nov 20, 2007 5:56 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young [EMAIL PROTECTED] wrote:
Hi,
I encountered kernel warningsr. I just executed xawtv without video dev
being found.
like this:
WARNING: at arch/x86/kernel/smp_32.c:561
Hi all:
* Alan Stern [EMAIL PROTECTED] [2007-11-19 15:27:14 -0500]:
On Mon, 19 Nov 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems to be what I have and you
don't.
Yes.
For the
Torsten Kaiser wrote:
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't
On Tue, Nov 20, 2007 at 03:40:30PM +0100, Milan Broz wrote:
(Note comment in code It is permissible to free the struct
work_struct from inside the function that is called from it.)
I don't understand yet how lockdep behaves if the work struct gets
reused and the reused one finishes first.
I
On Tuesday, 20 of November 2007, Mark M. Hoffman wrote:
Hi all:
* Alan Stern [EMAIL PROTECTED] [2007-11-19 15:27:14 -0500]:
On Mon, 19 Nov 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems
On Nov 20, 2007 5:59 PM, Dave Young [EMAIL PROTECTED] wrote:
On Nov 20, 2007 5:56 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 20 Nov 2007 17:47:28 +0800 Dave Young [EMAIL PROTECTED] wrote:
Hi,
I encountered kernel warningsr. I just executed xawtv without video dev
being
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't say if that
would
On Sun, 18 Nov 2007 14:18:06 -0500 Trond Myklebust <[EMAIL PROTECTED]> wrote:
> >
> > Torsten
>
> I had already fixed that one in my own stack. Attached are the 3 patches
> that I've got. 1 from SteveD, 2 fixes.
>
> Andrew, could you please unapply the sillyrename patches you've got, and
>
On Sun, 18 Nov 2007, root wrote:
> @@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
> {
> struct page *page;
> struct kmem_cache_node *n;
> + unsigned long flags;
>
> BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
>
Well local_irq_save is
On Monday, 19 of November 2007, Rudolf Marek wrote:
> Hello all,
> >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> >>> platform_device_unregister, so coretemp seems to be what I have and you
> >>> don't.
> >
> > Yes.
> >
> > For the coretemp developers: coretemp_cpu_callback()
Torsten Kaiser wrote:
> On Nov 19, 2007 8:56 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
...
> Above this acquire/release sequence is the following comment:
> #ifdef CONFIG_LOCKDEP
> /*
> * It is permissible to free the
On Mon, 19 Nov 2007, Rudolf Marek wrote:
> Hello all,
> >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> >>> platform_device_unregister, so coretemp seems to be what I have and you
> >>> don't.
> >
> > Yes.
> >
> > For the coretemp developers: coretemp_cpu_callback() needs to be
Hello all,
gives coretemp_cpu_callback -> coretemp_device_remove ->
platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does. During a system sleep transition
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:
> > [ 64.550203]
> > [ 64.550205] =
> > [
a.dif lets my testcase work.
> > Also lockdep no longer complains about the non-static key.
>
> Thanks.
>
> To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1?
Umm... As I applied this changes manually there is a not insignificant
change of goofups on my part.
Attached are the 3 patches
> > that I've got. 1 from SteveD, 2 fixes.
> >
>
> Moving the init_waitqueue_head() like patch
> linux-2.6.24-006-fix_to_fix_sillyrename_bug_on_umount.dif and applying
> linux-2.6.24-007-fix_nfs_free_unlinkdata.dif lets my testcase work.
> Also lockdep no l
-007-fix_nfs_free_unlinkdata.dif lets my testcase work.
Also lockdep no longer complains about the non-static key.
Thanks.
To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
.
To avoid goofups, could you please send the full fix against 2.6.24-rc2-mm1?
Umm... As I applied this changes manually there is a not insignificant
change of goofups on my part...
For the hang problem I think Tronds suggestion with replacing the
patches from -mm with fresh versions would be the best
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:
[ 64.550203]
[ 64.550205] =
[ 64.552213] [ BUG:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems to be what I have and you don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does. During a system sleep transition (suspend,
On Mon, 19 Nov 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems to be what I have and you
don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about
Torsten Kaiser wrote:
On Nov 19, 2007 8:56 AM, Ingo Molnar [EMAIL PROTECTED] wrote:
* Torsten Kaiser [EMAIL PROTECTED] wrote:
...
Above this acquire/release sequence is the following comment:
#ifdef CONFIG_LOCKDEP
/*
* It is permissible to free the struct
On Monday, 19 of November 2007, Rudolf Marek wrote:
Hello all,
gives coretemp_cpu_callback - coretemp_device_remove -
platform_device_unregister, so coretemp seems to be what I have and you
don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
On Sun, 18 Nov 2007, root wrote:
@@ -2155,6 +2155,7 @@ static struct kmem_cache_node *early_kme
{
struct page *page;
struct kmem_cache_node *n;
+ unsigned long flags;
BUG_ON(kmalloc_caches-size sizeof(struct kmem_cache_node));
Well local_irq_save is a bit of
On Sun, 18 Nov 2007 14:18:06 -0500 Trond Myklebust [EMAIL PROTECTED] wrote:
Torsten
I had already fixed that one in my own stack. Attached are the 3 patches
that I've got. 1 from SteveD, 2 fixes.
Andrew, could you please unapply the sillyrename patches you've got, and
apply these 3
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't say if that
would yield
* 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:
> [ 64.550203]
> [ 64.550205] =
> [ 64.552213] [ BUG: held lock freed! ]
> [ 64.553633] -
1
tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
v4l1_compat hid pata_amd sg
[ 108.665913] Pid: 8715, comm: reboot Not tainted 2.6.24-rc2-mm1 #14
[ 108.672103] RIP: 0010:[<0a6425203a72>] [<0a6425203a72>
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_server()!
> >
> > I wonder why
From: Kamalesh Babulal <[EMAIL PROTECTED]>
The kernel builds fails with following error, with randconfig
CC arch/powerpc/mm/stab.o
arch/powerpc/mm/stab.c: In function ‘stab_initialize’:
arch/powerpc/mm/stab.c:282: error: implicit declaration of function ‘HvCall1’
Hi Stephen,
Resubmitting the patch titled
powerpc-iseries-build-failure-mm-stabc.patch in the -mm tree.
Signed-off-by: Kamalesh Babulal <[EMAIL PROTECTED]>
--
--- linux-2.6.24-rc2/arch/powerpc/mm/stab.c 2007-11-07 03:27:46.0
+0530
+++ linux-2.6.24-rc2/arch/powerpc/mm/~stab.c
On Sun, 18 Nov 2007, Jiri Slaby wrote:
> > gives coretemp_cpu_callback -> coretemp_device_remove ->
> > platform_device_unregister, so coretemp seems to be what I have and you
> > don't.
Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more
careful about what it does.
Hi Kamalesh,
On Wed, 14 Nov 2007 16:24:10 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> +#ifdef CONFIG_PPC_ISERIES
> +#include
> +#endif /* CONFIG_PPC_ISERIES */
You should not need the #ifdef and we prefer not to ifdef include unless
necessary. Please resubmit.
--
Cheers,
Stephen
Aah, we probably should let coretemp people known.
Whole thread:
http://marc.info/?t=11950720581=1=2
On 11/18/2007 08:09 PM, Jiri Slaby wrote:
> On 11/18/2007 06:07 PM, Alan Stern wrote:
>> You'll get more useful results if you redo your changes to
>> notifier_call_chain(). Have it print
On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote:
> > You can use a global variable to switch the logging only before the CPU
> > hotunplug done by the suspend code. You just need to hack
> > disable_nonboot_cpus() for that.
>
> If I understand
On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote:
> You can use a global variable to switch the logging only before the CPU
> hotunplug done by the suspend code. You just need to hack
> disable_nonboot_cpus() for that.
If I understand you correctly, that's what BUBAK variable is there for. But it
On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 06:07 PM, Alan Stern wrote:
> > You'll get more useful results if you redo your changes to
> > notifier_call_chain(). Have it print out the address of the routine
> > _before_ making the call, and don't limit it to 20. That way
On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
> 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
On 11/18/2007 06:07 PM, Alan Stern wrote:
> You'll get more useful results if you redo your changes to
> notifier_call_chain(). Have it print out the address of the routine
> _before_ making the call, and don't limit it to 20. That way you'll
> know exactly which notifier routine ends up
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
On Sun, 18 Nov 2007, Jiri Slaby wrote:
> On 11/18/2007 04:23 PM, RafaÅ J. Wysocki wrote:
> > On Sunday, 18 of November 2007, Jiri Slaby wrote:
> >> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
> >>> Can you also make the new System-map available, please?
> >> Sure:
> >>
On 11/18/2007 04:23 PM, Rafał J. Wysocki wrote:
> On Sunday, 18 of November 2007, Jiri Slaby wrote:
>> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
>>> Can you also make the new System-map available, please?
>> Sure:
>> http://www.fi.muni.cz/~xslaby/sklad/System.map1
>
> The last notifier
On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
> > Can you also make the new System-map available, please?
>
> Sure:
> http://www.fi.muni.cz/~xslaby/sklad/System.map1
The last notifier called in
On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
> Can you also make the new System-map available, please?
Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote:
> > On Sunday, 18 of November 2007, Jiri Slaby wrote:
> >> On 11/18/2007 01:42 PM, Jiri Slaby wrote:
> >>> See shot of prints here:
> >>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
> >> BTW
b usb5: suspend_rh (auto-stop)
After this all output stops.
I'm not subscribed to the list, so please CC me.
If I had made any mistakes with this report, please tell me.
Thank you.
Karol Swietlicki
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2-mm1
# Sun Nov 18 13
On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote:
> On Sunday, 18 of November 2007, Jiri Slaby wrote:
>> On 11/18/2007 01:42 PM, Jiri Slaby wrote:
>>> See shot of prints here:
>>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
>> BTW output from that tree minus the patch:
>
> Hm, it looks like
On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 01:42 PM, Jiri Slaby wrote:
> > See shot of prints here:
> > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
>
> BTW output from that tree minus the patch:
Hm, it looks like one of the CPU hotplug notifiers is doing something
On 11/18/2007 01:42 PM, Jiri Slaby wrote:
> See shot of prints here:
> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
BTW output from that tree minus the patch:
_cpu_down: s
_cpu_down: t
CPU 1 is now offline
SMP alternatives: switching to UP code
_cpu_down: u
notifier_call_chain: c
Alan Stern napsal(a):
> On Sat, 17 Nov 2007, Rafael J. Wysocki wrote:
>> On Saturday, 17 of November 2007, Jiri Slaby wrote:
>>> On 11/16/2007 05:10 PM, Alan Stern wrote:
The thing to do is figure out which driver is causing the problem.
Jiri, try enabling CONFIG_DEBUG_DRIVER.
>>>
1 - 100 of 402 matches
Mail list logo
