Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! > > I should take some sleep now, so I can't test the patch, but I don't > > think it will help. If someone has PF_FREEZE set, he should be in > > refrigerator. > > OK, so if that doesn't help, here's an alternate approach - this > lets xfsbufd track when its entering the refrigerator(), so that > other callers know that attempts to wake it are futile. Thanks, this patch helped. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi, On Tuesday, 12 of April 2005 01:51, Pavel Machek wrote: ]--snip--[ > > Since the refrigerator() call is in place in the main xfsbufd loop, > > I suspect we're hitting that second case here, where a low memory > > situation is resulting in someone attempting to wakeup xfsbufd -- > > I'm not sure if this is the right way to check if we're in that > > state, but does this patch help? (it would certainly prevent the > > spurious wakeups, but only if the caller has PF_FREEZE set - will > > that be the case here?) > > I should take some sleep now, so I can't test the patch, but I don't > think it will help. If someone has PF_FREEZE set, he should be in > refrigerator. Or he was in TASK_UNINTERRUPTIBLE while processes were being frozen. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:04:25PM +0200, Pavel Machek wrote: > > OK, so if that doesn't help, here's an alternate approach - this > > lets xfsbufd track when its entering the refrigerator(), so that > > other callers know that attempts to wake it are futile. > > Thanks, this patch helped. I can confirm, the 2nd patch worked and the 1st one didn't. (This is against 2.6.12-rc2-mm1 with sched-x86-patch-name-is-way-too-long.patch backed out. ;) ) -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi, On Tuesday, 12 of April 2005 01:51, Pavel Machek wrote: ]--snip--[ Since the refrigerator() call is in place in the main xfsbufd loop, I suspect we're hitting that second case here, where a low memory situation is resulting in someone attempting to wakeup xfsbufd -- I'm not sure if this is the right way to check if we're in that state, but does this patch help? (it would certainly prevent the spurious wakeups, but only if the caller has PF_FREEZE set - will that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Or he was in TASK_UNINTERRUPTIBLE while processes were being frozen. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. OK, so if that doesn't help, here's an alternate approach - this lets xfsbufd track when its entering the refrigerator(), so that other callers know that attempts to wake it are futile. Thanks, this patch helped. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
> I should take some sleep now, so I can't test the patch, but I don't
> think it will help. If someone has PF_FREEZE set, he should be in
> refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track when its entering the refrigerator(), so that
other callers know that attempts to wake it are futile.
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 10:14:27.468202824 +1000
@@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon
STATIC struct task_struct *pagebuf_daemon_task;
STATIC int pagebuf_daemon_active;
STATIC int force_flush;
-
+STATIC int force_sleep;
STATIC int
pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (force_sleep)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
@@ -1778,7 +1780,12 @@ pagebuf_daemon(
INIT_LIST_HEAD();
do {
- try_to_freeze(PF_FREEZE);
+ if (unlikely(current->flags & PF_FREEZE)) {
+ force_sleep = 1;
+ refrigerator(PF_FREEZE);
+ } else {
+ force_sleep = 0;
+ }
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100);
-
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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! > > > > > No, XFS is my root filesystem. :( (Now that I think about it, would > > > > > modularizing XFS and using an initrd be OK?) > > > > > > > > Yes, loading xfs from initrd should help. [At least it did during > > > > suse9.3 testing.] > > > > > > Once I modularized xfs and switched to using an initrd, the problem > > > disappeared. > > > > I reproduced it locally. Problem is that xfsbufd goes refrigerated, > > but someone still tries to wake it up *very* often. Probably something > > else in xfs needs refrigerating, too, but I'm not a XFS wizard... > > Thanks Pavel - I've been reading the thread from the other side > of the fence, not understanding the swsusp side of things. :) > > There are two ways the xfsbufd thread will wake up - either by its > timer going off (for it to flush delayed write metadata buffers) > or by being explicitly woken up when we're low on memory (in which > case it also flushes out dirty metadata, such that pages can be > cleaned and made available to the system). > > Since the refrigerator() call is in place in the main xfsbufd loop, > I suspect we're hitting that second case here, where a low memory > situation is resulting in someone attempting to wakeup xfsbufd -- > I'm not sure if this is the right way to check if we're in that > state, but does this patch help? (it would certainly prevent the > spurious wakeups, but only if the caller has PF_FREEZE set - will > that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > modularizing XFS and using an initrd be OK?)
> > >
> > > Yes, loading xfs from initrd should help. [At least it did during
> > > suse9.3 testing.]
> >
> > Once I modularized xfs and switched to using an initrd, the problem
> > disappeared.
>
> I reproduced it locally. Problem is that xfsbufd goes refrigerated,
> but someone still tries to wake it up *very* often. Probably something
> else in xfs needs refrigerating, too, but I'm not a XFS wizard...
Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)
There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).
Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help? (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (current->flags & PF_FREEZE)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
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/
swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! > > > No, XFS is my root filesystem. :( (Now that I think about it, would > > > modularizing XFS and using an initrd be OK?) > > > > Yes, loading xfs from initrd should help. [At least it did during > > suse9.3 testing.] > > Once I modularized xfs and switched to using an initrd, the problem > disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
Barry K. Nathan wrote: > On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: >> Can you try without XFS? > > No, XFS is my root filesystem. :( (Now that I think about it, would > modularizing XFS and using an initrd be OK?) Yes, although it is not totally trivial. > I'll see if I can reproduce this on one of my test boxes. I'll *try* to > get to it later today, but it's possible that I won't be able to get to > it until next Friday or Saturday. > >> I do not why it interferes, but I've seen that before on suse >> kernels... > > Have you seen it without the resume-from-initrd patch too, or only with > that patch? We have seen it in 9.3-beta, exact scenario was: - root fs is XFS, ide driver is modular => xfs module and ide-controller module is in initramfs => first all modules were loaded (device driver + fs) => resume was triggered, resume was _really_ slow. we worked around it in the initramfs by first loading device drivers, triggering resume, then loading the fs modules and continuing boot. In the resume case, we'd never reach the "load fs modules" part and generally it seems a good idea (if the drivers are modular) to keep the setup before resume as minimalistic as possible. We never tried with XFS compiled in. It seems we can no longer hide from fixing XFS ;-) Best regards, Stefan - 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/
Re: 2.6.12-rc2-mm1
Barry K. Nathan wrote: On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, although it is not totally trivial. I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. I do not why it interferes, but I've seen that before on suse kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? We have seen it in 9.3-beta, exact scenario was: - root fs is XFS, ide driver is modular = xfs module and ide-controller module is in initramfs = first all modules were loaded (device driver + fs) = resume was triggered, resume was _really_ slow. we worked around it in the initramfs by first loading device drivers, triggering resume, then loading the fs modules and continuing boot. In the resume case, we'd never reach the load fs modules part and generally it seems a good idea (if the drivers are modular) to keep the setup before resume as minimalistic as possible. We never tried with XFS compiled in. It seems we can no longer hide from fixing XFS ;-) Best regards, Stefan - 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/
swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
Hi!
No, XFS is my root filesystem. :( (Now that I think about it, would
modularizing XFS and using an initrd be OK?)
Yes, loading xfs from initrd should help. [At least it did during
suse9.3 testing.]
Once I modularized xfs and switched to using an initrd, the problem
disappeared.
I reproduced it locally. Problem is that xfsbufd goes refrigerated,
but someone still tries to wake it up *very* often. Probably something
else in xfs needs refrigerating, too, but I'm not a XFS wizard...
Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)
There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).
Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help? (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (current-flags PF_FREEZE)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Thanks Pavel - I've been reading the thread from the other side of the fence, not understanding the swsusp side of things. :) There are two ways the xfsbufd thread will wake up - either by its timer going off (for it to flush delayed write metadata buffers) or by being explicitly woken up when we're low on memory (in which case it also flushes out dirty metadata, such that pages can be cleaned and made available to the system). Since the refrigerator() call is in place in the main xfsbufd loop, I suspect we're hitting that second case here, where a low memory situation is resulting in someone attempting to wakeup xfsbufd -- I'm not sure if this is the right way to check if we're in that state, but does this patch help? (it would certainly prevent the spurious wakeups, but only if the caller has PF_FREEZE set - will that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
I should take some sleep now, so I can't test the patch, but I don't
think it will help. If someone has PF_FREEZE set, he should be in
refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track when its entering the refrigerator(), so that
other callers know that attempts to wake it are futile.
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 10:14:27.468202824 +1000
@@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon
STATIC struct task_struct *pagebuf_daemon_task;
STATIC int pagebuf_daemon_active;
STATIC int force_flush;
-
+STATIC int force_sleep;
STATIC int
pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (force_sleep)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
@@ -1778,7 +1780,12 @@ pagebuf_daemon(
INIT_LIST_HEAD(tmp);
do {
- try_to_freeze(PF_FREEZE);
+ if (unlikely(current-flags PF_FREEZE)) {
+ force_sleep = 1;
+ refrigerator(PF_FREEZE);
+ } else {
+ force_sleep = 0;
+ }
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100);
-
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/
Re: 2.6.12-rc2-mm1
On Mon, Apr 11, 2005 at 01:00:53AM +0200, Pavel Machek wrote: > > No, XFS is my root filesystem. :( (Now that I think about it, would > > modularizing XFS and using an initrd be OK?) > > Yes, loading xfs from initrd should help. [At least it did during > suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I just noticed a difference between the kernel messages with XFS built-in and with it modularized. I'm having trouble putting my finger on it; it seems like the screen gets cleared at some point during resume, and with XFS built-in, it starts reading the data from swap *after* the screen gets cleared. In contrast, if the enable-initrd patch is removed or XFS is modularized, it reads in from swap *before* the screen gets cleared. Or something like that. I'll see if I can get anything more detailed & useful with a serial console... Failing that, I'll try a camcorder or digital camera and transcribe from that. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
Hi! > > Can you try without XFS? > > No, XFS is my root filesystem. :( (Now that I think about it, would > modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] > I'll see if I can reproduce this on one of my test boxes. I'll *try* to > get to it later today, but it's possible that I won't be able to get to > it until next Friday or Saturday. > > > I do not why it interferes, but I've seen that before on suse > > kernels... > > Have you seen it without the resume-from-initrd patch too, or only with > that patch? Only with resume-from-initrd. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: > Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. > I do not why it interferes, but I've seen that before on suse > kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
Hi! > (Sorry I took so long to respond. I was busy with tons of stuff > offline...) > > On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: > > Do you have XFS compiled in, by chance? > > Yes. Can you try without XFS? I do not why it interferes, but I've seen that before on suse kernels... Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
(Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: > Do you have XFS compiled in, by chance? Yes. > You are not actually resuming from initrd, right? That is correct. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
(Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: Do you have XFS compiled in, by chance? Yes. You are not actually resuming from initrd, right? That is correct. -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1
Hi! (Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: Do you have XFS compiled in, by chance? Yes. Can you try without XFS? I do not why it interferes, but I've seen that before on suse kernels... Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. I do not why it interferes, but I've seen that before on suse kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1
Hi! Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. I do not why it interferes, but I've seen that before on suse kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? Only with resume-from-initrd. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
On Mon, Apr 11, 2005 at 01:00:53AM +0200, Pavel Machek wrote: No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I just noticed a difference between the kernel messages with XFS built-in and with it modularized. I'm having trouble putting my finger on it; it seems like the screen gets cleared at some point during resume, and with XFS built-in, it starts reading the data from swap *after* the screen gets cleared. In contrast, if the enable-initrd patch is removed or XFS is modularized, it reads in from swap *before* the screen gets cleared. Or something like that. I'll see if I can get anything more detailed useful with a serial console... Failing that, I'll try a camcorder or digital camera and transcribe from that. -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1
Hi! > > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the > > > problem goes away if I remove this patch: > > > swsusp-enable-resume-from-initrd.patch > > > > That really helps, thanks. > > You're welcome. > > > The patch looks fairly innocent. I'll give up on this and cc the > > developers. > > Yeah, it *seemed* innocent enough -- that's why I had to do a binary > search on the 2.6.11-mm3 "series" file in order to find it as the > culprit... Do you have XFS compiled in, by chance? You are not actually resuming from initrd, right? Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
Hi! Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch That really helps, thanks. You're welcome. The patch looks fairly innocent. I'll give up on this and cc the developers. Yeah, it *seemed* innocent enough -- that's why I had to do a binary search on the 2.6.11-mm3 series file in order to find it as the culprit... Do you have XFS compiled in, by chance? You are not actually resuming from initrd, right? Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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/
Re: 2.6.12-rc2-mm1
On Thu, 2005-04-07 at 18:08 -0700, Siddha, Suresh B wrote: > On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: > > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped > > itself to death after 2 infinite loop tasks had been pinned to one > > of the CPUs. See how you go. > > Its goes well beyond the initial 7000 number I mentioned. Thanks. > OK, good thanks for testing that. I'll send it to Andrew. > One side-effect of this patch is: for example we have only two processes > running on a cpu and both are pinned to that cpu. If someone comes and > changes the affinity of one of these processes to all cpu's in the system, > then it might take MAX_PINNED_INTERVAL before this process moves to an idle > cpu. > Yeah, that is true. OTOH it is a bit of a special case, and our multiprocessor scheduling in general practically shuts down when we have a situation with a single queue with a lot of pinned tasks. What did I have for MAX_PINNED_INTERVAL? ~1second. I guess that could come down a bit - maybe 1/4 or 1/2 a second? I think it is a "good enough for now" kind of situation. -- SUSE Labs, Novell Inc. - 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/
Re: 2.6.12-rc2-mm1
On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped > itself to death after 2 infinite loop tasks had been pinned to one > of the CPUs. See how you go. Its goes well beyond the initial 7000 number I mentioned. Thanks. One side-effect of this patch is: for example we have only two processes running on a cpu and both are pinned to that cpu. If someone comes and changes the affinity of one of these processes to all cpu's in the system, then it might take MAX_PINNED_INTERVAL before this process moves to an idle cpu. thanks, suresh - 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/
Re: 2.6.12-rc2-mm1: ieee1394 process hang
On Thu, Apr 07, 2005 at 01:58:45AM -0700, Andrew Morton wrote: > > I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my > > Apple iSight camera, it is not detected; repeated > > connections/disconnections don't help. When I tried to rmmod all the > > appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the > > rmmod command hung. Alt-Sysreq-t shows this: > > I don't think there have been any 1394 changes recently. This bug might be > more fallout from Pat's recent changes. > > More attempts have been made to fix that stuff up. Maybe you could try > http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.12-rc2-mm1.5.gz I'm not so sure, last week I had similar results with an external IEEE 1394 disk drive. On the first attempt it wasn't detected, in the 2nd and 3rd attempt detecting worked ok. After copying a data for like 2min the system paniced with no useful data in the log. Further attempts resulted in more hangs and panics. The kernel was the latest and greatest FC3 kernel, kernel-2.6.10-1.770_FC3. (I'm a 1h flight away from the system so can't do any more testing on that system) Ralf - 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/
Re: 2.6.12-rc2-mm1 - printk timing broken
Hi Andrew, Le Tuesday 05 April 2005 09:45, Andrew Morton a écrit : > Brice Goglin <[EMAIL PROTECTED]> wrote: > > Andrew Morton a écrit : > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6. > > >12-rc2/2.6.12-rc2-mm1/ > > > > Hi Andrew, > > > > printk timing seems broken. > > It always shows [ 0.00] on my Compaq Evo N600c. > > What sort of CPU does that thing have? Please share the /proc/cpuinfo > output. i can reproduce this "[ 0.00]"-bug with a Thinkpad A31p with a P4M: cpu family : 15 model : 2 model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz stepping: 7 cpu MHz : 1998.447 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid > Does reverting > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc >2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_h >pet-or-config_numa-systems.patch fix it? for me too - yes strange, because the cpu supports tsc as the flags indicate in the cpuinfo i posted. hopefully this mystery is no more, soon ;-) best regards, Damir -- Don't confuse things that need action with those that take care of themselves. pgpKOpBaYyukE.pgp Description: PGP signature
Re: 2.6.12-rc2-mm1: ieee1394 process hang
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > > I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my > Apple iSight camera, it is not detected; repeated > connections/disconnections don't help. When I tried to rmmod all the > appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the > rmmod command hung. Alt-Sysreq-t shows this: I don't think there have been any 1394 changes recently. This bug might be more fallout from Pat's recent changes. More attempts have been made to fix that stuff up. Maybe you could try http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.12-rc2-mm1.5.gz - 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/
Re: 2.6.12-rc2-mm1
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
>
> - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
> `nmi_watchdog=0' if you experience weird crashes.
>
> - The possible kernel-timer related hangs might possibly be fixed. We
> haven't heard yet.
>
> - Nobody said anything about the PM resume and DRI behaviour in
> 2.6.12-rc1-mm4. So it's all perfect now?
>
> - Various fixes and updates. Nothing earth-shattering.
>
Hi,
-> compiling 2.6.12-rc2-mm1 on amd64 :
arch/x86_64/kernel/nmi.c:116: error: static declaration of
'check_nmi_watchdog' follows non-static declaration
include/asm/apic.h:102: error: previous declaration of
'check_nmi_watchdog' was here
I guess the fix is easy enough :)
-> while I am it, I got a soft lookup on a bi-opteron using
2.6.12-rc1-mm4 (while stressing reiser4 with rsync so I guess it is
reiser4's fault ;)
config at
http://www-fourier.ujf-grenoble.fr/~mmarcha/config-2.6.12-rc1-mm4.gz
I also got some "flushing like mad" warning messages from reiser4 (which
are safe apparently).
BUG: soft lockup detected on CPU#0!
Modules linked in: ipv6 parport_pc parport eth1394 ehci_hcd uhci_hcd
ohci1394 ieee1394 ohci_hcd usbcore snd_intel8x0 snd_ac97_codec snd_pcm
snd_timer snd snd_page_alloc i2c_amd756 i2c_amd8111 i2c_isa w83781d
i2c_sensor i2c_core e1000
Pid: 25291, comm: pdflush Not tainted 2.6.12-rc1-mm4
RIP: 0010:[] {protect_extent_nodes+382}
RSP: 0018:81007df45678 EFLAGS: 0202
RAX: 810015c7c5e0 RBX: 81007c609000 RCX: 81001074ba60
RDX: 81001074b220 RSI: 81001074b1c0 RDI: 81001074b210
RBP: 0020 R08: 81007df458a0 R09: 810044068e14
R10: 001c R11: 802119a0 R12: 7fe07df455e0
R13: 81007c609004 R14: 81007df4565c R15: 7fe1
FS: 2adfeae0() GS:806e7840() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2aac2000 CR3: 9bc83000 CR4: 06e0
Call Trace:{protect_extent_nodes+378}
{extent_size+30}
{txnh_get_atom+41}
{alloc_extent+562}
{plugin_by_unsafe_id+28}
{item_length_by_coord+17}
{handle_pos_on_twig+351}
{flush_current_atom+2022}
{flush_some_atom+458}
{generic_sync_sb_inodes+723}
{keventd_create_kthread+0}
{reiser4_sync_inodes+229}
{writeback_inodes+137}
{background_writeout+124}
{pdflush+0} {pdflush+316}
{background_writeout+0}
{kthread+217}
{schedule_tail+64} {child_rip+8}
{keventd_create_kthread+0}
{kthread+0}
{child_rip+0}
Cheers,
Mik
-
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/
Re: 2.6.12-rc2-mm1
On Wed, Apr 06, 2005 at 08:06:14PM -0700, Barry K. Nathan wrote: > > > BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: > > > With that kernel, suspend is also ridiculously slow (speed is comparable > > > to the slow resume with the aforementioned patch). 2.6.11-rc2 does not > > > have that problem. > > > > Does reverting swsusp-enable-resume-from-initrd.patch fix this also? > > No. Reverting it from 2.6.12-rc2-mm1 (oops, I got the version number > wrong in my previous mail -- and that should also be 2.6.12-rc2 not > 2.6.11-rc2) speeds up resume to the original speed, but suspend is still > ridiculously slow. Time to narrow things down again, I presume... > > > > Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where > > > all the printk timestamps are 000.000 (don't take the # of > > > digits too literally). Probably unrelated, but I may as well mention it. > > > (System is an Athlon XP 2200+ with SiS chipset. I can't remember which > > > model of SiS chipset.) > > > > Yes, sorry. Reverting > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch > > will fix that one. Reverting sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch fixed both the printk timestamps and the slow suspend. And it also fixed a **major** interactivity problem (running kernel compiles made X almost unusably slow) which I discovered since sending the previous e-mail. So, something about this patch is seriously evil. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
On Wed, Apr 06, 2005 at 08:06:14PM -0700, Barry K. Nathan wrote: BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: With that kernel, suspend is also ridiculously slow (speed is comparable to the slow resume with the aforementioned patch). 2.6.11-rc2 does not have that problem. Does reverting swsusp-enable-resume-from-initrd.patch fix this also? No. Reverting it from 2.6.12-rc2-mm1 (oops, I got the version number wrong in my previous mail -- and that should also be 2.6.12-rc2 not 2.6.11-rc2) speeds up resume to the original speed, but suspend is still ridiculously slow. Time to narrow things down again, I presume... Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where all the printk timestamps are 000.000 (don't take the # of digits too literally). Probably unrelated, but I may as well mention it. (System is an Athlon XP 2200+ with SiS chipset. I can't remember which model of SiS chipset.) Yes, sorry. Reverting http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch will fix that one. Reverting sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch fixed both the printk timestamps and the slow suspend. And it also fixed a **major** interactivity problem (running kernel compiles made X almost unusably slow) which I discovered since sending the previous e-mail. So, something about this patch is seriously evil. -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/
- x86 NMI handling seems to be bust in 2.6.12-rc2. Try using
`nmi_watchdog=0' if you experience weird crashes.
- The possible kernel-timer related hangs might possibly be fixed. We
haven't heard yet.
- Nobody said anything about the PM resume and DRI behaviour in
2.6.12-rc1-mm4. So it's all perfect now?
- Various fixes and updates. Nothing earth-shattering.
Hi,
- compiling 2.6.12-rc2-mm1 on amd64 :
arch/x86_64/kernel/nmi.c:116: error: static declaration of
'check_nmi_watchdog' follows non-static declaration
include/asm/apic.h:102: error: previous declaration of
'check_nmi_watchdog' was here
I guess the fix is easy enough :)
- while I am it, I got a soft lookup on a bi-opteron using
2.6.12-rc1-mm4 (while stressing reiser4 with rsync so I guess it is
reiser4's fault ;)
config at
http://www-fourier.ujf-grenoble.fr/~mmarcha/config-2.6.12-rc1-mm4.gz
I also got some flushing like mad warning messages from reiser4 (which
are safe apparently).
BUG: soft lockup detected on CPU#0!
Modules linked in: ipv6 parport_pc parport eth1394 ehci_hcd uhci_hcd
ohci1394 ieee1394 ohci_hcd usbcore snd_intel8x0 snd_ac97_codec snd_pcm
snd_timer snd snd_page_alloc i2c_amd756 i2c_amd8111 i2c_isa w83781d
i2c_sensor i2c_core e1000
Pid: 25291, comm: pdflush Not tainted 2.6.12-rc1-mm4
RIP: 0010:[8021f7de] 8021f7de{protect_extent_nodes+382}
RSP: 0018:81007df45678 EFLAGS: 0202
RAX: 810015c7c5e0 RBX: 81007c609000 RCX: 81001074ba60
RDX: 81001074b220 RSI: 81001074b1c0 RDI: 81001074b210
RBP: 0020 R08: 81007df458a0 R09: 810044068e14
R10: 001c R11: 802119a0 R12: 7fe07df455e0
R13: 81007c609004 R14: 81007df4565c R15: 7fe1
FS: 2adfeae0() GS:806e7840() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2aac2000 CR3: 9bc83000 CR4: 06e0
Call Trace:8021f7da{protect_extent_nodes+378}
8021c00e{extent_size+30}
801f5df9{txnh_get_atom+41}
8021ffd2{alloc_extent+562}
8020a0bc{plugin_by_unsafe_id+28}
80220bd1{item_length_by_coord+17}
801f8a4f{handle_pos_on_twig+351}
801fabc6{flush_current_atom+2022}
801f7aca{flush_some_atom+458}
801a2993{generic_sync_sb_inodes+723}
8014cc50{keventd_create_kthread+0}
80203b85{reiser4_sync_inodes+229}
801a2bd9{writeback_inodes+137}
8016012c{background_writeout+124}
80160c10{pdflush+0} 80160d4c{pdflush+316}
801600b0{background_writeout+0}
8014cec9{kthread+217}
80133160{schedule_tail+64} 8010f59b{child_rip+8}
8014cc50{keventd_create_kthread+0}
8014cdf0{kthread+0}
8010f593{child_rip+0}
Cheers,
Mik
-
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/
Re: 2.6.12-rc2-mm1: ieee1394 process hang
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my Apple iSight camera, it is not detected; repeated connections/disconnections don't help. When I tried to rmmod all the appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the rmmod command hung. Alt-Sysreq-t shows this: I don't think there have been any 1394 changes recently. This bug might be more fallout from Pat's recent changes. More attempts have been made to fix that stuff up. Maybe you could try http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.12-rc2-mm1.5.gz - 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/
Re: 2.6.12-rc2-mm1 - printk timing broken
Hi Andrew, Le Tuesday 05 April 2005 09:45, Andrew Morton a écrit : Brice Goglin [EMAIL PROTECTED] wrote: Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6. 12-rc2/2.6.12-rc2-mm1/ Hi Andrew, printk timing seems broken. It always shows [ 0.00] on my Compaq Evo N600c. What sort of CPU does that thing have? Please share the /proc/cpuinfo output. i can reproduce this [ 0.00]-bug with a Thinkpad A31p with a P4M: cpu family : 15 model : 2 model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz stepping: 7 cpu MHz : 1998.447 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid Does reverting ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc 2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_h pet-or-config_numa-systems.patch fix it? for me too - yes strange, because the cpu supports tsc as the flags indicate in the cpuinfo i posted. hopefully this mystery is no more, soon ;-) best regards, Damir -- Don't confuse things that need action with those that take care of themselves. pgpKOpBaYyukE.pgp Description: PGP signature
Re: 2.6.12-rc2-mm1: ieee1394 process hang
On Thu, Apr 07, 2005 at 01:58:45AM -0700, Andrew Morton wrote: I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my Apple iSight camera, it is not detected; repeated connections/disconnections don't help. When I tried to rmmod all the appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the rmmod command hung. Alt-Sysreq-t shows this: I don't think there have been any 1394 changes recently. This bug might be more fallout from Pat's recent changes. More attempts have been made to fix that stuff up. Maybe you could try http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.12-rc2-mm1.5.gz I'm not so sure, last week I had similar results with an external IEEE 1394 disk drive. On the first attempt it wasn't detected, in the 2nd and 3rd attempt detecting worked ok. After copying a data for like 2min the system paniced with no useful data in the log. Further attempts resulted in more hangs and panics. The kernel was the latest and greatest FC3 kernel, kernel-2.6.10-1.770_FC3. (I'm a 1h flight away from the system so can't do any more testing on that system) Ralf - 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/
Re: 2.6.12-rc2-mm1
On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped itself to death after 2 infinite loop tasks had been pinned to one of the CPUs. See how you go. Its goes well beyond the initial 7000 number I mentioned. Thanks. One side-effect of this patch is: for example we have only two processes running on a cpu and both are pinned to that cpu. If someone comes and changes the affinity of one of these processes to all cpu's in the system, then it might take MAX_PINNED_INTERVAL before this process moves to an idle cpu. thanks, suresh - 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/
Re: 2.6.12-rc2-mm1
On Thu, 2005-04-07 at 18:08 -0700, Siddha, Suresh B wrote: On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped itself to death after 2 infinite loop tasks had been pinned to one of the CPUs. See how you go. Its goes well beyond the initial 7000 number I mentioned. Thanks. OK, good thanks for testing that. I'll send it to Andrew. One side-effect of this patch is: for example we have only two processes running on a cpu and both are pinned to that cpu. If someone comes and changes the affinity of one of these processes to all cpu's in the system, then it might take MAX_PINNED_INTERVAL before this process moves to an idle cpu. Yeah, that is true. OTOH it is a bit of a special case, and our multiprocessor scheduling in general practically shuts down when we have a situation with a single queue with a lot of pinned tasks. What did I have for MAX_PINNED_INTERVAL? ~1second. I guess that could come down a bit - maybe 1/4 or 1/2 a second? I think it is a good enough for now kind of situation. -- SUSE Labs, Novell Inc. - 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/
Re: 2.6.12-rc2-mm1
On Wed, Apr 06, 2005 at 02:27:49PM -0700, Andrew Morton wrote: > "Barry K. Nathan" <[EMAIL PROTECTED]> wrote: > > > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the > > problem goes away if I remove this patch: > > swsusp-enable-resume-from-initrd.patch > > That really helps, thanks. You're welcome. > The patch looks fairly innocent. I'll give up on this and cc the > developers. Yeah, it *seemed* innocent enough -- that's why I had to do a binary search on the 2.6.11-mm3 "series" file in order to find it as the culprit... > > (Recap of the problem in case this gets forwarded: Resume is almost > > instant without the apparently-guilty patch. With the patch, resume > > takes almost half an hour.) > > > > BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: > > With that kernel, suspend is also ridiculously slow (speed is comparable > > to the slow resume with the aforementioned patch). 2.6.11-rc2 does not > > have that problem. > > Does reverting swsusp-enable-resume-from-initrd.patch fix this also? No. Reverting it from 2.6.12-rc2-mm1 (oops, I got the version number wrong in my previous mail -- and that should also be 2.6.12-rc2 not 2.6.11-rc2) speeds up resume to the original speed, but suspend is still ridiculously slow. Time to narrow things down again, I presume... > > Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where > > all the printk timestamps are 000.000 (don't take the # of > > digits too literally). Probably unrelated, but I may as well mention it. > > (System is an Athlon XP 2200+ with SiS chipset. I can't remember which > > model of SiS chipset.) > > Yes, sorry. Reverting > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch > will fix that one. I kind of figured that from another LKML discussion but I wasn't 100% sure that's what I should do. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
On Tuesday 05 April 2005 03:05, Andrew Morton wrote: > - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using > `nmi_watchdog=0' if you experience weird crashes. > > - The possible kernel-timer related hangs might possibly be fixed. We > haven't heard yet. > > - Nobody said anything about the PM resume and DRI behaviour in > 2.6.12-rc1-mm4. So it's all perfect now? > > - Various fixes and updates. Nothing earth-shattering. This refuses to boot here. It dies when assigning the EHCI driver. The mb is an MSI-7030 K8N Neo Platinium based on a nForce 3 250Gb Chipset (x86_64). I`ve been on vacation - the last kernel tried was 11-mm3 which booted fine but refuses to use all the usb ports supplied by the system (two work, three do not all using low speed). Any ideas what might be happening? Ed Tomlinson - 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/
Re: 2.6.12-rc2-mm1
Neil Brown <[EMAIL PROTECTED]> wrote: > > On Tuesday April 5, [EMAIL PROTECTED] wrote: > > > > - Nobody said anything about the PM resume and DRI behaviour in > > 2.6.12-rc1-mm4. So it's all perfect now? > > Well, Seeing you asked... > > PM resume certainly seems to be improving. > My main problem in rc1-mm3 is with PCMCIA. > If I stop cardmgr before suspend-to-RAM, and then try to > restart it after resume, I cannot. Some message about the socket > being in use, and am I sure there is no other cardmgr running (there > isn't). I don't know whether the PCMCIA problem is due to PCMCIA changes or not. The only thing I see having changed between 2.6.12-rc1-mm3 and 2.6.12-rc2-mm1 is the addition of pcmcia-resource-handling-fixes.patch. Would you have time to revert that, retest? There have been a few problem in the area of device management in bk-driver-core. I think we're getting that settled down now. - 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/
Re: 2.6.12-rc2-mm1
Jindrich Makovicka <[EMAIL PROTECTED]> wrote:
>
> oes not compile on AthlonXP. For mmx_clear_page, only the prototype was
> changed, but the implementation is still the same. I guess that part of
> the patch slipped out somehow.
>
> -extern void mmx_clear_page(void *page);
>
> +extern void mmx_clear_page(void *page, int order);
I guess this will fix it...
diff -puN
arch/i386/lib/mmx.c~add-a-clear_pages-function-to-clear-pages-of-higher-fix
arch/i386/lib/mmx.c
---
25/arch/i386/lib/mmx.c~add-a-clear_pages-function-to-clear-pages-of-higher-fix
Wed Apr 6 15:00:54 2005
+++ 25-akpm/arch/i386/lib/mmx.c Wed Apr 6 15:06:09 2005
@@ -128,9 +128,10 @@ void *_mmx_memcpy(void *to, const void *
* other MMX using processors do not.
*/
-static void fast_clear_page(void *page)
+static void fast_clear_page(void *page, int order)
{
int i;
+ int chunks = (4096 << order) / 64;
kernel_fpu_begin();
@@ -138,8 +139,7 @@ static void fast_clear_page(void *page)
" pxor %%mm0, %%mm0\n" : :
);
- for(i=0;i<4096/64;i++)
- {
+ for (i = 0; i < chunks; i++) {
__asm__ __volatile__ (
" movntq %%mm0, (%0)\n"
" movntq %%mm0, 8(%0)\n"
@@ -257,18 +257,18 @@ static void fast_copy_page(void *to, voi
* Generic MMX implementation without K7 specific streaming
*/
-static void fast_clear_page(void *page)
+static void fast_clear_page(void *page, int order)
{
int i;
-
+ int chunks = (4096 << order) / 128;
+
kernel_fpu_begin();
__asm__ __volatile__ (
" pxor %%mm0, %%mm0\n" : :
);
- for(i=0;i<4096/128;i++)
- {
+ for (i = 0; i < chunks; i++) {
__asm__ __volatile__ (
" movq %%mm0, (%0)\n"
" movq %%mm0, 8(%0)\n"
@@ -359,23 +359,23 @@ static void fast_copy_page(void *to, voi
* Favour MMX for page clear and copy.
*/
-static void slow_zero_page(void * page)
+static void slow_zero_page(void *page, int order)
{
int d0, d1;
__asm__ __volatile__( \
"cld\n\t" \
"rep ; stosl" \
: "=" (d0), "=" (d1)
- :"a" (0),"1" (page),"0" (1024)
+ :"a" (0),"1" (page),"0" (1024 << order)
:"memory");
}
-void mmx_clear_page(void * page)
+void mmx_clear_page(void *page, int order)
{
if(unlikely(in_interrupt()))
- slow_zero_page(page);
+ slow_zero_page(page, order);
else
- fast_clear_page(page);
+ fast_clear_page(page, order);
}
static void slow_copy_page(void *to, void *from)
_
-
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/
Re: 2.6.12-rc2-mm1
"Barry K. Nathan" <[EMAIL PROTECTED]> wrote: > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the > problem goes away if I remove this patch: > swsusp-enable-resume-from-initrd.patch That really helps, thanks. The patch looks fairly innocent. I'll give up on this and cc the developers. > (Recap of the problem in case this gets forwarded: Resume is almost > instant without the apparently-guilty patch. With the patch, resume > takes almost half an hour.) > > BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: > With that kernel, suspend is also ridiculously slow (speed is comparable > to the slow resume with the aforementioned patch). 2.6.11-rc2 does not > have that problem. Does reverting swsusp-enable-resume-from-initrd.patch fix this also? > Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where > all the printk timestamps are 000.000 (don't take the # of > digits too literally). Probably unrelated, but I may as well mention it. > (System is an Athlon XP 2200+ with SiS chipset. I can't remember which > model of SiS chipset.) Yes, sorry. Reverting http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch will fix that one. - 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/
Re: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Steven Cole <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > Steven Cole <[EMAIL PROTECTED]> wrote: > > > >>arch/i386/kernel/setup.c: In function 'setup_arch': > >> arch/i386/kernel/setup.c:1571: warning: implicit declaration of function > >> 'acpi_boot_table_init' > >> arch/i386/kernel/setup.c:1572: warning: implicit declaration of function > >> 'acpi_boot_init' > > > > > > > > diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h > > --- 25/include/linux/acpi.h~no-acpi-build-fix 2005-04-05 > > 00:14:46.0 -0700 > > +++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700 > > @@ -418,16 +418,6 @@ extern int sbf_port ; > [patch snipped] > > Yes, that worked with no CONFIG_ACPI. Thanks. OK, I'll keep spamming the acpi guys with it until they tell me to shut up. > On a slightly offtopic note, I'm now using this gcc: > gcc (GCC) 4.0.0 20050308 (Red Hat 4.0.0-0.32) > > I don't have any quantitative data at hand, this seems SLW. > I guess that's progress. But it slows down testing somewhat. > There's a reason why I persist in keeping the kernel working with gcc-2.95.4! - 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/
Re: 2.6.12-rc2-mm1: inotify and directory removal
On Wed, 2005-04-06 at 14:21 +0100, Sean Neakums wrote: > Using your glib sample thingy from > http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ Thanks. It was a bug in the glib utility, not inotify itself. I fixed it in inotify-glib-0.0.2, which should appear at the above URL as soon as the mirrors sync. Thanks again! Robert Love - 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/
Re: 2.6.12-rc2-mm1
Siddha, Suresh B wrote: On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote: Lastly, I'd like to be a bit less intrusive with pinned task handling improvements. I think we can do this while still being effective in preventing livelocks. We want to see this fixed. Please post your patch and I can let you know the test results. Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped itself to death after 2 infinite loop tasks had been pinned to one of the CPUs. See how you go. -- SUSE Labs, Novell Inc. Index: linux-2.6/kernel/sched.c === --- linux-2.6.orig/kernel/sched.c 2005-04-07 02:39:22.0 +1000 +++ linux-2.6/kernel/sched.c2005-04-07 02:45:26.0 +1000 @@ -2041,6 +2041,12 @@ static runqueue_t *find_busiest_queue(st } /* + * Max backoff if we encounter pinned tasks. Pretty arbitrary value, but + * so long as it is large enough. + */ +#define MAX_PINNED_INTERVAL1024 + +/* * Check this_cpu to ensure it is balanced within domain. Attempt to move * tasks if there is an imbalance. * @@ -2052,7 +2058,7 @@ static int load_balance(int this_cpu, ru struct sched_group *group; runqueue_t *busiest; unsigned long imbalance; - int nr_moved, all_pinned; + int nr_moved, all_pinned = 0; int active_balance = 0; spin_lock(_rq->lock); @@ -2143,7 +2149,8 @@ out_balanced: sd->nr_balance_failed = 0; /* tune up the balancing interval */ - if (sd->balance_interval < sd->max_interval) + if ((all_pinned && sd->balance_interval < MAX_PINNED_INTERVAL) || + (sd->balance_interval < sd->max_interval)) sd->balance_interval *= 2; return 0;
Re: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Andrew Morton wrote: Steven Cole <[EMAIL PROTECTED]> wrote: arch/i386/kernel/setup.c: In function 'setup_arch': arch/i386/kernel/setup.c:1571: warning: implicit declaration of function 'acpi_boot_table_init' arch/i386/kernel/setup.c:1572: warning: implicit declaration of function 'acpi_boot_init' diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h --- 25/include/linux/acpi.h~no-acpi-build-fix 2005-04-05 00:14:46.0 -0700 +++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700 @@ -418,16 +418,6 @@ extern int sbf_port ; [patch snipped] Yes, that worked with no CONFIG_ACPI. Thanks. On a slightly offtopic note, I'm now using this gcc: gcc (GCC) 4.0.0 20050308 (Red Hat 4.0.0-0.32) I don't have any quantitative data at hand, this seems SLW. I guess that's progress. But it slows down testing somewhat. Steven - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 05:56:00PM -0700, Andrew Morton wrote: > > I'll see if I can isolate it any further. > > Please, that would help. [Right now I'm in a race against my lack of sleep. I'm trying to send this e-mail before I involuntarily fall asleep, so the contents and/or recipient list may be incomplete...] Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch (Recap of the problem in case this gets forwarded: Resume is almost instant without the apparently-guilty patch. With the patch, resume takes almost half an hour.) BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: With that kernel, suspend is also ridiculously slow (speed is comparable to the slow resume with the aforementioned patch). 2.6.11-rc2 does not have that problem. Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where all the printk timestamps are 000.000 (don't take the # of digits too literally). Probably unrelated, but I may as well mention it. (System is an Athlon XP 2200+ with SiS chipset. I can't remember which model of SiS chipset.) -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
Ingo Molnar a écrit : weird - none of the WARN_ON(1)'s show up. In particular, the sched_clock() ones should have triggered at least once! I've attached a new version of the patch below (please unapply the previous patch), could you try it and send me the log? (It will unconditionally print something in tsc_init(), which is always called during the boot process.) Hi Ingo, The result is exactly the same, except the following lines at the begining of dmesg. Note that only these lines have a valid timestamp. All remaining lines show 0.000. [4294667.296000] Linux version 2.6.12-rc2-mm1=LoulousMobile ([EMAIL PROTECTED]) (version gcc 3.3.5 (Debian 1:3.3.5-8)) #9 PREEMPT Tue Apr 5 09:28:57 CEST 2005 [4294667.296000] Badness in sched_clock at arch/i386/kernel/timers/timer_tsc.c:143 [4294667.296000] [] sched_clock+0x84/0x110 [4294667.296000] [] vscnprintf+0x2b/0x40 [4294667.296000] [] vprintk+0xa2/0x260 [4294667.296000] [] printk+0x17/0x20 [4294667.296000] [] start_kernel+0x14/0x180 [4294667.296000] art_kernel+0x14/0x180 Brice - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 05:56:00PM -0700, Andrew Morton wrote: > Odd. Yes, it is odd... > > 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10). > > 2.6.11-bk10 has the weird slowdown. > > Unfortunately that's a pretty bug diff (2 megs). Yeah, I know. *sigh* [snip] > but you'd be getting a printk storm if that was triggering. I'm not seeing a printk storm, at least, none that I can discern... > > I'll see if I can isolate it any further. > > Please, that would help. I'm working on it right now. 2.6.11 + linus.patch from 2.6.11-mm3 works. 2.6.11 + approx. 292 patches from 2.6.11-mm3 is broken. 2.6.11 + approx. 130 patches (a proper subset of the 292 patches) works. (this is counting each subsystem bk tree as a single patch) The diff between the latter two trees is still larger than the 2.6.11-bk9 -> -bk10 diff, but after one or two more iterations of (psuedo-)binary search, it should be much smaller. I'm planning to go as far as I can before going to bed tonight. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
RE: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
>@Len: >ACPI=y and ACPI_BOOT=n seems to be a legal configuration (with >X86_HT=y), but it breaks into pieces if you try the compilation. yeah, don't do that:-) I'm sorry I didn't push the patch to delete CONFIG_ACPI_BOOT earlier. For now, just enable them both. thanks, -Len - 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/
RE: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
@Len: ACPI=y and ACPI_BOOT=n seems to be a legal configuration (with X86_HT=y), but it breaks into pieces if you try the compilation. yeah, don't do that:-) I'm sorry I didn't push the patch to delete CONFIG_ACPI_BOOT earlier. For now, just enable them both. thanks, -Len - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 05:56:00PM -0700, Andrew Morton wrote: Odd. Yes, it is odd... 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10). 2.6.11-bk10 has the weird slowdown. Unfortunately that's a pretty bug diff (2 megs). Yeah, I know. *sigh* [snip] but you'd be getting a printk storm if that was triggering. I'm not seeing a printk storm, at least, none that I can discern... I'll see if I can isolate it any further. Please, that would help. I'm working on it right now. 2.6.11 + linus.patch from 2.6.11-mm3 works. 2.6.11 + approx. 292 patches from 2.6.11-mm3 is broken. 2.6.11 + approx. 130 patches (a proper subset of the 292 patches) works. (this is counting each subsystem bk tree as a single patch) The diff between the latter two trees is still larger than the 2.6.11-bk9 - -bk10 diff, but after one or two more iterations of (psuedo-)binary search, it should be much smaller. I'm planning to go as far as I can before going to bed tonight. -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1
Ingo Molnar a écrit : weird - none of the WARN_ON(1)'s show up. In particular, the sched_clock() ones should have triggered at least once! I've attached a new version of the patch below (please unapply the previous patch), could you try it and send me the log? (It will unconditionally print something in tsc_init(), which is always called during the boot process.) Hi Ingo, The result is exactly the same, except the following lines at the begining of dmesg. Note that only these lines have a valid timestamp. All remaining lines show 0.000. [4294667.296000] Linux version 2.6.12-rc2-mm1=LoulousMobile ([EMAIL PROTECTED]) (version gcc 3.3.5 (Debian 1:3.3.5-8)) #9 PREEMPT Tue Apr 5 09:28:57 CEST 2005 [4294667.296000] Badness in sched_clock at arch/i386/kernel/timers/timer_tsc.c:143 [4294667.296000] [c010f464] sched_clock+0x84/0x110 [4294667.296000] [c01d7b5b] vscnprintf+0x2b/0x40 [4294667.296000] [c011e252] vprintk+0xa2/0x260 [4294667.296000] [c011e1a7] printk+0x17/0x20 [4294667.296000] [c046f6f4] start_kernel+0x14/0x180 [4294667.296000] art_kernel+0x14/0x180 Brice - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 05:56:00PM -0700, Andrew Morton wrote: I'll see if I can isolate it any further. Please, that would help. [Right now I'm in a race against my lack of sleep. I'm trying to send this e-mail before I involuntarily fall asleep, so the contents and/or recipient list may be incomplete...] Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch (Recap of the problem in case this gets forwarded: Resume is almost instant without the apparently-guilty patch. With the patch, resume takes almost half an hour.) BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: With that kernel, suspend is also ridiculously slow (speed is comparable to the slow resume with the aforementioned patch). 2.6.11-rc2 does not have that problem. Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where all the printk timestamps are 000.000 (don't take the # of digits too literally). Probably unrelated, but I may as well mention it. (System is an Athlon XP 2200+ with SiS chipset. I can't remember which model of SiS chipset.) -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Andrew Morton wrote: Steven Cole [EMAIL PROTECTED] wrote: arch/i386/kernel/setup.c: In function 'setup_arch': arch/i386/kernel/setup.c:1571: warning: implicit declaration of function 'acpi_boot_table_init' arch/i386/kernel/setup.c:1572: warning: implicit declaration of function 'acpi_boot_init' diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h --- 25/include/linux/acpi.h~no-acpi-build-fix 2005-04-05 00:14:46.0 -0700 +++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700 @@ -418,16 +418,6 @@ extern int sbf_port ; [patch snipped] Yes, that worked with no CONFIG_ACPI. Thanks. On a slightly offtopic note, I'm now using this gcc: gcc (GCC) 4.0.0 20050308 (Red Hat 4.0.0-0.32) I don't have any quantitative data at hand, this seems SLW. I guess that's progress. But it slows down testing somewhat. Steven - 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/
Re: 2.6.12-rc2-mm1
Siddha, Suresh B wrote: On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote: Lastly, I'd like to be a bit less intrusive with pinned task handling improvements. I think we can do this while still being effective in preventing livelocks. We want to see this fixed. Please post your patch and I can let you know the test results. Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped itself to death after 2 infinite loop tasks had been pinned to one of the CPUs. See how you go. -- SUSE Labs, Novell Inc. Index: linux-2.6/kernel/sched.c === --- linux-2.6.orig/kernel/sched.c 2005-04-07 02:39:22.0 +1000 +++ linux-2.6/kernel/sched.c2005-04-07 02:45:26.0 +1000 @@ -2041,6 +2041,12 @@ static runqueue_t *find_busiest_queue(st } /* + * Max backoff if we encounter pinned tasks. Pretty arbitrary value, but + * so long as it is large enough. + */ +#define MAX_PINNED_INTERVAL1024 + +/* * Check this_cpu to ensure it is balanced within domain. Attempt to move * tasks if there is an imbalance. * @@ -2052,7 +2058,7 @@ static int load_balance(int this_cpu, ru struct sched_group *group; runqueue_t *busiest; unsigned long imbalance; - int nr_moved, all_pinned; + int nr_moved, all_pinned = 0; int active_balance = 0; spin_lock(this_rq-lock); @@ -2143,7 +2149,8 @@ out_balanced: sd-nr_balance_failed = 0; /* tune up the balancing interval */ - if (sd-balance_interval sd-max_interval) + if ((all_pinned sd-balance_interval MAX_PINNED_INTERVAL) || + (sd-balance_interval sd-max_interval)) sd-balance_interval *= 2; return 0;
Re: 2.6.12-rc2-mm1: inotify and directory removal
On Wed, 2005-04-06 at 14:21 +0100, Sean Neakums wrote: Using your glib sample thingy from http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ Thanks. It was a bug in the glib utility, not inotify itself. I fixed it in inotify-glib-0.0.2, which should appear at the above URL as soon as the mirrors sync. Thanks again! Robert Love - 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/
Re: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Steven Cole [EMAIL PROTECTED] wrote: Andrew Morton wrote: Steven Cole [EMAIL PROTECTED] wrote: arch/i386/kernel/setup.c: In function 'setup_arch': arch/i386/kernel/setup.c:1571: warning: implicit declaration of function 'acpi_boot_table_init' arch/i386/kernel/setup.c:1572: warning: implicit declaration of function 'acpi_boot_init' diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h --- 25/include/linux/acpi.h~no-acpi-build-fix 2005-04-05 00:14:46.0 -0700 +++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700 @@ -418,16 +418,6 @@ extern int sbf_port ; [patch snipped] Yes, that worked with no CONFIG_ACPI. Thanks. OK, I'll keep spamming the acpi guys with it until they tell me to shut up. On a slightly offtopic note, I'm now using this gcc: gcc (GCC) 4.0.0 20050308 (Red Hat 4.0.0-0.32) I don't have any quantitative data at hand, this seems SLW. I guess that's progress. But it slows down testing somewhat. There's a reason why I persist in keeping the kernel working with gcc-2.95.4! - 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/
Re: 2.6.12-rc2-mm1
Barry K. Nathan [EMAIL PROTECTED] wrote: Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch That really helps, thanks. The patch looks fairly innocent. I'll give up on this and cc the developers. (Recap of the problem in case this gets forwarded: Resume is almost instant without the apparently-guilty patch. With the patch, resume takes almost half an hour.) BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: With that kernel, suspend is also ridiculously slow (speed is comparable to the slow resume with the aforementioned patch). 2.6.11-rc2 does not have that problem. Does reverting swsusp-enable-resume-from-initrd.patch fix this also? Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where all the printk timestamps are 000.000 (don't take the # of digits too literally). Probably unrelated, but I may as well mention it. (System is an Athlon XP 2200+ with SiS chipset. I can't remember which model of SiS chipset.) Yes, sorry. Reverting http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch will fix that one. - 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/
Re: 2.6.12-rc2-mm1
Jindrich Makovicka [EMAIL PROTECTED] wrote:
oes not compile on AthlonXP. For mmx_clear_page, only the prototype was
changed, but the implementation is still the same. I guess that part of
the patch slipped out somehow.
-extern void mmx_clear_page(void *page);
+extern void mmx_clear_page(void *page, int order);
I guess this will fix it...
diff -puN
arch/i386/lib/mmx.c~add-a-clear_pages-function-to-clear-pages-of-higher-fix
arch/i386/lib/mmx.c
---
25/arch/i386/lib/mmx.c~add-a-clear_pages-function-to-clear-pages-of-higher-fix
Wed Apr 6 15:00:54 2005
+++ 25-akpm/arch/i386/lib/mmx.c Wed Apr 6 15:06:09 2005
@@ -128,9 +128,10 @@ void *_mmx_memcpy(void *to, const void *
* other MMX using processors do not.
*/
-static void fast_clear_page(void *page)
+static void fast_clear_page(void *page, int order)
{
int i;
+ int chunks = (4096 order) / 64;
kernel_fpu_begin();
@@ -138,8 +139,7 @@ static void fast_clear_page(void *page)
pxor %%mm0, %%mm0\n : :
);
- for(i=0;i4096/64;i++)
- {
+ for (i = 0; i chunks; i++) {
__asm__ __volatile__ (
movntq %%mm0, (%0)\n
movntq %%mm0, 8(%0)\n
@@ -257,18 +257,18 @@ static void fast_copy_page(void *to, voi
* Generic MMX implementation without K7 specific streaming
*/
-static void fast_clear_page(void *page)
+static void fast_clear_page(void *page, int order)
{
int i;
-
+ int chunks = (4096 order) / 128;
+
kernel_fpu_begin();
__asm__ __volatile__ (
pxor %%mm0, %%mm0\n : :
);
- for(i=0;i4096/128;i++)
- {
+ for (i = 0; i chunks; i++) {
__asm__ __volatile__ (
movq %%mm0, (%0)\n
movq %%mm0, 8(%0)\n
@@ -359,23 +359,23 @@ static void fast_copy_page(void *to, voi
* Favour MMX for page clear and copy.
*/
-static void slow_zero_page(void * page)
+static void slow_zero_page(void *page, int order)
{
int d0, d1;
__asm__ __volatile__( \
cld\n\t \
rep ; stosl \
: =c (d0), =D (d1)
- :a (0),1 (page),0 (1024)
+ :a (0),1 (page),0 (1024 order)
:memory);
}
-void mmx_clear_page(void * page)
+void mmx_clear_page(void *page, int order)
{
if(unlikely(in_interrupt()))
- slow_zero_page(page);
+ slow_zero_page(page, order);
else
- fast_clear_page(page);
+ fast_clear_page(page, order);
}
static void slow_copy_page(void *to, void *from)
_
-
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/
Re: 2.6.12-rc2-mm1
Neil Brown [EMAIL PROTECTED] wrote: On Tuesday April 5, [EMAIL PROTECTED] wrote: - Nobody said anything about the PM resume and DRI behaviour in 2.6.12-rc1-mm4. So it's all perfect now? Well, Seeing you asked... PM resume certainly seems to be improving. My main problem in rc1-mm3 is with PCMCIA. If I stop cardmgr before suspend-to-RAM, and then try to restart it after resume, I cannot. Some message about the socket being in use, and am I sure there is no other cardmgr running (there isn't). I don't know whether the PCMCIA problem is due to PCMCIA changes or not. The only thing I see having changed between 2.6.12-rc1-mm3 and 2.6.12-rc2-mm1 is the addition of pcmcia-resource-handling-fixes.patch. Would you have time to revert that, retest? There have been a few problem in the area of device management in bk-driver-core. I think we're getting that settled down now. - 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/
Re: 2.6.12-rc2-mm1
On Tuesday 05 April 2005 03:05, Andrew Morton wrote: - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using `nmi_watchdog=0' if you experience weird crashes. - The possible kernel-timer related hangs might possibly be fixed. We haven't heard yet. - Nobody said anything about the PM resume and DRI behaviour in 2.6.12-rc1-mm4. So it's all perfect now? - Various fixes and updates. Nothing earth-shattering. This refuses to boot here. It dies when assigning the EHCI driver. The mb is an MSI-7030 K8N Neo Platinium based on a nForce 3 250Gb Chipset (x86_64). I`ve been on vacation - the last kernel tried was 11-mm3 which booted fine but refuses to use all the usb ports supplied by the system (two work, three do not all using low speed). Any ideas what might be happening? Ed Tomlinson - 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/
Re: 2.6.12-rc2-mm1
On Wed, Apr 06, 2005 at 02:27:49PM -0700, Andrew Morton wrote: Barry K. Nathan [EMAIL PROTECTED] wrote: Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch That really helps, thanks. You're welcome. The patch looks fairly innocent. I'll give up on this and cc the developers. Yeah, it *seemed* innocent enough -- that's why I had to do a binary search on the 2.6.11-mm3 series file in order to find it as the culprit... (Recap of the problem in case this gets forwarded: Resume is almost instant without the apparently-guilty patch. With the patch, resume takes almost half an hour.) BTW, there's another strange thing that's introduced by 2.6.11-rc2-mm1: With that kernel, suspend is also ridiculously slow (speed is comparable to the slow resume with the aforementioned patch). 2.6.11-rc2 does not have that problem. Does reverting swsusp-enable-resume-from-initrd.patch fix this also? No. Reverting it from 2.6.12-rc2-mm1 (oops, I got the version number wrong in my previous mail -- and that should also be 2.6.12-rc2 not 2.6.11-rc2) speeds up resume to the original speed, but suspend is still ridiculously slow. Time to narrow things down again, I presume... Also, with 2.6.12-rc2-mm1, this computer happens to hit the bug where all the printk timestamps are 000.000 (don't take the # of digits too literally). Probably unrelated, but I may as well mention it. (System is an Athlon XP 2200+ with SiS chipset. I can't remember which model of SiS chipset.) Yes, sorry. Reverting http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_hpet-or-config_numa-systems.patch will fix that one. I kind of figured that from another LKML discussion but I wasn't 100% sure that's what I should do. -Barry K. Nathan [EMAIL PROTECTED] - 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/
Re: 2.6.12-rc2-mm1 compile error in mmx.c
On April 5, 2005 09:22 pm, Berck E. Nash wrote: > 2.6.12-rc2-mm1 fails to build for me with the following error: > > arch/i386/lib/mmx.c:374: error: conflicting types for `mmx_clear_page' > include/asm/mmx.h:11: error: previous declaration of `mmx_clear_page' > make[1]: *** [arch/i386/lib/mmx.o] Error 1 > make: *** [arch/i386/lib] Error 2 I don't know the proper fix, but reversing this patch: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm1/broken-out/add-a-clear_pages-function-to-clear-pages-of-higher.patch worked for me. - 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/
Re: 2.6.12-rc2-mm1
On Tuesday April 5, [EMAIL PROTECTED] wrote: > > - Nobody said anything about the PM resume and DRI behaviour in > 2.6.12-rc1-mm4. So it's all perfect now? Well, Seeing you asked... PM resume certainly seems to be improving. My main problem in rc1-mm3 is with PCMCIA. If I stop cardmgr before suspend-to-RAM, and then try to restart it after resume, I cannot. Some message about the socket being in use, and am I sure there is no other cardmgr running (there isn't). I can stop and restart happily before suspending, but not after. If I leave it running during a suspend/resume cycle it keeps working but if I then stop and restart, it fails. (and if I do leave it running, my PCMCIA wireless gets started before my tg3 wired, so eth0 and eth1 get swapped). I just tried rc2-mm1 and... decided to go back to rc1-mm3. It seemed to boot mostly OK. I tried suspend-to-RAM and it seems to suspend. But when I turned it back on again it rebooted rather than resumed. During boot I got: Apr 6 10:18:46 localhost kernel: cs: memory probe 0xf600-0xfbff:iounmap: bad address f8828000 Apr 6 10:18:46 localhost kernel: [set_cis_map+150/256] set_cis_map+0x96/0x100 Apr 6 10:18:46 localhost kernel: [remove_vm_area+60/80] remove_vm_area+0x3c/0x50 Apr 6 10:18:46 localhost kernel: [pcmcia_read_cis_mem+412/560] pcmcia_read_cis_mem+0x19c/0x230 Apr 6 10:18:46 localhost kernel: [set_cis_map+150/256] set_cis_map+0x96/0x100 Apr 6 10:18:46 localhost kernel: [read_cis_cache+358/400] read_cis_cache+0x166/0x190 Apr 6 10:18:46 localhost kernel: [follow_link+141/544] follow_link+0x8d/0x220 Apr 6 10:18:46 localhost kernel: [pccard_get_next_tuple+688/784] pccard_get_next_tuple+0x2b0/0x310 Apr 6 10:18:46 localhost kernel: [pccard_get_first_tuple+144/336] pccard_get_first_tuple+0x90/0x150 Apr 6 10:18:46 localhost kernel: [pccard_validate_cis+151/592] pccard_validate_cis+0x97/0x250 Apr 6 10:18:46 localhost kernel: [readable+90/160] readable+0x5a/0xa0 Apr 6 10:18:46 localhost kernel: [cis_readable+129/224] cis_readable+0x81/0xe0 Apr 6 10:18:46 localhost kernel: [do_mem_probe+469/496] do_mem_probe+0x1d5/0x1f0 Apr 6 10:18:46 localhost kernel: [inv_probe+159/176] inv_probe+0x9f/0xb0 Apr 6 10:18:46 localhost kernel: [validate_mem+271/304] validate_mem+0x10f/0x130 Apr 6 10:18:46 localhost kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Apr 6 10:18:46 localhost kernel: [pcmcia_nonstatic_validate_mem+120/128] pcmcia_nonstatic_validate_mem+0x78/0x80 Apr 6 10:18:46 localhost kernel: [pcmcia_validate_mem+26/32] pcmcia_validate_mem+0x1a/0x20 Apr 6 10:18:46 localhost kernel: [pcmcia_card_add+42/208] pcmcia_card_add+0x2a/0xd0 Then it hung in some device discovery. Not sure which device, maybe firewire. Alt-Sysrq-T showed Apr 6 10:19:45 localhost kernel: khpsbpkt S C04643E0 0 1956 1 1973 915 (L-TLB) Apr 6 10:19:45 localhost kernel: f6cf3f94 0046 f68dd070 c04643e0 f7c0f030 c0464410 f7c0f030 Apr 6 10:19:45 localhost kernel:f6cf3f8c f68dd070 f68dd198 f8af2444 f6cf2000 Apr 6 10:19:45 localhost kernel:0246 f68dd070 c031ce5d f8af244c 0001 f68dd070 c0114a70 Apr 6 10:19:45 localhost kernel: Call Trace: Apr 6 10:19:45 localhost kernel: [__down_interruptible+157/300] __down_interruptible+0x9d/0x12c Apr 6 10:19:45 localhost kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Apr 6 10:19:45 localhost kernel: [__down_failed_interruptible+7/12] __down_failed_interruptible+0x7/0xc Apr 6 10:19:45 localhost kernel: [pg0+945105653/1067918336] .text.lock.ieee1394_core+0x1b/0x26 [ieee1394] Apr 6 10:19:45 localhost kernel: [pg0+945105424/1067918336] hpsbpkt_thread+0x0/0xb0 [ieee1394] Apr 6 10:19:45 localhost kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 Apr 6 10:19:45 localhost kernel: knodemgrd_0 S C04643E0 0 1973 1 2023 1956 (L-TLB) Apr 6 10:19:45 localhost kernel: f7e75f7c 0046 f7c0f030 c04643e0 a1ff c018a7cc f648e62c Apr 6 10:19:45 localhost kernel:f6ec8380 f7c0f030 f7c0f158 f6f6b670 f7e74000 Apr 6 10:19:45 localhost kernel:0246 f7c0f030 c031ce5d f6f6b678 0001 f7c0f030 c0114a70 Apr 6 10:19:45 localhost kernel: Call Trace: Apr 6 10:19:45 localhost kernel: [sysfs_make_dirent+44/160] sysfs_make_dirent+0x2c/0xa0 Apr 6 10:19:45 localhost kernel: [__down_interruptible+157/300] __down_interruptible+0x9d/0x12c Apr 6 10:19:45 localhost kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Apr 6 10:19:45 localhost kernel: [__down_failed_interruptible+7/12] __down_failed_interruptible+0x7/0xc Apr 6 10:19:45 localhost kernel: [pg0+945133083/1067918336] .text.lock.nodemgr+0x112/0x1a7 [ieee1394] Apr 6 10:19:45 localhost kernel: [pg0+945131536/1067918336] nodemgr_host_thread+0x0/0x190 [ieee1394] Apr
Re: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Steven Cole <[EMAIL PROTECTED]> wrote:
>
> arch/i386/kernel/setup.c: In function 'setup_arch':
> arch/i386/kernel/setup.c:1571: warning: implicit declaration of function
> 'acpi_boot_table_init'
> arch/i386/kernel/setup.c:1572: warning: implicit declaration of function
> 'acpi_boot_init'
diff -puN include/linux/acpi.h~no-acpi-build-fix include/linux/acpi.h
--- 25/include/linux/acpi.h~no-acpi-build-fix 2005-04-05 00:14:46.0
-0700
+++ 25-akpm/include/linux/acpi.h2005-04-05 00:23:39.0 -0700
@@ -418,16 +418,6 @@ extern int sbf_port ;
#define acpi_mp_config 0
-static inline int acpi_boot_init(void)
-{
- return 0;
-}
-
-static inline int acpi_boot_table_init(void)
-{
- return 0;
-}
-
#endif /*!CONFIG_ACPI_BOOT*/
unsigned int acpi_register_gsi (u32 gsi, int edge_level, int active_high_low);
@@ -538,5 +528,18 @@ static inline int acpi_get_pxm(acpi_hand
extern int pnpacpi_disabled;
+#else /* CONFIG_ACPI */
+
+static inline int acpi_boot_init(void)
+{
+ return 0;
+}
+
+static inline int acpi_boot_table_init(void)
+{
+ return 0;
+}
+
#endif /* CONFIG_ACPI */
+
#endif /* _LINUX_ACPI_H */
_
-
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/
Re: 2.6.12-rc2-mm1
"Barry K. Nathan" <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 05, 2005 at 06:44:08AM -0700, Barry K. Nathan wrote:
> > swsusp: reading slkf;jalksfsadflkjas;dlfasdfkl (12345 pages): 34%
> > [sorry, I just got up so my short-term memory isn't working that well
> > yet]
> >
> > takes 10-30 minutes (depending on whether it's closer to 11000 pages or
> > 2) rather than the 5-10 seconds or so that it takes under 2.6.11-ac5
> > (or mainline 2.6.11 if I remember correctly).
Odd.
> [snip]
> > I'll try to do some more testing to see (a) when this problem started
> > and (b) whether it still exists in 2.6.12-rc2 or later. This is going to
> > be ridiculously difficult for me to fit into my schedule right now, but
> > I'll try
>
> 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10).
> 2.6.11-bk10 has the weird slowdown.
Unfortunately that's a pretty bug diff (2 megs).
The only thing I can see in the memory reclaim area is this:
--- b/mm/vmscan.c 2005-03-10 00:39:02 -08:00
+++ b/mm/vmscan.c 2005-03-13 15:29:39 -08:00
@@ -313,8 +313,20 @@
*/
if (!is_page_cache_freeable(page))
return PAGE_KEEP;
- if (!mapping)
+ if (!mapping) {
+ /*
+* Some data journaling orphaned pages can have
+* page->mapping == NULL while being dirty with clean buffers.
+*/
+ if (PageDirty(page) && PagePrivate(page)) {
+ if (try_to_free_buffers(page)) {
+ ClearPageDirty(page);
+ printk("%s: orphaned page\n", __FUNCTION__);
+ return PAGE_CLEAN;
+ }
+ }
return PAGE_KEEP;
+ }
if (mapping->a_ops->writepage == NULL)
return PAGE_ACTIVATE;
if (!may_write_to_queue(mapping->backing_dev_info))
but you'd be getting a printk storm if that was triggering.
> I'll see if I can isolate it any further.
Please, that would help.
-
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/
Re: 2.6.12-rc2-mm1
Siddha, Suresh B wrote: On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote: Suresh's underlying problem with the unnecessary sched domains is a failing of sched-balance-exec and sched-balance-fork, which That wasn't the only motivation. For example, on non-HT cpu's we shouldn't be setting up SMT sched-domain, same with NUMA domains on non-NUMA systems. Yep, sure. It is a good, if slight, optimisation. And I've also just slightly extended your patch, so we don't have any domains if booting with maxcpus=1 I am working on now. Removing unnecessary domains is a nice optimisation, but just needs to account for a few more flags before declaring that a Can you elaborate when we require a domain with special flags but has no or only one group in it. The SD_WAKE_* flags do not use groups, so it would be legitimate to have a domain that has one of these set, with no groups. domain is unnecessary (not to mention this probably breaks if isolcpus= is used). I have made some modifications to the patch I have tested my patch with "ioslcpus=" and it works just fine. OK, my apologies ;) to fix these problems. Lastly, I'd like to be a bit less intrusive with pinned task handling improvements. I think we can do this while still being effective in preventing livelocks. We want to see this fixed. Please post your patch and I can let you know the test results. I will try to get it working and tested tonight for you. I will keep you posted with regards to the various scheduler patches. Nick, Can you post the patches you sent me earlier to this list? Yep, I'll post them. -- SUSE Labs, Novell Inc. - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 07:14:45AM -0700, Barry K. Nathan wrote: > 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10). > 2.6.11-bk10 has the weird slowdown. > > I'll see if I can isolate it any further. 2.6.11-mm2 works, but 2.6.11-mm3 has the ridiculously slow resumes. Later today I'll see if I can narrow things down any further (e.g. to a specific patch in 2.6.11-mm3 or whatever). -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 05:45:58PM +0200, Jan Dittmer wrote: > Something has broken make O= : > > HOSTCC scripts/kallsyms > HOSTCC scripts/conmakehash > make[1]: *** No rule to make target `include/asm', needed by > `arch/alpha/kernel/asm-offsets.s'. Stop. > make: *** [_all] Error 2 > > Happens for most archs. See http://l4x.org/k/ Thanks - here is a patch: # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2005/04/05 23:37:09+02:00 [EMAIL PROTECTED] # kbuild: fix make O=... build # # It fixes the following error: # # make[1]: *** No rule to make target `include/asm', needed by `arch/alpha/kernel/asm-offsets.s'. Stop. # # Reported by: # From: Jan Dittmer <[EMAIL PROTECTED]> # # In same patch fix spaces to tabs as reported by: # From: Adrian Bunk <[EMAIL PROTECTED]> # # Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> # # Makefile # 2005/04/05 23:36:45+02:00 [EMAIL PROTECTED] +3 -3 # fix make O=... build # diff -Nru a/Makefile b/Makefile --- a/Makefile 2005-04-05 23:37:38 +02:00 +++ b/Makefile 2005-04-05 23:37:38 +02:00 @@ -576,7 +576,7 @@ ifdef CONFIG_LOCALVERSION_AUTO localversion-auto := \ - $(shell $(PERL) $(srctree)/scripts/setlocalversion $(srctree)) + $(shell $(PERL) $(srctree)/scripts/setlocalversion $(srctree)) LOCALVERSION := $(LOCALVERSION)$(localversion-auto) endif @@ -808,7 +808,7 @@ # prepare1 creates a makefile if using a separate output directory prepare1: prepare2 outputmakefile -prepare0: prepare1 include/linux/version.h $(objtree)/include/asm \ +prepare0: prepare1 include/linux/version.h include/asm \ include/config/MARKER ifneq ($(KBUILD_MODULES),) $(Q)rm -rf $(MODVERDIR) @@ -845,7 +845,7 @@ # hard to detect, but I suppose "make mrproper" is a good idea # before switching between archs anyway. -$(objtree)/include/asm: +include/asm: @echo ' SYMLINK $@ -> include/asm-$(ARCH)' $(Q)if [ ! -d include ]; then mkdir -p include; fi; @ln -fsn asm-$(ARCH) $@ - 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/
Re: 2.6.12-rc2-mm1: ACPI=y, ACPI_BOOT=n problems
Adrian Bunk wrote: On Wed, Apr 06, 2005 at 12:32:52AM +1200, Reuben Farrelly wrote: Hi again At 12:14 a.m. 6/04/2005, Adrian Bunk wrote: On Tue, Apr 05, 2005 at 08:34:11PM +1200, Reuben Farrelly wrote: Hi, Hi Reuben, ... Hrm. Something changed between the last -mm release which compiled through, and this one.. ... LD .tmp_vmlinux1 arch/i386/kernel/built-in.o(.init.text+0x1823): In function `setup_arch': : undefined reference to `acpi_boot_table_init' arch/i386/kernel/built-in.o(.init.text+0x1828): In function `setup_arch': : undefined reference to `acpi_boot_init' make: *** [.tmp_vmlinux1] Error 1 [EMAIL PROTECTED] linux-2.6]# Backing out bk-acpi.patch works around it.. Please send your .config . Have just figured out that it seems to be caused by having ACPI disabled in .config, once I re-enabled ACPI the build problem went away. Config attached anyway, I imagine the problem is quite reproduceable.. Ah, this was the working .config . fter setting CONFIG_ACPI=n I started seeing different but most likely related problems. @Len: ACPI=y and ACPI_BOOT=n seems to be a legal configuration (with X86_HT=y), but it breaks into pieces if you try the compilation. Here is some additional and hopefully helpful information. Without CONFIG_ACPI=y, I first got: arch/i386/kernel/setup.c: In function 'setup_arch': arch/i386/kernel/setup.c:1571: warning: implicit declaration of function 'acpi_boot_table_init' arch/i386/kernel/setup.c:1572: warning: implicit declaration of function 'acpi_boot_init' and then at the end: arch/i386/kernel/built-in.o(.init.text+0x1b81): In function `setup_arch': : undefined reference to `acpi_boot_table_init' arch/i386/kernel/built-in.o(.init.text+0x1b86): In function `setup_arch': : undefined reference to `acpi_boot_init' make: *** [.tmp_vmlinux1] Error 1 With these set linux-2.6.12-rc2-mm1 built OK. [EMAIL PROTECTED] linux-2.6.12-rc2-mm1]$ grep ^CONFIG_ACPI .config CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y Steven - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 05:33:49PM +1000, Nick Piggin wrote: > Andrew Morton wrote: > > > +sched-remove-unnecessary-sched-domains.patch > > +sched-improve-pinned-task-handling-again.patch > [snip] > > > > CPU scheduler updates > > > > It is no problem that you picked these up for testing. But > don't merge them yet, please. > > Suresh's underlying problem with the unnecessary sched domains > is a failing of sched-balance-exec and sched-balance-fork, which That wasn't the only motivation. For example, on non-HT cpu's we shouldn't be setting up SMT sched-domain, same with NUMA domains on non-NUMA systems. > I am working on now. > > Removing unnecessary domains is a nice optimisation, but just > needs to account for a few more flags before declaring that a Can you elaborate when we require a domain with special flags but has no or only one group in it. > domain is unnecessary (not to mention this probably breaks if > isolcpus= is used). I have made some modifications to the patch I have tested my patch with "ioslcpus=" and it works just fine. > to fix these problems. > > Lastly, I'd like to be a bit less intrusive with pinned task > handling improvements. I think we can do this while still being > effective in preventing livelocks. We want to see this fixed. Please post your patch and I can let you know the test results. > > I will keep you posted with regards to the various scheduler > patches. Nick, Can you post the patches you sent me earlier to this list? thanks, suresh - 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/
Re: 2.6.12-rc2-mm1
* Brice Goglin <[EMAIL PROTECTED]> wrote:
> >could you send the full bootlog (starting at the 'gcc...' line)? I'm not
> >sure whether TSC calibration was done on your CPU. If cyc2ns_scale is
> >not set up then sched_clock() will return 0, and this could result in
> >that printk symptom.
>
> Here you are.
weird - none of the WARN_ON(1)'s show up. In particular, the
sched_clock() ones should have triggered at least once! I've attached a
new version of the patch below (please unapply the previous patch),
could you try it and send me the log? (It will unconditionally print
something in tsc_init(), which is always called during the boot
process.)
Ingo
--- linux/arch/i386/kernel/timers/timer_tsc.c.orig
+++ linux/arch/i386/kernel/timers/timer_tsc.c
@@ -137,16 +137,15 @@ static unsigned long long monotonic_cloc
unsigned long long sched_clock(void)
{
unsigned long long this_offset;
+ static int once = 1;
- /*
-* In the NUMA case we dont use the TSC as they are not
-* synchronized across all CPUs.
-*/
-#ifndef CONFIG_NUMA
- if (!use_tsc)
-#endif
+ if (!cpu_has_tsc) {
+ if (once) { once = 0; WARN_ON(1); }
/* no locking but a rare wrong value is not a big deal */
return jiffies_64 * (10 / HZ);
+ }
+
+ if (once) { once = 0; WARN_ON(1); }
/* Read the Time Stamp Counter */
rdtscll(this_offset);
@@ -434,7 +433,8 @@ static void mark_offset_tsc(void)
static int __init init_tsc(char* override)
{
-
+ printk("TSC init.\n");
+ WARN_ON(1);
/* check clock override */
if (override[0] && strncmp(override,"tsc",3)) {
#ifdef CONFIG_HPET_TIMER
@@ -443,6 +443,7 @@ static int __init init_tsc(char* overrid
} else
#endif
{
+ WARN_ON(1);
return -ENODEV;
}
}
@@ -518,8 +519,10 @@ static int __init init_tsc(char* overrid
}
set_cyc2ns_scale(cpu_khz/1000);
return 0;
- }
+ } else
+ WARN_ON(1);
}
+ WARN_ON(1);
return -ENODEV;
}
@@ -528,12 +531,14 @@ static int __init init_tsc(char* overrid
* in cpu/common.c */
static int __init tsc_setup(char *str)
{
+ WARN_ON(1);
tsc_disable = 1;
return 1;
}
#else
static int __init tsc_setup(char *str)
{
+ WARN_ON(1);
printk(KERN_WARNING "notsc: Kernel compiled with CONFIG_X86_TSC, "
"cannot disable TSC.\n");
return 1;
--- linux/arch/i386/kernel/timers/common.c.orig
+++ linux/arch/i386/kernel/timers/common.c
@@ -39,8 +39,10 @@ unsigned long __init calibrate_tsc(void)
/* Error: ECTCNEVERSET */
- if (count <= 1)
+ if (count <= 1) {
+ WARN_ON(1);
goto bad_ctc;
+ }
/* 64-bit subtract - gcc just messes up with long longs */
__asm__("subl %2,%0\n\t"
@@ -50,12 +52,16 @@ unsigned long __init calibrate_tsc(void)
"0" (endlow), "1" (endhigh));
/* Error: ECPUTOOFAST */
- if (endhigh)
+ if (endhigh) {
+ WARN_ON(1);
goto bad_ctc;
+ }
/* Error: ECPUTOOSLOW */
- if (endlow <= CALIBRATE_TIME)
+ if (endlow <= CALIBRATE_TIME) {
+ WARN_ON(1);
goto bad_ctc;
+ }
__asm__("divl %2"
:"=a" (endlow), "=d" (endhigh)
@@ -107,12 +113,16 @@ unsigned long __init calibrate_tsc_hpet(
"0" (tsc_endlow), "1" (tsc_endhigh));
/* Error: ECPUTOOFAST */
- if (tsc_endhigh)
+ if (tsc_endhigh) {
+ WARN_ON(1);
goto bad_calibration;
+ }
/* Error: ECPUTOOSLOW */
- if (tsc_endlow <= CALIBRATE_TIME_HPET)
+ if (tsc_endlow <= CALIBRATE_TIME_HPET) {
+ WARN_ON(1);
goto bad_calibration;
+ }
ASM_DIV64_REG(result, remain, tsc_endlow, 0, CALIBRATE_TIME_HPET);
if (remain > (tsc_endlow >> 1))
-
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/
Re: 2.6.12-rc2-mm1
Hi Andrew, > - Nobody said anything about the PM resume and DRI behaviour in > 2.6.12-rc1-mm4. So it's all perfect now? Yes, works for me. DRI (i915) is working again and USB is now happy after a PM resume too. signature.asc Description: This is a digitally signed message part
Re: 2.6.12-rc2-mm1
On Tue, 2005-04-05 at 08:45 +0100, Christoph Hellwig wrote: > This introduces various AUDIT_ARCH numerical constants, which is a blatantly > stupid idea. We already have a way to uniquely identify architectures, and > that's the ELF headers, no need for another parallel namespace. We do use the EM_xxx number space but that isn't sufficient to distinguish between 32-bit and 64-bit incarnations of certain machine types (S390,SH,MIPS,...). I didn't much like adding it either, but couldn't see a better option. I pondered strings but we want to filter on this and don't want to have to use strcmp. Got any better answers? > (btw, could you please add to all patches who's responsible for them, > bk-audit.patch doesn't tell) If it were just to point to the BK tree, that might help. ( linux-audit.bkbits.net/audit-2.6-mm ) -- dwmw2 - 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/
Re: 2.6.12-rc2-mm1
> bk-kbuild.patch Something has broken make O= : $ make mrproper $ mkdir /tmp/42 $ make ARCH=alpha CROSS_COMPILE=alpha-linux- O=/tmp/42 defconfig $ make ARCH=alpha CROSS_COMPILE=alpha-linux- O=/tmp/42 Using /home/jdittmer/src/lk/linus as source for kernel GEN/tmp/42/Makefile CHK include/linux/version.h SYMLINK /tmp/42/include/asm -> include/asm-alpha SPLIT include/linux/autoconf.h -> include/config/* CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/conmakehash make[1]: *** No rule to make target `include/asm', needed by `arch/alpha/kernel/asm-offsets.s'. Stop. make: *** [_all] Error 2 Happens for most archs. See http://l4x.org/k/ Jan - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 06:44:08AM -0700, Barry K. Nathan wrote: > swsusp: reading slkf;jalksfsadflkjas;dlfasdfkl (12345 pages): 34% > [sorry, I just got up so my short-term memory isn't working that well > yet] > > takes 10-30 minutes (depending on whether it's closer to 11000 pages or > 2) rather than the 5-10 seconds or so that it takes under 2.6.11-ac5 > (or mainline 2.6.11 if I remember correctly). [snip] > I'll try to do some more testing to see (a) when this problem started > and (b) whether it still exists in 2.6.12-rc2 or later. This is going to > be ridiculously difficult for me to fit into my schedule right now, but > I'll try 2.6.11-bk9 works (actually it takes under 2 seconds, not 5-10). 2.6.11-bk10 has the weird slowdown. I'll see if I can isolate it any further. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 12:05:24AM -0700, Andrew Morton wrote: > - Nobody said anything about the PM resume and DRI behaviour in > 2.6.12-rc1-mm4. So it's all perfect now? No, I just didn't get a chance to send mail yet. Compared to 2.6.11-ac5, I'm seeing one regression: the part of the resume where it says something like: swsusp: reading slkf;jalksfsadflkjas;dlfasdfkl (12345 pages): 34% [sorry, I just got up so my short-term memory isn't working that well yet] takes 10-30 minutes (depending on whether it's closer to 11000 pages or 2) rather than the 5-10 seconds or so that it takes under 2.6.11-ac5 (or mainline 2.6.11 if I remember correctly). However, this is not vanilla 2.6.12-rc1-mm4. It has my own modified version of the Win4Lin patch applied; this is GPL, but the userspace program that uses this patch (Win4Lin 5.1) isn't, nor is the software ultimately executed by this patch via Win4Lin (Microsoft Windows Millennium Edition[*]). And I didn't try swsusp on any kernels between 2.6.11 and 2.6.12-rc1-mm4. I'll try to do some more testing to see (a) when this problem started and (b) whether it still exists in 2.6.12-rc2 or later. This is going to be ridiculously difficult for me to fit into my schedule right now, but I'll try BTW, ieee1394 is still broken after resume (impossible to rmmod, too) and snd_cmipci (but this can be resurrected by quitting anything that uses sound, rmmod snd_cmipci, then modprobe snd_cmipci). But these are long-standing issues, and under 2.6.12-rc1-mm4, ieee1394/sbp2 can at least stay up indefinitely as long as I don't suspend -- that's a tremendous improvement over 2.6.11. -Barry K. Nathan <[EMAIL PROTECTED]> - 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/
Re: 2.6.12-rc2-mm1
a missing include: ... drivers/usb/storage/debug.c: In function `usb_stor_show_sense': drivers/usb/storage/debug.c:166: warning: implicit declaration of function `scsi_sense_key_string' drivers/usb/storage/debug.c:167: warning: implicit declaration of function `scsi_extd_sense_format' ... --- drivers/usb/storage/debug.c.orig2005-04-05 14:24:21.0 +0200 +++ drivers/usb/storage/debug.c 2005-04-05 14:24:35.0 +0200 @@ -47,7 +47,7 @@ #include #include #include - +#include #include "debug.h" #include "scsi.h" Regards, Boris. - 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/
Re: 2.6.12-rc2-mm1
Hi again At 12:14 a.m. 6/04/2005, Adrian Bunk wrote: On Tue, Apr 05, 2005 at 08:34:11PM +1200, Reuben Farrelly wrote: > Hi, Hi Reuben, >... > Hrm. Something changed between the last -mm release which compiled > through, and this one.. >... > LD .tmp_vmlinux1 > arch/i386/kernel/built-in.o(.init.text+0x1823): In function `setup_arch': > : undefined reference to `acpi_boot_table_init' > arch/i386/kernel/built-in.o(.init.text+0x1828): In function `setup_arch': > : undefined reference to `acpi_boot_init' > make: *** [.tmp_vmlinux1] Error 1 > [EMAIL PROTECTED] linux-2.6]# > > Backing out bk-acpi.patch works around it.. Please send your .config . Have just figured out that it seems to be caused by having ACPI disabled in .config, once I re-enabled ACPI the build problem went away. Config attached anyway, I imagine the problem is quite reproduceable.. Reuben .config Description: Binary data
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 08:34:11PM +1200, Reuben Farrelly wrote: > Hi, Hi Reuben, >... > Hrm. Something changed between the last -mm release which compiled > through, and this one.. >... > LD .tmp_vmlinux1 > arch/i386/kernel/built-in.o(.init.text+0x1823): In function `setup_arch': > : undefined reference to `acpi_boot_table_init' > arch/i386/kernel/built-in.o(.init.text+0x1828): In function `setup_arch': > : undefined reference to `acpi_boot_init' > make: *** [.tmp_vmlinux1] Error 1 > [EMAIL PROTECTED] linux-2.6]# > > Backing out bk-acpi.patch works around it.. Please send your .config . > reuben cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 07:35:46PM +1000, Paul Mackerras wrote: > Christoph Hellwig writes: > > > It's documented where the other filesystem entry points are documented. > > Which is? > > $ grep -r compat_ioctl Documentation > Documentation/filesystems/Locking: long (*compat_ioctl) (struct file *, > unsigned int, unsigned long); > Documentation/filesystems/Locking:compat_ioctl: no > > Marvellous documentation, that. :) The other methods don't have much more documentation either ;-) - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 07:51:57PM +1000, Paul Mackerras wrote: > Christoph Hellwig writes: > > > Please make it a module option so it doesn't regress everyone for your > > specific needs. > > Sorry, I don't follow you. E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled in for running i386 apps. But I don't want dri to hand out 32bit handles everywhere just because of that, because I most certainly won't be running i386 OpenGL apps. - 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/
Re: 2.6.12-rc2-mm1
Christoph Hellwig writes: > - the magic CONFIG_COMPAT changes for SHM handles should only be done when >a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can >run 32bit code and drm shouldn't behave differently just because we can >run 32bit code. Yes it should - we can have a 64-bit X server and a 32-bit DRI client. In this case the server will allocate a _DRM_SHM area and pass the handle to the client, which will then try to mmap the area. If we give a 64-bit handle to the server the client won't be able to access the area. Paul. - 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/
Re: 2.6.12-rc2-mm1
On 095, 04 05, 2005 at 12:05:24AM -0700, Andrew Morton wrote:
what useful this part of the patch is supposed to do ?
Looks like the result of whitespace damage.
--- linux-2.6.12-rc2/drivers/acpi/sleep/main.c 2005-03-02 01:09:19.0
-0800
+++ 25/drivers/acpi/sleep/main.c2005-04-04 22:33:10.0 -0700
@@ -190,16 +180,16 @@ static int __init init_ints_after_s1(str
static struct dmi_system_id __initdata acpisleep_dmi_table[] = {
{
- .callback = init_ints_after_s1,
- .ident = "Toshiba Satellite 4030cdt",
- .matches = { DMI_MATCH(DMI_PRODUCT_NAME, "S4030CDT/4.3"), },
- },
- { },
+.callback = init_ints_after_s1,
+.ident = "Toshiba Satellite 4030cdt",
+.matches = {DMI_MATCH(DMI_PRODUCT_NAME, "S4030CDT/4.3"),},
+},
+ {},
};
-
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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 07:58:19PM +1000, Dave Airlie wrote: > > > > E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled > > in for running i386 apps. But I don't want dri to hand out 32bit handles > > everywhere just because of that, because I most certainly won't be running > > i386 OpenGL apps. > > > > It doesn't actually matter what size the handles are from what I > understand of this... as long as they are hashed properly.. I've been > thinking of changing the handle from something with meaning to a hash > just to find out some more bugs.. even on plain 32-bit systems.. Or, I though the handle was related to the dma_mask somewhat. I'll take all flames on this subject back and apologize for not researching the subject better, although I still think it's not a good idea to have a different handle format depending on whether CONFIG_COMPAT is set or not. - 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/
Re: 2.6.12-rc2-mm1
Andrew Morton wrote: [...] Does not compile on AthlonXP. For mmx_clear_page, only the prototype was changed, but the implementation is still the same. I guess that part of the patch slipped out somehow. -extern void mmx_clear_page(void *page); +extern void mmx_clear_page(void *page, int order); -- Jindrich Makovicka - 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/
Re: 2.6.12-rc2-mm1
> > E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled > in for running i386 apps. But I don't want dri to hand out 32bit handles > everywhere just because of that, because I most certainly won't be running > i386 OpenGL apps. > It doesn't actually matter what size the handles are from what I understand of this... as long as they are hashed properly.. I've been thinking of changing the handle from something with meaning to a hash just to find out some more bugs.. even on plain 32-bit systems.. Dave. - 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/
Re: 2.6.12-rc2-mm1
Christoph Hellwig writes: > E.g. on my ia64 box CONFIG_COMPAT is set because I have support compiled > in for running i386 apps. But I don't want dri to hand out 32bit handles > everywhere just because of that, because I most certainly won't be running > i386 OpenGL apps. The handle for a _DRM_SHM area is almost completely arbitrary, why do you care whether it fits in 32 bits or not? All that matters is that you can take the handle you get and use it as the offset in an mmap call. The CONFIG_COMPAT changes don't break 64-bit clients. Paul. - 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/
Re: 2.6.12-rc2-mm1
Christoph Hellwig writes: > It's documented where the other filesystem entry points are documented. Which is? $ grep -r compat_ioctl Documentation Documentation/filesystems/Locking: long (*compat_ioctl) (struct file *, unsigned int, unsigned long); Documentation/filesystems/Locking:compat_ioctl: no Marvellous documentation, that. :) > This is not about beeing impatient but about adding APIs that at the same > time are actively removed all over the tree. Sure, just don't be so impatient... :) > You can of course take the BKL inside your ->compat_ioctl method. Yes, the question is whether we need to or not. Paul. - 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/
Re: 2.6.12-rc2-mm1
Christoph Hellwig writes: > Please make it a module option so it doesn't regress everyone for your > specific needs. Sorry, I don't follow you. - 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/
Re: 2.6.12-rc2-mm1
On Tue, Apr 05, 2005 at 07:44:38PM +1000, Paul Mackerras wrote: > Christoph Hellwig writes: > > > - the magic CONFIG_COMPAT changes for SHM handles should only be done when > >a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can > >run 32bit code and drm shouldn't behave differently just because we can > >run 32bit code. > > Yes it should - we can have a 64-bit X server and a 32-bit DRI > client. In this case the server will allocate a _DRM_SHM area and > pass the handle to the client, which will then try to mmap the area. > If we give a 64-bit handle to the server the client won't be able to > access the area. Please make it a module option so it doesn't regress everyone for your specific needs. - 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/
Re: 2.6.12-rc2-mm1
On Tue, 2005-04-05 at 19:20 +1000, Paul Mackerras wrote: > Dave Airlie writes: > > > Paulus these look like your patches care to update them with the "new" > > method of doing stuff.. > > What are we going to do about the DRM CVS? Change it to the new way > and break everyone running 2.6.10 or earlier, or leave it at the old > way that will work for people with distro kernels, and have a > divergence between it and what's in the kernel? (some distros like Fedora Core have modern kernels even for older releases) > Also, the compat_ioctl method is called without the BKL held, unlike > the ioctl method. What impact will that have? Do we need to take the > BKL in the compat_ioctl method? How much does DRM actually depend on the BKL? I would hope not too much... - 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/
Re: 2.6.12-rc2-mm1
Btw, some more comments on the 32bit compat code in drm: - instead of set_fs & co and passing kernel addresses to drm_ioctl please use compat_alloc_user_space() - this: +ifeq ($(CONFIG_COMPAT),y) +drm-objs+= drm_ioc32.o +radeon-objs += radeon_ioc32.o +endif should be written as drm-$(CONFIG_COMPAT)+= drm_ioc32.o radeon-$(CONFIG_COMPAT) += radeon_ioc32.o and everything else should use foo-y instead of foo-objs - the magic CONFIG_COMPAT changes for SHM handles should only be done when a module is set. CONFIG_COMPAT is set for mostly 64bit systems that can run 32bit code and drm shouldn't behave differently just because we can run 32bit code. - 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/
Re: 2.6.12-rc2-mm1
> > > Paulus these look like your patches care to update them with the "new" > > method of doing stuff.. > > What are we going to do about the DRM CVS? Change it to the new way > and break everyone running 2.6.10 or earlier, or leave it at the old > way that will work for people with distro kernels, and have a > divergence between it and what's in the kernel? Yet more backwards compatibility is more than likely going to be needed, but if it is a biggie I'd be happy to drop the older 32/64-bit stuff from CVS and make it contingent on having 2.6.11 or greater as it is a new feature anyways and hasn't seen a release yet... > > Also, the compat_ioctl method is called without the BKL held, unlike > the ioctl method. What impact will that have? Do we need to take the > BKL in the compat_ioctl method? I don't think so as the DRM has its own locking that handles most of the issues at a higher level... I've been thinking of switching DRM to ioctl_unlocked but I'd really want someone with an SMP system to beat on it .. (not that the DRI has a great record on SMP anyways..) Dave. Dave. - 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/
Re: 2.6.12-rc2-mm1
Dave Airlie writes: > Paulus these look like your patches care to update them with the "new" > method of doing stuff.. What are we going to do about the DRM CVS? Change it to the new way and break everyone running 2.6.10 or earlier, or leave it at the old way that will work for people with distro kernels, and have a divergence between it and what's in the kernel? Also, the compat_ioctl method is called without the BKL held, unlike the ioctl method. What impact will that have? Do we need to take the BKL in the compat_ioctl method? Paul. - 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/
