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 "
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 is in
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
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: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
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.
-
* terminate 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
in 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
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 ses
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
nd on 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/
the right
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 &
uency 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
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 the
e 1024 got
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.ne
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
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 some
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" in
the
h has some 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.n
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
Y. Also, me thinks 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-
c context, 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 unsubscrib
l" 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
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe f
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/
-
To
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 respond to it. Now with Ingo'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
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
tation. This
way _more_ 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://sourcefo
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'
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
ons.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
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
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
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 TS
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 dis
timer list after 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 fro
, 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
atches the TGID, 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
So, don't we need to also change 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" th
ist);
itimer_delete(tmr);
}
- 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
Pleas
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
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@mvist
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: send the line "unsubscribe linux-kernel" i
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
stack grows down, b) no switch stack at interrupt.
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-t
It seems that the subject patch generates a warning (missed it on the
compile). Here is a patch to eliminate the warning.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger
Type
y port you do.
One more question : I believe Ingo's preemption patch run
timers/interrupt handlers within kernel threads, how should I assign
specific priority to address my goals without compromising system
stability ?
Carefully :)
--
George Anzinger george@mvista.co
Keith Owens wrote:
On Fri, 29 Jul 2005 13:55:23 -0700,
George Anzinger wrote:
This patch adds a notify to the die_nmi notify that the system
is about to be taken down. If the notify is handled with a
NOTIFY_STOP return, the system is given a new lease on life.
void
alert_counter[cpu] = 0;
That all makes sense - let's go that way?
Looks good to me. Trimed a bit more fat too. Here is the complete patch.
-
-
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Sof
Keith Owens wrote:
On Thu, 28 Jul 2005 13:31:58 -0700,
George Anzinger wrote:
I have been doing some work on kgdb to pull a few of it "fingers" out of
various places in the kernel. This is the final location where we have
a kgdb intercept not covered by a notify.
I like the
Andrew Morton wrote:
George Anzinger wrote:
This patch adds a notify to the nmi watchdog to notify that
the system is about to be taken down by the watchdog. If the
notify is handled with a NOTIFY_STOP return, the system is
given a new lease on life.
It
o the same notify code. Would you be open to a patch to
create a seperate notify list for nmi events?
-
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger
Type: Enhancement
D
. This causes the result to be shifted ~4
seconds ahead instead of ~2 seconds back in time. Patch is attached.
-
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger
Type: Defect Fix
Andrew Morton wrote:
George Anzinger wrote:
+ while (time_before_eq(p->signal->real_timer.expires, jiffies))
+ p->signal->real_timer.expires += inc;
It gives me the creeps when I see timer code doing this, and it seems to be
done relatively frequently.
Sure
e timer code to take that into account.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc.
Type: Defect Fix
Disposition:
Description:
This changes setitimer as follows:
1. The repeating timer
0 0
200 1193182 598119600 19600
250 1193182 4000250162500 62500
500 1193182 19996881001843688 1843688
1000 1193182 999848 1000847848 847848
846 1193182 118
will really mess up the jiffie_to_* and *_to_jiffie conversions. They rely
in a rather large way on the complier doing all the heavy lifting. If HZ is a
variable we introduce a LOT of runtime overhead here. (Try make kernel/itimer.i
and look for jiffies_to_t* and friends.)
--
George
alue of jiffie given CLOCK_TICK_RATE. Today the value we use for jiffie is
999849 nanoseconds which is what the given CLOCK_TICK_RATE and HZ end up getting
from the PIT.
By the time the user comes along we have TICK_NSEC and the current conversion
routines which are not exactly simple but they ar
r really is in the
range of 848ppm for HZ=1000 BECAUSE we need to follow the standard. You can
easily see this with the current 2.6 kernel. We even have a bug report on it:
http://bugzilla.kernel.org/show_bug.cgi?id=3289
~
--
George Anzinger george@mvista.com
HRT (High-res-timers
but rather an argumentation of the
help text that goes with it. For those who want timers to repeat at one second
(or multiples there of) this is useful info.
For you enjoyment I have attached the program used to print this. It allows you
to try additional values...
--
George Anzinge
nclude/asm-generic: No such file or directory
The problem is in this line:
ifeq ($(KBUILD_OUTPUT),)
KBUILD_OUTPUT is not defined (ever) after make reruns itself. This line is used
in the TAGS, tags, and cscope makes.
Here is a fix:
Signed-off-by: George Anzinger
--- linux-2.6.12-org/Makef
George Anzinger wrote:
If you try:
make O=/usr/src/ver/2.6.13-rc/obj/ -j5 LOCALVERSION=_2.6.13-rc TAGS
ARCH=i386
it fails with:
MAKE TAGS
find: security/selinux/include: No such file or directory
find: include: No such file or directory
find: include/asm-i386: No such file or directory
Horms wrote:
On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote:
Horms wrote:
Use netdev as the mailing list contact instead of the mostly dead
linux-net list.
~
PHRAM MTD DRIVER
@@ -1795,7 +1795,7 @@
POSIX CLOCKS and TIMERS
P: George Anzinger
M: george@mvista.com
-L
P: George Anzinger
M: george@mvista.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
S: Supported
I don't really know about the rest of them, but I think this should be:
L: linux-kernel@vger.kernel.org
Least wise that is where I look...
~
--
George Anzinger george@mvista.com
Andrew Morton wrote:
George Anzinger wrote:
Did you pick this up? First sent on 3-11.
I did, although now looking at it I have issues.
I was not happy with the locking on this. Two changes:
1) Turn off irq while setting the clock.
2) Call the timer code only through the timer interface
Did you pick this up? First sent on 3-11.
Andrew Morton wrote:
Lee Revell <[EMAIL PROTECTED]> wrote:
On Thu, 2005-03-10 at 00:42 -0800, George Anzinger wrote:
This patch changes the update of the cmos clock to be timer driven
rather than poll driven by the timer interrupt function. If the
t of thing:
if (oc.tv_sec | oc.tv_nsec) {
oc.tv_nsec += clock->res;
timespec_norm(&oc);
}
Also, we run rather extensive tests for this sort of thing.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
2 trees are as built, and the
diff I got was far larger than forgetting to apply the
bk-ieee1394.patch to one of them would account for. Many tens of
kilobytes in fact.
Please throw me a bone here folks.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/proj
john stultz wrote:
On Mon, 2005-03-14 at 15:40 -0800, George Anzinger wrote:
john stultz wrote:
On Sat, 2005-03-12 at 16:49 -0800, Matt Mackall wrote:
+ /* finally, update legacy time values */
+ write_seqlock_irqsave(&xtime_lock, x_flags);
+ xtime = ns2timespec(system_
e high-res-timers project site you
want to download the support patch. In there, among other things, is a set of
man pages on posix clocks & timers. The patch applies to any kernel and just
adds a new set of directories off of Documentation.
--
George Anzinger george@mvista.com
High-res
for which he has a patch tendered.
--
George Anzinger george@mvista.com
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 a
er have shown its ugly face if the system
wasn't using NTP.
--
George Anzinger george@mvista.com
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 [
errupt source. To
this point in time, the jiffies interrupt has been the indication that one or
more timer may have expired. While we don't need to "count" the interrupts, we
DO need them to expire the timers AND they need to be on time.
~
--
George Anzinger george@mvista.com
H
Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
I agree. Still in all that follows, no one has addressed the apparent race
described above. The reason the system reported the errors that started this
thread is that the APM restore code was trying to read the cmos clock (I
Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
Looks like we need the irq on the read clock also. This is true both before
and after the prior cmos_time changes.
The attached replaces the patch I sent yesterday.
For those wanting to fix the kernel with out those patches, all
pin_lock(arch/i386/kernel/time.c:c0603c28) already locked by
arch/i386/kernel/time.c/309
Mar 12 07:07:31 puzzle kernel: arch/i386/kernel/time.c:316:
spin_unlock(arch/i386/kernel/time.c:c0603c28) not locked
~
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-t
Andrew Morton wrote:
Lee Revell <[EMAIL PROTECTED]> wrote:
On Thu, 2005-03-10 at 00:42 -0800, George Anzinger wrote:
This patch changes the update of the cmos clock to be timer driven
rather than poll driven by the timer interrupt function. If the clock
is not being synced to an outside
tch is against linux-2.6.11-mm2 as it relies on the
'determine-scx200-cb-address-at-run-time.patch' patch which has not
made it into in the mainline.
Please CC me if you reply as I'm not subscribed to LKML.
Cheers,
-Ted
--
George Anzinger george@mvista.com
High-res-timers: http://sou
Ok, here is a patch. See what you think. This patch assumes that Lee's patch
has been merged (although it eliminates all of it).
George
George Anzinger wrote:
Lee Revell wrote:
On Fri, 2005-03-04 at 12:58 -0800, George Anzinger wrote:
Lee Revell wrote:
On Fri, 2005-03-04 at 02:28 -0800, G
Lee Revell wrote:
On Fri, 2005-03-04 at 12:58 -0800, George Anzinger wrote:
Lee Revell wrote:
On Fri, 2005-03-04 at 02:28 -0800, George Anzinger wrote:
The thing that brought this code to my attention is that with PREEMPT_RT
this happens to be the longest non-preemptible code path in the kernel
Lee Revell wrote:
On Fri, 2005-03-04 at 02:28 -0800, George Anzinger wrote:
Lee Revell wrote:
On Thu, 2005-03-03 at 16:45 -0800, Andrew Morton wrote:
If efi_enabled is true and efi_set_rtc_mmss(xtime.tv_sec) returns zero, the
new code will run set_rtc_mmss(xtime.tv_sec) whereas the old code won&#
such.
Surly this is covered in the various driver writing guides...
--
George Anzinger george@mvista.com
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
}
if (MCA_bus) {
-
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 g
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
High-res-timers: http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe
ping interrupts N/HZ where N is the number of CPUs.
George I am just working on your suggestion, let me know if it will work
for SMPs.
See above. Should solve your problem.
If there is some good implementation for SMP, please let me know.
Thanks,
- Puneet
On Tue, 2005-02-22 at 08:36, George A
.
Try the HRT patch (see signature below) and see if if doesn't do better.
--
George Anzinger george@mvista.com
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
an down the problem as the "boss" was
not interested in SMP...
George
--
George Anzinger george@mvista.com
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 [
ailer (Microsoft Outlook) set up your attachment in such a
way that my mailer would not inline it. You might want to look into this.
Sven
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
George Anzinger
Sent: Thursday, February 10, 2005 12:21 PM
To:
0)
#define __raw_spin_unlock_wait(x) \
do { barrier(); } while(__spin_is_locked(x))
in asm/spinlock.h
should that be __raw_spin_is_locked(x) instead?
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: se
If I want to write a patch that will work with or without the RT patch applied
is the following enough?
#ifndef RAW_SPIN_LOCK_UNLOCKED
typedef raw_spinlock_t spinlock_t
#define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED
#endif
--
George Anzinger george@mvista.com
High-res-timers: http
the address found in the dmesg file.
--
George Anzinger george@mvista.com
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
e signal
delivery) could switch in.
The primary thing needed for this is a simple and quick way to switch a tasks
priority, both from outside and from the task itself.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe fr
George Anzinger wrote:
Ingo Molnar wrote:
* George Anzinger wrote:
What I am suggesting is spliting the mark code so that it would only
grap the offset (current TSC in most systems) during interrupt
processing. Applying this would be done later in the thread. Since
it is not applying the
period;
+ timr->it.mmtimer.expires -= period;
if (reschedule_periodic_timer(base+i))
err = -EINVAL;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
1 - 100 of 225 matches
Mail list logo
