* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 07 Feb 2007 00:17:33 +0100
> Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2007-02-07 at 00:12 +0100, Tilman Schmidt wrote:
> > > > No, not this. Anyway the last patch Thomas forwarded does fix the
> > > > problem.
> > >
> > > Whic
On Tue, 2007-02-06 at 17:12 -0800, Daniel Walker wrote:
> On Wed, 2007-02-07 at 00:36 +0100, Thomas Gleixner wrote:
>
> > There are no other clock event devices in a PC system at the moment
> > and /proc/interrupt does not care, whether the interrupt was setup for a
> > clock event device or somet
I guess I will respond
On Wed, 2007-02-07 at 00:51 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > | If we change the current "timer" entry to be listed as
> > > | "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > > | and replace it with th
On Wed, 2007-02-07 at 00:36 +0100, Thomas Gleixner wrote:
> There are no other clock event devices in a PC system at the moment
> and /proc/interrupt does not care, whether the interrupt was setup for a
> clock event device or something else. It displays the name which is
> given in the irqaction
On Wed, 07 Feb 2007 00:17:33 +0100
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-07 at 00:12 +0100, Tilman Schmidt wrote:
> > > No, not this. Anyway the last patch Thomas forwarded does fix the
> > > problem.
> >
> > Which one would that be? I might try it for comparison.
>
> Find
On Tuesday 06 February 2007 6:28 pm, Daniel Walker wrote:
> On Tue, 2007-02-06 at 18:15 -0500, Rob Landley wrote:
> > On Tuesday 06 February 2007 3:40 pm, Daniel Walker wrote:
> > > In this case "different" goes into userspace .. So different could mean
> > > userspace regression, which is somethin
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > | If we change the current "timer" entry to be listed as
> > | "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > | and replace it with the count from LOC
> >
> > this is a pretty clear sentence, i dont think i misunderstood
> >
On Tue, 2007-02-06 at 15:35 -0800, Daniel Walker wrote:
> Last and final correction. I'm saying drop the timer entry, which means
> drop the call to request_irq() for irq0.
Right, that's a real good suggestion. Here's the patch especially for
you. Apply it and figure out yourself, why your compute
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > > > the kernel simply displays reality: IRQ#0 isnt increasing
> > > > because it's not used, and LOC (local apic timers) is
> > > > increasing.
> > >
> > > What about the statistics for the other interrupts in the system ?
> > > It clearly doesn'
On Wed, 2007-02-07 at 00:28 +0100, Ingo Molnar wrote:
> actually, i quoted what you said:
>
> | If we change the current "timer" entry to be listed as "lapic-timer"
> | and not "IO-APIC-edge" (or one of the other names) and replace it with
> | the count from LOC
>
> this is a pretty clear sent
On Tue, 2007-02-06 at 15:22 -0800, Daniel Walker wrote:
> > > What about the statistics for the other interrupts in the system ? It
> > > clearly doesn't list all interrupts in the system .
> >
> > what is your point?
>
> Isn't the listing inconsistent ? /proc/interrupts only showing some
> spe
On Tue, 2007-02-06 at 18:15 -0500, Rob Landley wrote:
> On Tuesday 06 February 2007 3:40 pm, Daniel Walker wrote:
> > In this case "different" goes into userspace .. So different could mean
> > userspace regression, which is something that we don't want. I have no
> > idea if any apps use /proc/int
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-07 at 00:14 +0100, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> > >
> > > > changing the current 'timer' entry (which is line 2 of
> > > > /proc/i
On Wed, 2007-02-07 at 00:14 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> >
> > > changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> > > to be 'listed as lapic-timer' and to 'replace it
On Wed, 2007-02-07 at 00:12 +0100, Tilman Schmidt wrote:
> > No, not this. Anyway the last patch Thomas forwarded does fix the
> > problem.
>
> Which one would that be? I might try it for comparison.
Find the combined patch of all fixlets on top of -mm3 below.
tglx
Index: linux-2.6.20/k
On Tuesday 06 February 2007 3:40 pm, Daniel Walker wrote:
> In this case "different" goes into userspace .. So different could mean
> userspace regression, which is something that we don't want. I have no
> idea if any apps use /proc/interrupts , but it's possible since it's
> been around for a lon
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
>
> > changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> > to be 'listed as lapic-timer' and to 'replace it with the count from
> > LOC' is faking a count in a line where
Am 06.02.2007 20:28 schrieb Mattia Dongili:
> On Tue, Feb 06, 2007 at 05:48:26PM +0100, Ingo Molnar wrote:
>> Could you try the patch below? The RCU serialization code (a rare call
>> but can be common in some types of setups) has a nasty implicit
>> dependency on the HZ tick - which until now wa
On Tue, 2007-02-06 at 23:56 +0100, Ingo Molnar wrote:
> changing the current 'timer' entry (which is line 2 of /proc/interrupts)
> to be 'listed as lapic-timer' and to 'replace it with the count from
> LOC' is faking a count in a line where nothing like that should be.
This point is getting irr
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-02-06 at 23:08 +0100, Ingo Molnar wrote:
>
> > sorry but that's precisely what your suggestion above results in:
>
> I'm not trying to suggest we "fake" anything. Your just
> misunderstanding me.. [...]
as i pointed it out in the previ
On Tue, 2007-02-06 at 23:08 +0100, Ingo Molnar wrote:
> sorry but that's precisely what your suggestion above results in:
I'm not trying to suggest we "fake" anything. Your just misunderstanding
me.. I'm am suggesting we change LOC to something readable. If you think
we're "faking" something by d
On Tue, 2007-02-06 at 13:54 -0800, Daniel Walker wrote:
> > The same happens when say a network driver implements NAPI: the IRQ
> > count goes way, way down. Or if a driver starts supporing MSI - the IRQ
> > line even moves to another one. Do we try to fix those counts up to
> > match the 'previ
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > > If we change the current "timer" entry to be listed as
> > > "lapic-timer" and not "IO-APIC-edge" (or one of the other names)
> > > and replace it with the count from LOC
[...]
> > But, as per the previous mails, the new behavior is just fine,
>
On Tue, 2007-02-06 at 22:43 +0100, Thomas Gleixner wrote:
> > I think the regression (if you can call it that) is not scripts
> > crashing, but more people not know what's going on with there system ..
>
> I did not hear a complaint of anyone except you. I doubt that there will
> be a big confus
On Tue, 2007-02-06 at 22:41 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > we could make this clearer by renaming 'LOC' (which stands for
> > > 'LOCal timer interupts' and was added [and misnamed] by yours truly
> > > many moons ago) to 'apic-timer' and 'timer' to
On Tue, 2007-02-06 at 13:23 -0800, Daniel Walker wrote:
> > we could make this clearer by renaming 'LOC' (which stands for 'LOCal
> > timer interupts' and was added [and misnamed] by yours truly many moons
> > ago) to 'apic-timer' and 'timer' to 'PIT-timer' but /that/ would be more
> > of a user
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > we could make this clearer by renaming 'LOC' (which stands for
> > 'LOCal timer interupts' and was added [and misnamed] by yours truly
> > many moons ago) to 'apic-timer' and 'timer' to 'PIT-timer' but
> > /that/ would be more of a userspace visib
On Tue, 2007-02-06 at 22:17 +0100, Thomas Gleixner wrote:
> > The reason that I'm bringing it up at all is because people have ask me
> > "Why isn't my timer ticking??"
>
> So it's a problem of user perception and not of a user space regression.
> Please stop confusing things.
At least we agree
On Tue, 2007-02-06 at 22:09 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > it's quite easy to explain: because of the new dynticks feature.
> > > Both 'timer' and 'LOC' counts go way down.
> >
> > I don't have that enabled tho .. This is with HRT/dynamic tick both
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > I don't have that enabled tho .. This is with HRT/dynamic tick both
> > off..
>
> your kernel utilizes the kernel in a more optimal way: the new
^hardware
> clockevents code now utilizes the loc
On Tue, 2007-02-06 at 12:40 -0800, Daniel Walker wrote:
> > Yes, it is different. Why are you insisting, that something is a problem
> > just because it is different ?
>
> In this case "different" goes into userspace .. So different could mean
> userspace regression, which is something that we don
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> > it's quite easy to explain: because of the new dynticks feature.
> > Both 'timer' and 'LOC' counts go way down.
>
> I don't have that enabled tho .. This is with HRT/dynamic tick both
> off..
your kernel utilizes the kernelin a more optimal way:
On Tue, 2007-02-06 at 21:52 +0100, Ingo Molnar wrote:
> Well, if you enable dynticks you should expect the number of timer irqs
> to go down. There's no problem here.
Ok .
> > The reason that I'm bringing it up at all is because people have ask
> > me "Why isn't my timer ticking??"
>
> it's q
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-02-06 at 21:20 +0100, Thomas Gleixner wrote:
> > On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > > > What kind of artificial problem are you creating here ?
> > >
> > > I'm not trying to create anything .. However, as I said be
On Tue, 2007-02-06 at 21:20 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > > What kind of artificial problem are you creating here ?
> >
> > I'm not trying to create anything .. However, as I said before
> > the /proc/interrupts "timer" entry doesn't wor
On Tue, 2007-02-06 at 11:55 -0800, Daniel Walker wrote:
> > What kind of artificial problem are you creating here ?
>
> I'm not trying to create anything .. However, as I said before
> the /proc/interrupts "timer" entry doesn't work the same as it has in
> other kernels.
Yes, it is different. Why
On Tue, 2007-02-06 at 20:07 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 10:45 -0800, Daniel Walker wrote:
> > > > -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> > > > related ..
> > >
> > > And why should it increment ? Is there a rule that it has to ?
> >
> >
On Tue, Feb 06, 2007 at 05:48:26PM +0100, Ingo Molnar wrote:
>
> Mattia,
>
> * Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > > I have it halfways reproducible now and I'm working to find the root
> > > cause. Thanks for providing the info.
> >
> > Great, I'm obviously available to test any p
On Tue, 2007-02-06 at 10:45 -0800, Daniel Walker wrote:
> > > -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> > > related ..
> >
> > And why should it increment ? Is there a rule that it has to ?
>
> I don't know .. I would imagine some users might look at it and wonder
On Tue, 2007-02-06 at 19:36 +0100, Thomas Gleixner wrote:
> On Tue, 2007-02-06 at 08:03 -0800, Daniel Walker wrote:
> > It appears there a problem with the /proc/interrupts entry for
> > "timer" .. It doesn't increment anymore .. This problem exists in the
> > -rt tree also .. I haven't done a bise
On Tue, 2007-02-06 at 08:03 -0800, Daniel Walker wrote:
> It appears there a problem with the /proc/interrupts entry for
> "timer" .. It doesn't increment anymore .. This problem exists in the
> -rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
> related ..
And why should it
Mattia,
* Mattia Dongili <[EMAIL PROTECTED]> wrote:
> > I have it halfways reproducible now and I'm working to find the root
> > cause. Thanks for providing the info.
>
> Great, I'm obviously available to test any patch :)
Could you try the patch below? The RCU serialization code (a rare call
It appears there a problem with the /proc/interrupts entry for
"timer" .. It doesn't increment anymore .. This problem exists in the
-rt tree also .. I haven't done a bisect , but I'm assuming this is HRT
related ..
Also my NMI watchdog isn't functioning , which also exists in the -rt
tree, and -
On Mon, 05 Feb 2007 20:55:35 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> Seeing these BUGs on 2.6.20-rc6-mm3 when mounting an NTFS partition. I
> saw some reports of something like this on -mm1, was this supposed to be
> patched already?
>
> BUG: at arch/i386/mm/highmem.c:52 kmap_atomic()
On Mon, Feb 05 2007, Christoph Lameter wrote:
> On Mon, 5 Feb 2007, Jens Axboe wrote:
>
> > But for now this is just a debug test, can you see if xfs with barriers
> > for that kernel now works as expected?
>
> The kernel that failed before boots fine with this patch.
Wonderful, I'll leave the p
On Mon, 5 Feb 2007, Jens Axboe wrote:
> But for now this is just a debug test, can you see if xfs with barriers
> for that kernel now works as expected?
The kernel that failed before boots fine with this patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Dave Jones wrote:
On Mon, Feb 05, 2007 at 01:56:22PM +0100, Thomas Hellström wrote:
> Dave Jones wrote:
> > On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> > > On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > > > Eric,
> > > > Sorry for the breakage
On Mon, Feb 05, 2007 at 01:56:22PM +0100, Thomas Hellström wrote:
> Dave Jones wrote:
> > On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> > > On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > > > Eric,
> > > > Sorry for the breakage. Can you try the at
Dave Jones wrote:
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > Eric,
> > Sorry for the breakage. Can you try the attached patch and see if it
> > fixes the problem.
> >
> > /Thomas
>
> Thomas,
On Mon, Feb 05 2007, Jens Axboe wrote:
> On Mon, Feb 05 2007, Jens Axboe wrote:
> > On Thu, Feb 01 2007, Christoph Lameter wrote:
> > > On Thu, 1 Feb 2007, Jens Axboe wrote:
> > >
> > > > That looks like barriers, could you try with those disabled? Sorry for
> > > > making you go through this, I c
On Mon, Feb 05 2007, Jens Axboe wrote:
> On Thu, Feb 01 2007, Christoph Lameter wrote:
> > On Thu, 1 Feb 2007, Jens Axboe wrote:
> >
> > > That looks like barriers, could you try with those disabled? Sorry for
> > > making you go through this, I can't debug and fix it myself before
> > > monday.
>
On Thu, Feb 01 2007, Christoph Lameter wrote:
> On Thu, 1 Feb 2007, Jens Axboe wrote:
>
> > That looks like barriers, could you try with those disabled? Sorry for
> > making you go through this, I can't debug and fix it myself before
> > monday.
>
> Disabling barriers + your patch works. Modified
On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
> On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> > Eric,
> > Sorry for the breakage. Can you try the attached patch and see if it
> > fixes the problem.
> >
> > /Thomas
>
> Thomas,
>
> Thanks! That s
On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
> Eric,
> Sorry for the breakage. Can you try the attached patch and see if it
> fixes the problem.
>
> /Thomas
Thomas,
Thanks! That seems to fix it:
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt :01:00.0[A] -> GS
Eric Buddington wrote:
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
What AGP chipset do you have? it looks like it might be caused by the
AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI bridg
On Sun, Feb 04, 2007 at 10:20:29AM +1100, Dave Airlie wrote:
> What AGP chipset do you have? it looks like it might be caused by the
> AGP changes for TTM..
lspci:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 741/741GX/M741 Host (rev
03)
00:01.0 PCI bridge: Silicon Integrated Systems [S
agpgart: Found an AGP 3.5 compliant device at :00:00.0.
agpgart: Device is in legacy mode, falling back to 2.x
agpgart: Putting AGP V2 device at :00:00.0 into 1x mode
agpgart: Putting AGP V2 device at :01:00.0 into 1x mode
BUG: unable to handle kernel NULL pointer dereference at virtua
On Sat, Feb 03, 2007 at 04:22:17PM -0500, Lee Revell wrote:
> On 2/3/07, Eric Buddington <[EMAIL PROTECTED]> wrote:
> >EIP:0060:[<>]Tainted: G M VLI
> >EFLAGS: 00013246 (2.6.20-rc6-mm3 #1)
>
> The "M" taint flag indicates that a machine check exception has
> occured. Check y
On 2/3/07, Eric Buddington <[EMAIL PROTECTED]> wrote:
EIP:0060:[<>]Tainted: G M VLI
EFLAGS: 00013246 (2.6.20-rc6-mm3 #1)
The "M" taint flag indicates that a machine check exception has
occured. Check your logs for the MCE and make sure the hardware is
OK.
Lee
-
To unsubs
Hi!
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > Serial port console is off here and the jiffies update fix doesn't
> > make a noticeable difference.
>
> ok, this eliminates my serial port theory.
>
> and this means i'm having trouble reproducing this problem locally.
> Maybe i tried it
ric Le Goater [mailto:[EMAIL PROTECTED]
>Sent: Saturday, February 03, 2007 10:30 AM
>To: Cedric Le Goater
>Cc: Starikovskiy, Alexey Y; Andrew Morton;
linux-kernel@vger.kernel.org;
>Moore, Robert; keith mannthey
>Subject: Re: 2.6.20-rc6-mm3
>
>Cedric Le Goater wrote:
>> Star
Cedric Le Goater wrote:
> Starikovskiy, Alexey Y wrote:
>>> so it probably means that drivers/acpi/tables/tbxfroot.c is
>>> obsolete ?
>> Yes.
Could you please try it?
>>> sure, I'll cancel the current boot test in which I was using
>>> acpi_find_root_pointer() in tbxfroot.c and restart one wi
On Fri, Feb 02, 2007 at 09:27:14PM +0100, Thomas Gleixner wrote:
> On Fri, 2007-02-02 at 20:18 +0100, Mattia Dongili wrote:
> > > May I ask you for another test ? Please turn on high resolution timers
> > > and check, if the same strange behaviour is happening.
> >
> > Yep, here we go again. Still
On Fri, 2007-02-02 at 20:18 +0100, Mattia Dongili wrote:
> > May I ask you for another test ? Please turn on high resolution timers
> > and check, if the same strange behaviour is happening.
>
> Yep, here we go again. Still seeing long stalls but no negative expires
> offset.
> Actually one more t
Cc-ing netdev and netfilter-devel, the beginning of the thread is here
http://lkml.org/lkml/2007/1/31/306
On Thu, Feb 01, 2007 at 11:33:22PM +0100, Thomas Gleixner wrote:
> Mattia,
...
> May I ask you for another test ? Please turn on high resolution timers
> and check, if the same strange behavio
On Mon, 2007-01-29 at 20:45 -0800, Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-rc6-mm3/
>
> Will appear later at
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/
>
I was running likely profiling and
Starikovskiy, Alexey Y wrote:
>> so it probably means that drivers/acpi/tables/tbxfroot.c is
>> obsolete ?
> Yes.
>>> Could you please try it?
>> sure, I'll cancel the current boot test in which I was using
>> acpi_find_root_pointer() in tbxfroot.c and restart one with your
>> new patch. I should h
>so it probably means that drivers/acpi/tables/tbxfroot.c is
>obsolete ?
Yes.
>
>> Could you please try it?
>
>sure, I'll cancel the current boot test in which I was using
>acpi_find_root_pointer() in tbxfroot.c and restart one with your
>new patch. I should have the result today.
How long does it
Hello !
Starikovskiy, Alexey Y wrote:
> Hi,
> I updated patch to use acpi_find_rsdp(), as all other code does.
so it probably means that drivers/acpi/tables/tbxfroot.c is
obsolete ?
> Could you please try it?
sure, I'll cancel the current boot test in which I was using
acpi_find_root_pointer(
lexey Y; Andrew Morton;
linux-kernel@vger.kernel.org;
>Moore, Robert; keith mannthey
>Subject: Re: 2.6.20-rc6-mm3
>
>Cedric Le Goater wrote:
>> Starikovskiy, Alexey Y wrote:
>>> Sorry, here is the patch... ACPI has switched to acpi_find_rsdp(),
so
>>> srat.c mi
On Fri, Feb 02 2007, David Chinner wrote:
> On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> > That down() probably wants a replug to precede it. Probably something
> > like:
> >
> > if (atomic_read(&bp->b_io_remaining))
> > blk_replug_current_nested();
> >
>
On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> That down() probably wants a replug to precede it. Probably something
> like:
>
> if (atomic_read(&bp->b_io_remaining))
> blk_replug_current_nested();
>
> for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this f
On Thu, 1 Feb 2007, Jens Axboe wrote:
> That looks like barriers, could you try with those disabled? Sorry for
> making you go through this, I can't debug and fix it myself before
> monday.
Disabling barriers + your patch works. Modified /etc/fstab and added a
nobarrier option to the root filesy
Mattia,
On Thu, 2007-02-01 at 22:11 +0100, Mattia Dongili wrote:
> > It might be helpful if you could try with your original config again.
> > Please enable printk timestamps and SysRq. Once the slowness kicks in
> > please issue a SysRq-Q, so we can look at the internal state of the tick
> > code
On Thu, Feb 01, 2007 at 09:01:41PM +0100, Thomas Gleixner wrote:
> On Thu, 2007-02-01 at 20:36 +0100, Thomas Gleixner wrote:
> > On Thu, 2007-02-01 at 00:21 +0100, Mattia Dongili wrote:
> > > yes, slowness is gone. Any useful information I can provide?
> >
> > Can you please try with CONFIG_ACPI_
On Thu, Feb 01, 2007 at 09:01:41PM +0100, Thomas Gleixner wrote:
> On Thu, 2007-02-01 at 20:36 +0100, Thomas Gleixner wrote:
> > On Thu, 2007-02-01 at 00:21 +0100, Mattia Dongili wrote:
> > > yes, slowness is gone. Any useful information I can provide?
> >
> > Can you please try with CONFIG_ACPI_
Cedric Le Goater wrote:
> Starikovskiy, Alexey Y wrote:
>> Sorry, here is the patch... ACPI has switched to acpi_find_rsdp(), so
>> srat.c might want to do that too, please check.
>
> got it. running a compile and boot test.
hmm, i got another issue while compiling :
CHK include/linux/com
Starikovskiy, Alexey Y wrote:
> Sorry, here is the patch... ACPI has switched to acpi_find_rsdp(), so
> srat.c might want to do that too, please check.
got it. running a compile and boot test.
I should have the results in 'my' morning (UTC+1).
Thanks !
C.
-
To unsubscribe from this list: send
On Thu, Feb 01 2007, Christoph Lameter wrote:
> On Thu, 1 Feb 2007, Jens Axboe wrote:
>
> > for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this fix it?
>
> No it still hangs consistently. This time at an earlier spot.
That looks like barriers, could you try with those disabled? Sorry for
maki
On Thu, Feb 01, 2007 at 08:36:12PM +0100, Thomas Gleixner wrote:
> On Thu, 2007-02-01 at 00:21 +0100, Mattia Dongili wrote:
> > yes, slowness is gone. Any useful information I can provide?
>
> Can you please try with CONFIG_ACPI_PROCESSOR=y instead of =m ? This
> should make the slowness go away
On Thu, 1 Feb 2007, Jens Axboe wrote:
> for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this fix it?
No it still hangs consistently. This time at an earlier spot.
All OS INIT slaves have reached rendezvous
Processes interrupted by INIT - 0 (cpu 0 task 0xa00100b24000) 0 (cpu 1
task 0xe000
On Thu, 2007-02-01 at 20:36 +0100, Thomas Gleixner wrote:
> On Thu, 2007-02-01 at 00:21 +0100, Mattia Dongili wrote:
> > yes, slowness is gone. Any useful information I can provide?
>
> Can you please try with CONFIG_ACPI_PROCESSOR=y instead of =m ? This
> should make the slowness go away too.
>
n
>Cc: linux-kernel@vger.kernel.org; Moore, Robert; Starikovskiy, Alexey
Y;
>keith mannthey
>Subject: Re: 2.6.20-rc6-mm3
>
>Hello !
>
>changes in git-acpi.patch in 2.6.20-rc6-mm3 (and maybe before) broke
the
>Summit
>sub-arch (IBM x440) compile :(
>
>thanks,
>
>
On Thu, 2007-02-01 at 00:21 +0100, Mattia Dongili wrote:
> yes, slowness is gone. Any useful information I can provide?
Can you please try with CONFIG_ACPI_PROCESSOR=y instead of =m ? This
should make the slowness go away too.
I think I know what happens. I try to reproduce with
CONFIG_ACPI_PROC
On Thu, Feb 01 2007, Christoph Lameter wrote:
> On Wed, 31 Jan 2007, Andrew Morton wrote:
>
> > But usually none of that is necessary, because io_schedule() does all the
> > work for you.
> >
> > err, this might help.
>
> Well okay boot progresses further (maybe only on this boot) but system is
* Mattia Dongili <[EMAIL PROTECTED]> wrote:
> > Full dmesg and config:
> > http://oioio.altervista.org/linux/nohz_soft-lockup.dmesg
> > http://oioio.altervista.org/linux/config-2.6.20-rc6-mm3-1
> >
> > As a side note the process becomes slower and slower as it proceeds,
> > it's definitely noti
On Wed, 31 Jan 2007, Andrew Morton wrote:
> But usually none of that is necessary, because io_schedule() does all the
> work for you.
>
> err, this might help.
Well okay boot progresses further (maybe only on this boot) but system is
still hung.
Traces (this was a backtrace of all processes on
Hello !
changes in git-acpi.patch in 2.6.20-rc6-mm3 (and maybe before) broke the Summit
sub-arch (IBM x440) compile :(
thanks,
C.
CC arch/i386/kernel/cpu/intel.o
CC arch/i386/kernel/early_printk.o
arch/i386/kernel/srat.c: In function 'parse_cpu_affinity_structure':
arch/i386/
Am Donnerstag, 1. Februar 2007 11:44 schrieb Karsten Wiese:
> I think the wait is caused by an interrupt starting somewhere under
> sysdev_resume(void).
> possibly lapic timer interrupt? Will try to trace that.
Some evidence:
[EMAIL PROTECTED] Desktop]# echo reboot > /sys/power/disk
[EMAIL PROTECT
Am Donnerstag, 1. Februar 2007 09:01 schrieb Ingo Molnar:
>
> and this means i'm having trouble reproducing this problem locally.
> Maybe i tried it the wrong way: does it only occur with suspend-to-disk,
> or suspend-to-ram too? Does it need ACPI suspend-to-disk, or
> software-suspend?
Haven'
* Karsten Wiese <[EMAIL PROTECTED]> wrote:
> Serial port console is off here and the jiffies update fix doesn't
> make a noticeable difference.
ok, this eliminates my serial port theory.
and this means i'm having trouble reproducing this problem locally.
Maybe i tried it the wrong way: does i
On Thu, 1 Feb 2007 17:20:18 +1100 David Chinner <[EMAIL PROTECTED]> wrote:
> What are the new unplugging rules introduced by the git-block
> patch?
Pretty simple: you read the largely-useless changelog then call the bravely
uncommented blk_plug_current() when you're about to submit some IO and yo
On Wed, Jan 31, 2007 at 04:36:38PM -0800, Andrew Morton wrote:
> On Wed, 31 Jan 2007 16:27:16 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 31 Jan 2007, Andrew Morton wrote:
> >
> > > ow. Please don't make me drop git-block-and-lots-of-other-things again.
> > > Was 2.6
On Tuesday 30 January 2007 04:26, Andrew Morton wrote:
> On Tue, 30 Jan 2007 10:06:45 +0100
> Olivier Galibert <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jan 29, 2007 at 08:45:28PM -0800, Andrew Morton wrote:
> > > -x86_64-mm-share-whats-shareable.patch
> > > -x86_64-mm-only-call-unreachable_devices
On Wed, 31 Jan 2007 23:10:32 -0500 Len Brown <[EMAIL PROTECTED]> wrote:
> > CC arch/i386/kernel/traps.o
> > CC arch/i386/kernel/irq.o
> > CC arch/i386/kernel/ptrace.o
> > CC arch/i386/kernel/time.o
> > CC arch/i386/kernel/ioport.o
> > CC arch/i386/kernel/l
On Wednesday 31 January 2007 06:54, Maciej Rutecki wrote:
> Andrew Morton napisał(a):
>
> > OK, thanks. That might be due to the time-management updates as well.
> > I'll see if I can reproduce this.
> >
> > If you're keen, you could test just 2.6.19-rc6+origin.patch+git-acpi.patch
> > from
> >
On Tuesday 30 January 2007 06:52, Sunil Naidu wrote:
> Hi Andrew,
>
> I did compile the same, it's a trouble free boot. I did observe
> interesting changes in the dmesg between 2.6.20-rc6 & 2.6.20-rc6-mm3
> (wondering why there are so many changes in the output). Anyway, the
> changes in brief:-
>
On Wed, 31 Jan 2007, Andrew Morton wrote:
> Actually, we might not have lost an IO: it could be that we're simply
> missing an unplug. Are you able to unblock things by forcing some other IO
> against that queue? Say, do a read from /dev/sda?
The system does not come up to a prompt. The traces
On Wed, 31 Jan 2007 16:27:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 31 Jan 2007, Andrew Morton wrote:
>
> > ow. Please don't make me drop git-block-and-lots-of-other-things again.
> > Was 2.6.20-rc6-mm2 OK? It didn't have git-block.
>
> Yes, 2.6.20-rc6-mm2 was okay.
On Wed, 31 Jan 2007, Andrew Morton wrote:
> ow. Please don't make me drop git-block-and-lots-of-other-things again.
> Was 2.6.20-rc6-mm2 OK? It didn't have git-block.
Yes, 2.6.20-rc6-mm2 was okay. Sorry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
1 - 100 of 126 matches
Mail list logo
