John,
On Fri, 2007-04-20 at 15:15 +0200, John Sigler wrote:
I've tweaked patch-2.6.20-rt8(*) so that it applies to 2.6.20.7
(*) http://rt.wiki.kernel.org/index.php/Main_Page
The original patch can be found here:
http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.20-rt8
On Mon, 2007-04-23 at 10:03 +0200, John Sigler wrote:
Can you create an entry in the rt-wiki, so people can find your
patches ?
Sure.
Should I add a link to my patch on the CONFIG PREEMPT RT Patch page?
http://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch#Download
e.g. in the
On Thu, 2007-03-08 at 18:29 +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Hi Ingo,
I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically,
it tests whether the SA_RESTART flag works for the sem_wait operation.
Not sure, whether the testcase is correct
On Thu, 2007-03-08 at 15:39 -0800, Jeremy Fitzhardinge wrote:
Ingo Molnar wrote:
- /One/ _intelligent_ higher-level virtualization API/ABI. Xen's API is
quite advanced on this front.
At last! Some love!
The Xen approach has always been to prefer high-level interfaces over
On Thu, 2007-03-08 at 15:55 -0800, Zachary Amsden wrote:
Jeremy Fitzhardinge wrote:
No, but I'm not prejudiced against virtual hardware. If we have a piece
of code that thinks its talking to an apic, then I think its OK to use
that code whether its a real apic or a virtual one, _so long as
On Fri, 2007-03-09 at 06:10 +0100, Nick Piggin wrote:
i think that's quite right. I'm wondering why this never came up before?
But your fix is not complete i think:
+ restart-arg2 = time;
+ return -ERESTART_RESTARTBLOCK;
+ }
'time' here is
On Fri, 2007-03-09 at 13:24 +0100, Nick Piggin wrote:
'time' here is relative, so the restarted syscall will do a /full/ wait
again.
But it has been modified by schedule_timeout?
But this does not change the syscall registers, so it is restarted in
the same way. We need a
On Fri, 2007-03-09 at 15:26 -0800, Jeremy Fitzhardinge wrote:
How does the clock period get set on periodic timers? In my clock
driver, I'm seeing a call to -set_mode(CLOCK_EVT_MODE_PERIODIC, evt),
but then... nothing. I was expecting a call to set_next_event to set
the timer period.
Good
On Sat, 2007-03-10 at 07:50 -0800, Jeremy Fitzhardinge wrote:
Thomas Gleixner wrote:
Good point. I never thought about that and we set the period in the
clock event device itself. You are right, the clockevents layer should
hand over the period either with the set_mode call or seperately
On Sat, 2007-03-10 at 14:52 -0800, Jeremy Fitzhardinge wrote:
When booting under Xen, you'll get this if you're using both the xen
clocksource and clockevent drivers. However, it seems that during boot
on a NO_HZ HIGHRES_TIMERS system, the kernel does not use the Xen
clocksource until it
On Sat, 2007-03-10 at 16:42 -0800, Jeremy Fitzhardinge wrote:
Thomas Gleixner wrote:
It's simply enforced in NO_HZ, HIGHRES mode as we operate in absolute
time, which is read back from the clocksource, even if we use a relative
value for real hardware clock event devices to program the next
Davide,
On Sat, 2007-03-10 at 18:22 -0800, Davide Libenzi wrote:
Some remarks:
+
+asmlinkage long sys_timerfd(int ufd, int clockid, int tmrtype,
+ const struct timespec __user *utmr)
+{
+ int error;
+ struct timerfd_ctx *ctx;
+ struct file *file;
+
On Sun, 2007-03-11 at 22:09 +0100, Rafael J. Wysocki wrote:
update_sched_domains
detach_destroy_domains
[waits here] -- synchronize_sched (==synchronize_rcu)
Well, I think the call to wait_for_completion() does not return,
probably
because the task
. Must-have for v2.6.21.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
--
kernel/futex.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/kernel/futex.c
===
--- linux.orig
Davide,
On Sun, 2007-03-11 at 16:04 -0700, Davide Libenzi wrote:
+static int timerfd_setup(struct timerfd_ctx *ctx, int clockid, int tmrtype,
+ const struct itimerspec *ktmr)
+{
+ enum hrtimer_mode htmode;
+ ktime_t texp, tintv;
+
+ if (clockid !=
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll
On Mon, 2007-03-12 at 12:02 +0100, Ingo Molnar wrote:
Well I did convert futex_wait to an absolute timeout based version in
the subsequent incremental patch. I think that is OK?
it still has the rounding artifacts: using timer_list there is no way to
do a precise long sleep based on many
On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote:
Subject: hrtimer_switch_to_hres():
wrong tick_init_highres() return value handling
References : http://lkml.org/lkml/2007/3/6/262
Submitter : Linus Torvalds [EMAIL PROTECTED]
Caused-By : Thomas Gleixner [EMAIL PROTECTED
On Tue, 2007-03-13 at 16:02 -0400, Chuck Ebbert wrote:
struct itimerval tim = {
.it_interval = {
.tv_sec = 140735669863712,
.tv_usec = 4199521
},
Could this be fixed by:
On Tue, 2007-03-13 at 13:50 +0100, Adrian Bunk wrote:
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a
for this condition and set the expiry value to the max. expiry
time in the future.
The fix should be applied to stable kernel series as well.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED],de
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index ec4cb9f..5e7122d 100644
--- a/kernel/hrtimer.c
+++ b
On Wed, 2007-03-14 at 19:02 +0100, Florian Lohoff wrote:
On Wed, Mar 14, 2007 at 12:44:17PM +0100, Adrian Bunk wrote:
Due to the huge amount of recipients, please trim the Cc when answering.
Subject: Clocksource tsc unstable (delta = -154983451 ns)
References :
commit f4304ab21513b834c8fe3403927c60c2b81a72d7 (HZ free NTP) moved the
access to wall_to_monotonic in hrtimer_get_softirq_time() out of the
xtime_lock protection.
Move it back into the seq_lock section.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/kernel/hrtimer.c b/kernel
Davide,
On Wed, 2007-03-14 at 15:19 -0700, Davide Libenzi wrote:
+static int timerfd_tmrproc(struct hrtimer *htmr)
+{
+ struct timerfd_ctx *ctx = container_of(htmr, struct timerfd_ctx, tmr);
+ int rval = HRTIMER_NORESTART;
+ unsigned long flags;
+
+
On Thu, 2007-03-15 at 17:22 -0700, Davide Libenzi wrote:
+static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+ const struct itimerspec *ktmr)
+{
+ enum hrtimer_mode htmode;
+
+ htmode = (flags TFD_TIMER_ABSTIME) ? HRTIMER_MODE_ABS:
On Thu, 2007-03-15 at 16:02 -0700, Davide Libenzi wrote:
+ /*
+ * When we call this, the initialization must be complete, since
+ * aino_getfd() will install the fd.
+ */
+ error = aino_getfd(ufd, inode, file, [timerfd],
+
On Fri, 2007-03-16 at 21:34 +0100, Rafael J. Wysocki wrote:
On Friday, 16 March 2007 17:33, Linus Torvalds wrote:
I pushed out the -git trees yesterday, but then got distracted, so the
patches and tar-balls and the announcement got delayed until this morning.
Oops. I'm a scatter-brain.
On Fri, 2007-03-16 at 12:43 -0800, Andrew Morton wrote:
On Wed, 14 Mar 2007 11:00:12 +0100 Thomas Gleixner [EMAIL PROTECTED] wrote:
rtimer_forward() does not check for the possible overflow of
timer-expires. This can happen on 64 bit machines with large interval
values and results
phase and then switch over to highres resp.
nohz mode were simply wrong.
Add the appropriate suspend / resume handling for the non periodic
modes.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 5567745..eadfce2
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
Mar 14 00:22:23 MAIN kernel: [2.072875] caller is
check_tsc_sync_source+0x1d/0x100
Mar 14 00:22:23 MAIN kernel: [2.072878] [show_trace_log_lvl+26/48]
show_trace_log_lvl+0x1a/0x30
Mar 14 00:22:23 MAIN kernel: [2.072931]
Maxim,
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
3) Sometimes I get this (once in three boots or so)
[ 36.217405] ENABLING IO-APIC IRQs
[ 36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 36.433917] APIC timer disabled due to verification failure.
And
or not) USB keyboard.
This prohibits the accurate delivery of PIT interrupts, which are used
to calibrate the local APIC timer. Unfortunately we have no way to
disable this BIOS misfeature in the early boot process.
Add also the dropped cpu_relax() back to the wait loops.
Signed-off-by: Thomas
On Wed, 2007-02-14 at 15:26 -0800, [EMAIL PROTECTED] wrote:
Subject: small irq management simplification
From: Jan Beulich [EMAIL PROTECTED]
Use mask_ack_irq() where possible.
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL
On Fri, 2007-02-16 at 21:38 +0100, Michal Piotrowski wrote:
Hi,
This looks like a tickless stuff
Yup.
0xc0139ea0 is in tick_nohz_stop_sched_tick
(/mnt/md0/devel/linux-git/kernel/time/tick-sched.c:168).
163
164 if (need_resched())
165 goto end;
166
167
On Fri, 2007-02-16 at 21:08 -0500, Len Brown wrote:
Yes, an obscure .config, but it used to build before today:
kernel/built-in.o: In function `tick_broadcast_on_off':
(.text+0x1b6f0): undefined reference to `smp_call_function_single'
Yup, this obscure machine is missing
On Sat, 2007-02-17 at 15:47 +0100, Alex Riesen wrote:
164 if (need_resched())
165 goto end;
166
167 cpu = smp_processor_id();
168 BUG_ON(local_softirq_pending());
Hmm, the BUG_ON is inside of an interrupt disabled region,
On Sat, 2007-02-17 at 15:56 +0100, Andi Kleen wrote:
This is one of the reasons why we don't just use good old
do_gettimeofday(), since it takes locks and can lead to lock recursion
if parts of itself are probed.
do_gettimeofday doesn't take locks.
Only restriction is that you can't
On Sat, 2007-02-17 at 17:46 +0100, Alex Riesen wrote:
Can you please apply the patch below, so we can at least see, which
softirq is pending. This should trigger independently of hrtimers and
dynticks. You can keep it compiled in and disable it at the kernel
commandline with nohz=off and /
On Sat, 2007-02-17 at 12:25 -0600, James Bottomley wrote:
Yup, this obscure machine is missing smp_call_function_single().
James ?
Where's this coming from? smp_call_function_single() is an obscure kvm
only API think for x86/ia64 ... it's not supported on any other
architecure. The
The broadcast functionality is only necessary when a local APIC is
available. Make the config switch depend on X86_LOCAL_APIC. This
resolves the mach-voyager breakage introduced by the tick managament
code.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/arch/i386/Kconfig b/arch
On Sat, 2007-02-17 at 23:41 +0100, Michal Piotrowski wrote:
sudo cat /var/log/messages | grep Idle
Feb 17 17:35:34 bitis-gabonica kernel: Idle: local softirq pending:
00206hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache,
UDMA(33)
Feb 17 19:20:01 bitis-gabonica kernel: Idle: local
On Sun, 2007-02-18 at 10:50 +0100, Alex Riesen wrote:
The arch/i386/kernel/process.c part of the patch should apply to 2.6.20
as well. Can you check if the problem is there too ?
It does not apply and does not look trivially hackable.
The code for cpu_idle was introduced in 2ff2d3d7 i386:
Len,
On Fri, 2007-03-16 at 21:32 -0400, Len Brown wrote:
[ 36.433917] APIC timer disabled due to verification failure.
And NO_HZ is disabled due to that (I get 1000/s timer's interrupts)
I haven't investigated that yet.
It looks like another new test that my hardware fails to
On Sat, 2007-03-17 at 10:56 +0100, Thomas Gleixner wrote:
calibrating APIC timer ...
... lapic delta = 2426884
... PM timer delta = 833908
APIC calibration PIT not consistent with PM Timer: 232ms instead of 100ms
APIC delta adjusted to PM-Timer: 1041737 (2426884)
. delta 1041737
On Sat, 2007-03-17 at 10:56 +0100, Thomas Gleixner wrote:
Maybe I could follow the new logic in apic.c if I saw the apic=debug
output for this box.
calibrating APIC timer ...
... lapic delta = 2426884
... PM timer delta = 833908
APIC calibration PIT not consistent with PM Timer: 232ms
On Sat, 2007-03-17 at 23:41 +0200, Michael S. Tsirkin wrote:
a quick ping: on your box that doesnt resume - if you can log in over
the network after resume (or somehow run shell commands), does 'date'
advance properly or not? (or do you not get that far to be able to
tell?)
Maxim,
On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization
[CPU#0 - CPU#1]:
Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC
warp between CPUs, turning off
^ This one I don't think is related
On Sun, 2007-03-18 at 00:12 -0800, Andrew Morton wrote:
On Sat, 17 Mar 2007 01:04:56 +0100 Thomas Gleixner [EMAIL PROTECTED] wrote:
When PM-Timer is available for local APIC timer calibration we can skip
the verification of the calibrated time value. The resulting error is
quite small
On Sun, 2007-03-18 at 17:16 -0400, Chuck Ebbert wrote:
Thomas Gleixner wrote:
I'd prefer this one: The maximum seconds value we can handle on 32bit is
LONG_MAX.
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index c68c7ac..248305b 100644
--- a/include/linux/ktime.h
On Sun, 2007-03-18 at 17:53 -0400, Chuck Ebbert wrote:
Just to be clear: this replaces the earlier patch, right?
This replaces the fix Andrew did.
http://marc.info/?l=linux-kernelm=117407812411997w=2
Right, but is the original Prevent DOS patch from you still needed?
Or did
On Mon, 2007-03-19 at 18:10 +0100, Stefan Prechtel wrote:
So I tried to boot with nolapic on battery and with this option the
kernel (and system) starts as it should.
If you need more information, I will send it to you.
Can you please provide your .config and a bootlog from a boot with
nolapic
On Mon, 2007-03-19 at 18:36 +0100, Thomas Gleixner wrote:
On Mon, 2007-03-19 at 18:10 +0100, Stefan Prechtel wrote:
So I tried to boot with nolapic on battery and with this option the
kernel (and system) starts as it should.
If you need more information, I will send it to you.
Can you
Matt,
On Mon, 2007-03-19 at 12:08 -0500, Matt Mackall wrote:
On Sun, Mar 18, 2007 at 03:31:50PM -0500, Josh Boyer wrote:
On Sun, Mar 18, 2007 at 02:18:12PM -0500, Matt Mackall wrote:
I'm well aware of all that. I wrote a NAND driver just last month.
Let's consider this table:
Stefan,
On Mon, 2007-03-19 at 19:53 +0100, Stefan Prechtel wrote:
You can find the files here:
http://bugzilla.kernel.org/show_bug.cgi?id=8235
thanks for providing the data. Your ACPI tables don't provide
information about the power states (C-States), but your BIOS seems to
switch the CPUs
On Mon, 2007-03-19 at 20:49 +0100, Stefan Prechtel wrote:
Can you please boot with 2.6.20 or earlier and check the output
of /proc/interrupts ?
IRQ#0 and the LOC (local APIC timer) Interrupts should increment in the
same frequency.
tglx
Here is the output of
On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote:
CPU0 CPU1
0: 28289 0 local-APIC-edge-fasteio timer
...
LOC: 28237 28236
after a read: (I hope that is this what you want :-)
CPU0 CPU1
0: 30344 0
On Mon, 2007-03-19 at 15:12 -0500, Matt Mackall wrote:
Should we export block devices with 16/32/64/128 KiB size ?
Sure, why not?
Simply because we want to have the ability to write fine grained in
order to write data safe to FLASH. If we export those large sizes we
lose this ability and
On Mon, 2007-03-19 at 14:54 -0500, Matt Mackall wrote:
(UBI also has static volumes which LVM doesn't but that is an aside.)
If a static volume is simply a non-dynamic volume, then device mapper
can do that too. And countless other things. Which is not an aside.
UBI growing to do all the
rx2660).
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
Acked-by: Thomas Gleixner [EMAIL PROTECTED]
-
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
On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
If a static volume is simply a non-dynamic volume, then device mapper
can do that too. And countless other things. Which is not an aside.
UBI growing to do all the things that device mapper does is exactly
the thing we should be
On Mon, 2007-03-19 at 16:36 -0500, Matt Mackall wrote:
On Mon, Mar 19, 2007 at 11:06:33PM +0200, Artem Bityutskiy wrote:
On Mon, 2007-03-19 at 14:54 -0500, Matt Mackall wrote:
The issue is 14000 lines of patch to make a parallel subsystem.
Parallel system exists since very long. One is
Davide,
On Mon, 2007-03-19 at 16:47 -0700, Davide Libenzi wrote:
This patch add an anonymous inode source, to be used for files that need
and inode only in order to create a file*. We do not care of having an
inode for each file, and we do not even care of having different names in
the
On Mon, 2007-03-19 at 22:51 +0100, Stefan Prechtel wrote:
2007/3/19, Thomas Gleixner [EMAIL PROTECTED]:
On Mon, 2007-03-19 at 21:35 +0100, Stefan Prechtel wrote:
CPU0 CPU1
0: 28289 0 local-APIC-edge-fasteio timer
...
LOC: 28237 28236
On Mon, 2007-03-19 at 20:05 -0500, Matt Mackall wrote:
On Tue, Mar 20, 2007 at 01:42:46AM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
This is exactly the same problem as booting on a desktop PC. But
somehow LILO manages. My first Linux box had
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote:
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully
On Tue, 2007-03-20 at 17:47 +0100, Grzegorz Chwesewicz wrote:
I have HP nx6325. I've tried to use WARN_ON_ONCE patch, but I don't see
nothing special in dmesg. Just in case I'm posting my
dmesg_2.6.20_WARN_ON_ONCE_on_battery log on
http://bugzilla.kernel.org/show_bug.cgi?id=8235 .
Below I
On Wed, 2007-03-21 at 10:46 +0100, Andi Kleen wrote:
On Wednesday 21 March 2007 10:24, Thomas Gleixner wrote:
On Tue, 2007-03-20 at 17:47 +0100, Grzegorz Chwesewicz wrote:
I have HP nx6325. I've tried to use WARN_ON_ONCE patch, but I don't see
nothing special in dmesg. Just in case I'm
On Wed, 2007-03-21 at 11:37 +0100, Andi Kleen wrote:
The BIOS/ACPI is broken and does only expose C1, which should not switch
off LAPIC. The BIOS is switching into deeper C-States behind the kernels
back somehow.
Hmm, perhaps we can check AMD (cstate = 2 || has a battery) ?
Should be
On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote:
On Tue, 20 March 2007 01:42:46 +0100, Thomas Gleixner wrote:
On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
4. JFFS2 has its own wear-leving scheme, as do several other
filesystems, so they probably want to bypass
On Wed, 2007-03-21 at 12:35 +0100, Jörn Engel wrote:
Even if such flashes still contain a bootloader and a kernel, that will
occupy less than 1% of the device. Wear leveling across the device is
fairly pointless here. This is what I designed LogFS for.
Still you need to have a solution for
Stefan, Grzegorz
On Wed, 2007-03-21 at 12:14 +0100, Thomas Gleixner wrote:
On Wed, 2007-03-21 at 11:37 +0100, Andi Kleen wrote:
The BIOS/ACPI is broken and does only expose C1, which should not switch
off LAPIC. The BIOS is switching into deeper C-States behind the kernels
back somehow
On Wed, 2007-03-21 at 13:15 +0100, Thomas Gleixner wrote:
+ return;
+ }}
+
Ooops, sorry. Did not quilt refresh before sending it out. Correct
version below.
tglx
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 5cff797..83cf98d 100644
--- a/arch
On Tue, 2007-03-20 at 20:23 +0100, Andi Kleen wrote:
+ else if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
+ boot_cpu_data.x86 == 6)
+(boot_cpu_data.x86_model == 13 ||
+ boot_cpu_data.x86_model == 9))
What is
On Wed, 2007-03-21 at 14:04 +0100, Stefan Prechtel wrote:
I uploaded the output of dmesg (kernel 2.6.21-rc4-git5) (battery / ac)
and dmidecode
I can boot on battery with nolapic_timer and the second core is online, too.
/proc/acpi/processor/C000/ shows the same as before but
/proc/interrupts
On Tue, 2007-03-20 at 10:35 +0100, Marcus Better wrote:
Thomas Gleixner wrote:
I finally found a dual core box, which survives suspend/resume without
crashing in the middle of nowhere. Sigh, I never figured out from the
code and the bug reports what's going on.
The observed hangs
apic
timer interrupts for ever and makes the systems unusable.
Add a command line option to disable the local apic timer and a dmi
quirk for known broken systems.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel
On Thu, 2007-03-22 at 08:28 -0700, Greg KH wrote:
On Tue, Mar 20, 2007 at 11:54:03AM +, Pavel Machek wrote:
Hi!
[EMAIL PROTECTED]:/home/maxim# cat
/sys/devices/system/clockevents/clockevents0/registered
lapicF:0007 M:3(periodic) C: 1
hpet
On Thu, 2007-03-22 at 12:25 -0700, john stultz wrote:
On Thu, 2007-03-22 at 13:14 -0600, Bob Tracy wrote:
john stultz wrote:
Try this patch and let me know if it does the right thing.
Will do. I'll report back in a few hours.
Although I do
still need to dig a bit on the PIT
and later to periodic mode
fixes the weird bogomips value and also the resulting slowness.
The fix is confirmed on OLPC and another Geode based box.
Note: this is unrelated to the Dual Core problem discussed here:
http://lkml.org/lkml/2007/3/17/48
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED
On Thu, 2007-03-22 at 14:09 -0700, Andrew Morton wrote:
I think the term 'timer_interrupt' is a bit generic-sounding. Would it be
better to call it irqpoll_interrupt? After all, some architecture might
want to use, umm, the keyboard interrupt to trigger IRQ polling ;)
Interesting thought,
On Thu, 2007-03-22 at 14:42 +0100, Adrian Bunk wrote:
Starting with head as of yesterday and reverting two commits (that are
duplicates of each other -- the same commit came into Linus's tree via
two different paths) 'fixes' the problem for me. I'll let those with the
big brains decide
On Thu, 2007-03-22 at 15:16 +0100, Adrian Bunk wrote:
Does it work if you do _not_ revert the commits, and instead replace in
drivers/acpi/processor_idle.c the
#ifdef ARCH_APICTIMER_STOPS_ON_C3
with an
#if 0
?
Then NOAPIC probably works again, but booting w/o NOAPIC
On Fri, 2007-03-23 at 12:42 +0100, Ingo Molnar wrote:
there's a new post-rc4 regression: my T60 hangs during early bootup. I
bisected the hang down to this recent commit:
| commit 25496caec111481161e7f06bbfa12a533c43cc6f
| Author: Thomas Renninger [EMAIL PROTECTED]
| Date: Tue Feb 27
On Fri, 2007-03-23 at 12:56 +0100, Thomas Gleixner wrote:
We should revert that patch and add a trust_lapic_timer_in_c2
commandline option instead. So we are on the safe side.
Here is a patch which applies after reverting
25496caec111481161e7f06bbfa12a533c43cc6f
It turned out
On Fri, 2007-03-23 at 11:28 -0700, Linus Torvalds wrote:
On Fri, 23 Mar 2007, Linus Torvalds wrote:
Thomas, please fix.
Here's a possible fix. It compiles. And I still wish we had common files.
You beat me by 30 seconds.
ia64 shouldn't be affected, because ia64 doesn't #define the
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter : David L [EMAIL PROTECTED]
Caused-By : Thomas Gleixner [EMAIL PROTECTED]
commit
On Fri, 2007-03-23 at 20:15 +0100, Thomas Gleixner wrote:
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter : David L [EMAIL PROTECTED]
Caused-By : Thomas Gleixner
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter : Emil Karlson [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Status
Submitter : Michael S. Tsirkin [EMAIL PROTECTED]
Soeren Sonnenburg [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Tejun Heo [EMAIL PROTECTED]
Rafael J. Wysocki [EMAIL PROTECTED]
Status : problem
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: Dynticks and High resolution Timer hanging the system
workaround: clocksource=acpi_pm
References : http://lkml.org/lkml/2007/3/7/504
Submitter : Stephane Casset [EMAIL PROTECTED]
Caused-By : Thomas Gleixner
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter : Michal Piotrowski [EMAIL PROTECTED]
Handled-By : Thomas Gleixner [EMAIL PROTECTED]
Ingo Molnar [EMAIL PROTECTED]
Status
On Fri, 2007-03-23 at 19:48 +0100, Adrian Bunk wrote:
Subject: x86_64: ACPI regression with noapic (APICTIMER_STOPS_ON_C3?)
References : http://lkml.org/lkml/2007/3/8/468
http://lkml.org/lkml/2007/3/22/156
Submitter : Ray Lee [EMAIL PROTECTED]
Handled-By : Thomas Gleixner
On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
Thomas Gleixner wrote:
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org/show_bug.cgi?id=8027
Submitter : David L [EMAIL PROTECTED]
Caused
On Fri, 2007-03-23 at 23:43 +0100, Thomas Gleixner wrote:
On Fri, 2007-03-23 at 18:23 -0400, Chuck Ebbert wrote:
Thomas Gleixner wrote:
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: gettimeofday increments too slowly
References : http://bugzilla.kernel.org
Ray,
On Fri, 2007-03-23 at 17:14 -0700, Ray Lee wrote:
(I wondered about the IPI on a UP system, seemed a bit weird :-).)
Works great, booting both with NOAPIC and without. *Much* thanks for
debugging this while you're also handling a bunch of other issues at
the same time.
Thank you for
Emil,
On Fri, 2007-03-23 at 20:22 +0100, Thomas Gleixner wrote:
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: dynticks makes ksoftirqd1 use unreasonable amount of cpu time
References : http://bugzilla.kernel.org/show_bug.cgi?id=8100
Submitter : Emil Karlson [EMAIL
On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote:
On 23/03/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
Subject: soft lockup detected on CPU#0
References : http://lkml.org/lkml/2007/3/3/152
Submitter : Michal
and tsc_unstable by tsc_enabled, which is only set
when the tsc is available and not unstable.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c
index 0e65f7a..6cb8f53 100644
--- a/arch/i386/kernel/tsc.c
+++ b/arch/i386/kernel/tsc.c
@@ -18,6
On Sun, 2007-03-25 at 09:11 +0200, Michael S. Tsirkin wrote:
I lost track of Michaels various nested problems.
Michael can you please give a summary on _all_ entries in the
regressions list against Linus latest ?
I tested 2 different configurations on my T60:
- With CONFIG_NO_HZ
Environment: Pre Pentium systems, (boot_cpu_data.wp_works_ok == 0)
Last known working kernel: 2.6.18 (did not try 2.6.19 yet)
Enabling CONFIG_PREEMPT on latest mainline as well as 2.6.20 trigger
[ 14.15] BUG: sleeping function called from invalid context at
1 - 100 of 29419 matches
Mail list logo
