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 *early_kmem_cache_node_alloc(gfp
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 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 wi
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
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 uns
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
t
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_LOCK
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-thre
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 deadlo
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 permiss
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 all?
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 vid
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_unregi
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.
> > >
lease_kernel_oplock: Error
>>>> when removing kernel oplock on file p0/d3XXX
>>>> XXXX/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 arch/x86/kern
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()
> [] native_smp_call_function_mask
rsion: 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
CONFI
/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)
> &
t; 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 me
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)
> 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 to
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 yi
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
> appl
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
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() nee
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 m
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 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.
nkdata.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
n my own stack. 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.
&g
* 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] -
>
ple mt20xx tea5761
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>] [<0
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 t
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’
arch/powerpc/mm/stab.c:282
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.c2007
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. Dur
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 Rot
Aah, we probably should let coretemp people known.
Whole thread:
http://marc.info/?t=11950720581&r=1&w=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 prin
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 y
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 y
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 corrup
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 hangi
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 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:
> >> http://www.fi.muni.cz/
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 call
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 http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.p
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 in
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
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 wr
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 802
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.
>>> Sadly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
> However, I got around the problem by making the code change manually -
> and my network connection is now working. Looking at the code being
> bypassed:
>
> if (pE.cap[i] || pP.cap[i] || pP.cap[i])
>
> looks somewhat we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
> Kevin,
>
> Can you try this quick hack?
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index e57d1aa..4088610 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,7 +109,7 @@ out:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Winchester wrote:
> Looking at the code being bypassed:
>
> if (pE.cap[i] || pP.cap[i] || pP.cap[i])
>
> looks somewhat weird as it is testing the same condition twice. Should
> it have been:
>
> if (pE.cap[i] || pP.cap[i] || pI.cap[i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew Morgan wrote:
> Kevin,
>
> Can you try this quick hack?
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index e57d1aa..4088610 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,7 +109,7 @@ out:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin,
Can you try this quick hack?
diff --git a/kernel/capability.c b/kernel/capability.c
index e57d1aa..4088610 100644
- --- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -109,7 +109,7 @@ out:
kdata[i].permitted = pP.ca
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] INFO: trying to register non-static key.
> > [
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] INFO: trying to register non-static key.
> [ 221.566999] the code is fine but needs lockdep annotation.
> [ 221.569206] turni
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] -
> > [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W}
t;>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> > >>>
> > >>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing
> > >>> new when
> > >>> the patch is applied.
> > >> Thanks for tracking
On Saturday, 17 of November 2007, Jiri Slaby wrote:
> On 11/16/2007 05:10 PM, Alan Stern wrote:
> > On Thu, 15 Nov 2007, Greg KH wrote:
> >
> >>> The offending -mm patch is
> >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> >>
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 for me, as it gets turned off early:
> > > [ 39.851594] -
On Sat, 17 Nov 2007, Andrew Morton wrote:
> > Don't know who to bug about that.
>
> 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 that was only run during
NUMA bootstrap
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 enters the xmon state while running the file system
> > >
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 enters the xmon state while running the file system
> > stress on nfs v4 mounted partition.
> [snip]
> > 0:mon> t
> > [c000dbd4fb50]
On Sat, 17 Nov 2007 19:09:46 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
>
> > Sadly lockdep does not work for me, as it gets turned off early:
> > [ 39.851594] -
> > [ 39.855963] inconsistent {softirq-on-W} ->
* Torsten Kaiser <[EMAIL PROTECTED]> wrote:
> Sadly lockdep does not work for me, as it gets turned off early:
> [ 39.851594] -
> [ 39.855963] inconsistent {softirq-on-W} -> {in-softirq-W} usage.
> [ 39.861981] swapper/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
> [ 3
drm nfsd exportfs ipv6
> w83792d tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx
> tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
> videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
> v4l1_compat hid sg i2c_nforce2 pata_amd
> [ 966.7
m videodev usbhid v4l2_common
v4l1_compat hid sg i2c_nforce2 pata_amd
[ 966.748306] Pid: 605, comm: rpciod/3 Not tainted 2.6.24-rc2-mm1 #4
[ 966.754653] RIP: 0010:[] []
_spin_lock_irqsave+0x12/0x30
[ 966.763424] RSP: 0018:81007ef33e28 EFLAGS: 0286
[ 966.768879] RAX: 0286 RBX:
On Sat, 17 Nov 2007, Jiri Slaby wrote:
> > The thing to do is figure out which driver is causing the problem.
> > Jiri, try enabling CONFIG_DEBUG_DRIVER.
>
> Sadly no output.
Guess I'll have to try running 2.6.24-rc2-mm1 on my own system. In the
meantime, you can
On 11/17/2007 04:08 PM, Jiri Slaby wrote:
> On 11/16/2007 05:10 PM, Alan Stern wrote:
>> If there's also a config
>> option to prevent the console from being suspended, set it as well.
>
> no_suspend_console kernel parameter has no effect (why?).
Eh, no, this (/proc/cmdline):
ro root=/dev/md1
On 11/16/2007 05:10 PM, Alan Stern wrote:
> On Thu, 15 Nov 2007, Greg KH wrote:
>
>>> The offending -mm patch is
>>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
>>>
>>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows noth
On Fri, Nov 16, 2007 at 09:16:58PM -0800, Andrew Morgan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> This warning is just saying that you might want to reconsider
> recompiling your dhclient with a newer libcap - which has native support
> for 64-bit capabilities. This is
On November 17, 2007 01:16:58 am Andrew Morgan wrote:
> Hi,
>
> This warning is just saying that you might want to reconsider
> recompiling your dhclient with a newer libcap - which has native support
> for 64-bit capabilities. This is supposed to be informative, and not be
> associated with any pa
20:28:29 -0400
> Kevin Winchester <[EMAIL PROTECTED]> wrote:
>
>> On November 15, 2007 06:02:09 am Andy Whitcroft wrote:
>>> When testing some of the later 2.6.24-rc2-mm1+hotfix combinations on three
>>> of our test systems one job from each batch (1/4) failed.
_simple mt20xx
tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg
videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common
v4l1_compat hid sg i2c_nforce2 pata_amd
[ 944.175225] Pid: 605, comm: rpciod/3 Not tainted 2.6.24-rc2-mm1 #4
[ 944.181573] RIP: 0010:[] []
_spin_lock_irq
On Thu, 15 Nov 2007, Greg KH wrote:
> > The offending -mm patch is
> > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> >
> > 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new
> > when
> > the patch is applied.
>
Hi Andrew,
The kernel enters the xmon state while running the file system
stress on nfs v4 mounted partition.
0:mon> e
cpu 0x0: Vector: 300 (Data Access) at [c000dbd4f820]
pc: c0065be4: .__wake_up_common+0x44/0xe8
lr: c0069768: .__wake_up+0x54/0x88
sp: c000dbd
On Thu, Nov 15, Torsten Kaiser wrote:
> While the next bisect proved that these patches are innocent, I'm
> still blaming you for my problems. ;)
:(
> 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
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-bind-mounts-elevate-write-count-over-calls-to-vfs_renam
On Thu, 15 Nov 2007 16:59:35 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c
> > ===
> > --- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c
> > +++
On Thu, 15 Nov 2007 16:53:30 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - return __alloc_bootmem_node(NODE_DATA(node), size, size,
> > + return __earlyonly_bootmem_alloc(node, size, size,
> > __pa(MAX_DMA_ADDRESS));
> > }
> >
>
> AFACIT th
unsubscribe linux-kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 15 Nov 2007 21:01:32 -0400
Kevin Winchester <[EMAIL PROTECTED]> wrote:
> On November 15, 2007 08:44:41 pm Andrew Morton wrote:
> > On Thu, 15 Nov 2007 20:28:29 -0400
> >
> > Kevin Winchester <[EMAIL PROTECTED]> wrote:
> > > On November 15, 2007 06:02:09 am Andy Whitcroft wrote:
>
> > > I
On November 15, 2007 08:44:41 pm Andrew Morton wrote:
> On Thu, 15 Nov 2007 20:28:29 -0400
>
> Kevin Winchester <[EMAIL PROTECTED]> wrote:
> > On November 15, 2007 06:02:09 am Andy Whitcroft wrote:
> > I see this as well - the computer boots fine but no network. The only
> > clues in the dmesg ar
7;arch_add_memory')
> ==
>
> Changelog:
> * changes __init_refok from find_early_table_space() to
>init_memory_mapping().
>
> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
>
> arch/x86/mm/init_64.c |2 +-
> 1 file changed, 1 in
On Nov 16, 2007 8:49 AM, Greg KH <[EMAIL PROTECTED]> wrote:
>
> On Fri, Nov 16, 2007 at 08:39:12AM +0800, Dave Young wrote:
> > On Nov 16, 2007 3:23 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Nov 14, 2007 at 10:19:48AM -0800, Greg KH wrote:
> > > > On Wed, Nov 14, 2007 at 06:02:07PM
On Fri, Nov 16, 2007 at 08:39:12AM +0800, Dave Young wrote:
> On Nov 16, 2007 3:23 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Nov 14, 2007 at 10:19:48AM -0800, Greg KH wrote:
> > > On Wed, Nov 14, 2007 at 06:02:07PM +0100, Jiri Kosina wrote:
> > > > On Wed, 14 Nov 2007, Jiri Kosina wrot
1 - 100 of 201 matches
Mail list logo
