On Fri, 2007-03-23 at 11:28 -0700, Linus Torvalds wrote:
>
> On Fri, 23 Mar 2007, Linus Torvalds wrote:
> >
> > Thomas, please fix.
>
> Here's a possible fix. It compiles. And I still wish we had common files.
You beat me by 30 seconds.
> ia64 shouldn't be affected, because ia64 doesn't
On Fri, 23 Mar 2007, Linus Torvalds wrote:
>
> Thomas, please fix.
Here's a possible fix. It compiles. And I still wish we had common files.
ia64 shouldn't be affected, because ia64 doesn't #define the
ARCH_APICTIMER_STOPS_ON_C3 flag (and then we don't use the "c2_ok" thing
either. But this
On Fri, 23 Mar 2007, Linus Torvalds wrote:
>
> I really wish we had an x86-64 maintainer that understood that it's
> confusing that files in arch/i386/ are also used for arch/x86-64.
Sorry, that was unfair. The patch was simply buggy. It added the test to
drivers/acpi/ *without* adding it to
On Fri, 23 Mar 2007, Thomas Gleixner wrote:
>
> We should revert that patch and add a "trust_lapic_timer_in_c2"
> commandline option instead. So we are on the safe side.
Damn. I applied your patch, but it breaks on x86-64:
drivers/acpi/processor_idle.c:271: error: 'local_apic_timer_c2_ok'
On Fri, Mar 23, 2007 at 10:37:38AM +0100, Nick Piggin wrote:
> On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
> > On 23/03/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >>
> > >> and that in turn points to the kernel log:
> > >>
> > >>
> >
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> [ Ok, I think it's those timers again...
agreed - this seems to be a genuine CONFIG_HIGH_RES_TIMERS=y bug. (which
has probably not been fixed since -rc4 either, we have no bugfix in this
area that could explain the expires_next==KTIME_MAX timer
On Fri, 2007-03-23 at 12:42 +0100, Ingo Molnar wrote:
> there's a new post-rc4 regression: my T60 hangs during early bootup. I
> bisected the hang down to this recent commit:
>
> | commit 25496caec111481161e7f06bbfa12a533c43cc6f
> | Author: Thomas Renninger <[EMAIL PROTECTED]>
> | Date: Tue
there's a new post-rc4 regression: my T60 hangs during early bootup. I
bisected the hang down to this recent commit:
| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger <[EMAIL PROTECTED]>
| Date: Tue Feb 27 12:13:00 2007 -0500
|
|ACPI: Only use IPI on known
On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
> On 23/03/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>
> >> and that in turn points to the kernel log:
> >>
> >>
> >http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log
> >
> >Seems
On 23/03/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
On Thu, Mar 22, 2007 at 06:40:41PM -0700, Linus Torvalds wrote:
>
> [ Ok, I think it's those timers again...
>
> Ingo: let me just state how *happy* I am that I told you off when you
> wanted to merge the hires timers and NO_HZ before
On 23/03/07, Nick Piggin [EMAIL PROTECTED] wrote:
On Thu, Mar 22, 2007 at 06:40:41PM -0700, Linus Torvalds wrote:
[ Ok, I think it's those timers again...
Ingo: let me just state how *happy* I am that I told you off when you
wanted to merge the hires timers and NO_HZ before 2.6.20
On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
On 23/03/07, Nick Piggin [EMAIL PROTECTED] wrote:
and that in turn points to the kernel log:
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc4/git-console.log
Seems convincing. Michal, can you
there's a new post-rc4 regression: my T60 hangs during early bootup. I
bisected the hang down to this recent commit:
| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger [EMAIL PROTECTED]
| Date: Tue Feb 27 12:13:00 2007 -0500
|
|ACPI: Only use IPI on known broken
On Fri, 2007-03-23 at 12:42 +0100, Ingo Molnar wrote:
there's a new post-rc4 regression: my T60 hangs during early bootup. I
bisected the hang down to this recent commit:
| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger [EMAIL PROTECTED]
| Date: Tue Feb 27
* Linus Torvalds [EMAIL PROTECTED] wrote:
[ Ok, I think it's those timers again...
agreed - this seems to be a genuine CONFIG_HIGH_RES_TIMERS=y bug. (which
has probably not been fixed since -rc4 either, we have no bugfix in this
area that could explain the expires_next==KTIME_MAX timer state
On Fri, Mar 23, 2007 at 10:37:38AM +0100, Nick Piggin wrote:
On Fri, Mar 23, 2007 at 08:51:13AM +0100, Michal Piotrowski wrote:
On 23/03/07, Nick Piggin [EMAIL PROTECTED] wrote:
and that in turn points to the kernel log:
On Fri, 23 Mar 2007, Thomas Gleixner wrote:
We should revert that patch and add a trust_lapic_timer_in_c2
commandline option instead. So we are on the safe side.
Damn. I applied your patch, but it breaks on x86-64:
drivers/acpi/processor_idle.c:271: error: 'local_apic_timer_c2_ok'
On Fri, 23 Mar 2007, Linus Torvalds wrote:
I really wish we had an x86-64 maintainer that understood that it's
confusing that files in arch/i386/ are also used for arch/x86-64.
Sorry, that was unfair. The patch was simply buggy. It added the test to
drivers/acpi/ *without* adding it to
On Fri, 23 Mar 2007, Linus Torvalds wrote:
Thomas, please fix.
Here's a possible fix. It compiles. And I still wish we had common files.
ia64 shouldn't be affected, because ia64 doesn't #define the
ARCH_APICTIMER_STOPS_ON_C3 flag (and then we don't use the c2_ok thing
either. But this is
On Fri, 2007-03-23 at 11:28 -0700, Linus Torvalds wrote:
On Fri, 23 Mar 2007, Linus Torvalds wrote:
Thomas, please fix.
Here's a possible fix. It compiles. And I still wish we had common files.
You beat me by 30 seconds.
ia64 shouldn't be affected, because ia64 doesn't #define the
On Thu, Mar 22, 2007 at 06:40:41PM -0700, Linus Torvalds wrote:
>
> [ Ok, I think it's those timers again...
>
> Ingo: let me just state how *happy* I am that I told you off when you
> wanted to merge the hires timers and NO_HZ before 2.6.20 because they
> were "stable". You were wrong,
[ Ok, I think it's those timers again...
Ingo: let me just state how *happy* I am that I told you off when you
wanted to merge the hires timers and NO_HZ before 2.6.20 because they
were "stable". You were wrong, and 2.6.20 is at least in reasonable
shape. Now we just need to make sure
On Thu, 2007-03-22 at 08:21 -0700, Linus Torvalds wrote:
>
> On Thu, 22 Mar 2007, Nick Piggin wrote:
> >
> > Nothing sleeps on PageUptodate, so I don't think that could explain it.
>
> Good point. I forget that we just test "uptodate", but then always sleep
> on "locked".
>
> > The fs: fix
Hello,
> > In contrast, the hang reported by Mariusz Kozlowski has a slightly
> > different feel to it, but there's a tantalizing pattern in there too:
Just to make things clear. I didn't say I could reproduce it on 2.6.21-rc4.
In fact I'm running 2.6.21-rc4-mm1 with no problems so far. I just
On Thu, 22 Mar 2007, Nick Piggin wrote:
>
> Nothing sleeps on PageUptodate, so I don't think that could explain it.
Good point. I forget that we just test "uptodate", but then always sleep
on "locked".
> The fs: fix __block_write_full_page error case buffer submission patch
> does change the
On Thu, 22 Mar 2007, Nick Piggin wrote:
Nothing sleeps on PageUptodate, so I don't think that could explain it.
Good point. I forget that we just test uptodate, but then always sleep
on locked.
The fs: fix __block_write_full_page error case buffer submission patch
does change the
Hello,
In contrast, the hang reported by Mariusz Kozlowski has a slightly
different feel to it, but there's a tantalizing pattern in there too:
Just to make things clear. I didn't say I could reproduce it on 2.6.21-rc4.
In fact I'm running 2.6.21-rc4-mm1 with no problems so far. I just
On Thu, 2007-03-22 at 08:21 -0700, Linus Torvalds wrote:
On Thu, 22 Mar 2007, Nick Piggin wrote:
Nothing sleeps on PageUptodate, so I don't think that could explain it.
Good point. I forget that we just test uptodate, but then always sleep
on locked.
The fs: fix
[ Ok, I think it's those timers again...
Ingo: let me just state how *happy* I am that I told you off when you
wanted to merge the hires timers and NO_HZ before 2.6.20 because they
were stable. You were wrong, and 2.6.20 is at least in reasonable
shape. Now we just need to make sure
On Thu, Mar 22, 2007 at 06:40:41PM -0700, Linus Torvalds wrote:
[ Ok, I think it's those timers again...
Ingo: let me just state how *happy* I am that I told you off when you
wanted to merge the hires timers and NO_HZ before 2.6.20 because they
were stable. You were wrong, and
Linus Torvalds wrote:
In contrast, the hang reported by Mariusz Kozlowski has a slightly
different feel to it, but there's a tantalizing pattern in there too:
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1243.html
Call Trace:
[] io_schedule+0x42/0x59
[]
On Sun, 18 Mar 2007, Adrian Bunk wrote:
>
> Subject: weird system hangs
> References : http://lkml.org/lkml/2007/3/16/288
> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
> Mariusz Kozlowski <[EMAIL PROTECTED]>
> Status : unknown
According to the console log, it seems
On Sun, 18 Mar 2007, Adrian Bunk wrote:
Subject: weird system hangs
References : http://lkml.org/lkml/2007/3/16/288
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Mariusz Kozlowski [EMAIL PROTECTED]
Status : unknown
According to the console log, it seems to be hung
Linus Torvalds wrote:
In contrast, the hang reported by Mariusz Kozlowski has a slightly
different feel to it, but there's a tantalizing pattern in there too:
http://www.ussg.iu.edu/hypermail/linux/kernel/0703.0/1243.html
Call Trace:
[c03ec87e] io_schedule+0x42/0x59
On Tue, Mar 20, 2007 at 11:24:41AM +0100, Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
>
> Since I didn't see any mention of this:
>
> I'm seeing an Oops when removing the ohci1394 module:
>
> [ 16.047275] ieee1394:
Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20.
Since I didn't see any mention of this:
I'm seeing an Oops when removing the ohci1394 module:
[ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860]
GUID[c033ced6]
[ 16.047287]
Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
Since I didn't see any mention of this:
I'm seeing an Oops when removing the ohci1394 module:
[ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860]
GUID[c033ced6]
[ 16.047287]
On Tue, Mar 20, 2007 at 11:24:41AM +0100, Tobias Diedrich wrote:
Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
Since I didn't see any mention of this:
I'm seeing an Oops when removing the ohci1394 module:
[ 16.047275] ieee1394: Node
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
40 matches
Mail list logo
