On Sat, 10 Feb 2007, Eric W. Biederman wrote:
There are not enough details in the justification to really understand
the issue so I'm asking to see if someone has some more details.
The description makes the assertion that reprograming the ioapic
when an interrupt is pending is the only
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
What I am looking at doing is:
mask
read io_apic
-- Past this point no more irqs are expected from the io_apic
-- Now I work to drain any inflight/pending instances of the irq
send ipi to all irq destinations cpus and wait for it to return
On Sun, 11 Feb 2007, Eric W. Biederman wrote:
2.15.2 PCI Express* Legacy INTx Support and Boot Interrupt
http://download.intel.com/design/chipsets/datashts/30262802.pdf
Ouch. And this kind of thing isn't exactly uncommon.
However if we have the irqs also disabled in the i8259 we should
thanks to Tobias Hain for help in testing and investigating the bug.
Tested on;
i386, Chips Technologies 65548 VESA VBE 1.2
CONFIG_VIDEO_SELECT=Y
CONFIG_FIRMWARE_EDID=Y
Untested on x86_64.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.20-rc6-mm1/arch/i386/boot/video.S
On Thu, 15 Feb 2007, Randy Dunlap wrote:
On Thu, 15 Feb 2007 08:29:49 -0800 (PST) Zwane Mwaikambo wrote:
VBE1.2 doesn't support function 15h (DDC) resulting in a 'hang' whilst
uncompressing kernel with some video cards. Make sure we check VBE version
before fiddling around with DDC
On Thu, 15 Feb 2007, Andrew Morton wrote:
This makes the long-suffering-but-vigorously-defended Vaio come up with a
black display. Everything's working OK otherwise. Sort of a Black Screen
of Life. I wouldn't call it an improvement though.
Bugger, what does your kernel commandline look
My previous compat AGP patch broke modular AGPGART.
Test built on;
i386 CONFIG_AGP=y,m
x86_64 CONFIG_AGP=y
ia64 CONFIG_AGP=m
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.20-mm1-ia64/drivers/char/agp/Makefile
On Thu, 15 Feb 2007, Andrew Morton wrote:
On Thu, 15 Feb 2007 21:45:06 -0800 Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 15 Feb 2007 21:35:35 -0800 (PST) Zwane Mwaikambo [EMAIL
PROTECTED] wrote:
On Thu, 15 Feb 2007, Andrew Morton wrote:
This makes the long-suffering
On Fri, 16 Feb 2007, Kyle McMartin wrote:
On Thu, Feb 15, 2007 at 10:09:57PM -0800, Zwane Mwaikambo wrote:
+ifeq ($(CONFIG_COMPAT),y)
+agpgart-y += compat_ioctl.o
+endif
+
eh?
Couldn't this be?
agpgart-$(CONFIG_COMPAT) += compat_ioctl.o
Yep thay works too
On Thu, 15 Feb 2007, Andrew Morton wrote:
It's not an X problem - the screen is black immediately upon loading the
kernel.
But I guess you knew that and you're just after display info:
http://userweb.kernel.org/~akpm/Xorg.0.log.txt
Thanks, the X log told me your VBE version. I tried to
On Fri, 16 Feb 2007, Andrew Morton wrote:
On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo [EMAIL PROTECTED]
wrote:
On Thu, 15 Feb 2007, Andrew Morton wrote:
It's not an X problem - the screen is black immediately upon loading the
kernel.
But I guess you knew
On Sun, 18 Feb 2007, Andi Kleen wrote:
On Saturday 17 February 2007 09:35, Zwane Mwaikambo wrote:
On Fri, 16 Feb 2007, Andrew Morton wrote:
On Fri, 16 Feb 2007 06:39:45 -0800 (PST) Zwane Mwaikambo [EMAIL
PROTECTED] wrote:
On Thu, 15 Feb 2007, Andrew Morton wrote
On Mon, 19 Feb 2007, Andi Kleen wrote:
I tested the x86_64 VBE3 case (similar to Andrew's VAIO), so we just need
a VBE1.2 on x86_64 test.
Does this mean you want to have an updated patch or not?
Nope, i'm happy with the last patch i sent (below to reconfirm).
Thanks
Index:
On Mon, 19 Feb 2007, Olaf Hering wrote:
2.6.20-git14
cp arch/powerpc/configs/g5_defconfig ../O-linus/.config
time env LC_ALL=C make -k O=../O-linus
...
Building modules, stage 2.
MODPOST 127 modules
WARNING: compat_agp_ioctl [drivers/char/agp/agpgart.ko] undefined!
make[2]: ***
On Mon, 19 Feb 2007, Prarit Bhargava wrote:
/* For assembly routines */
+#ifdef CONFIG_HOTPLUG_CPU
+#define __INIT .section.text,ax
+#define __INITDATA .section.data,aw
+#else
#define __INIT .section.init.text,ax
-#define __FINIT
On Tue, 27 Feb 2007, Eric W. Biederman wrote:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch
That's mainly an Andi decision. Let's cc him.
Would be good to have Eric also ack
On Sun, 4 Mar 2007, Gene Heskett wrote:
There will be times when the mainline scheduler feels more interactive
than this scheduler, and that is because it has significant unfairness
granted towards interactive tasks. This degree of unfairness in an
effort to maintain interactivity has been
Hi Daniel,
On Tue, 31 Jul 2007, Daniel Drake wrote:
Hi,
H. Peter Anvin wrote:
So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are
further patches needed?
It should, yes.
It didn't work, and the bug still exists in 2.6.23-rc1: the resolution is
wrong by
On Tue, 5 Apr 2005, shaun wrote:
+Hardware Specs
Dual Xeon 800FSB
Intel Server Board
4GB ECC DDR
3ware 9500 Sata Raid Card
5x200 GB sata drives in a raid 10 Config (1 hot spare)
Dual Nic
+OS Specs
CentOS 3.4 running a custom 2.6.x kernel patched with UML SKA's Patch
eth0 is 0.0.0.0
On Thu, 7 Apr 2005, Magnus Damm wrote:
On Apr 6, 2005 4:28 PM, Malcolm Rowe [EMAIL PROTECTED] wrote:
Magnus Damm writes:
And I guess the idea of replacing the initcall pointer with NULL will
work both with and without function descriptors, right? So we should
be safe on IA64 and
On Wed, 6 Apr 2005, Jeff Garzik wrote:
On Thu, Apr 07, 2005 at 11:40:23AM +1000, Martin Pool wrote:
On Wed, 06 Apr 2005 23:39:11 +0400, Paul P Komkoff Jr wrote:
http://bazaar-ng.org/
I'd like bazaar-ng to be considered too. It is not ready for adoption
yet, but I am working (more
On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote:
No, sorry, i have to run with bridging support other wise the guests(UML's)
wont be able to communicate with the outside world.
Ok in that case, can you connect a serial console so that you can capture
the entire output?
Thanks,
Zwane
-
Hello Shaohua,
On Tue, 12 Apr 2005, Li Shaohua wrote:
These patches (together with 5 patches followed this one) are updated
suspend/resume SMP patches. The patches fixed some bugs and do clean up
as suggested. Now they work for both suspend-to-ram and suspend-to-disk.
Patches are against
On Tue, 12 Apr 2005, Li Shaohua wrote:
#ifdef CONFIG_HOTPLUG_CPU
+int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
+{
+ return 0;
+}
+
Any way for you to avoid using weak attribute?
Thanks,
Zwane
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Tue, 12 Apr 2005, [EMAIL PROTECTED] wrote:
The machine crashed again twice today. I have vga=791 so i caugh a bit more
of the crash. i enabled serial redirection in the bios so i'm hoping to
catch the full dump next time.
Cool, can you also try Cc'ing [EMAIL PROTECTED]
Thanks,
On Tue, 12 Apr 2005, Li Shaohua wrote:
On Tue, 2005-04-12 at 20:17, Zwane Mwaikambo wrote:
On Tue, 12 Apr 2005, Li Shaohua wrote:
#ifdef CONFIG_HOTPLUG_CPU
+int __attribute__ ((weak)) smp_prepare_cpu(int cpu)
+{
+ return 0;
+}
+
Any way for you to avoid using weak
On Wed, 9 Feb 2005, Marcos D. Marado Torres wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 4 Feb 2005, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
Andrew,
Please add to -mm the patch in attachment,
oprofile_arch_exit
oprofile_arch_init()
error path
oprofile_arch_exit()
__exit nmi_exit()
__exit exit_driverfs()
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
= arch/i386/oprofile/nmi_int.c 1.27 vs edited =
--- 1.27/arch/i386/oprofile
management support.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
= arch/arm/oprofile/op_arm_model.h 1.1 vs edited =
--- 1.1/arch/arm/oprofile/op_arm_model.h2004-04-12 11:55:34 -06:00
+++ edited/arch/arm/oprofile/op_arm_model.h 2005-02-08 23:02:20 -07:00
@@ -24,6 +24,6
On Fri, 11 Feb 2005, Nathan Lynch wrote:
With 2.6.11-rc3-bk7 on ppc64 I am seeing lots of smp_processor_id
warnings whenever I hotplug cpus:
# echo 0 /sys/devices/system/cpu/cpu1/online
cpu 1 (hwid 1) Ready to die...
BUG: using smp_processor_id() in preemptible [0001] code:
On Mon, 14 Feb 2005, Nathan Lynch wrote:
It looks as if we need to explicitly bind worker threads to a newly
onlined cpu. This gets rid of the smp_processor_id warnings from
cache_reap. Adding a little more instrumentation to the debug
smp_processor_id showed that new worker threads were
Ensure that we only offline the processor when it's safe and never run
softirqs in another processor's ksoftirqd context. This also gets rid of
the warnings in ksoftirqd on cpu offline.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.11-rc3-mm2/kernel/softirq.c
On Tue, 15 Feb 2005, Andrew Morton wrote:
Zwane Mwaikambo [EMAIL PROTECTED] wrote:
Ensure that we only offline the processor when it's safe and never run
softirqs in another processor's ksoftirqd context. This also gets rid of
the warnings in ksoftirqd on cpu offline.
I don't get
On Wed, 16 Feb 2005, Joshua Kwan wrote:
CPU0
0:1073809 XT-PIC timer
1: 1291 XT-PIC i8042
2: 0 XT-PIC cascade
4: 7 XT-PIC serial
5: 4366 XT-PIC eth0
7: 12 XT-PIC
On Thu, 17 Feb 2005, Davide Rossetti wrote:
maybe RTFM...
a module:
- char device driver for..
- a PCI device
any clue as to how to protect from module unloading while there is still some
process opening it??? have I to sleep in the remove_one() pci driver function
till last process
On Thu, 17 Feb 2005, Zwane Mwaikambo wrote:
On Thu, 17 Feb 2005, Davide Rossetti wrote:
maybe RTFM...
a module:
- char device driver for..
- a PCI device
any clue as to how to protect from module unloading while there is still
some
process opening it??? have I to sleep
On Tue, 15 Feb 2005, Joseph Cosby wrote:
Hi,
Using VMWare 4 with a 2.6.9 kernel I get IO-APIC + timer doesn't work! As
suggested, the noapic option fixes the problem. This resulted after adding
APIC support to my kernel. My problem is, I need APIC support to boot on a
separate, non-VMWare
On Thu, 17 Feb 2005, Joshua Kwan wrote:
Zwane Mwaikambo wrote:
Check that the hostap interrupt handler is 2.6 aware (IRQ_HANDLED etc)
It shows up even before the hostap module is loaded (and in fact appears
to stop showing up when that happens.) Here's the full output of dmesg
On Fri, 15 Jul 2005, Lee Revell wrote:
On Fri, 2005-07-15 at 14:08 +1000, Con Kolivas wrote:
Audio did show slightly larger max latencies but nothing that would be of
significance.
On video, maximum latencies are only slightly larger at HZ 250, all the
desired cpu was achieved, but
already dereference current so we're already relying on MSR_GS_BASE being
sane.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc2-mm1/arch/x86_64/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.13-rc2-mm1
On Fri, 15 Jul 2005, Zwane Mwaikambo wrote:
Up to date i've been using the GS value to determine the processor number
in dumps from show_regs, however this can be cumbersome to do if you don't
have the vmlinux to verify with the address of cpu_pda, how about the
following? I considered
On Fri, 15 Jul 2005, Andi Kleen wrote:
On Fri, 15 Jul 2005 05:04:57 -0600 (MDT)
Zwane Mwaikambo [EMAIL PROTECTED] wrote:
void show_regs(struct pt_regs *regs)
{
+ printk(CPU %d:, smp_processor_id());
Isn't there a space after the : missing here?
I don't believe so
On Sat, 23 Jul 2005, Russell King wrote:
On Sat, Jul 23, 2005 at 02:29:24AM +0200, Pavel Machek wrote:
Is it necessary to do free_irq for suspend? Shouldn't disable_irq
be enough?
Due to recent changes in ACPI, yes, it is neccessary.
What if some other driver is sharing the IRQ,
On Sat, 23 Jul 2005, [koi8-r] ? ? wrote:
The letter itself is in an attached file.
Run memtest, it sounds like you have failing hardware.
On Mon, 25 Jul 2005, Lee Revell wrote:
On Mon, 2005-07-25 at 17:19 -0400, Brown, Len wrote:
Question one, are there other actions to consider?
Yes.
Speaking for ACPI C3 state, note that DMA also
wakes up the CPU -- even if there was no device interrupt.
(aka, the trouble
On Wed, 27 Jul 2005, Lee Revell wrote:
On Wed, 2005-07-27 at 02:13 -0600, Zwane Mwaikambo wrote:
What about audio? If there is a sound server running then you're going
to have a constant stream of interrupts and DMA activity from the sound
card even if the machine is idle
On Mon, 4 Jul 2005, Martin Mokrejs wrote:
Hi,
I use on i686 architecture Gentoo linux with XFS filesystem.
Recently it happened to me 3 time that the machine locked,
although at least once sys-rq+b worked. Here is the log
from remote console. I don't remeber having such problems
with
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
353-disable-highmem-tlb-flush-for-copyback.patch-new/mm/highmem.c
--- 353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
2005-06-20 11:47:32.0
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
402-mtrr-remove-sysdev.patch-new/arch/i386/kernel/cpu/mtrr/main.c
--- 402-mtrr-remove-sysdev.patch-old/arch/i386/kernel/cpu/mtrr/main.c
2005-06-20 11:46:42.0
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
+ /*
+ * eflags
+ */
+ asm volatile (pushfl ; popl (%0) : =m
(suspend2_saved_context.eflags));
To be future proof you probably want to do pushfq/popq
+
+ /*
+ * control registers
+ */
+ asm volatile
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp 602-smp.patch-old/kernel/power/suspend2_core/smp.c
602-smp.patch-new/kernel/power/suspend2_core/smp.c
--- 602-smp.patch-old/kernel/power/suspend2_core/smp.c1970-01-01
10:00:00.0 +1000
+++
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
On Wed, 2005-07-06 at 13:34, Zwane Mwaikambo wrote:
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
diff -ruNp
353-disable-highmem-tlb-flush-for-copyback.patch-old/mm/highmem.c
353-disable-highmem-tlb-flush-for-copyback.patch-new/mm
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
On Wed, 2005-07-06 at 13:35, Zwane Mwaikambo wrote:
Isn't this covered by Shaohua Li's patch?
I believe so, but Shaohua Li's patch isn't merged in 2.6.12 (is it yet
at all). This is the solution I've been using for... can't remember how
long
On Wed, 6 Jul 2005, Nigel Cunningham wrote:
I've just noticed that all the subject lines are off by one. Sorry.
Shall I repost with it right this time?
Yes the subject lines did look a bit confusing, it may be easier in future
to add a short description of the patch instead of relying on the
set_cpus_allowed as set_cpus_allowed ensures that you're executing on the
target processor on return.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.13-rc1-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
===
RCS file:
/home
As most are aware there is a growing need for more devices on i386/x86_64
based platforms and with that, support for interrupt servicing for all
these devices. The proliferation of MSI based devices will also drive that
requirement higher due to some devices requiring multiple vectors. Natalie
On Sun, 11 Jul 2005, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
I would also not define it statically, but allocate it at boot time
in node local memory.
I went per node so that it would be minimal/zero impact for the no-node
case, it would also simplify
On Mon, 11 Jul 2005, Arjan van de Ven wrote:
On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
Agreed, for two reasons even
1) Per cpu allows for even more devices and cache locality
2) While few people have a NUMA system,
Hi Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
The change is so that we can send IRQs higher than 256 to do_IRQ. That
looks like it tries to check if we came in via system_call since we'd save
the system call number as orig_eax. Now that i think about it, doesn't
that path always
On Mon, 11 Jul 2005, Brian Gerst wrote:
Zwane Mwaikambo wrote:
On Sun, 11 Jul 2005, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
I would also not define it statically, but allocate it at boot time
in node local memory.
I went per node
Hello Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
Zwane Mwaikambo wrote:
--- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43
- 1.1.1.1
+++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37
-
-
+/* Build the IRQ entry stubs
On Tue, 15 Mar 2005, J. Bruce Fields wrote:
On Sat, Mar 12, 2005 at 08:21:29AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, J. Bruce Fields wrote:
On APM resume this morning on my Thinkpad X31, I got a spin_lock is
already locked error; see below. This doesn't happen on every
Hi Bjorn,
On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
That seems awfully suspicious to me. So the following is
probably safe as far as it goes, but not sufficient for all
cases.
VIA bridges allow for IRQ routing updates by programming
PCI_INTERRUPT_LINE, so it is supposed to work even if we
On Wed, 16 Mar 2005, Nathan Lynch wrote:
On Wed, Mar 16, 2005 at 02:21:52PM +0100, Pavel Machek wrote:
I tried to solve long-standing uglyness in swsusp cmp code by calling
cpu hotplug... only to find out that CONFIG_CPU_HOTPLUG is not
available on i386. Is there way to enable CPU_HOTPLUG
On Thu, 3 Mar 2005, Neil Brown wrote:
On Wednesday March 2, [EMAIL PROTECTED] wrote:
A Linus based odd number
might be closer to that if we hope on people unwittingly running them.
^^^
On Wed, 9 Mar 2005, Coywolf Qi Hunt wrote:
On Tue, 08 Mar 2005 12:28:42 -0500, Robert Love [EMAIL PROTECTED] wrote:
On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
This has been a doubt for a couple of days, and I am wondering if this
one could also be cleared. When you say
Hi Francesco,
On Tue, 8 Mar 2005, Francesco Oppedisano wrote:
i'm trying to estimate the interrupt latency (time between hardware
interrrupt and the start of the ISR) of a linux kernel 2.4.29 and i used
a simple tecnique: inside the do_timer_interrupt i read the 8259 counter
to obtain the
On Wed, 9 Mar 2005, linux-os wrote:
We need to retain the spin_lock_init(lock) because not all spin-locks
are allocated at compile-time. They might be allocated from kmalloc()
on startup, probably in a structure, along with other so-called
global data.
Not to worry my good man, it's not
changed, 70 insertions(+), 35 deletions(-)
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
Index: linux-2.6.11-mm2/arch/i386/kernel/process.c
===
RCS file: /home/cvsroot/linux-2.6.11-mm2/arch/i386/kernel/process.c,v
retrieving
On Thu, 10 Mar 2005, Andi Kleen wrote:
Zwane Mwaikambo [EMAIL PROTECTED] writes:
Andi noted that during normal runtime cpu_idle_map is bounced around a
lot, and occassionally at a higher frequency than the timer interrupt
wakeup which we normally exit pm_idle from. So switch
timer overrides are bogus. Just ignore
Thanks Chris
Acked-by: Zwane Mwaikambo [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 read
:
spin_unlock(arch/i386/kernel/time.c:c0603c28) not locked
APM was calling device_power_down and device_power_up with interrupts
enabled, resulting in a few calls to get_cmos_time being done with
interrupts enabled (rtc_lock needs to be acquired with interrupts
disabled).
Signed-off-by: Zwane
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 that is needed
On Sat, 12 Mar 2005, Venkatesh Pallipadi wrote:
On Sat, Mar 12, 2005 at 09:25:13AM -0700, Zwane Mwaikambo wrote:
On Sat, 12 Mar 2005, George Anzinger wrote:
And more... That this occures implies we are attempting to update the cmos
clock on resume seems wrong. One would presume
On Wed, 9 Mar 2005, Francesco Oppedisano wrote:
On Tue, 8 Mar 2005 12:09:58 -0700 (MST), Zwane Mwaikambo
[EMAIL PROTECTED] wrote:
At some cpu frequency point on i386 the main cause of your interrupt
service latency will be in the interrupt controller and how long from irq
assertion
On Sat, 12 Mar 2005, Jon Smirl wrote:
On Fri, 11 Mar 2005 14:36:10 +1100, Peter Chubb
[EMAIL PROTECTED] wrote:
As many of you will be aware, we've been working on infrastructure for
user-mode PCI and other drivers. The first step is to be able to
handle interrupts from user space.
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
assume to set the
On Sun, 27 Mar 2005, Jesper Juhl wrote:
I've now been running kernels (both PREEMPT, SMP, both and without both)
with the patch below applied for a few days and I see no ill effects. I'm
still interrested in comments about wether or not something like this
makes sense and is acceptable ?
On Wed, 23 Mar 2005, Pavel Machek wrote:
This is against -mm kernel; it is smp swsusp done right, and it
actually works for me. Unlike previous hacks, it uses cpu hotplug
infrastructure. Disable CONFIG_MTRR before you try this...
Test this if you can, and report any problems. If not enough
On Wed, 30 Mar 2005, Pavel Machek wrote:
Hi!
This is against -mm kernel; it is smp swsusp done right, and it
actually works for me. Unlike previous hacks, it uses cpu hotplug
infrastructure. Disable CONFIG_MTRR before you try this...
Test this if you can, and report any
On Mon, 4 Apr 2005, Li Shaohua wrote:
Clean up all CPU states including its runqueue and idle thread,
so we can use boot time code without any changes.
Note this makes /sys/devices/system/cpu/cpux/online unworkable.
#ifdef CONFIG_HOTPLUG_CPU
#include asm/nmi.h
+
+#ifdef
Hi Pavel!
On Mon, 4 Apr 2005, Pavel Machek wrote:
The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
tree.
Should I merge that thing into mainline? It seems that a few people are
needing it.
Perhaps we should address the MTRR issue first.
I've
On Mon, 28 Mar 2005, Jesper Juhl wrote:
On Sun, 27 Mar 2005, Zwane Mwaikambo wrote:
On Sun, 27 Mar 2005, Jesper Juhl wrote:
I've now been running kernels (both PREEMPT, SMP, both and without both)
with the patch below applied for a few days and I see no ill effects. I'm
still
On Mon, 4 Apr 2005, Steven Rostedt wrote:
On Mon, 2005-04-04 at 22:47 +0200, Ingo Molnar wrote:
Currently my fix is in yield to lower the priority of the task calling
yield and raise it after the schedule. This is NOT a proper fix. It's
just a hack so I can get by it and test other
On Tue, 5 Apr 2005, Esben Nielsen wrote:
I'm sure a lot of the yield() users could be converted to
schedule_timeout(), some of the users i saw were for low memory conditions
where we want other tasks to make progress and complete so that we a bit
more free memory.
Easy, but damn
On Tue, 5 Apr 2005, Li Shaohua wrote:
On Tue, 2005-04-05 at 03:10, Zwane Mwaikambo wrote:
On Mon, 4 Apr 2005, Li Shaohua wrote:
linux-2.6.11-root/arch/i386/kernel/smpboot.c |6 ++
linux-2.6.11-root/arch/i386/kernel/sysenter.c | 10 ++
linux
Per our discussion, i've ported the 2.6 nforce skip timer override (and
early PCI access) code to 2.4. This fixes an issue whereupon nforce
systems have incorrect override values for irq0. Architectures affected
are i386 and x86_64
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED
On Tue, 1 Mar 2005, Nathan Lynch wrote:
On Sun, Feb 27, 2005 at 02:49:28PM -0800, Andrew Morton wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
- if (cpu_is_offline(smp_processor_id())
+ if (cpu_is_offline(_smp_processor_id())
On Wed, 2 Mar 2005, Jeff V. Merkey wrote:
__Stable__ would be a good thing. The entire 2.6 development has been a
disaster from a stability viewpoint. I have to maintain a huge tree of
patches in order to ship appliance builds due to the lack of stability
for 2.6. I think that the even
On Wed, 2 Mar 2005, Lars Marowsky-Bree wrote:
On 2005-03-02T14:21:38, Linus Torvalds [EMAIL PROTECTED] wrote:
We'd still do the -rcX candidates as we go along in either case, so as a
user you wouldn't even _need_ to know, but the numbering would be a rough
guide to intentions. Ie I'd
I'm having trouble booting here, were those random-* patches tested?
Initializing random number generator: [ OK ]
Unable to handle kernel paging request at virtual address f5e5
printing eip:
c037a0a5
*pde = 0086e067
Oops: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
I pressed a key on a VT during boot and got the following;
usb-storage: device scan complete
[ cut here ]
kernel BUG at kernel/workqueue.c:104!
invalid operand: [#1]
PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in:
CPU:0
EIP:0060:[c01314af]Not tainted VLI
On Mon, 24 Jan 2005, Matt Mackall wrote:
On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
I'm having trouble booting here, were those random-* patches tested?
Works here, can you send me a copy of your init script?
#!/bin/bash
#
# randomScript to snapshot random
On Mon, 24 Jan 2005, Andrew Morton wrote:
I can't reproduce it from a quick test here. I'd assume that the keystroke
came in before the vt's workqueue is initialised. fn_enter() calls
put_queue() calls con_schedule_flip() calls schedule_work() which goes BUG:
Boot into runlevel 1 (console
On Tue, 25 Jan 2005, Andrew Morton wrote:
OK, thanks. I get what appears to be a use-after-free error.
CONFIG_DEBUG_PAGEALLOC is set:
Program received signal SIGEMT, Emulation trap.
0xc0272bc2 in kbd_keycode (keycode=57, down=1, hw_raw=0, regs=0xc0673f9c)
at
On Tue, 25 Jan 2005, Matt Mackall wrote:
On Mon, Jan 24, 2005 at 09:36:37PM -0700, Zwane Mwaikambo wrote:
I'm having trouble booting here, were those random-* patches tested?
EIP is at __add_entropy_words+0xc5/0x1c0
eax: 002d ebx: 000f ecx: 007b edx: f5e5
esi
On Fri, 28 Jan 2005, Andi Kleen wrote:
Forgive me for not wading through the code, but it really needs to
be spelt out in the comments: what's wrong with the existing kernel,
with noapic nolapic in the distro's bootstring by default?
It's harder to explain and traditionally in LILO you
Code: 90 90 90 90 90 90 90 55 89 e5 83 ec 18 89 5d f4 31 db 89 55 f0 ba ff
ff ff ff 89 75 f8 89 ce 89 d1 89 7d fc 89 c7 89 04 24 89 d8 f2 ae f7 d1
49 89 4c 24 04 8b 45 f0 89 f2 8b 4d 08 e8 66 e4 c1
-cpu_type is NULL since p4_init skipped this specific processor.
Signed-off-by: Zwane Mwaikambo
GLOBAL_POWER_EVENTS events (time during which processor is not
stopped) with a unit mask of 0x01 (count cycles when processor is active)
count 1
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
= arch/i386/oprofile/nmi_int.c 1.26 vs edited =
--- 1.26/arch/i386/oprofile/nmi_int.c 2005-01-07 22:44
We should be using profile_pc in oprofile_add_sample so that lock
contention is attibuted to the correct function in profile output. Also
fix SH7750 support.
Signed-off-by: Zwane Mwaikambo [EMAIL PROTECTED]
= drivers/oprofile/cpu_buffer.c 1.17 vs edited =
--- 1.17/drivers/oprofile
1 - 100 of 335 matches
Mail list logo
