Thomas Gleixner <[EMAIL PROTECTED]> writes:
> >
> > Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
> > don't experience any problem, time is running fine. Still it's strange
> > that the timer is doing nothing; maybe something other than the PIT is
> > used for time
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I already bisected this on my old pIII, which has the same problem:
> > clockevents-i386-drivers.patch
>
> yes - we know what the problem is (and will fix it): the stopping of the
> PIT -
On Fri, 2007-02-23 at 12:35 +0100, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I already bisected this on my old pIII, which has the same problem:
> > clockevents-i386-drivers.patch
>
> yes - we know what the problem is (and will fix it): the stopping of the
> PIT -
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> I already bisected this on my old pIII, which has the same problem:
> clockevents-i386-drivers.patch
yes - we know what the problem is (and will fix it): the stopping of the
PIT - nmi_watchdog=1 is hack to use the IO-APIC's PIT pin to also signal
> On Wed, 21 Feb 2007 18:41:11 +0100 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > > switch to local apic timers happens afterwards.
> >
> > Could be the switch
On Wed, 21 Feb 2007 18:41:11 +0100 Thomas Gleixner [EMAIL PROTECTED] wrote:
On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
At this point the PIT / HPET _is_ active and incrementing jiffies. The
switch to local apic timers happens afterwards.
Could be the switch over then
* Andrew Morton [EMAIL PROTECTED] wrote:
I already bisected this on my old pIII, which has the same problem:
clockevents-i386-drivers.patch
yes - we know what the problem is (and will fix it): the stopping of the
PIT - nmi_watchdog=1 is hack to use the IO-APIC's PIT pin to also signal
On Fri, 2007-02-23 at 12:35 +0100, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
I already bisected this on my old pIII, which has the same problem:
clockevents-i386-drivers.patch
yes - we know what the problem is (and will fix it): the stopping of the
PIT -
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
I already bisected this on my old pIII, which has the same problem:
clockevents-i386-drivers.patch
yes - we know what the problem is (and will fix it): the stopping of the
PIT - nmi_watchdog=1 is hack
Thomas Gleixner [EMAIL PROTECTED] writes:
Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
don't experience any problem, time is running fine. Still it's strange
that the timer is doing nothing; maybe something other than the PIT is
used for time keeping?
Yes,
Arjan van de Ven wrote:
> if it's something built in the last year or two you have the hw.
>
>
I have an ICH4-M, and from Intel's datasheets it looks like I got the
short straw..
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core
Hi!
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
>
> There's a lot of changes, as is usual for an -rc1 thing, but at least so
> far it would seem that 2.6.20 has been a good base, and I don't think we
> have anything *really* scary here.
And lot of acpi/suspend
On Thu, 2007-02-22 at 22:07 +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power.
> >
> > you can try enabling HPET in your BIOS...
> >
> >
>
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
>
> Can I
Hi,
On Thu, Feb 22, 2007 at 10:07:19PM +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power.
> >
> > you can try enabling HPET in your BIOS...
> >
> >
>
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
>
>
Arjan van de Ven wrote:
> no; c3 saves a TON more power.
>
> you can try enabling HPET in your BIOS...
>
>
Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
as is humanly possible.
Can I determine if I have the required hardware? So I can tell if I'm
permanently screwed,
t;Subject: Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
>
>On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
>> > Sure. My dmesg is full of mmc debug crud right now, but
>I'll just reboot
>> > and I'll have a clean one for you.
>> >
>>
>&g
On Thu, 2007-02-22 at 17:27 +0100, Pierre Ossman wrote:
> Thomas Gleixner wrote:
> >
> > Here is the reason. The local APIC stops working in C3 state and we fall
> > back to the PIT in that case. Not really exciting for dynticks, but the
> > only way to keep the system alive. There is a patch
Thomas Gleixner wrote:
>
> Here is the reason. The local APIC stops working in C3 state and we fall
> back to the PIT in that case. Not really exciting for dynticks, but the
> only way to keep the system alive. There is a patch coming up from
> Intel, which finds out how to use HPET even if it is
On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
> > Sure. My dmesg is full of mmc debug crud right now, but I'll just reboot
> > and I'll have a clean one for you.
> >
>
> Here we go.
> [ 44.498253] ACPI: Lid Switch [C136]
> [ 44.577672] No dock devices found.
> [ 44.714156] ACPI:
On Thu, 2007-02-22 at 13:36 +0100, Jan Engelhardt wrote:
> >
> >Yes, we switch away from PIT and use the local APIC timer. (LOC)
>
> What's the benefit of doing so - and why has not it been done before?
> I mean, I run a regular 2.6.18.6,
>
Arjan van de Ven wrote:
> On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
>
>>
>> So with a local apic, and acpi_pm as clocksource, I shouldn't be getting
>> timer
>> interrupts?
>>
>
> timer interrupts as in "irq0"?
>
>
Yes:
0:9786349XT-PIC-XTtimer
> you
On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> >
> > some can be used for both (PIT), but on a concept level the uses are
> > independent. The advantage of local apic over PIT is that local apic is
> > cheap to do "one shot" future events with, while the PIT
Arjan van de Ven wrote:
>
> some can be used for both (PIT), but on a concept level the uses are
> independent. The advantage of local apic over PIT is that local apic is
> cheap to do "one shot" future events with, while the PIT will tick
> periodic at a fixed frequency. With tickless idle..
> What's the benefit of doing so - and why has not it been done before?
> I mean, I run a regular 2.6.18.6,
> /sys/devices/system/clocksource/clocksource0/current_clocksource (is this
> related?) shows "acpi_pm", but the IRQ0 counter increases at HZ. Maybe I
> am confusing things, but why the
On Feb 22 2007 00:17, Thomas Gleixner wrote:
>On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
>>
>> Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
>> don't experience any problem, time is running fine. Still it's strange
>> that the timer is doing nothing;
From: Anders Larsen <[EMAIL PROTECTED]>
Date: Thu, 22 Feb 2007 10:57:47 +0100
> On 2007-02-22 01:18:09, Greg KH wrote:
> > On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
> > > E.g. something calls the request_modle(), and if hotplug is using
> > > socket(PF_UNIX) and af_unix is
On 2007-02-22 01:18:09, Greg KH wrote:
> On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
> > E.g. something calls the request_modle(), and if hotplug is using
> > socket(PF_UNIX) and af_unix is module, it also calls request_modle()?
> >
> > Just my guess though...
>
> Ugh, why
On 2007-02-22 01:18:09, Greg KH wrote:
On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
E.g. something calls the request_modle(), and if hotplug is using
socket(PF_UNIX) and af_unix is module, it also calls request_modle()?
Just my guess though...
Ugh, why does anyone
From: Anders Larsen [EMAIL PROTECTED]
Date: Thu, 22 Feb 2007 10:57:47 +0100
On 2007-02-22 01:18:09, Greg KH wrote:
On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
E.g. something calls the request_modle(), and if hotplug is using
socket(PF_UNIX) and af_unix is module, it
On Feb 22 2007 00:17, Thomas Gleixner wrote:
On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
don't experience any problem, time is running fine. Still it's strange
that the timer is doing nothing; maybe
What's the benefit of doing so - and why has not it been done before?
I mean, I run a regular 2.6.18.6,
/sys/devices/system/clocksource/clocksource0/current_clocksource (is this
related?) shows acpi_pm, but the IRQ0 counter increases at HZ. Maybe I
am confusing things, but why the need for
Arjan van de Ven wrote:
some can be used for both (PIT), but on a concept level the uses are
independent. The advantage of local apic over PIT is that local apic is
cheap to do one shot future events with, while the PIT will tick
periodic at a fixed frequency. With tickless idle.. that's not
On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
Arjan van de Ven wrote:
some can be used for both (PIT), but on a concept level the uses are
independent. The advantage of local apic over PIT is that local apic is
cheap to do one shot future events with, while the PIT will tick
Arjan van de Ven wrote:
On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
So with a local apic, and acpi_pm as clocksource, I shouldn't be getting
timer
interrupts?
timer interrupts as in irq0?
Yes:
0:9786349XT-PIC-XTtimer
you shouldn't if you
On Thu, 2007-02-22 at 13:36 +0100, Jan Engelhardt wrote:
Yes, we switch away from PIT and use the local APIC timer. (LOC)
What's the benefit of doing so - and why has not it been done before?
I mean, I run a regular 2.6.18.6,
/sys/devices/system/clocksource/clocksource0/current_clocksource
On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
Sure. My dmesg is full of mmc debug crud right now, but I'll just reboot
and I'll have a clean one for you.
Here we go.
[ 44.498253] ACPI: Lid Switch [C136]
[ 44.577672] No dock devices found.
[ 44.714156] ACPI: CPU0
Thomas Gleixner wrote:
Here is the reason. The local APIC stops working in C3 state and we fall
back to the PIT in that case. Not really exciting for dynticks, but the
only way to keep the system alive. There is a patch coming up from
Intel, which finds out how to use HPET even if it is not
On Thu, 2007-02-22 at 17:27 +0100, Pierre Ossman wrote:
Thomas Gleixner wrote:
Here is the reason. The local APIC stops working in C3 state and we fall
back to the PIT in that case. Not really exciting for dynticks, but the
only way to keep the system alive. There is a patch coming up
[Re: Linux 2.6.21-rc1]
On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
Sure. My dmesg is full of mmc debug crud right now, but
I'll just reboot
and I'll have a clean one for you.
Here we go.
[ 44.498253] ACPI: Lid Switch [C136]
[ 44.577672] No dock devices found
Arjan van de Ven wrote:
no; c3 saves a TON more power.
you can try enabling HPET in your BIOS...
Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
as is humanly possible.
Can I determine if I have the required hardware? So I can tell if I'm
permanently screwed, or
Hi,
On Thu, Feb 22, 2007 at 10:07:19PM +0100, Pierre Ossman wrote:
Arjan van de Ven wrote:
no; c3 saves a TON more power.
you can try enabling HPET in your BIOS...
Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
as is humanly possible.
Can I determine
On Thu, 2007-02-22 at 22:07 +0100, Pierre Ossman wrote:
Arjan van de Ven wrote:
no; c3 saves a TON more power.
you can try enabling HPET in your BIOS...
Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
as is humanly possible.
Can I determine if I have
Hi!
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
There's a lot of changes, as is usual for an -rc1 thing, but at least so
far it would seem that 2.6.20 has been a good base, and I don't think we
have anything *really* scary here.
And lot of acpi/suspend changes,
Arjan van de Ven wrote:
if it's something built in the last year or two you have the hw.
I have an ICH4-M, and from Intel's datasheets it looks like I got the
short straw..
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer
On Thu, Feb 22, 2007 at 12:34:17PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 11:04:40 +0900 (JST)),
> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> says:
>
> > In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 04:12:04 +0900),
On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
>
> > On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
> >> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> writes:
> >>
> >> > In article <[EMAIL PROTECTED]> (at Tue, 20 Feb
On 2/22/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
> Hi Thomas,
> I'm testing NO_HZ on my machines. On the laptop I see that the timer
> interrupt counter is incremented (though slower than HZ). This machine
> is running UP kernel.
>
On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
> Hi Thomas,
> I'm testing NO_HZ on my machines. On the laptop I see that the timer
> interrupt counter is incremented (though slower than HZ). This machine
> is running UP kernel.
>
> On my desktop I see this:
>
>CPU0
Linus Torvalds <[EMAIL PROTECTED]> ha scritto:
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
>
> There's a lot of changes, as is usual for an -rc1 thing, but at least so
> far it would seem that 2.6.20 has been a good base, and I don't think we
> have anything *really*
On Wed, Feb 21, 2007 at 01:06:17PM -0800, Linus Torvalds wrote:
> That said, one thing to worry about when doing bisection: the kernel
> configuration.
This bit me badly the one time I did a git bisect; it kept ping-
ponging around a big change (sata? xtables?) that required me to
answer the
On Wed, 2007-02-21 at 13:06 -0800, Linus Torvalds wrote:
>
> On Wed, 21 Feb 2007, Daniel Walker wrote:
> >
> > Here's the final commit from the bisect which caused it . It says "No
> > changes to existing functionality" ?
>
> Ok, it wouldn't be the first time some change that is supposed to
Greg KH <[EMAIL PROTECTED]> writes:
> On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
>> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> writes:
>>
>> > In article <[EMAIL PROTECTED]> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)),
>> > Linus Torvalds <[EMAIL PROTECTED]> says:
On Wed, 2007-02-21 at 13:06 -0800, Linus Torvalds wrote:
> That said, considering that you did get a commit that doesn't look
> entirely unlikely (and that clearly changes things that are relevant), I
> suspect you did actually find the right one.
Yup, thats the one which switches off PIT after
On Wed, 21 Feb 2007, Daniel Walker wrote:
>
> Here's the final commit from the bisect which caused it . It says "No
> changes to existing functionality" ?
Ok, it wouldn't be the first time some change that is supposed to change
nothing does actually change something.
That said, one thing to
On Wed, 2007-02-21 at 21:43 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 12:00 -0800, Daniel Walker wrote:
> > There's a compile failure during my bisect.
> >
> > distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on
> > dwalker3/120 failed
> > kernel/hrtimer.c: In function
On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> writes:
>
> > In article <[EMAIL PROTECTED]> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)),
> > Linus Torvalds <[EMAIL PROTECTED]> says:
> >
> >> But there's a ton of architecture
On Wed, 2007-02-21 at 12:00 -0800, Daniel Walker wrote:
> There's a compile failure during my bisect.
>
> distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on dwalker3/120
> failed
> kernel/hrtimer.c: In function 'hrtimer_cpu_notify':
> kernel/hrtimer.c:884: warning: implicit
On Wed, 21 Feb 2007, Daniel Walker wrote:
>
> There's a compile failure during my bisect.
When that happens, you need to pick another commit to try than the one git
selected for you automatically. You can do that by doing
git bisect visualize
and select another commit somewhere
On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> > Right, but eventually there isn't a regular timer interrupt through the
> > io-apic. I don't think in the past IRQ0 stops without the system
> > crashing, so check_timer() could
On Wed, 21 Feb 2007 11:24:33 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 21 Feb 2007, Kok, Auke wrote:
> >
> > I think we need to drop this now. The report that says that this *fixes*
> > something might have been on regular interrupts only. I currently suspect
> >
On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> > Right, but eventually there isn't a regular timer interrupt through the
> > io-apic. I don't think in the past IRQ0 stops without the system
> > crashing, so check_timer() could
On Wed, 21 Feb 2007, Kok, Auke wrote:
>
> I think we need to drop this now. The report that says that this *fixes*
> something might have been on regular interrupts only. I currently suspect that
> it breaks all MSI interrupts, which would make sense if I look a the code.
> Very bad indeed.
>
On Wed, 21 Feb 2007, Faik Uygur wrote:
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CHK include/linux/compile.h
> CC [M] drivers/char/ip2/ip2main.o
> In file included from drivers/char/ip2/ip2main.c:285:
> drivers/char/ip2/i2lib.c: In function
On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> Right, but eventually there isn't a regular timer interrupt through the
> io-apic. I don't think in the past IRQ0 stops without the system
> crashing, so check_timer() could assume the timer (IRQ0) is _always_
> regular.
>
> do you know
Jiri Slaby napsal(a):
Faik Uygur napsal(a):
Hi,
Hi.
21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK
On Wed, Feb 21, 2007 at 07:34:01PM +0100, Andreas Schwab wrote:
> I'm getting an undefined symbol with CONFIG_AGP=m:
>
> WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined!
Fix went to Linus an hour ago.
It's been in -mm for a week, and agpgart.git for a day or so.
Faik Uygur napsal(a):
Hi,
Hi.
21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
CC [M]
I'm getting an undefined symbol with CONFIG_AGP=m:
WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined!
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756
On Wed, 2007-02-21 at 19:18 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
> > > >
> > > > Could be the switch over then which confuses the NMI .
> > >
> > > Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
> > > and friends at
On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
> > >
> > > Could be the switch over then which confuses the NMI .
> >
> > Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
> > and friends at all.
>
> I'm not an expert on the io-apic, but the check_timer()
On Wed, 2007-02-21 at 18:41 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > > switch to local apic timers happens afterwards.
> >
> > Could be the switch over then which
On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > switch to local apic timers happens afterwards.
>
> Could be the switch over then which confuses the NMI .
Why? The switch just stops the PIT/HPET. It does not
On Wed, 2007-02-21 at 18:07 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
> > > The most interesting core change may be the dyntick/nohz one, where timer
> > > ticks will only happen when needed. It's been brewing for a _loong_ time,
> > > but it's in
On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
> > The most interesting core change may be the dyntick/nohz one, where timer
> > ticks will only happen when needed. It's been brewing for a _loong_ time,
> > but it's in the standard kernel now as an option.
>
> On i386 I get the
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
>
> There's a lot of changes, as is usual for an -rc1 thing, but at least so
> far it would seem that 2.6.20 has been a good base, and I don't think we
> have anything
Hello.
In article <[EMAIL PROTECTED]> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)),
Linus Torvalds <[EMAIL PROTECTED]> says:
> But there's a ton of architecture updates (arm, mips, powerpc, x86, you
> name it), ACPI updates, and lots of driver work. And just a lot of
> cleanups.
I cannot boot
Thomas Gleixner wrote:
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
But there's a ton of architecture updates (arm, mips, powerpc, x86, you
name it), ACPI updates, and lots of driver work. And just a lot of
cleanups.
Have fun,
Yup. Fun starts in drivers/net/e1000
e1000 is not
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
> But there's a ton of architecture updates (arm, mips, powerpc, x86, you
> name it), ACPI updates, and lots of driver work. And just a lot of
> cleanups.
>
> Have fun,
Yup. Fun starts in drivers/net/e1000
e1000 is not working anymore.
Hi,
21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
CC [M] drivers/char/ip2/ip2main.o
In file
Hi,
21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
CC [M] drivers/char/ip2/ip2main.o
In file
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
But there's a ton of architecture updates (arm, mips, powerpc, x86, you
name it), ACPI updates, and lots of driver work. And just a lot of
cleanups.
Have fun,
Yup. Fun starts in drivers/net/e1000
e1000 is not working anymore. ifup
Thomas Gleixner wrote:
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
But there's a ton of architecture updates (arm, mips, powerpc, x86, you
name it), ACPI updates, and lots of driver work. And just a lot of
cleanups.
Have fun,
Yup. Fun starts in drivers/net/e1000
e1000 is not
Hello.
In article [EMAIL PROTECTED] (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)),
Linus Torvalds [EMAIL PROTECTED] says:
But there's a ton of architecture updates (arm, mips, powerpc, x86, you
name it), ACPI updates, and lots of driver work. And just a lot of
cleanups.
I cannot boot
On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
There's a lot of changes, as is usual for an -rc1 thing, but at least so
far it would seem that 2.6.20 has been a good base, and I don't think we
have anything
On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
The most interesting core change may be the dyntick/nohz one, where timer
ticks will only happen when needed. It's been brewing for a _loong_ time,
but it's in the standard kernel now as an option.
On i386 I get the following,
On Wed, 2007-02-21 at 18:07 +0100, Thomas Gleixner wrote:
On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
The most interesting core change may be the dyntick/nohz one, where timer
ticks will only happen when needed. It's been brewing for a _loong_ time,
but it's in the standard
On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
At this point the PIT / HPET _is_ active and incrementing jiffies. The
switch to local apic timers happens afterwards.
Could be the switch over then which confuses the NMI .
Why? The switch just stops the PIT/HPET. It does not
On Wed, 2007-02-21 at 18:41 +0100, Thomas Gleixner wrote:
On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
At this point the PIT / HPET _is_ active and incrementing jiffies. The
switch to local apic timers happens afterwards.
Could be the switch over then which confuses the NMI
On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
Could be the switch over then which confuses the NMI .
Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
and friends at all.
I'm not an expert on the io-apic, but the check_timer() function seemed
to
On Wed, 2007-02-21 at 19:18 +0100, Thomas Gleixner wrote:
On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
Could be the switch over then which confuses the NMI .
Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
and friends at all.
I'm not an
I'm getting an undefined symbol with CONFIG_AGP=m:
WARNING: compat_agp_ioctl [drivers/char/agp/agpgart.ko] undefined!
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3
On Wed, Feb 21, 2007 at 07:34:01PM +0100, Andreas Schwab wrote:
I'm getting an undefined symbol with CONFIG_AGP=m:
WARNING: compat_agp_ioctl [drivers/char/agp/agpgart.ko] undefined!
Fix went to Linus an hour ago.
It's been in -mm for a week, and agpgart.git for a day or so.
Faik Uygur napsal(a):
Hi,
Hi.
21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
CC [M]
Jiri Slaby napsal(a):
Faik Uygur napsal(a):
Hi,
Hi.
21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK
On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
Right, but eventually there isn't a regular timer interrupt through the
io-apic. I don't think in the past IRQ0 stops without the system
crashing, so check_timer() could assume the timer (IRQ0) is _always_
regular.
do you know what the
On Wed, 21 Feb 2007, Faik Uygur wrote:
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
CC [M] drivers/char/ip2/ip2main.o
In file included from drivers/char/ip2/ip2main.c:285:
drivers/char/ip2/i2lib.c: In function
On Wed, 21 Feb 2007, Kok, Auke wrote:
I think we need to drop this now. The report that says that this *fixes*
something might have been on regular interrupts only. I currently suspect that
it breaks all MSI interrupts, which would make sense if I look a the code.
Very bad indeed.
I'll
On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
Right, but eventually there isn't a regular timer interrupt through the
io-apic. I don't think in the past IRQ0 stops without the system
crashing, so check_timer() could assume
On Wed, 21 Feb 2007 11:24:33 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 21 Feb 2007, Kok, Auke wrote:
I think we need to drop this now. The report that says that this *fixes*
something might have been on regular interrupts only. I currently suspect
that
it breaks
On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
Right, but eventually there isn't a regular timer interrupt through the
io-apic. I don't think in the past IRQ0 stops without the system
crashing, so check_timer() could assume
1 - 100 of 114 matches
Mail list logo
