CLOCK_EVT_MODE_RESUME, then 'opts' will be uninitialised at the
'*IXP4XX_OSRT1 = osrt | opts;' statement.
Initialising opts to zero in this case may not be correct, but
at least it's better than writing random junk to the hardware.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--
I'm not cc:ing linux-arm
Adrian Bunk writes:
The issue described in [1] is still present and unfixed (and even the
fix there wasn't complete since it didn't cover SMP).
Thanks to Riku Voipio for noting that it is still unfixed.
cu
Adrian
[1] http://lkml.org/lkml/2007/8/1/474
I think calling it a
Andi Kleen writes:
Pavel Emelyanov [EMAIL PROTECTED] writes:
this subdir;
3. sysctl inodes are now smaller than the procfs ones.
That's always a good thing.
Note: update your initscripts to mount sysctl filesystem
right after the proc is mounted in order not to lose your
Ard Biesheuvel writes:
This patch adds support for the PROT_FINAL flag to
the mmap() and mprotect() syscalls.
The PROT_FINAL flag indicates that the requested set
of protection bits should be final, i.e., it shall
not be allowed for a subsequent mprotect call to
set protection bits
Yangfei (Felix) writes:
Hi all,
I found that hardcoded instruction in inline asm can cause certains
certain features fail to work on ARM platform due to endianness.
As an example, consider the following code snippet of
platform_do_lowpower function from
On Wed, 26 Sep 2007 17:18:06 +0530, Balbir Singh wrote:
Andreas Schwab wrote:
Maxim Uvarov [EMAIL PROTECTED] writes:
diff --git a/Documentation/accounting/getdelays.c
b/Documentation/accounting/getdelays.c
index cbee3a2..73924df 100644
--- a/Documentation/accounting/getdelays.c
Ulrich Drepper writes:
On 9/26/07, John Z. Bohach [EMAIL PROTECTED] wrote:
Is there some reason that syslog() sleeps in __kernel_vsyscall() when
invoked from a signal handler?
Only very few functions are allowed to be called from signal handlers.
This is clearly spelled out in the
On Wed, 03 Oct 2007 17:06:24 +0900, Shi Weihua wrote:
Fixing alternative signal stack wraparound.
If a process uses alternative signal stack by using sigaltstack()
and that stack overflow, stack wraparound occurs.
This patch checks whether the signal frame is on the alternative
stack. If
On Wed, 3 Oct 2007 22:20:46 +0900, KAMEZAWA Hiroyuki wrote:
On Wed, 3 Oct 2007 21:40:29 +0900
KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
On Wed, 3 Oct 2007 14:20:07 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
What I don't agree with is the logic itself:
- You only
On Wed, 3 Oct 2007 22:33:46 +0300, Riku Voipio wrote:
What's the state of this patch? I can confirm tst-robust1
from glibc testsuite locks a armv5 machine hard. With this patch
applied, the test succeeds.
There were no comments from any Linux arch or futex maintainer.
Because of that I intend
On Thu, 4 Oct 2007 21:47:30 +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 04 Oct 2007 21:33:12 +0900
Shi Weihua [EMAIL PROTECTED] wrote:
KAMEZAWA Hiroyuki wrote::
On Thu, 04 Oct 2007 20:56:14 +0900
Shi Weihua [EMAIL PROTECTED] wrote:
stack.ss_sp = addr + pagesize;
stack.ss_flags
Jeff Norden writes:
From: Jeff Norden [EMAIL PROTECTED]
Fix lost interrupt problem when using dma with CD/DVD drives in some
configurations. This problem can make installing linux from media
impossible for distro's that have switched to libata-only configurations.
The simple fix
On this machine (Gigabyte mobo with i815EP chipset and a PIII),
APM worked fine up to 2.6.22. With 2.6.23-rc1 however the APM
driver fails to locate the APM bios:
--- dmesg-2.6.222007-07-23 14:07:46.0 +0200
+++ dmesg-2.6.23-rc12007-07-23 14:48:24.0 +0200
@@ -102,7
supported? */
return -1;
Here we see that the test has been accidentally inverted.
The fix is to negate the test. I've verified that this
allows the APM driver to work again on my affected machines.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
diff -rupN linux-2.6.23-rc1
On Mon, 23 Jul 2007 08:50:41 -0700, H. Peter Anvin wrote:
Mikael Pettersson wrote:
On this machine (Gigabyte mobo with i815EP chipset and a PIII),
APM worked fine up to 2.6.22. With 2.6.23-rc1 however the APM
driver fails to locate the APM bios:
--- dmesg-2.6.22 2007-07-23 14:07
Clark Cooper writes:
[1] Caught SIGFPE exceptions aren't reset
[2]
On an i386, you can set a handler for a SIGFPE signal, and after
enabling FP
exceptions with feenableexceptions(), an FP exception will cause
your handler
to be called. However after the handler
On Fri, 10 Aug 2007 01:45:38 +0200, Bartlomiej Zolnierkiewicz wrote:
On Friday 10 August 2007, Alan Cox wrote:
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R]
On Fri, 10 Aug 2007 18:33:43 +0100, Alan Cox wrote:
However, I'm gettting consistently lower read throughput with pata_artop
(13-19 MB/s) than with aec62xx (22 MB/s) on an oldish WD drive, and using
pata_artop triggers a WARN_ON(irqs_disabled()) in arch/arm/mm/consistent.c:
It would be
New URL due to local reorganization.
--- linux-2.6.23-git9/CREDITS.~1~ 2007-10-16 09:26:14.0 +0200
+++ linux-2.6.23-git9/CREDITS 2007-10-16 09:26:54.0 +0200
@@ -2702,7 +2702,7 @@ S: Canada K2P 0X8
N: Mikael Pettersson
E: [EMAIL PROTECTED]
-W: http://www.csd.uu.se
On Wed, 4 Jul 2007 12:23:18 +0200, Lennert Buytenhek wrote:
If you're also running into glibc's tst-robust1 test suite test
locking up your ARM machine, you're probably running into the fact
that asm-arm/futex.h includes asm-generic/futex.h, and
asm-generic/futex.h defines
[Resend. I messed up the To: line the first time]
As has been reported recently by Lennert Buytenhek, robust futexes
are broken on ARM:
If you're also running into glibc's tst-robust1 test suite test
locking up your ARM machine, you're probably running into the fact
that asm-arm/futex.h includes
On Thu, 2 Aug 2007 01:49:02 +0200, Lennert Buytenhek wrote:
On Thu, Aug 02, 2007 at 01:00:21AM +0200, Mikael Pettersson wrote:
@@ -52,7 +53,34 @@ futex_atomic_op_inuser (int encoded_op,
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval
On Fri, 03 Aug 2007 13:12:10 +0200, Grega Fajdiga wrote:
Hello, LKML,
I'm wondering if the old ide-cd from the ide subsystem is still
necessary to get a CD/DVD-ROM working or is there a libata driver
available already,
Please CC me since I'm not subscribed.
If you use libata then you
On Thu, 26 Apr 2007 15:50:50 -0700, Stephen Hemminger wrote:
On Thu, 26 Apr 2007 23:24:18 +0200
Francois SIMOND [EMAIL PROTECTED] wrote:
Hello,
Lastest sky2 update between 2.6.21-rc7 and 2.6.21 final disables the support
of the integrated ethernet adapter build on the Asus P5B-E Plus
On Mon, 30 Apr 2007 12:51:05 +0200, Juergen Beisert wrote:
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
If this register is 0x00 before, it is still 0x00 after this line. If I
change
the line into this:
ccr2 = getCx86(CX86_CCR2);
ccr2 |= 0x88;
On Mon, 30 Apr 2007 15:09:58 +0200, Juergen Beisert wrote:
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined functions this line will work as
On 30 Apr 2007 17:32:04 +0200, Andi Kleen wrote:
From: Juergen Beisert [EMAIL PROTECTED]
Replace NSC/Cyrix specific chipset access macros by inlined functions.
With the macros a line like this fails (and does nothing):
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
With inlined
like this:
Clocksource tsc unstable (delta = -472746897 ns)
Tested on a Geode GX1 system.
This is the second version with some modifications suggested by
Mikael Pettersson
Signed-off-by: Juergen Beisert [EMAIL PROTECTED]
Acked-by: Mikael Pettersson [EMAIL PROTECTED]
Index: linux
On Thu, 07 Apr 2005 12:17:37 +0200, Arjan van de Ven wrote:
On Thu, 2005-04-07 at 20:10 +1000, Keith Owens wrote:
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep() result in a
start fields
64 bits (for future-proofing the ABI). Remove map field from
pmc[] array to avoid underutilised cache lines.
- x86.c: retrieve mapping from -control.pmc_map[].
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/x86.c | 24 ++--
include
state, and
increment it in perfctr_cpu_resume() and perfctr_cpu_sample().
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/ppc.c | 16
include/asm-ppc/perfctr.h | 15 +--
2 files changed, 17 insertions(+), 14 deletions(-)
diff -rupN linux
-visible state, and
increment it in perfctr_cpu_resume() and perfctr_cpu_sample().
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/ppc64.c | 16
include/asm-ppc64/perfctr.h | 13 -
2 files changed, 16 insertions(+), 13 deletions(-)
diff -rupN
On Mon, 18 Apr 2005 00:27:02 +0200, Alexander Nyberg wrote:
This patch fixes the NMI checking problems in -mm x64 for me. It
What problems?
changes the perfctr selection to use RETIRED_UOPS instead
(makes both processors tick even on my box).
This patch mixes what appears to be cleanups with
On Mon, 18 Apr 2005 11:56:15 +0200, Alexander Nyberg wrote:
This patch fixes the NMI checking problems in -mm x64 for me. It
What problems?
Sorry, in -mm on x64 check_nmi_watchdog() has started to be run as a
late_initcall(). Currently it reports the NMIs as stuck on a few systems
although
Andi Andrew,
The x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state.patch in
2.6.12-rc2-mm3 appears to have broken the NMI watchdog. Specifically:
diff -puN
arch/x86_64/kernel/nmi.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
arch/x86_64/kernel/nmi.c
---
On Fri, 04 Feb 2005 17:19:09 +0100, Andreas Gruenbacher wrote:
On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
Plain www.kernel.org kernels always.
Good, it's no bug then. Stephen already explained what's going on: when
a file has xattrs and you delete the file while running a kernel
On Sat, 05 Feb 2005 15:20:00 +0100, Andreas Gruenbacher wrote:
On Sat, 2005-02-05 at 13:39, Mikael Pettersson wrote:
[...] It does not explain why 2.6 allocated
the xattr blocks in the first place; as I wrote initially, I
have disabled the xattrs stuff:
CONFIG_EXT3_FS=y
Here is a preliminary set of patches to allow gcc-4.0 (20050130)
to compile the 2.4.30-pre1 kernel. I make no claim that the patches
are complete, but they have been tested successfully on i386 (multiple
boxes), x86-64, and ppc32.
The changes fall into these categories:
- static-vs-non-static
On my x86-64 laptop (Targa Visionary 811: Athlon64 + VIA chipset,
Arima OEM:d HW also sold by eMachines and others), ACPI is broken
and hangs the x86-64 2.6.13-rc3 kernel.
During boot, ACPI reduces the screen's brightness (it's always
done this in the x86-64 kernels but not the i386 ones), so I
On Thu, 14 Jul 2005 15:23:52 -0400, Brown, Len wrote:
acpi_ec-0217 [04] acpi_ec_leave_burst_mo: ---status fail
on the console, and then the machine is hung hard.
2.6.13-rc3 x86_64 failed, but
2.6.13-rc2 x86_64 worked
And both of these revisions in the i386 kernel still work?
With the i386
Adrian Bunk wrote:
On i386, the PERFCTR option is currently available under:
Power management options (ACPI, APM)
APM (Advanced Power Management) BIOS Support
On x86_64, the PERFCTR option is currently available under:
Executable file formats / Emulation
On ppc, the
On Tue, 26 Jul 2005 20:22:58 +0200, [EMAIL PROTECTED] wrote:
2.4.31 compiled with -m486, panics on boot (486DX) and says something about
TSC requires pentium, bang.
enabling the obscure flag
[*] Unsynced TSC support
seems to fix this - the corresponding .config label name is actually *more*
On Thu, 28 Jul 2005 14:00:12 +0200, Adrian Bunk wrote:
What is the oldest gcc we want to support in kernel 2.6?
Currently, it's 2.95 .
I'd suggest raising this to 3.2 which should AFAIK not be a problem for
any distribution supporting kernel 2.6 .
Is there any good reason why we should not
This is because 2.6.13-rc2 added a code block to this function which references
hotplug-only stuff. Fixed crudely by #ifdef CONFIG_HOTPLUG around it.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux-2.6.13-rc2/drivers/pci/pci-driver.c.~1~ 2005-07-06
15:20:41.0 +0200
+++ linux
On Wed, 6 Jul 2005 16:47:28 +0300 (EEST), Tero Roponen wrote:
my computer (a ThinkPad 380XD laptop) hangs at boot in 2.6.13-rc2.
When I revert the patch below everything seems to be fine.
Same here: my Targa Visionary 811 Athlon64 laptop
hangs during boot with 2.6.13-rc2, unless I revert
the
On Fri, 8 Jul 2005 12:38:28 +0300 (EEST), Tero Roponen wrote:
On Fri, 8 Jul 2005, Ivan Kokshaysky wrote:
On Fri, Jul 08, 2005 at 10:57:56AM +0300, Tero Roponen wrote:
Thanks! Vanilla 2.6.13-rc2 with below patch applied
works perfectly!
Thanks for testing. Though, bad news are that it's
On Sat, 9 Jul 2005 01:00:54 -0700, Sheo Shanker Prasad wrote:
(1) content of /proc/mtrr :
reg00: base=0x ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x8000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc000 (3072MB), size= 128MB: write-back, count=1
reg03:
On Sat, 12 Mar 2005 21:55:49 -0800, Andrew Morton wrote:
It would be nice to start folding these patches together a bit to reduce
such problems, but that's rather non-trivial because there is no way to
simply join these patches together which maintains a sensible sequencing.
If we're going to do
On Sun, 13 Mar 2005 00:46:24 -0500, Hacksaw [EMAIL PROTECTED] wrote:
In compiling 2.4.29 I get this during the compilation of pci-pc.c:
Warning: indirect lcall without `*'
I note from looking around the net that this is an old problem, dating back
at least to 2.4.18, if not earlier.
What does
jerome lacoste writes:
I have a VIA Epia M1 board that crashes very badly (and pretty
often, especially when using DMA). I want to fix that.
Serial console + magic SysRQ didn't help so I am going the nmi
watchdog way. But in order to have nmi watchdog I need APIC, right?
The C3
jerome lacoste writes:
So if I don't have APIC, that means I cannot use nmi_watchdog to
investigate the problem, right?
Correct.
Do I have any alternative to investigate this hang or should I just
give up and smash my board?
I can't help you with that one.
-
To unsubscribe from this
Fix two array-of-incomplete-type errors from gcc4 in isicom.c.
/Mikael
--- linux-2.6.11/drivers/char/isicom.c.~1~ 2005-03-02 19:24:15.0
+0100
+++ linux-2.6.11/drivers/char/isicom.c 2005-03-15 11:37:03.0 +0100
@@ -151,9 +151,6 @@ MODULE_DEVICE_TABLE(pci, isicom_pci_tbl)
Fix
drivers/net/arcnet/arcnet.c: In function 'release_arcbuf':
drivers/net/arcnet/arcnet.c:256: warning: operation on 'i' may be undefined
drivers/net/arcnet/arcnet.c: In function 'get_arcbuf':
drivers/net/arcnet/arcnet.c:292: warning: operation on 'i' may be undefined
warnings from gcc4 in
Fix
drivers/char/generic_serial.c:38: error: static declaration of 'gs_debug'
follows non-static declaration
include/linux/generic_serial.h:94: error: previous declaration of 'gs_debug'
was here
compilation error from gcc4 in generic_serial.h.
/Mikael
---
in the kernel any more, make perfctr_info kernel-only
and remove unused fields, use explicitly-sized integers
in user-visible types.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/init.c| 22 ---
drivers/perfctr/version.h |2 -
include/linux/perfctr.h
kernel-private.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/ppc.c |8 +++-
include/asm-ppc/perfctr.h | 43 ++-
2 files changed, 21 insertions(+), 30 deletions(-)
diff -rupN linux-2.6.11-mm4/drivers/perfctr/ppc.c
linux
x86-specific cleanups for perfctr:
- x86.c: use DEFINE_SPINLOCK().
- asm-i386/perfctr.h: remove cpu_type constants and
PERFCTR_CPU_VERSION unused in the kernel, use
explicitly-sized integers in user-visible types, make
perfctr_cpu_control kernel-private.
Signed-off-by: Mikael Pettersson
Andrew Morton writes:
Martin J. Bligh [EMAIL PROTECTED] wrote:
drivers/built-in.o(.text+0x182bc): In function `.matroxfb_probe':
: undefined reference to `.mac_vmode_to_var'
make: *** [.tmp_vmlinux1] Error 1
Anyone know what that is?
Mikael Pettersson writes:
Andrew Morton writes:
Martin J. Bligh [EMAIL PROTECTED] wrote:
drivers/built-in.o(.text+0x182bc): In function `.matroxfb_probe':
: undefined reference to `.mac_vmode_to_var'
make: *** [.tmp_vmlinux1] Error 1
Anyone know what
Here is a new set of patches to allow gcc-4.0 (20050312)
to compile the 2.4.30-rc1 kernel. Changes since the previous
version of the patch set are:
- Replaced -ffreestanding with -fno-builtin-sprintf.
freestanding was used to prevent gcc from transforming some
sprintf() calls to calls to
:25: error: array type has incomplete element type
make[1]: *** [arch/ppc64/kernel/asm-offsets.s] Error 1
make: *** [arch/ppc64/kernel/asm-offsets.s] Error 2
This is an array-of-incomplete-type error.
Fix: move array decl to after the struct decl.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED
')
arch/ppc64/kernel/prom.c:1692: warning: initialization makes pointer from
integer without a cast
make[1]: *** [arch/ppc64/kernel/prom.o] Error 1
make: *** [arch/ppc64/kernel] Error 2
Fix: repair the obvious syntax error (missing =).
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux
the
condition but accidentally negated it: on PSERIES the system call will
now go to sys_ni_syscall, and on !PSERIES linking will fail.
Fix: negate the condition.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux-2.6.12-rc1-mm1/arch/ppc64/kernel/misc.S.~1~ 2005-03-21
14:48
On Tue, 22 Mar 2005 03:32:59 +1100, Anton Blanchard wrote:
When 2.6.12-rc1-mm1 is configured for a ppc64/G5, so CONFIG_PPC_PSERIES
is disabled, linking of vmlinux fails with:
arch/ppc64/kernel/built-in.o(.text+0x7de0): In function `.sys_call_table32':
: undefined reference to `.ppc_rtas'
On Sat, 19 Mar 2005 17:26:27 +0100 (MET), I wrote:
Here is a new set of patches to allow gcc-4.0 (20050312)
to compile the 2.4.30-rc1 kernel.
...
The only known problem is
that the X server segfaults during PCI probing on x86-64. I'm
currently debugging that.
Problem solved. There was a bug in
flows are backpatched properly.
This is needed for gcc-4.0.
- Eliminate power-of-two sizeof assumption in access_regs().
- Merge check_ireset() and setup_imode_start_values().
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/x86.c | 34 --
1 files
for no real benefit.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
include/linux/perfctr.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -rupN linux-2.6.12-rc1-mm1/include/linux/perfctr.h
linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
--- linux
ppc32 fix and cleanups:
- If check_ireset() fails, clear state-cstatus to undo any
settings check_control() may have left there.
- Eliminate power-of-two sizeof assumption in access_regs().
- Merge check_ireset() and setup_imode_start_values().
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED
On Wed, 23 Mar 2005 14:34:30 +1100, David Gibson wrote:
On Wed, Mar 23, 2005 at 04:00:03AM +0100, Mikael Pettersson wrote:
- linux/perfctr.h: Change value fields in register descriptors
to 64 bits. This will be needed for ppc64, and ppc32 user-space
on ppc64 kernels, and may eventually also
no initial value.
Luckily 'sys' is reassigned later before being used, making this
assignment redundant, so the fix is to simply remove it.
This problem is not present in the 2.6 kernel.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux-2.4.30-pre2/drivers/pcmcia/cistpl.c.~1
Here is a new set of patches to allow gcc-4.0 (20050226)
to compile the 2.4.30-pre2 kernel. Changes since the previous
version of the patch set are:
- Moved -Wno-pointer-sign setting from arch/{i386,ppc,x86_64}/Makefile
to the top-level Makefile. Added check_gcc definition to top Makefile
and
On Sun, 06 Mar 2005 01:53:25 +0100, Pallai Roland wrote:
I'm playing with the NMI watchdog (nmi_watchdog=1) on a reproductable
hard lockup (no keyboard, etc) but seems like it doesn't works and I
can't understand why, please explain to me the possible causes.. I
belive it should work in this
Frank Rowand writes:
Source: MontaVista Software, Inc.
Signed-off-by: Frank Rowand [EMAIL PROTECTED]
Index: linux-2.6.10/arch/ppc/platforms/prpmc800.c
===
--- linux-2.6.10.orig/arch/ppc/platforms/prpmc800.c
+++
On Thu, 10 Mar 2005 09:50:11 +0100, Mikael Starvik wrote:
+#if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR = 96)
Should be __GNUC_MINOR__
Thanks, I'll fix that.
/Mikael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Andrew,
This is the last planned major perfctr API update.
This set of patches change how control data is communicated
between user-space and the kernel. The main idea is that the
control data is partitioned into domains, and each domain is
given its own representation. The design principles
to use the virtual-to-physical map.
- Users must now format the 2-6 event selector values into the
MMCR0/MMCR1 images.
- Verify that unused/non-existent parts of MMCR images are zero.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/ppc.c | 90
.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/x86.c | 73 -
include/asm-i386/perfctr.h | 14 ++--
2 files changed, 43 insertions(+), 44 deletions(-)
diff -rupN linux-2.6.11-mm3/drivers/perfctr/x86.c
linux
- Move tsc_on/nractrs/nrictrs control fields to new struct cpu_control_header.
This depends on the physical-indexing patch for ppc32.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/ppc.c | 18 +-
include/asm-ppc/perfctr.h |6 +-
2
- Move tsc_on/nractrs/nrictrs control fields to new struct cpu_control_header.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/virtual.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -rupN linux-2.6.11-mm3.perfctr-physical-indexing/drivers/perfctr
- Move tsc_on/nractrs/nrictrs control fields to new struct cpu_control_header.
This depends on the physical-indexing patch for x86.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/x86.c | 32
include/asm-i386/perfctr.h |6
on the physical-indexing patch for ppc32, and on the
common part of the cpu_control access patch.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/ppc.c | 70 ++
include/asm-ppc/perfctr.h | 11 +++
2 files changed, 81
on the physical-indexing patch for x86, and on the
common part of the cpu_control access patch.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/x86.c | 100 +
include/asm-i386/perfctr.h | 11
2 files changed, 111
- Add declarations of common arch-specific domain numbers and
corresponding data structures to linux/perfctr.h. This just
factors out common code, it does not impose any requirements
on arch-specific code.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
include/linux/perfctr.h
On ppc32 the ATI Mach64 frame buffer references symbols on macmodes.o.
In Linus' 2.6.11 macmodes.o is automatically included, but not so in
2.6.11-mm3, causing linkage errors.
The quick-and-dirty hack below worked for me.
/Mikael
--- linux-2.6.11-mm2/drivers/video/Makefile.~1~ 2005-03-09
The ia32 perfctr syscalls were moved due to addition of ioprio
syscalls, but the ia32 emulation code in x86-64 wasn't updated.
Simple fix below.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
arch/x86_64/ia32/ia32entry.S |4 +++-
include/asm-x86_64/ia32_unistd.h |4
.
- Remove _reserved and cpu_control fields from struct vperfctr_control.
This depends on the cpu_control header and the cpu_control access patches.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
/Mikael
drivers/perfctr/virtual.c | 144 --
include
Compiling 2.6.12-rc1-mm2 on x86_64 with gcc-4.0 fails with:
arch/x86_64/kernel/vsyscall.c:193: error: syntax error before
'vsyscall_sysctl_change'
Fix: repair the syntax error
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
--- linux-2.6.12-rc1-mm2/arch/x86_64/kernel/vsyscall.c.~1
My Beige PowerMac G3 has a Mach64 GT chip. The display is an old 15 PC monitor.
In recent 2.6 kernels, the framebuffer console suffers from distortions,
where pixels in several columns around 50% and 75% into the lines (all lines)
flicker on/off all the time.
All kernels up to and including
Andrew,
This set of patches change the layout of the perfctr cpu state object.
This state is mmap()able, providing a low-overhead sampling method to
user-space. But in order to limit the number of cache lines touched
at frequent operations (context switches and explicit samplings), some
perfctr x86 mapped state cleanup:
- Swap cstatus and k1 fields in struct perfctr_cpu_state. Move
now contiguous user-visible fields to struct perfctr_cpu_state_user.
Hide kernel-private stuff. Inline now obsolete k1 struct. Cleanups.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED
perfctr ppc32 mapped state cleanup:
- Swap cstatus and k1 fields in struct perfctr_cpu_state. Move
now contiguous user-visible fields to struct perfctr_cpu_state_user.
Hide kernel-private stuff. Inline now obsolete k1 struct. Cleanups.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED
perfctr common updates for mapped state cleanup:
- Update virtual.c for perfctr_cpu_state layout change.
- Add perfctr sysfs attribute providing user-space with the offset
in an mmap()ed perfctr object to the user-visible state.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers
Paul Jackson writes:
Yup - kills my x86_64 too. I can't stay up for half a minute.
...
My mainboard is an MSI K8N Neo2 Platinum.
I've tested both versions of the test program on two Athlon64 boxes,
and neither has had any problems with them.
My two machines are both VIA K8T800-based (a
.
ppc64 perfctr driver from David Gibson [EMAIL PROTECTED]:
- ppc64 arch hooks: Kconfig, syscalls numbers and tables, task struct,
and process management ops (switch_to, exit, fork)
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
arch/ppc64/Kconfig|1 +
arch/ppc64/kernel
and resume
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/Makefile |5 -
drivers/perfctr/version.h |2 +-
drivers/perfctr/virtual.c | 11 ++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff -rupN linux-2.6.12-rc1-mm4/drivers/perfctr/Makefile
linux
ppc64 perfctr driver from David Gibson [EMAIL PROTECTED]:
- ppc64 perfctr driver core
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
drivers/perfctr/ppc64.c | 743 ++
drivers/perfctr/ppc64_tests.c | 322 ++
drivers/perfctr
Andrew Morton writes:
David Gibson [EMAIL PROTECTED] wrote:
On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
Mikael Pettersson [EMAIL PROTECTED] wrote:
Here's a 3-part patch kit which adds a ppc64 driver to perfctr,
written by David Gibson [EMAIL PROTECTED
On Fri, 1 Apr 2005 18:24:00 -0500 (EST), Christopher Allen Wing wrote:
I also see messages from the kernel like:
APIC error on CPU0: 00(40)
APIC error on CPU0: 40(40)
so I'd guess that something is wrong in the way that the machine is set
up. Perhaps the BIOS or ACPI tables are
On Sat, 2 Apr 2005 13:19:44 -0500 (EST), Christopher Allen Wing wrote:
On Sat, 2 Apr 2005, Mikael Pettersson wrote:
APIC error on CPU0: 00(40)
APIC error on CPU0: 40(40)
Those are received illegal vector errors, and they
typically indicate hardware flakiness or BIOS issues.
Could
Don Guy writes:
PROBLEM:
Attempts to compile v2.4.29 with PCI support disabled result in the
following errors:
drivers/char/char.o: In function `siig10x_init_fn':
drivers/char/char.o(.text.init+0x12cd): undefined reference to
`pci_siig10x_fn'
drivers/char/char.o: In function
101 - 200 of 874 matches
Mail list logo
