Robert Hancock wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s)
and may
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential
Robert Hancock wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s)
and may
> >Does not apply cleanly against 2.6.20, is this one fixed up right?
> >
> > It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
> >
> > IOW, the forcedeth changes in question are not in 2.6.20, and you need
> > to apply the patch on top of t
to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
IOW, the forcedeth changes in question are not in 2.6.20, and you need
to apply the patch on top of the latest batch of forcedeth changes.
Well, it hasn't blown up on me despite being applied to 2.6.20...
The problem I was seeing might even
ne fixed up right?
>
> It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
>
> IOW, the forcedeth changes in question are not in 2.6.20, and you need
> to apply the patch on top of the latest batch of forcedeth changes.
Well, it hasn't blown up on me despite being
or 2.6.20-rc6-mm3.
IOW, the forcedeth changes in question are not in 2.6.20, and you need
to apply the patch on top of the latest batch of forcedeth changes.
Well, it hasn't blown up on me despite being applied to 2.6.20...
The problem I was seeing might even be fixed in 2.6.20 vanilla,
since
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
Seems to solve the problem for me (not heavily tested, but certainly
isn't totally dead as it was before).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL
Tobias Diedrich wrote:
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
IOW
Tobias Diedrich wrote:
> Ayaz Abdulla wrote:
> > For all those who are having issues, please try out the attached patch.
>
> Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
+0100
+++
Ayaz Abdulla wrote:
> For all those who are having issues, please try out the attached patch.
Will try.
I reverted to 2.6.19 w/o suspend/resume patch last weekend to make
sure on 2.6.19 forcedeth is stable and noticed something odd:
Because I didn't include the suspend/resume patch I obviously
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
I reverted to 2.6.19 w/o suspend/resume patch last weekend to make
sure on 2.6.19 forcedeth is stable and noticed something odd:
Because I didn't include the suspend/resume patch I obviously
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
+0100
+++
Tobias Diedrich wrote:
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3.
IOW
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
Seems to solve the problem for me (not heavily tested, but certainly
isn't totally dead as it was before).
--
Robert Hancock Saskatoon, SK, Canada
To email, remove nospam from [EMAIL
04 Feb 2007 23:13:09 -0600 Robert Hancock <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me
relative to
> >> 2.6.20-rc6. There's no errors in dmesg, but it seems no
p
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me
relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no
packets ever get
received and so the machine can't get an IP address. I tried
On Mon, 5 Feb 2007 16:52:24 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Mon, 05 Feb 2007 18:35:06 -0600
> Robert Hancock <[EMAIL PROTECTED]> wrote:
>
> > Daniel Barkalow wrote:
> > > On Sun, 4 Feb 2007, Robert Hancock wrote:
> > >
> >
* 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.
> > >
> > >
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
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 something
* 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.
Which one would that be? I
On Mon, 5 Feb 2007 16:52:24 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 05 Feb 2007 18:35:06 -0600
Robert Hancock [EMAIL PROTECTED] wrote:
Daniel Barkalow wrote:
On Sun, 4 Feb 2007, Robert Hancock wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative
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
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.
>
>
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
* 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
* 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
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
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
>
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
* 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
> > > >
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
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:
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
* 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
ick - which until now was a hidden wart but became
>> an explicit bug under dynticks. Maybe this is what is slowing down your
>> box.
I have the same problem (huge delay when loading iptables) with
2.6.20-rc6-mm3, and for me this patch did fix it.
> No, not this. Anyway the
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
* 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
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
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
* 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
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'
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
* 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
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
* 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
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
* 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
* 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
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
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
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
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
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
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 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
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 bisect , but
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
why there
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 ?
I don't know .. I
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 are you
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 work the same
* 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 before
the
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 quite easy
* 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: the new
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't want.
* 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 local APIC
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
off..
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 this
* 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 visible change
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 userspace
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 'PIT-timer'
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 confusion as
* 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,
because
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 'previous
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
* 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 previous mail,
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
* 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 nothing
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 long
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 with the
* 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/interrupts)
to be
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/interrupts
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 sentence, i dont
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
special
* 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't list all interrupts
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 computer
* 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
anything about it.
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 something that we
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
1 - 100 of 294 matches
Mail list logo
