On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
> Jan Kiszka wrote:
>> George Anzinger wrote:
>>> On 01/30/2008 04:08 PM, Jan Kiszka was caught saying:
>>>> [Here comes a rebased version against latest x86/mm]
>>>>
>>>> In case "
On 01/31/2008 01:36 AM, Jan Kiszka was caught saying:
Jan Kiszka wrote:
George Anzinger wrote:
On 01/30/2008 04:08 PM, Jan Kiszka was caught saying:
[Here comes a rebased version against latest x86/mm]
In case kgdbwait is passed as kernel parameter, KGDB tries to set up
and connect
Serge Noiraud wrote:
mercredi 7 Septembre 2005 23:16, George Anzinger wrote/a écrit :
Serge Noiraud wrote:
...
I'm trying this kgdb patch with 2.6.13 and I get the following errors.
Is there something I forgot ?
Where did you get the kgdb you are using? It looks like kgdb_ts
Serge Noiraud wrote:
mercredi 7 Septembre 2005 23:16, George Anzinger wrote/a écrit :
Serge Noiraud wrote:
...
I'm trying this kgdb patch with 2.6.13 and I get the following errors.
Is there something I forgot ?
Where did you get the kgdb you are using? It looks like kgdb_ts
Serge Noiraud wrote:
mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/
The common_kgdb_cfi_ stuff creates debug records for entry.S and
friends so that you can "bt" through th
Serge Noiraud wrote:
mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/
The common_kgdb_cfi_ stuff creates debug records for entry.S and
friends so that you can "bt" through th
Serge Noiraud wrote:
mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/
The common_kgdb_cfi_ stuff creates debug records for entry.S and
friends so that you can bt through them. Apply
Serge Noiraud wrote:
mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/
The common_kgdb_cfi_ stuff creates debug records for entry.S and
friends so that you can bt through them. Apply
Q at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vge
/
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Tom Rini wrote:
On Tue, Aug 30, 2005 at 12:33:25AM -0700, George Anzinger wrote:
Tom Rini wrote:
CC: Andi Kleen <[EMAIL PROTECTED]>
This adds a call to notify_die() in the "no context" portion of
do_page_fault() as someone on the chain might care and want to do a fixup.
-
minate things with extreme prejudice.
Please use a more descriptive text than "no context". This bit of info
SHOULD be available to the gdb/kgdb user and should indicate why kgdb
was entered. It thus should be something like "bad kernel address" or
"illegal kernel addr
prejudice.
Please use a more descriptive text than no context. This bit of info
SHOULD be available to the gdb/kgdb user and should indicate why kgdb
was entered. It thus should be something like bad kernel address or
illegal kernel address.
--
George Anzinger george@mvista.com
HRT (High-res
Tom Rini wrote:
On Tue, Aug 30, 2005 at 12:33:25AM -0700, George Anzinger wrote:
Tom Rini wrote:
CC: Andi Kleen [EMAIL PROTECTED]
This adds a call to notify_die() in the no context portion of
do_page_fault() as someone on the chain might care and want to do a fixup.
---
linux-2.6.13-trini
within the area
the kernel flags as being in an interrupt which is a subset of the
actual interrupt.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
flags as being in an interrupt which is a subset of the
actual interrupt.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Wilkerson, Bryan P wrote:
George Anzinger [mailto:[EMAIL PROTECTED] wrote:
Well, I checked, it is "int $3". Why then the panic? If you try the
boot with kgdb (i.e. wait) and the do:
(gdb) disass gdb_interrupt
What do you find at +75?
Below is the console from t
George Anzinger wrote:
Wilkerson, Bryan P wrote:
Thanks you Tom and George for the tips on using kgdb with
2.6.13-rc4-mm1.
I almost have it working but kgdb seems to have a few issues. I can get
it running from the dev machine using the kgdb and console=kgdb boot
options on the test kernel
long term accuracy of something as fast as the TSC. Vendors
are even modulating these to reduce RFI, but still, because of its
speed, it makes the best interpolator for the jiffie to jiffie times.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-
instruction for this machine? If not you would make the change in
kgdb.h. I think that is the only place it is defined.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "un
shifting here, especially if it happens
with out notice.
~
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
shifting here, especially if it happens
with out notice.
~
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
the change in
kgdb.h. I think that is the only place it is defined.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
accuracy of something as fast as the TSC. Vendors
are even modulating these to reduce RFI, but still, because of its
speed, it makes the best interpolator for the jiffie to jiffie times.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers
George Anzinger wrote:
Wilkerson, Bryan P wrote:
Thanks you Tom and George for the tips on using kgdb with
2.6.13-rc4-mm1.
I almost have it working but kgdb seems to have a few issues. I can get
it running from the dev machine using the kgdb and console=kgdb boot
options on the test kernel
Wilkerson, Bryan P wrote:
George Anzinger [mailto:[EMAIL PROTECTED] wrote:
Well, I checked, it is int $3. Why then the panic? If you try the
boot with kgdb (i.e. wait) and the do:
(gdb) disass gdb_interrupt
What do you find at +75?
Below is the console from the session it is interesting
John McCutchan wrote:
On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:
Robert Love wrote:
On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:
On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
~
I think the best thing is to take idr into user space and emulate
allocated twice. Am I reading the log correctly?
So, is it correct to assume that the tree is empty save these two at
this time? I am just trying to figure out what the test program needs
to do.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects
save space if it is NOT inlined. I don't think it is ever in a
critical code path...
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
save space if it is NOT inlined. I don't think it is ever in a
critical code path...
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
allocated twice. Am I reading the log correctly?
So, is it correct to assume that the tree is empty save these two at
this time? I am just trying to figure out what the test program needs
to do.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects
John McCutchan wrote:
On Thu, 2005-08-25 at 11:54 -0700, George Anzinger wrote:
Robert Love wrote:
On Thu, 2005-08-25 at 09:33 -0400, John McCutchan wrote:
On Thu, 2005-08-25 at 22:07 +1200, Reuben Farrelly wrote:
~
I think the best thing is to take idr into user space and emulate
john stultz wrote:
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote:
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something
john stultz wrote:
On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote:
CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and
tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is
then used to compute (at compile time) the conversion constants needed
.
Switching to a fall back clock would also require an update of this
structure.
Commits?
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
documentation at Documentation/i386/kgdb/* as well as
a couple of gdb macros...
The wait option is "gdb". This has been in flux so, to be absolutely
sure, look at include/asm-i386/bugs.h
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/project
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something like:
xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
Where did y
john stultz wrote:
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote:
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something like:
xtime + (get_cycles()-last_update)*(mult+ntp_adj)shift
Where did you get
documentation at Documentation/i386/kgdb/* as well as
a couple of gdb macros...
The wait option is gdb. This has been in flux so, to be absolutely
sure, look at include/asm-i386/bugs.h
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers
.
Switching to a fall back clock would also require an update of this
structure.
Commits?
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
john stultz wrote:
On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote:
CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and
tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is
then used to compute (at compile time) the conversion constants needed
inks there is only one such change that can be
present at any given time.
Hope this helps...
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
so timers should not be
allowed to call scsi_remove_device, which eventually schedules.
Any suggestions on the best way to fix this?
Workqueue, perhaps.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this lis
not be
allowed to call scsi_remove_device, which eventually schedules.
Any suggestions on the best way to fix this?
Workqueue, perhaps.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line
such change that can be
present at any given time.
Hope this helps...
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
spin_unlock_irqrestore(>sighand->siglock, flags);
- read_unlock(_lock);
return(ret);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
);
return(ret);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
to base the rearm on human (nsac) units, so this
effect will go away. But this is waste of time until (1.) is not solved.
George ???
Could I (we) see what you have in mind?
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers
Thomas Gleixner wrote:
George,
On Fri, 2005-08-19 at 17:19 -0700, George Anzinger wrote:
2. Drift of cyclic timers (armed by set_timer()):
Due to rounding errors and the drift adjustment code, the fixed
increment which is precalculated when the timer is set up and added on
rearm, I see
to base the rearm on human (nsac) units, so this
effect will go away. But this is waste of time until (1.) is not solved.
George ???
Could I (we) see what you have in mind?
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers
Thomas Gleixner wrote:
George,
On Fri, 2005-08-19 at 17:19 -0700, George Anzinger wrote:
2. Drift of cyclic timers (armed by set_timer()):
Due to rounding errors and the drift adjustment code, the fixed
increment which is precalculated when the timer is set up and added on
rearm, I see
o's that is really fast.
Another way to do it is to set up a repeating timer. You _must_ read
back the timer to get the repeat time it is really using, and then
measure how well it does giving signals at these repeat times. FAR FAR
more than three lines of code...
--
George Anzinger geo
cummings diesel is fast with
out saying what sort of car/truck it is mounted in.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
is fast with
out saying what sort of car/truck it is mounted in.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
that is really fast.
Another way to do it is to set up a repeating timer. You _must_ read
back the timer to get the repeat time it is really using, and then
measure how well it does giving signals at these repeat times. FAR FAR
more than three lines of code...
--
George Anzinger george
folks will be made aware of the mid jiffie issue. Far to
often we see (and let get in) patches that mess up user interfaces
around this issue. The recent changes to itimer come to mind...
~
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res
Ingo Molnar wrote:
* George Anzinger wrote:
I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/
The common_kgdb_cfi_ stuff creates debug records for entry.S and
friends so that you can "bt" through them. Apply in this order:
Ingo's pat
xtime2.tv_sec++;
+ second_overflow2();
+ }
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the F
of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list
Ingo Molnar wrote:
* George Anzinger george@mvista.com wrote:
I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/
The common_kgdb_cfi_ stuff creates debug records for entry.S and
friends so that you can bt through them. Apply in this order
folks will be made aware of the mid jiffie issue. Far to
often we see (and let get in) patches that mess up user interfaces
around this issue. The recent changes to itimer come to mind...
~
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res
ions.patch
This is, more or less, the same kgdb that is in Andrew's mm tree changed
to fix the RT issues.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Nishanth Aravamudan wrote:
On 04.08.2005 [09:45:55 -0700], George Anzinger wrote:
Uh... PLEASE tell me you are NOT changing timespec_to_jiffies() (and
timeval_to_jiffies() to add 1. This is NOT the right thing to do. For
repeating times (see setitimer code) we need the actual time as we
Nishanth Aravamudan wrote:
On 04.08.2005 [09:45:55 -0700], George Anzinger wrote:
Uh... PLEASE tell me you are NOT changing timespec_to_jiffies() (and
timeval_to_jiffies() to add 1. This is NOT the right thing to do. For
repeating times (see setitimer code) we need the actual time as we
This is, more or less, the same kgdb that is in Andrew's mm tree changed
to fix the RT issues.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
* George Anzinger wrote:
Ingo, all
I, silly person that I am, configured an RT, SMP, PREEMPT_DEBUG system.
Someone put code in the NMI path to modify the preempt count which,
often as not will generate a PREEMPT_DEBUG m
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
* George Anzinger george@mvista.com wrote:
Ingo, all
I, silly person that I am, configured an RT, SMP, PREEMPT_DEBUG system.
Someone put code in the NMI path to modify the preempt count which,
often as not will generate
Zachary Amsden wrote:
George Anzinger wrote:
Nick Piggin wrote:
George Anzinger wrote:
The NMI entry and exit code fiddles with bits in the preempt count.
If an NMI happens while some other code is doing the same, bits will
be lost. This patch removes this modify code from the NMI path
Zachary Amsden wrote:
George Anzinger wrote:
Nick Piggin wrote:
George Anzinger wrote:
The NMI entry and exit code fiddles with bits in the preempt count.
If an NMI happens while some other code is doing the same, bits will
be lost. This patch removes this modify code from the NMI path
Nick Piggin wrote:
George Anzinger wrote:
The NMI entry and exit code fiddles with bits in the preempt count.
If an NMI happens while some other code is doing the same, bits will
be lost. This patch removes this modify code from the NMI path till
we can come up with something better
the
attached patch to Andrew on this, but meanwhile, if you want RT, SMP,
PREEMPT_DEBUG you will be much better off with this.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger
Type
The NMI entry and exit code fiddles with bits in the preempt count. If
an NMI happens while some other code is doing the same, bits will be
lost. This patch removes this modify code from the NMI path till we can
come up with something better.
--
George Anzinger george@mvista.com
HRT (High
Bill Davidsen wrote:
George Anzinger wrote:
Srivatsa Vaddagiri wrote:
On Tue, Aug 09, 2005 at 12:36:58PM -0700, George Anzinger wrote:
IMNOHO, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
George,
Can't TSC
Bill Davidsen wrote:
George Anzinger wrote:
Srivatsa Vaddagiri wrote:
On Tue, Aug 09, 2005 at 12:36:58PM -0700, George Anzinger wrote:
IMNOHO, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
George,
Can't TSC
The NMI entry and exit code fiddles with bits in the preempt count. If
an NMI happens while some other code is doing the same, bits will be
lost. This patch removes this modify code from the NMI path till we can
come up with something better.
--
George Anzinger george@mvista.com
HRT (High
the
attached patch to Andrew on this, but meanwhile, if you want RT, SMP,
PREEMPT_DEBUG you will be much better off with this.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger george
Nick Piggin wrote:
George Anzinger wrote:
The NMI entry and exit code fiddles with bits in the preempt count.
If an NMI happens while some other code is doing the same, bits will
be lost. This patch removes this modify code from the NMI path till
we can come up with something better
Tony Lindgren wrote:
~
Do you have a patch around for improving next_timer_interrupt()?
Well, sort of. The code in the VST patch does the right thing. Problem
is it does a bit more than the timer.c code. You can find that code on
the HRT site CVS.
--
George Anzinger george@mvista.com
Srivatsa Vaddagiri wrote:
On Tue, Aug 09, 2005 at 12:36:58PM -0700, George Anzinger wrote:
IMNOHO, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
George,
Can't TSC (or equivalent) serve as a backup while PIT is disabled
Srivatsa Vaddagiri wrote:
On Tue, Aug 09, 2005 at 12:36:58PM -0700, George Anzinger wrote:
IMNOHO, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
George,
Can't TSC (or equivalent) serve as a backup while PIT is disabled
Tony Lindgren wrote:
~
Do you have a patch around for improving next_timer_interrupt()?
Well, sort of. The code in the VST patch does the right thing. Problem
is it does a bit more than the timer.c code. You can find that code on
the HRT site CVS.
--
George Anzinger george@mvista.com
er I had the
next_timer... answer and finding a better answer, not always, but some
times. That code does not address the cascade list correctly.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: se
, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
My VST patch just turns masks the interrupt.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list
, this is the ONLY way to keep proper time. As soon as you
reprogram the PIT you have lost track of the time.
My VST patch just turns masks the interrupt.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list
... answer and finding a better answer, not always, but some
times. That code does not address the cascade list correctly.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux
, until there are no live threads with its TGID. That is
how process-wide kill can still work.
Yes, I see, traced through the signal delivery. So Linus' patch as well
as the regression of Ingo's will fix all of this. Right?
--
George Anzinger george@mvista.com
HRT (High-res-timers): http
ge real_timer's task when the
exiting task is the real_timer wake up task, assigning it to some other
member of the group? Note, I don't say just if it is the group leader...
Then when we finally release the signal structure, we can "del" the timer.
Did I miss something here?
--
real_timer's task when the
exiting task is the real_timer wake up task, assigning it to some other
member of the group? Note, I don't say just if it is the group leader...
Then when we finally release the signal structure, we can del the timer.
Did I miss something here?
--
George Anzinger george
, until there are no live threads with its TGID. That is
how process-wide kill can still work.
Yes, I see, traced through the signal delivery. So Linus' patch as well
as the regression of Ingo's will fix all of this. Right?
--
George Anzinger george@mvista.com
HRT (High-res-timers): http
itimer_delete(tmr);
}
- del_timer_sync(>real_timer);
}
/*
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lk
Gerd Knorr wrote:
Hi,
Somewhere between 2.6.11 and 2.6.12 the regression in $subject
was added to the linux kernel. Testcase below.
Yep. The itimer changes got a bit carried away. Here is a fix.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net
)
This is not the same as "always add 1". We don't do it this way just to
have fun with C. If you change schedule_timeout() to add the 1,
nanosleep() will need to do things differently to get the same behavior.
(And, YES users do pass in zero sleep times.)
--
George Anzinger george@mvista.com
lease read the FAQ at http://www.tux.org/lkml/
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
/
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
)
This is not the same as always add 1. We don't do it this way just to
have fun with C. If you change schedule_timeout() to add the 1,
nanosleep() will need to do things differently to get the same behavior.
(And, YES users do pass in zero sleep times.)
--
George Anzinger george@mvista.com
HRT (High
Gerd Knorr wrote:
Hi,
Somewhere between 2.6.11 and 2.6.12 the regression in $subject
was added to the linux kernel. Testcase below.
Yep. The itimer changes got a bit carried away. Here is a fix.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net
);
}
- del_timer_sync(sig-real_timer);
}
/*
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
George Anzinger
Keith Owens wrote:
On Tue, 02 Aug 2005 18:12:27 -0700,
George Anzinger wrote:
How about something like:
if (current + THREAD_SIZE/sizeof(long) - (regs + sizeof(pt_regs)) >
MAGIC)
current points to the current struct task, regs points to the kernel
stack. Those two data areas
errupt.
MAGIC is some small number. For x86 user it is actually zero, don't
know about others but the saved context should be the first thing on the
stack so a minimun frame size should do.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-
1 - 100 of 440 matches
Mail list logo
